WordPress on Blog do Aquasp

7 coisas que você deve fazer depois de instalar o WordPress

Tue, 09 Dec 2025 01:45:24 +0000

Introdução

Vai começar um site WordPress do zero em 2026? Seja um blog, uma loja virtual ou um portfólio, estes ajustes vão turbinar a velocidade, reforçar a segurança e garantir um desempenho lisinho desde o primeiro dia.

Sem ferramentas pagas — só plugins gratuitos e configurações rápidas. Vamos lá!

1. Redimensione e comprima imagens automaticamente no upload

Imagens são a principal assassina de banda. Não suba uma foto de 10 MB torcendo para dar certo — automatize a compressão para manter seu site enxuto.

Plugin recomendado: Resize Image After Upload (gratuito, mais de 90 mil instalações ativas, nota 4,8/5)

Instale e ative logo de cara.
Defina a largura/altura máxima (por exemplo, 1920px de largura) e o nível de compressão (a qualidade JPEG padrão de 82% é boa).
Ele redimensiona JPEG/PNG/GIF automaticamente no upload, corta o tamanho dos arquivos em 50–80% e melhora o SEO com carregamentos mais rápidos.

Dica de mestre: para otimizar em massa as imagens que já existem, use junto com o Smush (o plano gratuito processa 50 imagens/mês).

Resultado: páginas carregam 2–3x mais rápido, menos carga no servidor e o Google mais feliz com o seu site.

2. Corte o excesso desnecessário

O WordPress vem com “extras” de que você talvez não precise — como blocos do Gutenberg, XML-RPC ou scripts de emoji. Corte a gordura para ter um núcleo mais leve.

Plugin recomendado: Unbloater (gratuito, mais de 10 mil instalações ativas, nota 5/5)

Painel simples em Configurações > Unbloater.
Opções recomendadas:
- Backend: desative as atualizações automáticas (se você faz isso manualmente), limite as revisões de posts a 3, esconda os avisos de atualização para quem não é administrador, desative o XML-RPC.
- Frontend: remova os manifestos RSD/WLW, os links curtos, os links de feed, o jQuery Migrate e os scripts de emoji.
- Editor de blocos: desative totalmente o Gutenberg (se você usa o Editor Clássico) ou remova os blocos que não usa.
- Extras: bloqueie o DNS prefetch para o WordPress.org e remova a meta tag generator.

Tudo é reversível — desative se aparecer algum problema. Isso reduz as consultas ao banco de dados e o excesso de JS/CSS em 20–30%.

3. Dome a Heartbeat API

A Heartbeat API do WordPress faz requisições ao seu servidor a cada 15–60 segundos para salvamento automático, presença de usuários etc. Ótimo para colaboração, mas faz a CPU disparar em hospedagem compartilhada.

Plugin recomendado: Heartbeat Control (gratuito, mais de 90 mil instalações ativas, nota 4,1/5)

Vá em Configurações > Heartbeat Control.
Defina os intervalos: 60 segundos (frontend), 120 segundos (painel/editor).
Ou desative totalmente no frontend se você não precisa de pré-visualizações ao vivo.

O Unbloater também resolve isso. Espere uma economia de 10–20% de CPU em sessões ociosas.

4. Limite as revisões de posts

Por padrão, o WordPress salva 25 revisões por post — inchando seu banco de dados com o tempo (por exemplo, um site com 1.000 posts = mais de 25 mil registros).

Adicione ao wp-config.php (antes de “That’s all, stop editing!”):

// Limit to 3 revisions (or false to disable)
define('WP_POST_REVISIONS', 3);

O Unbloater tem uma opção para isso. Limpe as revisões antigas com o WP-Optimize (gratuito).

Resultado: banco de dados menor = consultas e backups mais rápidos.

5. Desative o XML-RPC (a menos que você precise)

O XML-RPC permite publicar remotamente e usar apps, mas é um ímã de ataques de força bruta (a maioria dos bots mira nele).

Se você usa o Jetpack/apps de celular: mantenha, mas libere só o seu IP.
Caso contrário: bloqueie via .htaccess (Apache/LiteSpeed):

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
# Allow from YOUR.IP.ADDRESS (uncomment if needed)
</Files>

O Unbloater ou o Loginizer (gratuito, mais de 1 milhão de instalações) também podem desativá-lo.

