Por que seu site WordPress é tão lento e um guia útil para acelerar as coisas

Eu queria começar este post informando que este NÃO é apenas mais um artigo genérico “Como acelerar o WordPress”.

Não vou regurgitar nada que já possa ser encontrado na web. Não vou dizer que você deve instalar um plugin de cache, habilitar a compressão, minificar seu css / js etc….

Afinal, você já deve saber fazer essas coisas. E se você não fizer isso, você pode encontrar essas informações genéricas em centenas de outros blogs.

Em vez disso, este artigo contém tudo personalizado / semipersonalizado que implementei no mês passado ou mais para acelerar meu próprio blog WordPress e basicamente impedir que acessos desonestos derrubem meu servidor.

E a razão de ser “pouco conhecido” é porque as técnicas que estou prestes a descrever serão muito específicas para o seu próprio blog, dependendo dos padrões de tráfego que você está vendo.

Nota: Se você tem um blog lento e realmente não quer lidar com nenhum dos aspectos técnicos de acelerar um site, você provavelmente deve se inscrever em um serviço como o WP Engine .

Esses caras são especializados em hospedagem WordPress e farão com que seu blog seja executado o mais rápido possível. Mas, naturalmente, isso tem um preço. Você deve dar uma olhada se este post passar por cima da sua cabeça :)

De qualquer forma, antes que eu possa explicar como e por que fiz o que fiz no meu blog, você precisa entender alguns conceitos fundamentais sobre WordPress e cache que descreverei a seguir.

Alguns fatos interessantes do WordPress

Digamos que você já tenha seguido todas as diretrizes sobre como acelerar o WordPress. Seu blog parece animado. Webpagetest.org informa que seu blog é rápido como o inferno. Está tudo bem certo? Não necessariamente .

Eu costumava me sentir exatamente da mesma maneira em relação ao meu blog. Afinal, eu sigo a maioria dos protocolos de aceleração padrão. Eu executo poucos plug-ins e meu blog parece muito rápido sob uso normal da perspectiva de um leitor humano (as redes de anúncios são o que tornam meu blog mais lento, então eu carrego os anúncios por último).

Mas então comecei a analisar meus gráficos de uso da CPU e freqüentemente percebi períodos de alta carga do servidor, apesar dos níveis de tráfego baixos a moderados. Ocasionalmente, meu servidor ficava inutilizável ou não respondia por longos períodos.

Observe, a única razão pela qual comecei a prestar atenção a essas estatísticas foi porque há um tempo eu estava executando minha loja online no mesmo servidor do meu blog. E, periodicamente, eu fazia os clientes reclamarem que a loja estava extremamente lenta. Quando eu finalmente fiz algumas pesquisas, descobri que meu blog WordPress otimizado e totalmente armazenado em cache estava deixando meu servidor de joelhos!

Moral da história? Só porque um teste de velocidade indica que seu blog é rápido, não significa necessariamente que está tudo bem.

Aqui estão alguns fatos engraçados sobre WordPress e plug-ins de cache como WP Super Cache e W3 Total Cache que você deve conhecer.

• As respostas do WordPress 404 são lentas . Sempre que seu blog recebe um acesso a uma página que não existe, seu servidor pobre tem que carregar o WordPress, executar um monte de código php, fazer um monte de consultas MySQL e, em seguida, cuspir sua página personalizada do WordPress 404. Esta é uma tarefa que consome muitos recursos e o armazenamento em cache não vai ajudar.
• Seu plug-in de cache não funciona muito bem quando há parâmetros GET na URL. Por exemplo, eu costumava notar que meu blog ficava lento para um rastreamento sempre que eu enviava uma mensagem para minha lista de e-mail. Em teoria, com o cache de arquivo estático, meu servidor deve ser quase invencível.

  Mas porque Aweber insere parâmetros de rastreamento na URL, nenhum dos meus arquivos são super cacheados. Como resultado, o WordPress precisa gerar um novo arquivo de cache (embora já exista), compactá-lo e enviá-lo todas as vezes. A pior parte é que esses arquivos em cache são usados ​​apenas uma vez, o que os torna um desperdício de recursos do servidor

• Os acessos desonestos são lentos. Como os acessos desonestos exigem que o WordPress seja carregado por padrão, um bot ou rastreador mal-intencionado que decide enviar spam para seu site com solicitações incorretas pode derrubar seu blog com bastante facilidade.
• Seu plug-in de cache pode ter um bug ou incompatibilidade com a forma como você configurou seu blog . Por exemplo, por 3 anos eu pensei que o WP Super Cache estava fazendo a coisa certa até que comecei a assistir meus logs e notei um bug no código. Por causa da maneira como eu configurei as coisas, tive um problema em que o WP Super Cache estava limpando meu cache com muita frequência.

