Fastest Cache : acelerar o seu site com Varnish e NGINX

Procédure

Por que acelerar a velocidade de carregamento do seu site? 

É bom saber que a velocidade de carregamento do seu site é primordial para garantir o sucesso do mesmo. Para uma empresa, por exemplo, isso dá uma primeira impressão aos seus visitantes. Além disso, um carregamento demasiado longo deste último pode ter um impacto no SEO do seu site nos principais motores de busca e não permitirá uma exposição suficiente para o manter em funcionamento.

Não existe um limite a não ultrapassar relativamente ao carregamento das suas páginas web. No entanto, o tempo de carregamento da maioria dos sites na internet é inferior a três segundos.

O que é o Fastest Cache e para que serve? 

A ferramenta Fastest Cache é um sistema concebido e desenvolvido pela LWS que permite otimizar o desempenho de carregamento do seu site graças à utilização de mecanismos de cache de página, configurados ao nível do servidor web. A ferramenta combina as tecnologias fornecidas por NGINX e Varnish.

NGINX é um servidor web orientado para o desempenho, permitindo gerir muito mais pedidos em comparação com o servidor web tradicional Apache HTTPd Server (veja o nosso artigo de blog intitulado “Apache VS Nginx : Teste de desempenho”). A LWS utiliza o NGINX para poder receber a montante um elevado volume de pedidos HTTP sem compromisso de desempenho. Este pode então ser filtrado de forma eficiente e eliminar pedidos maliciosos (ver LWS Protect) e encaminhar os pedidos HTTP para o servidor de cache Varnish ou LiteSpeed, conforme a escolha do cliente na sua interface de alojamento.

Varnish é um serviço HTTP que implementa um mecanismo de cache de página, permitindo guardar em cache o resultado de um pedido HTTP na memória RAM.

Com as configurações corretas implementadas, o NGINX permite receber mais pedidos no seu site, e o Varnish permite ao mesmo tempo acelerar o tempo de carregamento da sua página, reduzindo a sua utilização de CPU e memória RAM.

Como funciona o serviço Fastest Cache?

Funcionamento sem cache

Para compreender melhor o funcionamento, veremos primeiro como tudo se passa sem sistema de cache para que o visitante possa ver o seu site.

1. O visitante pede a página ao servidor web. Exemplo: index.php
2. O servidor web executa os scripts necessários (PHP, Python, Node.js …)
3. O servidor web recebe o resultado da execução
4. O servidor web envia a página HTML resultante da execução do script

Funcionamento com o módulo Fastest Cache

Quando o Fastest Cache está ativado, um servidor de cache é introduzido entre o visitante e o servidor web.

O objetivo é reduzir o número de execuções de scripts necessárias, guardando o resultado da execução em memória para os próximos pedidos que necessitem da mesma resposta. Isto permite deixar de executar várias vezes o mesmo script para chegar ao mesmo resultado.

Desta forma, eliminamos o tempo de espera da execução do script no tempo de carregamento da página e, ao mesmo tempo, poupamos os recursos utilizados durante a execução do script.

11. O visitante pede a página ao servidor web. Exemplo: index.php
2. O Fastest Cache verifica se a resposta pode ser obtida a partir do cache:

• Se sim, a página é devolvida diretamente ao visitante sem necessidade de aceder ao serviço web e sem executar o script
• Se não, a página é gerada pelo servidor web, o que leva à execução do script (PHP, Node.js, Perl, Ruby, …). Uma vez gerada a página, o Fastest Cache determina se a resposta pode ser mantida em cache.
  • Se sim, a página é gravada na memória cache e devolvida ao visitante
  • Se não, a página é devolvida ao visitante sem ser gravada na memória cache

Constata-se que, quando uma página é armazenada na memória cache, o processamento pelo servidor web, bem como a execução do script, é evitado, o que reduz consideravelmente o tempo de execução e o consumo de recursos.

Comportamento do sistema de cache

O Fastest Cache baseia-se em múltiplos sinais para decidir o comportamento de cache adotado:

• Extensão do ficheiro no URL
• Presença e conteúdo dos parâmetros URL (query strings)
• Header de resposta Cache-Control
• Cookies