6. Proteja os logins com limite de tentativas

Os bots martelam o /wp-login.php 24/7. Limite as tentativas para barrar os ataques de força bruta de vez.

Melhor escolha: Limit Login Attempts Reloaded (gratuito, mais de 2 milhões de instalações, nota 4,9/5)

Padrão: 3 tentativas falhas → bloqueio de 15 min (que sobe para 24h).
Cobre o wp-admin, o XML-RPC, o WooCommerce e logins personalizados.
Inclui logs + notificações.

Alternativa: BruteGuard (gratuito, bloqueio de botnets na nuvem através de uma rede compartilhada).

O Loginizer (mais de 1 milhão de instalações) adiciona 2FA + reCAPTCHA como camadas extras.

Teste: tente logins errados — você verá os bloqueios na hora.

7. Avalie os plugins antes de instalar

Nem todos os plugins são iguais — alguns incham o seu site com mais de 1 MB de uso de RAM ou com erros de JS. Sempre confira:

WP Hive: extensão do Chrome + site com testes automatizados (memória, impacto na velocidade da página, compatibilidade com PHP/WordPress, espaço no banco de dados). Por exemplo, Yoast SEO 20.1: +0,1 s no carregamento, 1 MB de RAM (mais pesado que a média).
PluginTests.com: testes básicos de compatibilidade/fumaça para 98% dos plugins do WP.org (erros de ativação, quebras óbvias).

Exemplo rápido (benchmarks de 2025):

Yoast SEO: sólido, mas pesado (+0,1 s no carregamento, 1 MB de RAM). Ótimo para legibilidade.
Rank Math SEO: mais leve (sem impacto no carregamento, <250 KB de RAM), mais recursos gratuitos. Muitas vezes 4x mais rápido nos testes.

Prefira as opções leves — só adicione as “pesadas” se forem essenciais.

Resumindo

Aplique isso hoje, e o seu site vai estrear 2–3x mais rápido, mais seguro e preparado para o futuro. Tempo total: ~30 minutos. Sem desculpas!

Obrigado pela leitura! 🚀

Como remover os limites de upload do All In One WP Migration

Tue, 09 Dec 2025 00:25:04 +0000

Introdução

Infelizmente, muitas hospedagens impõem limites de upload bem baixos (às vezes só 2–50 MB), e a Unlimited Extension oficial custa US$ 69.

Se você está nessa situação e precisa de um jeito gratuito de enviar backups enormes (10 GB, 40 GB ou mais), este truque simples vai ajudar.

A solução: use o plugin “Big File Uploads”

A versão gratuita do All-in-One WP Migration não limita os uploads artificialmente — ela só respeita o limite que a sua hospedagem ou servidor impõe. A Unlimited Extension paga funciona dividindo o arquivo .wpress em pedaços menores durante o upload.

A boa notícia: existe um plugin totalmente gratuito que faz exatamente o mesmo truque de dividir em pedaços!

Guia passo a passo

Instale e ative o plugin chamado Big File Uploads → Link direto: https://wordpress.org/plugins/tuxedo-big-file-uploads/
Depois de ativar, vá em: Configurações → Big File Uploads (ou encontre na página de Plugins → link “Configurações” embaixo do nome do plugin)
Você verá o tamanho máximo de upload atual (no começo, ele será igual ao limite padrão da sua hospedagem).
Mude para o valor que quiser:

1 GB = 1024 MB
10 GB = 10240 MB
40 GB = 40960 MB (Basta digitar o número em megabytes — não precisa colocar “MB” nem “GB”)

Clique em Salvar alterações

Pronto! O novo limite vale na hora.

Agora, quando você voltar em All-in-One WP Migration → Importar, o tamanho máximo de arquivo vai mostrar o novo valor (até 40 GB ou mais funciona perfeitamente).

Conclusão

Isto não é um ataque à ServMask — eles criaram um plugin incrível e merecem todo o apoio. Se você puder pagar, compre a Unlimited Extension oficial.

Mas, se o orçamento estiver apertado e você só precisa migrar ou restaurar um site enorme uma ou duas vezes, o plugin Big File Uploads é uma alternativa 100% gratuita e confiável, que funciona perfeitamente com a versão gratuita do All-in-One WP Migration.

Obrigado pela leitura! 🙂