O ponto principal que estou tentando fazer com os pontos acima é que sempre que um acesso fora do padrão acontece no seu blog, ele usa muitos recursos do servidor, não importa como você tenha configurado o seu blog WordPress. E são esses tipos de acesso que deixarão seu servidor de joelhos, não o tráfego regular.

Detectando acessos invasores

A primeira chave para otimizar seu blog WordPress é entender os padrões de tráfego que seu blog recebe. Estou disposto a apostar que 99% dos usuários do WordPress não fazem isso. Em vez disso, eles seguem cegamente e instalam vários plug-ins e presumem que tudo está funcionando corretamente. Não se sinta mal, eu era do mesmo jeito.

Portanto, o primeiro passo é descobrir o que diabos está acontecendo. Existem muitas maneiras de fazer isso, mas a maneira mais fácil é usar o modo de depuração que o plugin WP SuperCache fornece. O que esse modo faz? Basicamente, toda vez que um acesso for gerenciado diretamente pelo WordPress (uso intensivo de recursos), ele aparecerá no log do WP Super Cache. Veja como você ativa esse modo.

Na guia de depuração de seu plug-in WP Super Cache, basta clicar na caixa de seleção “Depuração habilitada” e pronto!

Uma vez que o registro está habilitado, você pode clicar no link “arquivo de log” que o levará a um arquivo detalhando seu tráfego do WordPress. Será semelhante ao texto abaixo.

15:03:46 /?utm_source=fwisp.com supercache dir:
15:03:46 /?utm_source=fwisp.com No wp-cache file exists. Must generate a new one.
15:03:46 /?utm_source=fwisp.com In WP Cache Phase 2
15:03:46 /?utm_source=fwisp.com Setting up WordPress actions
15:03:46 /?utm_source=fwisp.com Supercache caching disabled. Only using wp-cache. Non empty GET request.
15:03:46 /?utm_source=fwisp.com USER AGENT (Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)) rejected. Not Caching

O importante a notar é que sempre que você vir algo neste log, é uma coisa ruim, porque significa que o WordPress tem que funcionar. E como o WordPress é um consumidor de recursos, você quer que ele faça o mínimo de trabalho possível.

O que procurar nos registros

Os logs do WP Super Cache são ótimos porque informam tudo o que está acontecendo. Mas a grande quantidade de informações pode ser esmagadora, a menos que você saiba o que procurar. Aqui está o que você deve prestar atenção nesses logs.

• Erros 404 - Basicamente, são acessos a páginas que não existem em seu blog. Cada acesso 404 gerenciado pelo WordPress consome muitos recursos do servidor, então você deseja eliminá-los pela raiz, se possível
• Acessos únicos - são solicitações que fazem com que seu servidor armazene em cache e comprima páginas que serão usadas apenas uma vez (mais sobre isso depois)
• Strange Bursts Of Traffic - Geralmente são bots que martelam seu blog de uma só vez
• Comportamento estranho de cache - seus caches estão sendo liberados quando deveriam? Tudo está sendo armazenado em cache adequadamente em todas as circunstâncias?

Depois de manter um registro do tráfego do meu blog por um período de 2 semanas, descobri muitas ineficiências que descreverei a seguir.

Os bots estavam martelando meus arquivos

A primeira coisa que fiz foi olhar os logs do meu servidor para verificar os períodos de alta carga da CPU. Em seguida, analisei meus logs de supercache durante esses mesmos períodos para ver se havia algum negócio engraçado acontecendo. Acontece que uma vez a cada dois dias ou assim, um grupo de bots vinha e martelava todas as páginas de arquivo do meu blog ao mesmo tempo!

Como essas páginas de arquivo não são armazenadas em cache por padrão, vários acessos simultâneos foram suficientes para aumentar a carga do meu servidor e tornar as coisas extremamente lentas. E, ocasionalmente, até fazia meu servidor travar.

Então, examinei mais de perto minha saída HTML e percebi que tinha vários links de arquivo como parte do cabeçalho do WordPress. Portanto, bots e outros rastreadores da web chegariam e tentariam navegar nos arquivos.

Depois de uma grande pesquisa no Google, descobri que alguns outros webmasters estavam tendo problemas semelhantes.

