Hospedagem e desempenho
Como tornamos o WordPress rápido: LiteSpeed Enterprise, LSCache e Redis por site
A solicitação WordPress mais rápida é aquela que nunca é executada — veja como nossa pilha responde à maioria das visitas a partir do cache antes que o PHP ou o MySQL sejam sequer chamados, e o que isso significa para os Core Web Vitals.
A solicitação mais rápida é aquela que nunca é executada
Uma solicitação padrão do WordPress é custosa. O servidor web transfere o processo para o PHP, que inicia o WordPress, executa os plugins, consulta o MySQL dezenas de vezes, monta o HTML e só então envia os bytes de volta. Em um site movimentado, todo esse processo acontece para cada visitante, e é para onde vai quase todo o seu tempo até o primeiro byte.
Nossa resposta é garantir que, para a maioria das visitas, nada disso aconteça. Em todos os sites que hospedamos — mais de 100.000 sites PBN além de WordPress gerenciado convencional —, a grande maioria das visualizações de páginas front-end é servida como uma página inteira pré-renderizada diretamente do cache, sem chamar o PHP ou tocar no banco de dados. O resto desta postagem trata de como as camadas que tornam isso possível se encaixam e onde cada uma conquista seu lugar.
O enquadramento importante é que estes não são caches concorrentes entre os quais você escolhe. O cache de página inteira, o cache de objetos e a borda da CDN capturam cada um uma classe diferente de requisição, e o valor está em como eles se transferem entre si.
LiteSpeed Enterprise + LSCache: a camada de página inteira
Cada site roda em LiteSpeed Enterprise com LSCache em nível de servidor. Quando uma resposta de front-end é cacheável, o servidor web a marca com os cabeçalhos de controle de cache e tags do LiteSpeed, e o LiteSpeed serve a página completa diretamente na próxima solicitação — nenhum processo PHP é iniciado, nenhuma consulta MySQL é executada. Essa é a alavanca mais importante para o TTFB do WordPress, pois ela remove toda a inicialização da aplicação do caminho crítico.
Como o LSCache vive dentro do servidor web em vez de em um plugin PHP, ele começa a funcionar mais cedo no ciclo de vida da requisição e mantém as páginas em um formato que o servidor pode descarregar instantaneamente. Um rastreador de cache mantém as páginas populares aquecidas, de modo que o primeiro visitante após uma limpeza não seja aquele que paga para regenerar a 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 plug-in de cache de nível de repositório vem pré-instalado e com atualização automática em todos os sites, conectando o WordPress ao LSCache corretamente por padrão. Em uma origem que não seja LiteSpeed, ele simplesmente não emite nenhum cabeçalho de página inteira e sai do caminho, enquanto o cache de objetos e as regras de exclusão continuam fazendo seu trabalho — portanto, um site migrado nunca fica em um estado quebrado e parcialmente configurado.
Mantendo a velocidade sem servir conteúdo desatualizado: ESI e limpeza automática inteligente
O cache de página inteira agressivo tem duas falhas clássicas: servir a página de outra pessoa para um usuário conectado e servir a qualquer pessoa uma página que deveria ter sido alterada. Ambas são resolvidas na camada de cache, em vez de armazenar menos em cache.
O ESI (Edge Side Includes) nos permite fazer o cache da página enquanto criamos exceções para as partes que precisam continuar ativas. 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 mini-carrinho e o estado da conta por requisição. O carrinho, o checkout, a minha conta e quaisquer páginas de nonce ou sessão são excluídos por padrão. Os compradores sempre veem seu próprio carrinho e um checkout funcional; todos ainda recebem a vitrine a partir do cache.
A atualização é gerenciada por um recurso inteligente de limpeza automática. Os ganchos de limpeza são acionados automaticamente quando conteúdo, produtos, preços ou pedidos são alterados, para que as páginas em cache relevantes sejam atualizadas imediatamente, em vez de por um cronograma, e você também pode fazer a limpeza sob demanda no painel ou de dentro do WordPress. A limpeza baseada em tags significa que editar uma postagem limpa apenas essa postagem e seus arquivos — e não o cache inteiro —, portanto, uma única edição não causa uma inicialização a frio em todo o site.
Cache de objetos Redis por site: para o que não pode ser uma página inteira
Nem toda solicitação pode ser uma página estática completa. Sessões com login, o painel do WordPress, carrinhos do WooCommerce, buscas e os fragmentos dinâmicos deixados pelo ESI 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 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, e não compartilhado, o que importa tanto para o desempenho quanto para o isolamento. Combinado com a limitação de taxa de banco de dados por site, consultas pesadas ou mal escritas de um único site não conseguem esgotar o banco de dados para os vizinhos dele. Você pode ler mais sobre como toda a configuração multicamada se encaixa na nossa página de recursos de cache, e sobre os limites entre inquilinos em isolamento.
A borda e o transporte subjacente
O cache que fica na origem ainda precisa atravessar a rede. Na frente do servidor fica a borda da CDN, de modo que ativos estáticos e páginas armazenáveis em cache são servidos a partir de um ponto de presença próximo ao visitante, e a origem permanece silenciosa mesmo sob carga. Para a nossa linha de hospedagem Footprint-Free, essa mesma borda é um pool multi-CDN distribuído por vários provedores, que atende a um objetivo de footprint e também de desempenho; no WordPress tradicional, trata-se simplesmente de uma camada rápida e bem comportada que mantém as origens ociosas.
Por baixo do capô, os fundamentos não são negligenciados. Os sites rodam em armazenamento NVMe com HTTP/3, garantindo que os bytes enviados pelo cache cheguem 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 complemento opcional: LiteSpeed, LSCache, Redis por site, NVMe e HTTP/3 são a base em todos os planos, e não um nível superior de preço.
O que realmente move o Core Web Vitals
Vale a pena ser preciso, porque a hospedagem costuma ser excessivamente prometida em relação ao Core Web Vitals. O TTFB é a parte da equação que pertence 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 é o mais próximo que o TTFB pode chegar do mínimo. Como o TTFB é a ponta de lança do Largest Contentful Paint, uma origem rápida dá a todas as métricas subsequentes uma vantagem inicial que elas não teriam de outra forma.
Mas o LCP, o CLS e o INP são decididos principalmente no navegador, pela própria página: uma imagem de destaque não otimizada, CSS e JavaScript que bloqueiam a renderização, layout que se desloca à medida que fontes e anúncios são carregados, e muito trabalho na thread principal vindo de plugins. Nenhum cache de servidor resolve uma imagem de destaque de 2 MB ou um tema que entrega megabytes de JavaScript. Uma hospedagem honesta torna a contribuição do servidor efetivamente gratuita e consistente, e então cabe ao site manter o front-end enxuto.
Essa divisão do trabalho é o modelo mental útil. Nós garantimos que a solicitação chegue rápido ao navegador e permaneça rápida sob tráfego; você mantém a carga útil pequena e estável. Onde os dois se encontram — aquecimento de cache, entrega na borda e manutenção da resposta do banco de dados para que as páginas dinâmicas não travem — é exatamente onde nossa pilha é otimizada, e é o que torna o WordPress gerenciado nesta plataforma mais rápido do que o mesmo site em um host genérico.
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. Sobrepor um segundo plugin de cache de página inteira geralmente entra em conflito com o cache em nível de servidor em vez de ajudar, portanto, não é necessário e não é recomendado.
O cache vai quebrar meu carrinho do WooCommerce ou minhas páginas de login?
Não. O carrinho, o checkout, a minha conta e quaisquer páginas com nonce ou sessão são excluídos 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, estariam em cache. Os compradores sempre veem sua própria cesta e um checkout funcional, enquanto a vitrine ainda é carregada a partir do cache.
Como o cache se mantém atualizado quando publico ou edito?
A limpeza automática inteligente é acionada nos ganchos 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 aquece novamente. Você também pode fazer a limpeza sob demanda a partir do painel ou de dentro do WordPress.
A hospedagem sozinha pode me dar Core Web Vitals perfeitos?
Isso proporciona o melhor TTFB possível, que é a parte do servidor e uma vantagem inicial para o Largest Contentful Paint. Mas o LCP, o CLS e o INP são decididos em grande parte pela própria página — tamanhos de imagem, recursos que bloqueiam a renderização, estabilidade de layout e JavaScript da thread principal. A nossa pilha torna a contribuição do servidor rápida e consistente; manter o payload do front-end enxuto é o que fecha o restante da lacuna.
Relacionado
Experimente grátis por 14 dias
Crie seus primeiros sites gratuitamente por 14 dias — sem cartão. Vai mover uma rede existente? Sua primeira migração é por nossa conta.
Comece grátis