Hoje, o WordPress usa 33% da Internet . É fácil de usar, muito popular e você não vai a lugar nenhum tão cedo.

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

o que causou a crise econômica grega

Existem muitos artigos sobre como otimizar o WordPress. Na verdade, o próprio WordPress fornece um guia robusto de como otimizar.

Na maioria dos casos, esses artigos e tutoriais cobrem conceitos bastante básicos, mas úteis. Tal é o uso de plug-ins de cache, integração com redes de entrega de conteúdo (CDN) e minimização de solicitações. Embora essas dicas sejam altamente eficazes e até necessárias, elas não abordam o problema subjacente; A maioria dos sites Wordpress lentos é o resultado de uma codificação pobre ou ineficiente.

Wordpress pode ser lento, mas não precisa ser. Tweet

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

O WordPress oferece muitos recursos orientados para o desempenho que muitas vezes são esquecidos pelos desenvolvedores. O código que não permite que você aproveite esses recursos pode retardar as tarefas mais simples, como a obtenção de empregos. Este artigo detalha quatro soluções possíveis que tratam de alguns dos problemas subjacentes ao desempenho lento do WordPress.

Obtenção de empregos

O WordPress oferece a possibilidade de pesquisar qualquer tipo de posição na base de dados. Existem três maneiras básicas de fazer isso:

• Usando a função 'query_posts ()': Esta é uma abordagem muito direta, mas o problema é que ela substitui a consulta diretor o que poderia causar transtornos. Por exemplo, isso pode ser um problema se quisermos determinar em algum ponto após obter as postagens (como em 'footer.php') com que tipo de página estamos lidando. Na verdade, a documentação oficial tem uma observação recomendada contra o uso dessa 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 nos tempos de carregamento da página.

• Usando a função 'get_posts ()': Isso funciona quase como 'query_posts ()', mas não modifica a consulta principal. Por outro lado, ‘get_posts ()’ por padrão executa a consulta para ‘suppress_files’, 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 a classe ‘WP_query’: Na minha opinião, esta é a melhor forma de recuperar as postagens do banco de dados. Ele não altera a consulta principal e é executado em sua forma padrão, como qualquer outra consulta do WordPress.

Mas seja qual for o método que usamos para interagir com o banco de dados, há outras coisas a serem consideradas.

Limitando a consulta

Devemos sempre especificar quantas postagens nossa consulta deve trazer.

Para fazer isso, usamos o parâmetro 'posts por página'.

O WordPress permite indicar -1 como um valor possível para aquele parâmetro, caso em que o sistema tentará recuperar todas as mensagens que cumpram as condições definidas.

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

Por um lado, raramente pode ser verdade apenas obter resultados novamente. E mesmo se pudéssemos definir um limite, seria necessário que o mecanismo de banco de dados analisasse todo o banco de dados em busca de correspondências.

Em contraste, limitar os resultados geralmente permite que o mecanismo de banco de dados analise apenas parcialmente os dados, o que se traduz em menos tempo de processamento e uma resposta mais rápida.

Outra coisa que o WordPress faz por padrão é que ele pode afetar negativamente o desempenho, pois tenta trazer postagens fixas e calcular quantas linhas existem na consulta.

No entanto, realmente não precisamos dessas informações com muita frequência. A adição desses dois parâmetros é para 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 simples e agradável de fazer isso: com o parâmetro 'post__no_en'. 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 bastante simples, não é o ideal porque gera uma subconsulta internamente. Especialmente em grandes instalações, isso pode levar a uma resposta lenta. É 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 aqui

Basicamente, removi alguns jobs do mecanismo de banco de dados e os deixei no local para o mecanismo PHP, que faz as mesmas coisas, mas na memória, que é muito mais rápido.

Como?

Primeiro, removi o parâmetro 'post__no_en' da consulta.

Como a consulta pode nos trazer algumas postagens que não queremos como resultado, aumentei o parâmetro de “posts_per_page. Dessa forma, posso garantir que, mesmo se tivesse algumas postagens indesejadas em minha resposta, eu gostaria de ter em pelo menos '$ posts_per_page desejado' colocado lá.

Então, quando procuro os posts e só procuro aqueles que não estão dentro do array '$ posts_para_exclude'. '

Evite parametrização complexa

Estes métodos de consulta oferecem uma ampla variedade de possibilidades para obter posições: por categorias, por meta chaves ou valores, por data, por autor, etc.