Quando vemos problemas de carregamento em seu site muitas vezes, há um grande número de acessos para IPs de servidor proxy e a teoria é que esses proxies estão armazenando seu site em cache e acessando todos os links de arquivo. Muitos dos IPs que vemos quando seu site está causando problemas de carregamento são IPs corporativos, educacionais e de proxy governamental / militar que parecem pré-buscar conteúdo quando alguém acessa um site.

Solução: verifique se você possui a instrução php “wp_get_archives” no código do cabeçalho do seu blog e remova-a. Depois de excluir este pequeno trecho, todos os meus acessos ao arquivo desapareceram.

Os bots estavam acessando arquivos inexistentes

A segunda coisa importante que notei foi que havia um monte de bots que estavam acessando arquivos no meu servidor que não existiam. O problema é que cada vez que ocorre um acesso a um arquivo, seu servidor tem que carregar o WordPress, executar um monte de código PHP e então emitir uma página 404.

A solução para este problema é editar o arquivo .htaccess (Google isto se você não souber o que é) e adicionar as seguintes linhas.

RewriteCond% {REQUEST_FILENAME}! -F
RewriteCond% {REQUEST_FILENAME}! -D
RewriteCond% {REQUEST_URI}! (Robôs \ .txt | mapa do site \ .xml (\. Gz)?)
RewriteCond% {REQUEST_FILENAME} \. (Css | js | html | htm | rtf | rtx | svg
| svgz | txt | xsd | xsl | xml | asf | asx | cera | wmv | wmx | avi | bmp | classe | divx | doc
| docx | exe | gif | gz | gzip | ico | jpg | jpeg | jpe | mdb | mid | midi | mov | qt | mp3 |
m4a | mp4 | m4v | mpeg | mpg | mpe | mpp | odb | odc | odf | odg | odp | ods | odt | ogg | pdf
| png | pot | pps | ppt | pptx | ra | ram | rar | swf | tar | tif | tiff | wav | wma | wri |
xla | xls | xlsx | xlt | xlw | zip) $ [NC]
RewriteRule. * - [L]

Uma vez que essas linhas são inseridas em seu arquivo .htaccess, seu servidor web irá primeiro verificar se um arquivo existe. Caso contrário, ele emitirá uma resposta 404 SEM carregar o WordPress.

Os bots estavam acessando URLs que não existiam

O que é lamentável sobre a forma como o WordPress é escrito é que se houver um acesso a um artigo que não existe em seu banco de dados, seu servidor terá que carregar o WordPress, executar um monte de código PHP e fazer várias pesquisas MySQL antes de emitir um Resposta 404.

Se você olhar seus registros com atenção, provavelmente notará certos padrões de acesso que pode excluir antes mesmo de chegarem ao WordPress.

Por exemplo, percebi que vários bots estavam acessando meu site com o URL www.mywifequitherjob.com/some-article/www.facebook.com/like.php/… . E a cada vez, meu servidor carregava o WordPress e emitia uma resposta 404.

Então, em vez de fazer com que o WordPress lide com essas solicitações, adicionei as seguintes linhas ao meu arquivo .htaccess

RewriteCond% {REQUEST_FILENAME}! -F
RewriteCond% {REQUEST_FILENAME}! -D
RewriteCond% {REQUEST_URI} www \ .facebook \ .com / plugins [NC]
RewriteRule. * 404.html [L, R = 404]

Nas linhas acima, estou fazendo meu servidor procurar “www.facebook.com/plugins” na URL e imediatamente emitindo uma resposta 404 sem carregar o WordPress. Ao examinar seus registros, você encontrará muitos acessos não autorizados, como o que descrevi acima. Escreva uma regra .htaccess para cada um e esses acessos não carregarão mais em seu servidor.

Os bots estavam martelando meus links de comentários

Lembra quando eu disse que URLs com parâmetros GET são tratados de forma diferente por seu plug-in de cache? Descobri que havia uma tonelada de bots martelando meus artigos com o parâmetro “responder ao comentário” definido.

Quando isso acontece (dependendo das configurações de cache), o wordpress é carregado e um arquivo em cache / zip é servido, embora provavelmente nunca seja acessado novamente. Isso é um desperdício de recursos.

Exemplo retirado do meu registro
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 No wp-cache file exists. Must generate a new one.
12:01:11 /how-to-get-more-facebook-fans-with-a-facebook-reveal-tab-or-fan-gate/?replytocom=5972 Gzipping buffer.

A solução é redirecionar todos os bots e crawlers com esses parâmetros GET para a página principal do artigo. Aqui está o código que adicionei ao meu arquivo .htaccess.

RewriteCond% {QUERY_STRING} replytocom
RewriteCond% {HTTP_USER_AGENT} ^ (. *) (Bot | crawl | spider | slurp) [NC]
RewriteRule. * Https: //mywifequitherjob.com% {REQUEST_URI}? [EU]

