Hospedagem e desempenho
Como tornamos o WordPress rápido: LiteSpeed Enterprise, LSCache e Redis por site
A solicitação do WordPress mais rápida é aquela que nunca é executada — veja como nossa pilha responde à maioria das visitas a partir do cache antes mesmo de o PHP ou o MySQL serem chamados, e o que isso significa para o Core Web Vitals.
A requisição mais rápida é aquela que nunca é executada
Uma solicitação padrão do WordPress consome muitos recursos. O servidor web a encaminha para o PHP, o PHP inicializa o WordPress, executa os plugins, consulta o MySQL algumas dezenas de vezes, monta o HTML e só então envia os bytes de volta. Em um site movimentado, todo esse processo ocorre para cada visitante, e é aí que quase todo o seu time-to-first-byte é consumido.
Nossa resposta é garantir que, para a maioria das visitas, nada disso aconteça. Entre os sites que hospedamos — mais de 100.000 sites PBN, além do WordPress gerenciado convencional —, a grande maioria das visualizações de páginas no front-end é entregue como uma página completa pré-renderizada diretamente do cache, sem chamar o PHP ou acessar o banco de dados. O restante desta publicação aborda como as camadas que tornam isso possível se integram e onde cada uma justifica a sua presença.
O enquadramento importante é que esses não são caches concorrentes entre os quais você escolhe. O cache de página inteira, o cache de objetos e o edge da CDN capturam, cada um, uma classe diferente de solicitação, e o valor está em como eles se integram e transferem as requisições entre si.
LiteSpeed Enterprise + LSCache: a camada de página inteira
Cada site é executado no LiteSpeed Enterprise com LSCache em nível de servidor. Quando uma resposta de front-end pode ser armazenada em cache, o servidor web a identifica com cabeçalhos de controle de cache e de tags do LiteSpeed, e o LiteSpeed entrega a página completa diretamente no próximo acesso — nenhum processo PHP é gerado, nenhuma consulta MySQL é emitida. Essa é a maior alavanca individual para o TTFB do WordPress, pois remove toda a inicialização da aplicação do caminho crítico.
Como o LSCache reside dentro do servidor web em vez de em um plugin PHP, ele começa a operar mais cedo no ciclo de vida da requisição e mantém as páginas em um formato que o servidor pode liberar instantaneamente. Um rastreador de cache mantém as páginas populares aquecidas, para que o primeiro visitante após uma limpeza não seja quem arca com a regeneração da página. O resultado é um TTFB visivelmente menor e mais consistente do que o de um cache baseado apenas em plugin acoplado a uma pilha genérica, onde o cache ainda fica atrás do PHP.
Nosso próprio plugin de cache de nível de repositório já vem pré-instalado e com atualização automática em todos os sites, conectando o WordPress ao LSCache corretamente e de forma imediata. Em uma origem que não seja LiteSpeed, ele simplesmente não emite cabeçalhos de página inteira e não interfere, enquanto o cache de objetos e as regras de exclusão continuam funcionando — assim, um site migrado nunca fica quebrado ou parcialmente configurado.
Mantendo a rapidez sem entregar conteúdo obsoleto: ESI e expurgo automático inteligente
O cache agressivo de página inteira tem dois modos clássicos de falha: entregar a um usuário conectado a página de outra pessoa e entregar a qualquer pessoa uma página que deveria ter sido alterada. Ambos são resolvidos na camada de cache, e não armazenando menos em cache.
O ESI (Edge Side Includes) nos permite armazenar a página em cache enquanto abre exceções para as partes que devem permanecer dinâmicas. Em uma loja WooCommerce, as páginas de catálogo, produto e categoria são servidas como cache de página inteira para o TTFB mais rápido possível, enquanto o ESI renderiza o fragmento do carrinho, os totais do minicarrinho e o status da conta por solicitação. Carrinho, finalização de compra, minha conta e quaisquer páginas de nonce ou sessão são excluídos por padrão. Os clientes sempre veem sua própria cesta e uma finalização de compra funcional; todos continuam recebendo a vitrine a partir do cache.
O frescor do conteúdo é gerenciado pela limpeza automática inteligente. Os ganchos de limpeza são acionados automaticamente quando o conteúdo, produtos, preços ou pedidos são alterados, para que as páginas em cache relevantes sejam atualizadas imediatamente, em vez de dependerem de um temporizador, e você também pode fazer a limpeza sob demanda no painel ou dentro do WordPress. A limpeza baseada em tags significa que a edição de um post limpa apenas esse post e seus arquivos — e não todo o cache —, portanto, uma única edição não reinicia o site inteiro do zero.
Cache de objetos Redis por site: para o que não pode ser uma página inteira
Nem toda requisição pode ser uma página estática inteira. Sessões iniciadas, o painel do WordPress, carrinhos do WooCommerce, buscas e os fragmentos dinâmicos que o ESI mantém ativos precisam executar PHP. Para esses casos, o objetivo muda de 'ignorar a aplicação' para 'ignorar o banco de dados'.
Cada site recebe seu próprio cache de objetos Redis dedicado. O WordPress armazena em cache os resultados de leituras repetidas do banco de dados — opções, transients, consultas de posts e termos, dados de produtos e de sessões do WooCommerce — na memória, para que a mesma consulta não seja executada no MySQL a cada acesso. O efeito é mais visível exatamente onde o cache de página inteira não pode ajudar: painéis mais rápidos, carrinhos mais rápidos e uma carga de banco de dados muito menor sob tráfego.
O cache de objetos é por site, não compartilhado, o que é importante tanto para o desempenho quanto para o isolamento. Combinado com a limitação de banco de dados por site, as consultas pesadas ou mal escritas de um site não podem esgotar os recursos do banco de dados para os vizinhos. Você pode ler mais sobre como toda a configuração de várias camadas se integra em nossa página de recursos de cache e sobre os limites entre os locatários sob isolamento.
A borda e o transporte subjacente
O cache que reside na origem ainda precisa atravessar a rede. Na frente do servidor fica a borda da CDN, de modo que recursos estáticos e páginas que podem ser armazenadas em cache sejam servidos a partir de um ponto de presença próximo ao visitante, mantendo a origem tranquila mesmo sob carga. Para nossa linha de hospedagem footprint-free, essa mesma borda é um pool multi-CDN distribuído por vários provedores, atendendo tanto a uma meta de footprint quanto de desempenho; no WordPress convencional, é simplesmente uma camada rápida e bem-comportada que mantém as origens ociosas.
Por baixo dos panos, a infraestrutura básica não foi negligenciada. Os sites operam em armazenamento NVMe com HTTP/3, portanto os bytes enviados pelo cache chegam por meio de um transporte moderno e multiplexado, com armazenamento rápido por trás de qualquer falha de cache (cache miss). Nenhuma dessas camadas é um adicional pago: LiteSpeed, LSCache, Redis por site, NVMe e HTTP/3 são o padrão básico em todos os planos, e não um nível superior para venda casada.
O que realmente move o Core Web Vitals
Vale a pena ser preciso, pois a hospedagem costuma ser superestimada em relação aos Core Web Vitals. O TTFB é a parte da equação que cabe ao servidor, e a pilha de cache acima é o que o reduz — uma página inteira em cache servida via HTTP/3 a partir da borda é praticamente o menor TTFB possível. Como o TTFB é o ponto de partida do Largest Contentful Paint, uma origem rápida proporciona a cada métrica subsequente uma vantagem inicial que não poderia ser obtida de outra forma.
Mas o LCP, o CLS e o INP são decididos principalmente no navegador, pela própria página: uma imagem principal (hero) não otimizada, CSS e JavaScript que bloqueiam a renderização, layouts que se deslocam conforme fontes e anúncios são carregados e o processamento pesado na thread principal causado por plugins. Nenhuma quantidade de cache no servidor corrige uma imagem principal de 2 MB ou um tema que carrega megabytes de JavaScript. Uma hospedagem honesta torna a contribuição do servidor efetivamente neutra e consistente; cabe então ao site manter o front-end leve.
Essa divisão de trabalho é o modelo mental ideal. Nós garantimos que a requisição chegue rápido ao navegador e continue rápida sob tráfego; o senhor mantém a carga útil pequena e estável. Onde os dois se encontram — aquecimento de cache, entrega na borda e manutenção da capacidade de resposta do banco de dados para que páginas dinâmicas não travem — é exatamente onde nossa pilha é ajustada, e é o que torna o WordPress gerenciado nesta plataforma mais rápido do que o mesmo site em uma hospedagem genérica.
Perguntas frequentes
Eu ainda preciso de um plugin de cache como o WP Rocket?
Não. O cache de página inteira é gerenciado no servidor Web pelo LSCache do LiteSpeed, e nosso próprio plugin de cache — pré-instalado e atualizado automaticamente — conecta o WordPress a ele corretamente, com um cache de objetos Redis por site em segundo plano. Adicionar um segundo plugin de cache de página inteira normalmente entra em conflito com o cache no nível do servidor em vez de ajudar, portanto, não é necessário nem recomendado.
O cache causará problemas no meu carrinho do WooCommerce ou nas páginas para usuários conectados?
Não. Cart, checkout, my-account e quaisquer páginas de nonce ou session são excluídas do cache por padrão, e o ESI mantém o fragmento do carrinho e os totais atualizados em páginas que, de outra forma, seriam armazenadas em cache. Os compradores sempre veem seu próprio carrinho e um checkout funcional, enquanto a vitrine da loja ainda é carregada do cache.
Como o cache permanece atualizado quando eu publico ou edito?
A limpeza automática inteligente é acionada nos hooks relevantes do WordPress; portanto, publicar, editar conteúdo ou alterar um produto, preço ou pedido limpa apenas as páginas afetadas e seus arquivos — não todo o cache — e um rastreador as reaquece. Você também pode realizar a limpeza sob demanda a partir do painel ou de dentro do WordPress.
A hospedagem por si só pode me proporcionar Core Web Vitals perfeitos?
Ele oferece o melhor TTFB possível, que é a contribuição do servidor e uma vantagem inicial para o Largest Contentful Paint. Mas LCP, CLS e INP são determinados em grande parte pela própria página — tamanhos de imagem, recursos que bloqueiam a renderização, estabilidade do layout e JavaScript na thread principal. Nossa pilha torna a contribuição do servidor rápida e consistente; manter a carga do front-end enxuta é o que fecha o restante da lacuna.
Relacionado
Experimente grátis por 14 dias
Crie seus primeiros sites gratuitamente por 14 dias — sem necessidade de cartão. Vai migrar uma rede existente? As migrações são gratuitas e ilimitadas.
Comece grátis