A flexibilidade é um recurso muito poderoso, portanto, deve ser usada com cuidado, pois pode resultar na parametrização de junções de tabela complexas e operações de banco de dados caras.

Na próxima seção, delinearei elegantemente como obter funcionalidade semelhante sem comprometer o desempenho.

Aproveitando ao máximo as opções do Wordpress.

Opções API WordPress WordPress fornecem várias ferramentas para carregar ou salvar dados facilmente. Eles são úteis para lidar com pequenos pedaços de informação, uma vez que outros mecanismos que o WordPress oferece (como postagens ou taxonomias) são muito complexos.

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

O WordPress não só nos dá as funções para a sua gestão, mas também nos permite fazê-lo da maneira mais eficiente.

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

Considere, por exemplo, um site onde temos um carrossel específico exibindo notícias no back-end. Nosso primeiro instinto seria usar um objetivo principal 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, este método é muito simples, mas não é o ideal. Será feita uma consulta ao banco de dados tentando encontrar uma postagem com uma determinada meta-chave. 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 exemplo para exemplo.

Na primeira parte do código teremos sempre as notícias mais recentes, no que diz respeito à data de publicação do post.

Na segunda, sempre que uma nova postagem for estabelecida como notícia de última hora, ela será substituída pela notícia anterior.

Mas, como provavelmente queremos uma notícia de cada vez, isso não será um problema.

E no final nós mudamos uma consulta de banco de dados pesada (usando 'WP_QUERY' com meta chaves) em uma consulta simples e direta (a chamada 'get_post ()'), que é uma abordagem melhor e mais eficiente.

Também podemos fazer uma pequena mudança e usar transientes em vez de opções.

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

Por exemplo, no caso de uma notícia que se adapta perfeitamente, porque não queremos um post antigo como uma notícia de última hora e se deixarmos a tarefa de alterar ou remover essa notícia para o administrador, [ele] pode esquecer de fazê-lo . Portanto, com duas mudanças simples, podemos adicionar 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;

Ative um Cache Persistente

O WordPress nativamente tem um mecanismo de cache objeto .

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

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

O suporte a 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, o W3 Total Cache), mas outros não, e temos que instalá-lo separadamente.

Dependerá da arquitetura de nossa plataforma se vamos usar arquivos como Memcache ou algum outro mecanismo para armazenar dados em cache, devemos aproveitar este recurso incrível.

Você pode se perguntar: 'Se este é um ótimo recurso do WordPress, por que não está habilitado 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 quisermos hospedar um servidor distribuído em nosso site, por exemplo, devemos usar um sistema de cache externo (como um Servidor Memcached ), mas se nosso site residir em um único servidor, poderíamos economizar dinheiro e apenas usar o sistema de arquivos em cache.

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

Se não resolvermos isso de maneira adequada, nossos usuários reclamarão que não conseguirão ver as alterações que fizeram ou que suas alterações demoraram muito para serem aplicadas.

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

AJAXing 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 servidor.

Embora essas técnicas possam ser usadas com programação de ferramentas de back-end ou envio de formulários de front-end, elas devem ser evitadas se não forem estritamente necessárias.

A razão para isso é que, para utilizar esses mecanismos, somos obrigados a fazer uma solicitação de postagem para um arquivo localizado na pasta “wp-admin”. A maioria (senão todos) dos plug-ins do Wordpress não tem cache de página inteira, cache de pós-solicitação nem chamadas de gerenciador de arquivos.

Por exemplo, se quisermos postagens de carregamento mais dinâmicas quando o usuário navegar para nossa página inicial, seria melhor chamar diretamente alguma outra página de front-end, que receberá os benefícios de ser armazenada em cache.

o que um diretor financeiro faz

Então, poderíamos 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

Estas são apenas algumas dicas que os desenvolvedores devem ter em mente ao codificar para WordPress .

Às vezes esquecemos que nosso plugin ou tema é necessário para conviver com outros plugins, 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 como ele lida com essa funcionalidade, ou como fazê-lo em um eficaz .

Pelo que discuti anteriormente, está claro que as causas do baixo desempenho do WordPress são códigos ruins e ineficientes. No entanto, o WordPress oferece todas as funcionalidades necessárias através de suas várias APIs que podem nos ajudar a construir muitos mais plugins de desenvolvimento e temas sem comprometer a velocidade geral da plataforma.