Este código procura o parâmetro GET “replytocom” e então remove este parâmetro da URL final antes de apresentar o acesso ao WordPress.

Os rastreadores estavam acessando as postagens sem uma barra final

Não sei por que esse é o caso, mas percebi um monte de webcrawlers que pareciam estar legitimamente tentando acessar os artigos do meu blog sem uma barra à direita na URL.

Como você pode ou não saber, um URL escrito como http://yourblog.com/article/ é diferente de um URL escrito como http://yourblog.com/article .

Como resultado, quando uma URL sem uma barra final é encontrada, o WordPress tem que intervir, executar um monte de código PHP e então emitir um redirecionamento 301 para o artigo com a barra final. Para tirar a imagem do WordPress, você pode simplesmente inserir a seguinte regra em seu arquivo .htaccess.

# Adicionar barra final
RewriteCond% {REQUEST_FILENAME}! -F
RewriteCond% {REQUEST_URI}! (. *) / $
RewriteCond% {QUERY_STRING}!. * =. *
RewriteRule ^ (. *) $ 1 / [L, R = 301]

Ao adicionar uma barra final, você está emitindo o redirecionamento 301 para a URL correta antes de chegar ao WordPress, o que economizará recursos da CPU.

Encontrei um bug no WP Super Cache

Ao contrário da maioria das pessoas, não tenho meu blog WordPress instalado na raiz do meu diretório public_html. Além disso, a página inicial do meu blog também não é minha página de “posts”. Quando você tem seu blog configurado da mesma maneira que eu, há um bug no WP Super Cache onde todos os seus arquivos de cache podem ser excluídos prematuramente, mesmo se você pré-carregar o cache.

Não tenho certeza se o autor do plug-in está ciente desse problema, mas basicamente descobri que sempre que um comentário de spam fosse enviado para o meu blog, todo o meu cache seria liberado erroneamente. Como recebo comentários e spam de trackback o tempo todo, meu cache estava sendo esvaziado constantemente, o que tornava o armazenamento em cache muito menos eficiente.

Então, passei um fim de semana depurando esse problema e, finalmente, desenvolvi uma solução alternativa. Se algum de vocês estiver tendo os mesmos problemas, me avise e eu mostrarei minha correção. A moral da história aqui é nunca presumir que seu plug-in de cache simplesmente funciona. Você precisa olhar os logs!

Desativar plug-ins intensivos de CPU

Mesmo que você tenha seguido todos os meus passos acima, é impossível filtrar todos os acessos não autorizados antes que cheguem ao seu blog WordPress.

Portanto, você sempre receberá visitas em seu site que não serão tratadas de forma eficiente. Não há como contornar isso.

Mas o importante a perceber é que provavelmente você não terá um problema de largura de banda, você terá um problema de CPU.

Como resultado (e isso pode ser contra-intuitivo), você realmente não quer fazer nada que exija muito da CPU, como “reduzir” ou “compactar” suas páginas durante o processo. A redução e a compactação ajudam na largura de banda em detrimento do uso da CPU.

A última coisa que você quer fazer é minimizar e armazenar em cache os acessos não autorizados. Na verdade, você provavelmente deve considerar também não reduzir ou compactar URLs com parâmetros GET.

Mais importante ainda, você não deve executar nenhum plug-in com uso intensivo de CPU em seu site. O WP-Engine tem uma grande lista de plug-ins com uso intensivo de CPU que você provavelmente deve tentar evitar.

Enquanto examinava minha lista de plugins, percebi que estava usando um plugin de “posts semelhantes”. E quando dei uma olhada no código-fonte, fiquei chocado ao descobrir que o plug-in estava fazendo comparações de texto completo para encontrar artigos semelhantes, o que é um grande desgaste da CPU e não é escalável.

Assim que eu encontrar um substituto adequado, este plugin com certeza irá para o lixo.

Moral da história

Só porque um teste de velocidade online diz que seu blog é rápido não significa muito no grande esquema das coisas.

Não me entenda mal. A velocidade de carregamento da página é importante para os mecanismos de pesquisa e para seus clientes regulares, mas você também deve levar em conta os acessos desonestos que podem ignorar o cache e deixar o servidor de joelhos.

Portanto, não instale apenas o cache e outros plug-ins de aceleração às cegas. Reserve algum tempo para analisar seu tráfego e escreva o máximo possível de regras .htaccess para minimizar o trabalho que o WordPress precisa realizar. Boa sorte!