O Fastest Cache também deteta certos CMS e extensões/módulos e implementa comportamentos de cache específicos relacionados com essas ferramentas.

Comportamento ao receber o pedido

O Fastest Cache apenas coloca em cache os métodos HTTP GET e HEAD.

Quando um visitante visita um URL, o Fastest Cache normaliza o pedido, removendo os cookies e parâmetros de URL que não influenciam o resultado final do script do lado do servidor (parâmetros de URL do Google Analytics, cookies ligados a scripts Javascript ...).

Uma vez normalizado, o pedido é verificado para ver se contém uma autenticação HTTP (header de pedido HTTP Authorization) ou se ainda existem cookies (header de pedido HTTP Cookie). Se sim, então o pedido será reenviado para o servidor web sem passar pelo sistema de cache.

Comportamento ao enviar a resposta

Se o pedido não contornou o cache no momento da receção do pedido, o Fastest Cache analisa novamente a resposta HTTP fornecida pelo servidor web e verifica se é possível colocar a resposta em cache para utilização futura.

Se a resposta HTTP fornecer um header de resposta HTTP Cdn-Cache-Control, o Fastest Cache respeita imediatamente o que nele estiver definido:

• Se no-store, no-cache ou private estiver definido, o Fastest Cache devolve a resposta ao visitante sem a guardar no cache.
• Se s-maxage ou max-age estiver definido, o Fastest Cache utiliza imediatamente esse valor como prazo de retenção da página no cache.

Se Cdn-Cache-Control estiver definido com Set-Cookie, Cdn-Cache-Control será ignorado e a resposta não será guardada no cache.

Os ficheiros estáticos correspondentes aos temas, plugins, uploads e core WordPress são automaticamente guardados em cache durante 30 dias.

Se a resposta HTTP provier do sistema de cache de página LWS Optimize, WP Fastest Cache, Airlift, W3 Total Cache, WP Rocket, WP Optimize ou FastPixel, a mesma é guardada em cache durante 7 dias. Estes plugins WordPress procederão eles próprios à purga do cache Varnish quando eliminarem o cache de página.

Se a resposta HTTP provier da pasta /_next/static, esta também é guardada em cache durante 7 dias.

Se a resposta HTTP devolver um código HTTP 404, este é guardado em cache durante 900 segundos. Isto permite evitar ainda mais pedidos desnecessários na base de dados MySQL, nomeadamente para WordPress.

Se a resposta HTTP devolver um código HTTP 500, a resposta nunca é guardada em cache.

Se a resposta HTTP contiver um cookie (header de resposta HTTP Set-Cookie), a resposta nunca é guardada em cache.

Se a resposta HTTP fornecer um header de resposta HTTP Cache-Control ou Surrogate-Control, o Fastest Cache segue o comportamento de cache esperado para os navegadores. Se estes headers forem fornecidos com Cdn-Cache-Control, o Fastest Cache ignora Cache-Control e Surrogate-Control em favor de Cdn-Cache-Control. Isto permite, por exemplo, obrigar o navegador a fazer um pedido HTTP para consultar uma lista de artigos a cada visita, sem que a lista de artigos esteja ausente do cache do servidor.

Apresentação da interface e ativação do serviço

O Fastest Cache apresenta-se sob a forma de um ícone no cPanel na secção “Performance”.

Uma vez na interface, o domínio principal, os domínios adicionais e os subdomínios são apresentados na lista.

• A coluna “Estado do cache” apresenta o estado de ativação do cache. Se estiver em “Ativado”, então o cache está ativado.
• O botão “Purgar o cache” permite eliminar todos os dados em cache para esse nome de domínio em particular.
• O botão “Desativar o cache” permite desativar a colocação em cache.
• O botão “Ativar o cache” permite ativar a colocação em cache.
• O botão “Alterar o modo de funcionamento” permite modificar o comportamento do sistema de cache. Estes modos serão explicados de seguida.

Os diferentes modos de cache

Por defeito, o sistema de cache adota o modo « Utilização geral » que é adequado para utilizações gerais. No entanto, existem outros modos:

