Hoje, o WordPress dá poder mais de 30% da Internet . É fácil de usar, incrivelmente popular e não vai a lugar nenhum tão cedo.

Mas o WordPress pode ser lento. Então, como você otimiza isso?

Existem muitos artigos sobre como ajustar e otimizar o WordPress. Na verdade, o próprio WordPress fornece um guia robusto na otimização do WordPress.

Na maior parte, esses artigos e tutoriais cobrem conceitos bastante básicos, mas úteis, como o uso de plug-ins de cache, integração com redes de entrega de conteúdo (CDNs) e minimização de solicitações. Embora essas dicas sejam altamente eficazes e até necessárias, no final, elas não resolvem o problema subjacente: a maioria dos sites WordPress lentos é resultado de um código ruim ou ineficiente.

O WordPress pode ser lento, mas não precisa ser. Tweet

Portanto, este artigo tem como objetivo principal fornecer aos desenvolvedores e Empresas de desenvolvimento WordPress com algumas diretrizes que podem ajudá-los a resolver as causas subjacentes de muitos problemas de desempenho do WordPress.

O WordPress fornece muitos recursos orientados para o desempenho que muitas vezes são esquecidos pelos desenvolvedores. O código que não aproveita esses recursos pode retardar as tarefas mais simples, como a busca de postagens. Este artigo detalha quatro soluções possíveis, que abordam alguns dos problemas subjacentes por trás do desempenho lento do WordPress.

Buscando postagens

O WordPress oferece a possibilidade de buscar qualquer tipo de postagem no banco de dados. Existem três maneiras básicas de fazer isso:

• Usando o query_posts() função: Esta é uma abordagem muito direta, mas o problema é que substitui o principal inquerir , o que pode causar inconvenientes. Por exemplo, isso poderia ser um problema se quiséssemos determinar, em algum ponto depois de buscar os posts (como dentro de footer.php), com que tipo de página estamos lidando. Na verdade, a documentação oficial contém uma nota que recomenda contra o uso desta função, pois você precisará chamar uma função adicional para restaurar a consulta original. Além disso, substituir a consulta principal terá um impacto negativo no tempo de carregamento da página.

• Usando o get_posts() função: Isso funciona quase como query_posts(), mas não modifica a consulta principal. Por outro lado, get_posts() por padrão, executa a consulta com suppress_filters parâmetro definido como true. Isso pode levar a inconsistências, especialmente se usarmos filtros relacionados a consultas em nosso código, já que postagens que você não está esperando em uma página podem ser retornadas por esta função.

• Usando o WP_Query classe: Na minha opinião, essa é a melhor maneira de recuperar postagens do banco de dados. Ele não altera a consulta principal e é executado de maneira padrão, como qualquer outra consulta do WordPress.

Mas qualquer que seja o método que usamos para interagir com o banco de dados, há outras coisas que precisamos considerar.

Limitando a consulta

Devemos sempre especificar quantas postagens nossa consulta deve buscar.

Para fazer isso, usamos o posts_per_page parâmetro.

O WordPress permite indicar -1 como um valor possível para esse parâmetro, caso em que o sistema tentará buscar todos os posts que atendam às condições definidas.

Esta não é uma boa prática, mesmo se tivermos certeza de que receberemos apenas alguns resultados como resposta.

Por um lado, raramente podemos ter certeza de obter apenas alguns resultados de volta. E mesmo se pudermos, definir nenhum limite exigirá que o mecanismo de banco de dados verifique todo o banco de dados em busca de correspondências.

Por outro lado, limitar os resultados geralmente permite que o mecanismo de banco de dados varra apenas parcialmente os dados, o que se traduz em menos tempo de processamento e resposta mais rápida.

Outra coisa que o WordPress faz por padrão, que pode afetar negativamente o desempenho, é tentar trazer postagens fixas e calcular quantas linhas foram encontradas na consulta.

Muitas vezes, porém, realmente não precisamos dessa informação. Adicionar esses dois parâmetros desativará esses recursos e acelerará nossa consulta:

$query = new WP_Query( array( 'ignore_sticky_posts' => true, 'no_found_rows' => true ) );

Excluindo Postagens da Consulta

Às vezes, queremos excluir certas postagens da consulta. O WordPress oferece uma maneira bastante direta de consegui-lo: usando o post__not_in parâmetro. Por exemplo:

$posts_to_exclude = array( 1, 2, 3 ); $posts_per_page = 10; $query = new WP_Query( array( 'posts_per_page' => $posts_per_page, 'post__not_in' => $posts_to_exclude ) ); for ( $i = 0; $i posts ); $i++ ) { //do stuff with $query->posts[ $i ] }

Mas embora seja muito simples, não é ideal porque internamente gera uma subconsulta. Especialmente em grandes instalações, isso pode levar a respostas lentas. É mais rápido permitir que o processamento seja feito pelo interpretador PHP com algumas modificações simples:

$posts_to_exclude = array( 1, 2, 3 ); $posts_per_page = 10; $query = new WP_Query( array( 'posts_per_page' => $posts_per_page + count( $posts_to_exclude ) ) ); for ( $i = 0; $i posts ) && $i posts[ $i ]->ID, $posts_to_exclude ) ) { //do stuff with $query->posts[ $i ] } }

O que eu fiz lá?

Basicamente, retirei algum trabalho do mecanismo de banco de dados e deixei para o mecanismo PHP, que faz a mesma coisa, mas na memória, que é muito mais rápido.

Como?

Primeiro, removi o post__not_in parâmetro da consulta.

Como a consulta pode nos trazer algumas postagens que não queremos como resultado, aumentei o valor posts_per_page parâmetro. Dessa forma, garanto que, mesmo que tivesse algumas postagens indesejadas em minha resposta, teria pelo menos $posts_per_page postagens desejadas lá.

Então, quando faço um loop sobre os postes, só processo aqueles que não estão dentro de $posts_to_exclude array.

Evitando parametrizações complexas

Todos estes métodos de consulta oferecem uma ampla variedade de possibilidades para buscar postagens: por categorias, por meta-chaves ou valores, por data, por autor, etc.

E embora essa flexibilidade seja um recurso poderoso, ela deve ser usada com cautela porque essa parametrização pode se traduzir em junções de tabela complexas e operações caras de banco de dados.

Na próxima seção, descreveremos uma maneira elegante de ainda obter funcionalidade semelhante sem comprometer o desempenho.

Extraindo o máximo das opções do WordPress

o API de opções do WordPress fornece uma série de ferramentas para carregar ou salvar dados facilmente. É útil para lidar com pequenos pedaços de informação, para os quais outros mecanismos que o WordPress oferece (como postagens ou taxonomias) são excessivamente complexos.

Por exemplo, se quisermos armazenar uma chave de autenticação ou a cor de fundo do cabeçalho do nosso site, opções são o que procuramos.

O WordPress não só nos dá as funções para lidar com eles, mas também nos permite fazer isso da maneira mais eficiente.

Algumas das opções são até carregadas diretamente quando o sistema começa , proporcionando assim um acesso mais rápido (ao criar uma nova opção, devemos considerar se queremos carregá-la automaticamente ou não).

Considere, por exemplo, um site no qual temos um carrossel exibindo as notícias de última hora especificadas no back-end. Nosso primeiro instinto seria usar uma meta-chave para isso da seguinte forma:

// functions.php add_action( 'save_post', function ( $post_id ) { // For simplicity, we do not include all the required validation before saving // the meta key: checking nonces, checking post type and status, checking // it is not a revision or an autosaving, etc. update_post_meta( $post_id, 'is_breaking_news', ! empty ( $_POST['is_breaking_news'] ) ); } ); // front-page.php $query = new WP_Query( array( 'posts_per_page' => 1, 'meta_key' => 'is_breaking_news' ) ); $breaking_news = $query->posts[0] ?: NULL;

Como você pode ver, essa abordagem é muito simples, mas não é a ideal. Ele executará uma consulta ao banco de dados tentando encontrar uma postagem com uma meta-chave específica. Poderíamos usar uma opção para obter um resultado semelhante:

// functions.php add_action( 'save_post', function ( $post_id ) { // Same comment for post validation if ( ! empty ( $_POST['is_breaking_news'] ) ) update_option( 'breaking_news_id', $post_id ); } ); // front-page.php if ( $breaking_news_id = get_option( 'breaking_news_id' ) ) $breaking_news = get_post( $breaking_news_id ); else $breaking_news = NULL;

A funcionalidade varia ligeiramente de um exemplo para outro.

Na primeira parte do código, sempre teremos as últimas notícias de última hora, em termos de data de publicação da postagem.

No segundo, sempre que uma nova postagem for definida como notícia de última hora, ela substituirá as notícias de última hora anteriores.

Mas, como provavelmente queremos uma notícia de última hora por vez, isso não deve ser um problema.

E, no final, mudamos uma consulta de banco de dados pesada (usando WP_Query com chaves meta) em uma consulta simples e direta (chamando get_post()) que é uma abordagem melhor e com mais desempenho.

Também podemos fazer uma pequena alteração e usar transientes em vez de opções.

Os transientes funcionam de forma semelhante, mas nos permitem especificar um tempo de expiração.

Por exemplo, para notícias de última hora, cabe como uma luva porque não queremos uma postagem antiga como notícia de última hora, e se deixarmos a tarefa de alterar ou eliminar as notícias de última hora para o administrador, ele pode se esquecer de fazer isto. Portanto, com duas mudanças simples, adicionamos uma data de validade:

// functions.php add_action( 'save_post', function ( $post_id ) { // Same comment for post validation // Let's say we want that breaking news for one hour // (3600 = # of seconds in an hour). if ( ! empty ( $_POST['is_breaking_news'] ) ) set_transient( 'breaking_news_id', $post_id, 3600 ); } ); // front-page.php if ( $breaking_news_id = get_transient( 'breaking_news_id' ) ) $breaking_news = get_post( $breaking_news_id ); else $breaking_news = NULL;

Habilitar cache persistente

WordPress nativamente tem um mecanismo de cache de objeto .

As opções, por exemplo, são armazenadas em cache usando esse mecanismo.

Mas, por padrão, esse armazenamento em cache não é persistente, o que significa que ele vive apenas durante uma única solicitação. Todos os dados são armazenados em cache na memória, para acesso mais rápido, mas só ficam disponíveis durante essa solicitação.

O suporte ao cache persistente requer a instalação de um plugin de cache persistente.

Alguns plug-ins de cache de página inteira vêm com um plug-in de cache persistente incluído (por exemplo, W3 Total Cache), mas outros não, e precisamos instalá-lo separadamente.

Dependerá da arquitetura de nossa plataforma, se usaremos arquivos, Memcached ou algum outro mecanismo para armazenar dados em cache, mas devemos aproveitar este recurso incrível.

Alguém pode perguntar: “Se este é um recurso tão bom, por que o WordPress não o habilita por padrão”?

O principal motivo é que, dependendo da arquitetura de nossa plataforma, algumas técnicas de cache funcionarão e outras não.

Se hospedarmos nosso site em nosso servidor distribuído, por exemplo, devemos usar um sistema de cache externo, (como um Memcached servidor), mas se nosso site residir em um único servidor, poderíamos economizar algum dinheiro simplesmente usando o sistema de arquivos para armazenar em cache.

Uma coisa que precisamos levar em consideração é a expiração do cache. Esta é a armadilha mais comum de trabalhar com cache persistente.

Se não resolvermos esse problema corretamente, nossos usuários reclamarão que não verão as alterações que fizeram ou que suas alterações demoraram muito para serem aplicadas.

Às vezes, vamos nos encontrar fazendo trocas entre desempenho e dinamismo, mas mesmo com esses obstáculos, o cache persistente é algo que virtualmente toda instalação do WordPress deve aproveitar.

AJAX da maneira mais rápida

Se precisarmos nos comunicar via AJAX com nosso site, WordPress oferece alguma abstração no momento do processamento da solicitação no lado do servidor.

Embora essas técnicas possam ser usadas ao programar ferramentas de back-end ou envios de formulários desde o front-end, elas devem ser evitadas se não forem estritamente necessárias.

A razão para isso é que, para usar esses mecanismos, somos obrigados a fazer uma solicitação de postagem para algum arquivo localizado dentro do wp-admin pasta. A maioria (senão todos) dos plug-ins de cache de página inteira do WordPress não armazena solicitações de postagem em cache nem chamadas para arquivos de administrador.

Por exemplo, se carregarmos dinamicamente mais postagens quando o usuário estiver rolando nossa página inicial, seria melhor chamar diretamente para alguma outra página de front-end, que obterá os benefícios de ser armazenada em cache.

Podemos então analisar os resultados via JavaScript no navegador.

Sim, estamos enviando mais dados do que precisamos, mas estamos vencendo em termos de velocidade de processamento e tempo de resposta.

Destrua a noção de que o WordPress é lento

Estes são apenas alguns conselhos que os desenvolvedores devem considerar ao codificar para WordPress .

Às vezes, esquecemos que nosso plug-in ou tema pode precisar conviver com outros plug-ins, ou que nosso site pode ser servido por uma empresa de hospedagem que atende centenas ou milhares de outros sites com um banco de dados comum.

Nós apenas nos concentramos em como o plugin deve funcionar e não em como ele lida com essa funcionalidade, ou como fazer de forma eficiente .

Do que foi dito acima, fica claro que as causas do baixo desempenho no WordPress são códigos ruins e ineficientes. No entanto, o WordPress fornece todas as funcionalidades necessárias através de suas várias APIs que podem nos ajudar construir plugins e temas com muito mais desempenho sem comprometer a velocidade da plataforma geral.