Além de instalar o W3 Total Cache ou outro plug-in de armazenamento em cache, que etapas devo seguir para garantir que meu tema e site sejam executados o mais rápido possível.
Respostas:
Você pode instalar o WordPress no Nginx. Existem vários recursos para ajudar:
Algumas informações de desempenho desse último link (que parece ser uma configuração um pouco diferente das outras):
Então, decidi colocar um proxy na frente do wordpress para cache estático, tanto quanto possível. Todo o tráfego não autenticado é atendido diretamente do cache do arquivo nginx, levando algumas solicitações (como geração de feed RSS) de 6 páginas / segundo para mais de 7000 páginas / segundo. Oof. O Nginx também lida com log e gzipping, deixando os apêndices mais pesados para fazer o que fazem de melhor: servir páginas dinâmicas de wordpress somente quando necessário.
...
No nginx - é tão eficiente que é assustador. Nunca o vi usar mais de 10 a 15 meg de RAM e um pouco de CPU, mesmo sob a nossa carga mais pesada. Nossos gráficos de gânglios não mentem: reduzimos pela metade nossos requisitos de memória, dobramos nossa taxa de transferência de rede de saída e nivelamos completamente nossa carga. Basicamente, não tivemos problemas desde que configuramos isso.
Defina vencimentos do lado do cliente para itens como css, imagens, JavaScript etc., que não precisam ser baixados novamente para cada visualização da página. Isso, de longe, fez a maior diferença no tempo 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 enviá-lo no mesmo local que o arquivo que você acabou de compactar. Altere .htaccess para servir os arquivos pré-compactados, como abaixo. A ressalva aqui é que você precisa se lembrar de re-compactá-los se / quando você 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 bruta. Existem muitas variações sobre esse tema. Eu escrevi no blog 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 - são bons recursos.
Lembre-se de que, se você mexer frequentemente, os usuários precisarão atualizar seu cache.
Um plugin que achei muito útil também é o wp-minify . O que deve ser observado com este é que você deve excluir itens específicos da página (formulário de contato, controle deslizante da página inicial etc.) para não fazer o download novamente de todo o conjunto de css, JS etc. para cada página. É uma boa maneira de minificar, combinar e compactar o CSS, JS da linha de base, etc. Ele reduz muito as solicitações http. O Wp-minify funciona bem com supercache e também com cabeçalhos de vencimento que detalhei acima.
Use Yslow no Firebug (Firefox) ou similar para monitorar suas solicitações HTTP e o que é e não é compactado. Veja também os cabeçalhos de vencimento. Você verá em breve o que pode melhorar.
Minimize o número de plugins que você executa para apenas o que você realmente precisa. Esteja ciente dos plugins que adicionam código javascript e CSS em cada carregamento da página, mesmo quando esse código não está sendo usado na página.
Se você estiver criando seu próprio tema do zero, divida seu CSS para que os recursos necessários apenas para modelos de página específicos ou tipos de exibição (postagem única, arquivos, categoria etc.) sejam carregados apenas quando necessário.
Configure o W3TC para usar uma CDN (como o Amazon CloudFront ou qualquer um dos outros suportados pelo W3TC).
Veja se as opções Minify funcionam para você (alguns plug-ins geram js / css que não serão minimamente adequados; portanto, teste seu site depois de ativar o recurso minify).
Se você tem controle total do seu servidor MySQL, verifique se o query_cache está ativado. Use um script de ajuste do MySQL para encontrar outras maneiras de otimizar a configuração do banco de dados.
Se o uso de uma CDN for problemático por algum motivo, configure mod_expires na sua configuração do apache. Defina os prazos de validade, desde que razoáveis, para tipos estáticos, como imagens, css, javascript, vídeo, áudio etc.
Execute o memcached e use um cache de objeto para reduzir o número de consultas ao banco de dados. Isso armazena em cache os 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 de código de operação como o APC . (Existem vários outros disponíveis.)
Além de usar um plug-in de armazenamento em cache em disco, como wp-cache, coloque seu blog em um volume de host com a propriedade "noatime" definida. Caso contrário, faça o SSH no seu host (se o seu host da web fornecer isso) e execute rotineiramente este comando em seus arquivos a cada poucos dias:
chattr -R +A ~/*O ~ / * significa "meus arquivos no meu diretório pessoal". Você pode mudar esse caminho como achar melhor. Você também pode configurar isso em um trabalho cron no cpanel se o seu host fornecer isso.
Para mais informações sobre a propriedade atime, consulte isso . Ele acelera bastante 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 simplesmente abrandá-lo, e depois estrangular boas aranhas (como Google, Bing etc.) enviando-as aleatoriamente Mensagens HTTP 304 não modificadas.
Outra coisa que vejo são apenas plugins mal escritos. Se você aprender a criar plug-ins, começará a ver como alguns plug-ins são ineficientemente codificados ou até encontrar timebombs, como uma tabela de banco de dados que preenche e preenche e nunca é limpa, armazenando itens como dados de conexão recebidos.
Além de todas as outras soluções aqui, você também pode criar um farm do WordPress no seu blog hospedando-o em vários PCs de nós da web, todos conectados a um único banco de dados e um único volume de disco para os arquivos (como um volume montado sobre o NFS ) Confira o Ultra Monkey para saber como fazer isso acontecer.
Algumas respostas em cima da minha cabeça:
1) Minimize o número de solicitações HTTP que o navegador deve fazer para o seu host concatenando JavaScript e CSS sempre que possível / prático.
2) Descarregue o máximo possível de sua imagem / mídia para CDNs de terceiros, principalmente 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 antigas como trechos.
O armazenamento em cache do menu WordPress também oferece um aumento de desempenho. Especialmente se você tiver muitas páginas ou uma estrutura de menus gigante, isso deve ser considerado.
Faça isso em 2 etapas fáceis. Primeiro, crie uma função que obtenha ou crie o menu, em vez de chamar wp_nav_menudiretamente.
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
}
}
No seu tema, substitua os wp_nav_menupor get_cached_menu. Agora, toda vez que o menu é chamado, você tem uma consulta ao banco de dados em vez de toda a construção do menu.
Os menus não mudam frequentemente - mas você também precisa se conectar à wp_update_nav_menuação 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 use 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 identificações. Atualizei as funções para que funcione com theme_positione 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.
$nav_menu_selected_idé um número, enquanto chamamos get_cached_menu()the menu_idé uma variável de cadeia, porque esse parâmetro se torna o ID do CSS para o <ul>elemento.
Use uma classe de banco de dados cortada para otimização. Fizemos boas experiências com código próprio 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 com algumas pequenas alterações que também fazem muito.
Parte do código da classe do banco de dados pode ser encontrada no wordpress trac, mas não no núcleo ( ticket # 11799 e relacionados ).
Para um site altamente trafegado, 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 calculada .
De fato, se você tiver dados do InnoDB sem ativar o innodb_file_per_table, precisará limpar o InnoDB segmentando cada tabela em seu próprio espaço de tabela 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 o my.cnf sem conhecer a quantidade de dados a ser configurada. Você precisaria carregar periodicamente um conjunto de dados atual da produção em um ambiente intermediário, executar otimizações e obter os números a serem configurados no my.cnf do servidor de produção.
você pode ativar a compactação de saída global . isso fará com que tudo saia automaticamente automaticamente se o navegador suportar. Isso reduz drasticamente o tamanho dos arquivos transferidos, mas aumenta a carga da CPU.
Recentemente, falei sobre esse assunto no WordCamp Houston . Todas as recomendações acima são ótimas e o importante é garantir que todo o material de front-end esteja totalmente otimizado, para que você possa começar a trabalhar nos problemas de cache e desempenho 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, verifique se js de bloqueio está na parte inferior da página e css está na parte superior.
Além disso, se você usar muitos botões de mídia social, poderá personalizar os scripts para carregá-los em um iframe após o carregamento completo da página. Eu escrevi um tutorial sobre como fazê-lo com o botão de re Tweet do TweetMeMe (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, observe o Nginx como um proxy de front-end para conteúdo estático, com o Apache lidando com o pesado levantamento de PHP e MySQL.
Como ninguém o mencionou ainda, uma das etapas mais importantes para aprimorar o desempenho do servidor em conjunto com qualquer configuração do LAMP seria mudar para o thread de trabalho apache e mod_fcgid.
Isso liberou 500 MB de memória no meu servidor virtual privado.
Há um plug-in lindamente simples chamado Tempo de carregamento da página , que adiciona timer 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:
Sua planilha deve ter algo como
+-------+-------+-------+-------+--------+
| Run 1 | Run 2 | Run 3 | Order | Plugin |
Portanto, se após a desativação de um plug-in, o tempo de resposta da página aumentar significativamente, você poderá ver se pode evitar esse plug-in.
Encontrei dois plug-ins que causaram lentidão significativa ao mqtranslate e (o bastante antigo, mas bom) plug-in de navegação em vários níveis .
Use o plug-in W3 Total Cache para a funcionalidade de cache no WordPress. Ative o cache da página e o cache do banco de dados na página de configurações do plug-in. Certifique-se de escolher 'Cache PHP alternativo (APC / APCu)' como o mecanismo de cache. NÃO ative nenhuma minificação no cache total do W3, pois há muitas chances de você interromper a aparência e / ou a funcionalidade do site. Vamos deixar para Cloudflare.
Quando terminar de configurar o restante das funcionalidades do plug-in, configure o Cloudflare para o seu site. Certifique-se de ativar o Cloudflare nas configurações de Cache total do W3 também em 'Extensões'.
Cloudflare é uma rede de entrega de conteúdo que armazena em cache todo o conteúdo estático (arquivos de imagem, CSS, JS, documentos etc.) do seu site e o serve aos visitantes de seus servidores globais. Isso pode ajudar a acelerar o tempo de carregamento da página e reduzir a carga no seu servidor. Para obter uma lista dos tipos de arquivo armazenados em cache pelo Cloudlfare, faça check - out nesta lista . Além disso, o Cloudflare tem um plano gratuito.
No Cloudflare, defina o nível de cache como padrão e defina a expiração do cache do navegador como algo pelo menos maior que 20 horas. Ative o Always Online ™ para que, mesmo que o servidor seja desativado, o Cloudflare servirá as páginas estáticas do site a partir do cache. Ative também o recurso de minificação automática (lembre-se, por que pedi para você não ativar a minificação é o W3 Total Cache? Porque o Cloudflare melhora!) Em seguida, defina o Rocket Loader ™ como automático.
Aqui está um trecho do que o Rocket Loader faz:
Diminuir o número de solicitações de rede agrupando arquivos JavaScript, até mesmo recursos de terceiros, para evitar a lentidão da renderização da página.
Carregando scripts de forma assíncrona, incluindo scripts de terceiros, para
que eles não impeçam o carregamento
imediato do conteúdo da sua página .
Armazenando scripts em cache localmente (usando o LocalStorage, disponível na maioria dos
navegadores e smartphones), para que não sejam buscados novamente, a menos que seja
necessário.
Mais informações podem ser encontradas aqui .
Se possível mudança para o quadro Genesis para WordPress, porque eles estão limpos, sem qualquer inchaço. O Genesis foi construído com velocidade e SEO em mente. Eu mesmo testei e minhas pontuações no PageSpeed foram boas. Além disso, se você estiver usando o Genesis, não se esqueça de ativar o cache de fragmentos nas configurações de cache total do W3.
Como agora você está usando o Cloudlfare como CDN, pode usar um plug-in como ' Imagify ' ou ' Compactar imagens JPEG e PNG ' da TingPNG para compactar suas imagens. Ambos são plugins gratuitos disponíveis no repositório de plugins do WordPress.org. Além disso, o Imagify suporta o poderoso algoritmo de compactação com perdas.
Por fim, instale o plug-in ' Remover cadeias de consulta de recursos estáticos ' no repositório WordPress, para remover as cadeias de consulta de recursos estáticos, como arquivos CSS e JS. Isso ocorre porque os recursos com "?" Ou "&" na URL não são armazenados em cache por alguns servidores de cache proxy (lembre-se, o Cloudflare também é um servidor de cache proxy).
Em seguida, instale o plug-in ' Usar bibliotecas do Google '. Esse plug-in permite que seu site WordPress use a CDN da API da Biblioteca AJAX do Google, em vez de fornecer esses arquivos diretamente da instalação do WordPress.
Alguns dos benefícios são:
Por último, mas não menos importante, use o plug - in ' WP-Optimize ' de Ruhani Rabin para limpar e otimizar seu banco de dados.
Espero que isso responda à sua pergunta em relação à otimização do WordPress para reduzir a carga do servidor.