Como instalar o WordPress em LEMP com Redis e WP-CLI no Debian 11

Mon, 08 Dec 2025 23:47:36 +0000

Introdução

Este é o jeito mais rápido, mais seguro e que mais economiza recursos para hospedar o WordPress por conta própria em 2025. Vamos usar uma stack LEMP de verdade (Linux + Nginx + MySQL/MariaDB + PHP-FPM) com isolamento de PHP por site, cache de objetos com Redis, SSL automático e WP-CLI — tudo ajustado para velocidade e segurança.

Vamos lá.

Passo 0: Proteja e atualize sua VPS

(Se ainda não fez isso, siga primeiro um guia de proteção de VPS — só chaves SSH, firewall, fail2ban etc.)

apt update && apt upgrade -y
apt autoremove --purge
reboot

Passo 1: Instale a stack principal

# Nginx
apt install nginx -y
systemctl enable nginx

# MariaDB (better than MySQL on Debian)
apt install mariadb-server -y
systemctl enable mariadb

# PHP 8.3 + all needed extensions (using ondrej/sury repo)
apt install ca-certificates apt-transport-https lsb-release -y
wget -qO- https://packages.sury.org/php/apt.gpg | gpg --dearmor > /usr/share/keyrings/sury-php.gpg
echo "deb [signed-by=/usr/share/keyrings/sury-php.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/sury-php.list
apt update
apt install php8.3-fpm php8.3-mysql php8.3-curl php8.3-gd php8.3-mbstring php8.3-xml php8.3-zip php8.3-intl php8.3-imagick php8.3-redis -y
systemctl enable php8.3-fpm

# Redis
curl -fsSL https://packages.redis.io/gpg | gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" > /etc/apt/sources.list.d/redis.list
apt update && apt install redis-server -y
systemctl enable redis-server

# Certbot + WP-CLI
apt install python3-certbot-nginx -y
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar && mv wp-cli.phar /usr/local/bin/wp

Passo 2: Proteja o MariaDB e crie o banco de dados

mysql_secure_installation

mysql -u root -p
CREATE DATABASE wp_yoursite;
CREATE USER 'wp_yoursite'@'localhost' IDENTIFIED BY 'strongpassword';
GRANT ALL ON wp_yoursite.* TO 'wp_yoursite'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Passo 3: Isole o PHP-FPM por site (segurança + estabilidade)

cd /etc/php/8.3/fpm/pool.d/
cp www.conf yoursite.conf
nano yoursite.conf

Substitua:

[www] → [yoursite]
user = www-data → user = yoursiteuser (vamos criar esse usuário daqui a pouco)
group = www-data → group = yoursiteuser
listen = /run/php/php8.3-fpm.sock → listen = /run/php/php8.3-fpm-yoursite.sock
Mude o gerenciador de processos de dynamic → ondemand (economiza RAM)

systemctl restart php8.3-fpm

(Vai falhar até o usuário existir — tudo bem.)

Passo 4: Otimize o PHP e ative o OPcache

sed -i "s/memory_limit = .*/memory_limit = 1024M/" /etc/php/8.3/fpm/php.ini
sed -i "s/upload_max_filesize = .*/upload_max_filesize = 10240M/" /etc/php/8.3/fpm/php.ini
sed -i "s/post_max_size = .*/post_max_size = 10240M/" /etc/php/8.3/fpm/php.ini
sed -i "s/max_execution_time = .*/max_execution_time = 600/" /etc/php/8.3/fpm/php.ini
sed -i "s/;opcache.enable=1/opcache.enable=1/" /etc/php/8.3/fpm/php.ini
sed -i "s/;opcache.memory_consumption=.*/opcache.memory_consumption=512/" /etc/php/8.3/fpm/php.ini
sed -i "s/;opcache.max_accelerated_files=.*/opcache.max_accelerated_files=20000/" /etc/php/8.3/fpm/php.ini
sed -i "s/;cgi.fix_pathinfo=1/cgi.fix_pathinfo=0/" /etc/php/8.3/fpm/php.ini

Passo 5: Crie o usuário do sistema e o diretório do site

adduser yoursiteuser --shell /bin/bash
su yoursiteuser
mkdir ~/public_html && cd ~/public_html
echo "cd ~/public_html" >> ~/.bashrc
exit

Passo 6: Configuração do Nginx (rápida e segura)