Modo de desenvolvimento : idêntico à desativação do cache, isto permite contornar o sistema de cache durante os seus períodos de desenvolvimento.
WordPress : um modo de cache mais adaptado ao WordPress, em que a gestão das pastas (wp-content, wp-admin, …) e dos cookies específicos do WordPress é melhorada.
Prestashop : um modo de cache mais adaptado ao Prestashop, em que a gestão das pastas e dos cookies é melhorada.

Purga do cache

Para além da interface cPanel que permite purgar o cache, é possível purgar manualmente o cache a partir do terminal SSH da conta cPanel ou a partir de um script alojado no servidor.

Executados a partir do seu alojamento (script PHP do seu site, tarefa Cron ou terminal SSH), estes métodos não exigem nem token de API nem identificador: o Fastest Cache aceita diretamente os métodos HTTP PURGE.

Purga do cache com cURL

Purgar o cache de uma página:

curl -X PURGE https://mon-site-web.com/mapage.php

Isto permitirá purgar o cache do URL https://mon-site-web.com/mapage.php.

Purgar o cache de uma pasta:

curl -X PURGE 'https://mon-site-web.com/wp-content/uploads/.*'

Isto permitirá purgar todos os caches dos URLs que começam por 'https://mon-site-web.com/wp-content/uploads/'

Purgar o cache de um site

curl -X PURGE https://mon-site-web.com/.*

Para o conjunto destes três comandos, são possíveis três respostas:

Código HTTP 200 : a purga decorreu sem erros.

Código HTTP 4xx : a purga não é autorizada.

Código HTTP 5xx : ocorreu um erro.

Purga automática com um script PHP (tarefa Cron)

O seguinte script esvazia o cache de todo o site, ou apenas de algumas páginas. Copie-o para um ficheiro purge-cache.php do seu alojamento e, em seguida, indique o seu domínio em $site. Para purgar apenas certas páginas, liste-as em $pages.

 'PURGE',
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CONNECTTIMEOUT => 5,
        CURLOPT_TIMEOUT        => 20,
    ]);
    curl_exec($ch);
    $code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);
    return $code;
}

if (empty($pages)) {
    echo date('Y-m-d H:i:s') . ' purga completa : HTTP ' . purger($site . '/.*') . PHP_EOL;
}
else {
    foreach ($pages as $page) {
        echo date('Y-m-d H:i:s') . ' ' . $page . ' : HTTP ' . purger($site . $page) . PHP_EOL;
    }
}

Para o executar automaticamente, por exemplo todas as noites, crie uma tarefa Cron que execute este ficheiro com PHP. Se quiser simplesmente esvaziar todo o cache, a tarefa Cron também pode executar diretamente:

curl -s -o /dev/null -X PURGE 'https://mon-site-web.com/.*'

Purga com um plugin ou módulo

A maioria dos plugins/módulos com integração Varnish é compatível com o mecanismo interno de purga do Fastest Cache.

Aqui estão alguns plugins testados e verificados compatíveis:

• LWS Optimize
• WP Fastest Cache
• WP Rocket
• Proxy Cache Purge

Deteção de HTTPS e redirecionamentos

O estado HTTPS e as portas indicadas no Apache são injetados no ambiente e geralmente não requerem qualquer modificação adicional.

No entanto, se a deteção HTTPS não funcionar com o Fastest Cache, isto pode causar ciclos de redirecionamento infinitos. Assim, será necessário modificar os dados de deteção.

Os headers HTTP de confiança para a deteção são:

• X-Forwarded-Proto
• X-Forwarded-Port

Assim, se utilizar o seguinte redirecionamento HTTPS com um .htaccess:

RewriteEngine On 
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

e se isso não funcionar, pode substituir a variável SERVER_PORT por X-Forwarded-Proto :

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !on
RewriteRule ^(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R]

CloudFlare e outros CDN

Os CDN do tipo CloudFlare podem filtrar os pedidos HTTP que poderiam bloquear os pedidos “PURGE” e utilizados pelo Fastest Cache para purgar o cache. É então aconselhado indicar o endereço IP do servidor durante a sua purga com curl, a fim de contornar os CDN durante as ações de purga:

curl -X PURGE --resolve mon-site-web.com:443:IP_DU_SERVEUR 'https://mon-site-web.com/.*'

Os CDN também podem conter uma camada adicional de cache que deve gerir independentemente do cache fornecido pelo Fastest Cache.