Passos para otimizar o WordPress em relação à carga do servidor?
Além de instalar o W3 Total Cache ou outro plug-in de armazenamento em cache, quais etapas posso fazer para garantir que meu tema e site sejam executados o mais rápido possível.
Você pode instalar o WordPress no Nginx. Existem vários recursos para ajudar:
Algumas informações de desempenho do último link (que parece ser uma configuração um pouco diferente das outras):
Então eu decidi colocar um proxy na frente do wordpress para cache estático, tanto quanto possível. Todo o tráfego não autenticado é servido diretamente do cache do arquivo nginx, recebendo algumas solicitações (como geração de feeds RSS) de 6 páginas/segundo para 7000+ páginas/segundo. Oof. O Nginx também lida com logging e gzipping, deixando os mais pesados backach apaches para fazer o que eles fazem de melhor: servir páginas dinâmicas do wordpress somente quando necessário.
...
No nginx - é tão eficiente que é assustador. Eu nunca vi usar mais de 10 a 15 meg de RAM e um pontinho de CPU, mesmo sob nossa carga mais pesada. Nossos gráficos de gânglios não mentem: reduzimos nossos requisitos de memória pela metade, dobramos nossa taxa de transferência de rede de saída e nivelamos totalmente nossa carga. Nós basicamente não tivemos problemas desde que configuramos isso.
Definir expirações do lado do cliente para coisas como css, imagens, JavaScript, etc, que não precisam ser redownloaded para cada exibição de página. Isso, de longe, fez a maior diferença nos tempos de carregamento do meu site. O download mais rápido é o download que nunca aconteceu ...
# BEGIN Expire headers
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 7200 seconds"
ExpiresByType image/x-icon "access plus 2592000 seconds"
ExpiresByType image/jpeg "access plus 2592000 seconds"
ExpiresByType image/png "access plus 2592000 seconds"
ExpiresByType image/gif "access plus 2592000 seconds"
ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
ExpiresByType text/css "access plus 2592000 seconds"
ExpiresByType text/javascript "access plus 2592000 seconds"
ExpiresByType application/x-javascript "access plus 2592000 seconds"
ExpiresByType text/html "access plus 7200 seconds"
ExpiresByType application/xhtml+xml "access plus 7200 seconds"
</IfModule>
# END Expire headers
# BEGIN Cache-Control Headers
<IfModule mod_headers.c>
<FilesMatch "\\.(ico|jpe?g|png|gif|swf|gz)$">
Header set Cache-Control "max-age=2592000, public"
</FilesMatch>
<FilesMatch "\\.(css)$">
Header set Cache-Control "max-age=2592000, public"
</FilesMatch>
<FilesMatch "\\.(js)$">
Header set Cache-Control "max-age=2592000, private"
</FilesMatch>
<filesMatch "\\.(html|htm)$">
Header set Cache-Control "max-age=7200, public"
</filesMatch>
# Disable caching for scripts and other dynamic files
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
</IfModule>
# END Cache-Control Headers
Você pode pré-compactar tudo o que puder razoavelmente (o 7-Zip é uma boa ferramenta para isso) e carregá-lo no mesmo local que o arquivo que você acabou de compactar. Altere o .htaccess para servir os arquivos pré-zipados, conforme abaixo. A advertência aqui é que você precisa lembrar de atualizá-las se/quando atualizar as coisas. Isso elimina a sobrecarga da CPU, além de analisar o .htaccess.
RewriteEngine on
#Check to see if browser can accept gzip files. If so and we have it - serve it!
ReWriteCond %{HTTP:accept-encoding} gzip
RewriteCond %{HTTP_USER_AGENT} !Safari
#make sure there's no trailing .gz on the url
ReWriteCond %{REQUEST_FILENAME} !^.+\.gz$
#check to see if a .gz version of the file exists.
RewriteCond %{REQUEST_FILENAME}.gz -f
#All conditions met so add .gz to URL filename (invisibly)
RewriteRule ^(.+) $1.gz [QSA,L]
Esta é apenas uma resposta crua. Existem muitas variações sobre esse tema. Eu escrevi sobre isso e adicionei algumas referências a artigos mais detalhados em http://icanhazdot.net/2010/03/23/some-wordpress-stuff/ . Leia isso e, mais importante, as referências para as quais aponto - elas são bons recursos.
Esteja ciente de que, se você mexer com frequência, os usuários precisarão atualizar seu cache.
Um plugin que eu achei muito útil também é wp-minify . A coisa para assistir com este é que você deve excluir itens específicos da página (formulário de contato, controle deslizante de primeira página, etc) para que você não faça o download de todo o conjunto de css, JS etc para cada página. É uma boa maneira de minimizar, combinar e compactar seu CSS de linha de base, JS etc. Ele reduz muito os pedidos de http. Wp-minify joga bem com supercache e também com cabeçalhos de expiração que detalhei acima.
Use o Yslow no Firebug (Firefox) ou similar para monitorar suas solicitações http e o que é e não é compactado. Dê uma olhada nos cabeçalhos de expiração também. Você logo verá o que pode melhorar.
Minimize o número de plugins que você executa para apenas o que você realmente precisa. Especialmente estar ciente de plugins que adicionam javascript e código CSS em cada carregamento de página, mesmo quando esse código não está sendo usado na página.
Se você estiver criando seu próprio tema desde o início, divida seu CSS de modo que os recursos que são necessários apenas para modelos de página ou tipos de visualização específicos (postagem única, arquivos, categoria etc.) sejam carregados apenas quando necessário.
Configure o W3TC para usar um CDN (como o Amazon CloudFront ou qualquer um dos outros suportados pelo W3TC).
Veja se as opções de Minify funcionam para você (alguns plugins geram js/css que não são muito bons, portanto teste seu site depois de ativar o recurso de minify).
Se você tem controle total do seu servidor MySQL, certifique-se de ter o query_cache ativado. Use um script de ajuste MySQL para encontrar outras maneiras de otimizar sua configuração de banco de dados.
Se o uso de um CDN for problemático por algum motivo, configure mod_expires em sua configuração do Apache. Defina tempos de expiração, desde que seja razoável para tipos estáticos como imagens, css, javascript, vídeo, áudio, etc.
Execute memcached e use um cache de objetos para reduzir o número de consultas ao banco de dados. Isso armazena dados do banco de dados, em vez de páginas. Não tenho certeza se o w3-total-cache já faz isso.
Verifique se você está executando um cache opcode como APC . (Existem vários mais disponíveis.)
Além de usar um plug-in de cache de disco como o wp-cache, coloque seu blog em um volume do Host que tenha a propriedade "noatime" configurada nele. Caso contrário, use o SSH no seu Host (se o seu provedor de hospedagem fornecer isso) e rotineiramente execute este comando em seus arquivos a cada poucos dias:
chattr -R +A ~/*
O ~/* significa "meus arquivos sob meu diretório pessoal". Você pode mudar esse caminho como quiser. Você também pode configurá-lo em um cron job no cpanel se o seu host web fornecer isso.
Para mais informações sobre a propriedade atime, consulte this . Ele acelera muito o desempenho de leitura de disco do Linux.
Às vezes seu site está sendo martelado por aranhas. Você pode usar uma ferramenta como SpyderSpanker ou Chennai Central para filtrar aranhas que não ajudam a trazer mais page rank para o seu site e apenas retardá-lo, e então estrangular boas aranhas (como Google, Bing, etc.) enviando aleatoriamente Mensagens HTTP 304 Não Modificadas.
Outra coisa que vejo é apenas plugins mal escritos. Se você aprender a fazer plugins, começará a ver como alguns plugins são ineficientemente codificados ou até mesmo encontrar timebombs, como uma tabela de banco de dados que preenche e preenche e nunca é limpa, armazenando coisas como dados de conexão de entrada.
Além de todas as outras soluções, você também pode criar um web farm do WordPress hospedando-o em vários PCs de nó da web que se conectam a um único banco de dados e um único volume de disco (como um volume montado sobre NFS). ). Confira Ultra Monkey para saber como fazer isso tudo.
Algumas respostas no topo da minha cabeça:
1) Minimize o número de solicitações HTTP que o navegador precisa fazer ao seu Host, concatenando JavaScript e CSS sempre que possível/prático.
2) Descarregue o máximo possível de sua imagem/mídia veiculada para CDNs de terceiros, especialmente se você estiver usando hospedagem compartilhada.
3) Tente reduzir o número de postagens que você está exibindo na primeira página para reduzir o tempo total de renderização.
3a) Tente usar um tema que apresente algumas postagens em destaque na primeira página e todas as outras postagens mais antigas como trechos.
Armazenar em cache o WordPress Menu também oferece um aumento de desempenho. Especialmente se você tem um monte de páginas ou uma estrutura de menu gigante, isso deve ser considerado.
Faça isso em 2 etapas fáceis. Em primeiro lugar, crie uma função que obtenha ou crie o menu, em vez de chamar wp_nav_menu diretamente.
function get_cached_menu( $menuargs ) {
if ( !isset( $menuargs['menu'] ) ) {
$theme_locations = get_nav_menu_locations();
$nav_menu_selected_id = $theme_locations[$menuargs['theme_location']];
$termslug = get_term_by( 'id', $nav_menu_selected_id, 'nav_menu' );
$transient = 'menu_' . $termslug->slug . '_transient';
} else {
$transient = 'menu_' . $menuargs['menu'] . '_transient';
}
if ( !get_transient( $transient ) ) { // check if the menu is already cached
$menuargs['echo'] = '0'; // set the output to return
$this_menu = wp_nav_menu( $menuargs ); // build the menu with the given $menuargs
echo $this_menu; // output the menu for this run
set_transient( $transient, $this_menu ); // set the transient, where the build HTML is saved
} else {
echo get_transient( $transient ); // just output the cached version
}
}
Em seu tema, substitua wp_nav_menus por get_cached_menu. Agora, toda vez que o menu é chamado, você tem uma Databasequery em vez de toda a Menubuilding.
Os menus não mudam com frequência - mas você também precisa se conectar à ação wp_update_nav_menu para excluir os transientes antigos.
Faça isso deste modo:
add_action('wp_update_nav_menu', 'my_delete_menu_transients');
function my_delete_menu_transients($nav_menu_selected_id) {
$termslug = get_term_by( 'id', $nav_menu_selected_id, 'nav_menu' );
$transient = 'menu_' . $termslug->slug . '_transient';
delete_transient( $transient );
}
O Menu será gerado na próxima vez que a página for chamada - e usará a versão em cache até que alguém atualize o menu novamente.
Versão atualizada
Obrigado @helgatheviking por apontar um erro entre lesmas e IDs. Eu atualizei as funções para que funcione tanto com theme_position e menu (para uma chamada direta do menu).
Os menus são sempre salvos com o nome do menu, não a posição no tema.
Use uma classe de banco de dados que é aparada para otimização. Fizemos boas experiências com o próprio código para reduzir o uso de memória e a velocidade de acesso ao banco de dados. Além disso, você pode otimizar a própria estrutura do banco de dados por meio de pequenas alterações que fazem muito também.
Parte do código de classe do banco de dados pode ser encontrado no trac wordpress, ele não o fez no núcleo ( Ticket # 11799 e relacionado ).
Para um site altamente veiculado, você deve ajustar todos os buffers do MySQL para o conteúdo que está em vigor agora. Independentemente da versão do WordPress, a camada MySQL pode ter sua configuração computada .
De fato, se você tem dados do InnoDB sem habilitar o innodb_file_per_table, você precisa limpar o InnoDB, segmentando cada tabela em seu próprio tablespace físico . É possível fazer um ajuste decente do MySQL mesmo se você tiver um hardware limitado . Existem muitos cenários para fazer essas otimizações do InnoDB .
IMHO, você não pode planejar boas configurações para my.cnf sem saber a quantidade de dados para configurar. Você teria que carregar periodicamente um conjunto de dados atual da produção em um ambiente de preparação, executar otimizações e obter os números para configurar no my.cnf do servidor de produção.
Eu falei recentemente sobre este assunto em WordCamp Houston . Todas as recomendações acima são ótimas e o importante é garantir que todo o material do front-end seja totalmente otimizado e que você possa começar a trabalhar nos problemas de desempenho do cache e do servidor.
A renderização progressiva fará com que suas páginas pareçam mais rápidas, porque o usuário verá o conteúdo da página antes de ser totalmente carregado. Para fazer isso, certifique-se de que qualquer js de bloqueio esteja na parte inferior da página e que o css esteja no topo.
Além disso, se você usar muitos botões de mídia social, poderá personalizar os scripts para que sejam carregados em um iframe depois que a página estiver totalmente carregada. Eu escrevi um tutorial sobre como fazer isso com o botão Tweet Tweet Tweet (agora obsoleto desde que o Twitter lançou seu próprio botão de retweet), mas ainda pode ser aplicado a outros botões de compartilhamento.
Para o desempenho do servidor, procure o Nginx como um proxy de front-end para conteúdo estático com o Apache lidando com o pesado PHP e com o MySQL.
você poderia habilitar global output compression . isso irá gzipar tudo automaticamente se o navegador suportar. Isso reduz drasticamente o tamanho dos arquivos transferidos, mas aumenta sua carga de CPU.
Como ninguém mencionou ainda, uma das etapas mais importantes para melhorar o desempenho do servidor em conjunto com qualquer configuração LAMP seria alternar para o thread de trabalho do Apache e o mod_fcgid.
Isso liberou 500MB de memória no meu servidor privado virtual.
Guia para verificar o plugin diminuir a velocidade
Há um plugin bem simples chamado Page Load Time , que adiciona temporizador ao rodapé da página. Na verdade, são apenas quatro linhas de código:
<?php
function ur_pageload_footer() {
printf(__('Page in %s seconds', 'pageload'), timer_stop());
}
add_action('wp_footer', 'ur_pageload_footer')
Então:
- Crie uma planilha
- Listar todos os seus plugins ativos e colocá-los lá
- Atualize a página três vezes observando o tempo de carregamento da página a cada turno
- Percorra seus plugins, um a um, desativando-os
- Repita o passo 3
- Observe a ordem em que você desativou os plug-ins
Sua planilha deve ser algo como
+-------+-------+-------+-------+--------+
| Run 1 | Run 2 | Run 3 | Order | Plugin |
Então, se depois de desativar um plugin o tempo de resposta da página aumentar significativamente, então você pode ver se você pode evitar esse plugin.
Eu encontrei dois plugins que causaram lentidão 'significativa' mqtranslate e (o bastante antigo, mas bom) Multi-level Navigation Plugin .