nano /etc/nginx/sites-available/yoursite.conf

upstream php-yoursite {
 server unix:/run/php/php8.3-fpm-yoursite.sock;
}

server {
 listen 80;
 listen [::]:80;
 server_name yourdomain.com www.yourdomain.com;
 root /home/yoursiteuser/public_html;
 index index.php index.html;

 client_max_body_size 10G;

 location / {
 try_files $uri $uri/ /index.php?$args;
 }

 location ~ \.php$ {
 include fastcgi_params;
 fastcgi_pass php-yoursite;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 }

 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff2?|ttf|eot)$ {
 expires max;
 log_not_found off;
 }
}

ln -s /etc/nginx/sites-available/yoursite.conf /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

Passo 7: Instale o WordPress via WP-CLI (como o usuário do site)

su yoursiteuser
cd ~/public_html

wp core download
wp config create --dbname=wp_yoursite --dbuser=wp_yoursite --dbpass='strongpassword' --locale=en_US
wp core install --url=https://yourdomain.com --title="Your Site" --admin_user=admin --admin_password='strongpass' --admin_email=you@domain.com

Passo 8: SSL com Let’s Encrypt (renovação automática)

certbot --nginx -d yourdomain.com -d www.yourdomain.com
# Choose redirect to HTTPS when asked

Adicione o cron de renovação automática:

crontab -e
# Add:
0 0 * * 0 certbot renew --quiet

Passo 9: Ative o cache de objetos com Redis

# As root
usermod -aG redis yoursiteuser
chmod 770 /var/run/redis/redis-server.sock

# Optimize Redis config
sed -i 's/port 6379/port 0/' /etc/redis/redis.conf
sed -i 's|# unixsocket /run/redis/redis-server.sock|unixsocket /var/run/redis/redis-server.sock|' /etc/redis/redis.conf
sed -i 's/# unixsocketperm 700/unixsocketperm 770/' /etc/redis/redis.conf
sed -i 's/# maxmemory .*/maxmemory 1024mb/' /etc/redis/redis.conf
systemctl restart redis-server

# As yoursiteuser
cd ~/public_html
wp plugin install redis-cache --activate
wp config set WP_REDIS_SCHEME unix
wp config set WP_REDIS_PATH '/var/run/redis/redis-server.sock'
wp redis enable

Pronto!

Agora você tem:

Pool do PHP-FPM totalmente isolado (1 usuário = 1 site = nenhum estrago entre sites)
Cache de objetos com Redis via socket Unix
OPcache + limites de upload enormes
Renovação automática do SSL
O roteamento mais rápido possível no Nginx
WP-CLI pronto para usar

O seu wp-admin vai parecer instantâneo, e o site vai aguentar o tráfego como um campeão — mesmo numa VPS de US$ 5/mês.

Próximos passos:

Instale um plugin de cache de página (qualquer um gratuito serve)
Configure o Cloudflare (opcional, mas recomendado)
Backups regulares

Aproveite o seu WordPress privado e ultrarrápido!

Obrigado pela leitura! 😊

Cache de página, cache de objetos e cache de CDN – entendendo todos os tipos de cache

Mon, 08 Dec 2025 23:13:04 +0000

Entendendo os diferentes tipos de cache (principalmente para escalar sites com CMS)

Se você já se perguntou o que as pessoas querem dizer quando falam em “cache de página”, “cache de objetos” ou “cache de CDN”, este post é para você. Essas são as três principais camadas de cache, que fazem uma diferença enorme na hora de escalar o WordPress, o WooCommerce ou qualquer outro CMS.

O que é cache de página?

O cache de página (também chamado de cache de página inteira ou cache de HTML) é exatamente o que o nome diz: a página HTML inteira já renderizada é salva como um arquivo estático.

Em um site realmente estático (HTML + CSS + JS puros), não há necessidade de cache de página, porque todos os arquivos já são estáticos. Mas, com um CMS como o WordPress, cada requisição normalmente dispara PHP → tema → plugins → consultas ao banco de dados → saída em HTML. Esse processo consome CPU e leva tempo.

O cache de página inteira pula tudo isso. O primeiro visitante dispara o processo completo de PHP+MySQL, o HTML resultante é salvo, e todos os visitantes seguintes recebem na hora o HTML estático já gerado — sem PHP, sem consultas ao banco de dados, com quase zero de CPU.

Resultado: carga no servidor de 10 a 100× menor e páginas carregando muito mais rápido.

O que é cache de objetos?

O cache de objetos guarda os resultados de consultas caras ao banco de dados (ou de qualquer processamento lento) em uma memória rápida (geralmente Redis ou Memcached).

Pense nele como um intermediário superrápido entre o seu código PHP e o banco de dados.

Exemplo com o WordPress:

O WordPress precisa da lista de posts publicados → ele pergunta ao MySQL.
Primeira requisição: o MySQL faz o trabalho e devolve os dados, e o cache de objetos os salva na RAM.
As próximas 10 000 requisições: o cache de objetos devolve na hora os mesmos dados direto da memória → o MySQL dorme em paz.

O cache de objetos é esperto — ele se invalida sozinho quando os dados mudam (por exemplo, quando você publica um post novo).

Por que você ainda precisa dele, mesmo com o cache de página inteira:

Usuários logados (incluindo o painel do WordPress, as páginas de conta do WooCommerce etc.) não podem ter a página inteira em cache para todo mundo.
Essas páginas ainda passam pelo PHP e pelo MySQL → o cache de objetos as deixa toleráveis, em vez de dolorosamente lentas.

Cache de objetos + cache de página inteira juntos formam a combinação clássica para tráfego alto.

O que é cache de CDN?

Uma CDN (Content Delivery Network, ou rede de distribuição de conteúdo) copia seus arquivos estáticos (CSS, JS, imagens, fontes) — e, se você quiser, também suas páginas HTML inteiras — para servidores “PoP” espalhados pelo mundo.

Sem CDN: um visitante no Japão baixa tudo do seu servidor de origem que fica, digamos, no Brasil → latência alta.

Com CDN:

Os arquivos estáticos são entregues pelo PoP mais próximo (muitas vezes a menos de 30 ms).
Se você também ativar o cache de página inteira na CDN, a página HTML inteira também é entregue por esse PoP próximo → o servidor de origem nem é tocado nas páginas em cache.

É por isso que alguns sites carregam instantaneamente de qualquer lugar do planeta.

Exemplo real: o fluxo de tráfego do WordPress

Sem nenhum cache

Visitante → servidor web → PHP → dezenas de arquivos de plugins → consultas ao MySQL → HTML → visitante → CPU alta, TTFB lento, bate fácil nos limites de recursos.

Só com cache de página inteira

Primeiro visitante: o mesmo caminho lento de cima (mas o HTML é salvo). Os próximos 10 000 visitantes: o servidor web entrega na hora o HTML pronto → quase zero de CPU.

Só com cache de objetos

Toda requisição ainda roda PHP + plugins, mas as consultas ao banco são respondidas pela RAM em vez do disco → mais rápido que sem cache, mas ainda pesado.

Com cache de página inteira + cache de objetos

Visitantes anônimos → HTML estático (superrápido, quase sem carga)
Usuários logados → o PHP roda, mas o cache de objetos deixa as consultas ao banco instantâneas → carga administrável

Adicione por cima uma CDN com cache de página inteira

Agora até o HTML estático é entregue a partir de pontos de borda no mundo todo. O seu servidor de origem pode basicamente tirar um cochilo até que algo realmente precise de PHP (por exemplo, envio de formulários, invalidação de cache).

Conclusão

Aqui está a hierarquia, do mais impactante para o menos (para a maioria dos sites com CMS):

Cache de página inteira na CDN → o mais rápido para os visitantes, escala para milhões de acessos com quase nenhuma carga na origem.
Cache de página inteira na origem → ainda é um ganho enorme se você não puder fazer cache na CDN.
Cache de objetos (Redis/Memcached) → obrigatório para usuários logados, WooCommerce, painéis etc.
Todo o resto (OPcache, cache do navegador etc.) → bom de ter, geralmente já vem ativado por padrão.

Se você for fazer uma coisa só: ative um cache de página inteira decente (e leve-o para a sua CDN, se possível). Se você tem tráfego de usuários logados ou uma loja: adicione o cache de objetos com Redis/Memcached.

É isso — as três camadas de cache que movem basicamente todo site WordPress com tráfego alto no planeta.

Espero que isso tenha esclarecido as coisas!

Obrigado pela leitura! 😊