Desempenho
Cada site WordPress recebe um cache de página inteira e um cache de objetos Redis por site, incluídos na hospedagem e executados no servidor, em vez de em um plugin que você precisa configurar. Ambos são opções na aba Desempenho do site, e a mesma aba mede o que eles alteram: Core Web Vitals de visitantes reais, tempos de resposta de requisições medidos no servidor e criação de perfil em nível de código que identifica o plugin ou a consulta que está consumindo tempo.
Estes recursos já vêm incluídos na hospedagem. Eles não são um plano à parte e desativar o upgrade pago nunca os remove — o que é importante, pois um downgrade que removesse discretamente seu cache estaria tirando algo que você nunca comprou e pelo qual nunca deixou de pagar.
As páginas renderizadas são servidas diretamente do cache, ignorando o PHP completamente para visitantes que não estão conectados. Para um site de conteúdo ou institucional, este é o maior ganho disponível, sendo a diferença entre um servidor que suporta um pico de tráfego sem esforço e um que cai.
Um cache de objetos persistente impede que o WordPress reconstrua a mesma consulta de banco de dados a cada requisição, para que as páginas sejam montadas mais rapidamente sob carga e o banco de dados permaneça estável. Por site, não compartilhado — seu cache não sofre remoções causadas por outros.
Carrinhos, páginas de finalização de compra, páginas de conta e qualquer conteúdo exibido a um visitante conectado são excluídos por padrão, tanto para o WordPress quanto para o WooCommerce. Um cache que exibe a cesta de um cliente para outro não é um recurso de desempenho.
Publique um post e isso limpará esse post e as listagens em que ele aparece; um comentário limpa seu item pai; uma troca de tema limpa tudo.
O armazenamento em cache torna a veiculação de uma página mais econômica. Ele não torna uma imagem pesada mais leve nem impede que um script de bloqueio continue bloqueando — esse é um trabalho no próprio site, e é para isso que serve a aceleração especializada.
| Cache incluído | Aceleração especializada | |
|---|---|---|
| Cache de página inteira (LiteSpeed LSCache) | Sim | Configured for how the site is built |
| Cache de objetos Redis por site | Sim | Configured and tuned |
| Compressão de imagem e formatos modernos | Não | Sim |
| CSS e scripts que bloqueiam o Render | Não | Deferred; critical CSS on the heaviest tier |
| Uma CDN na frente do site | From the CDN tab | From the CDN tab |
| Como é cobrado | With the hosting | One-off, by how complex the site is |
| Quem realiza o trabalho | You switch it on | Our engineers |
| Como você obtém | The Performance tab | Bought as an add-on |
O preço da aceleração especializada é definido de acordo com a complexidade do site, pois a complexidade determina a quantidade de horas necessárias — consulte a página de aceleração para conferir o que cada plano inclui.
Todo site tem um. Ele mostra o cache que já está ativado, o que os visitantes reais estão vivenciando e para onde está indo o tempo do seu site.
O cache de página e o cache de objeto estão incluídos e listados lá. Cada um tem seu próprio interruptor, para que um site que precise deixar um desativado mantenha o outro.
Leia primeiro o cartão do Core Web Vitals e os tempos do lado do servidor, para que você tenha uma base de comparação em vez de apenas uma impressão.
Se os números ainda forem decepcionantes, o gargalo geralmente não é o cache — são as imagens, um plugin ou uma consulta. A aceleração especializada consiste em nossos desenvolvedores encontrarem e corrigirem exatamente isso.
Provas, não impressões
O Core Web Vitals vem do que os visitantes reais realmente vivenciaram, verificado automaticamente para a sua página inicial e sob demanda para qualquer outra página. Os tempos do lado do servidor são solicitações reais atendidas pelo seu site, cronometradas no servidor antes que qualquer coisa chegasse a um navegador — portanto, uma página lenta é separada de uma rede lenta.
A criação de perfil a nível de código é o que muda o que você faz a seguir: cada requisição é analisada no servidor, e o histórico mostra quais páginas estão mais lentas, qual plugin ou consulta está consumindo o tempo e se a situação está piorando. Uma pontuação em cem diz que há um problema; isto mostra de quem é o problema.
A diferença entre eles é quem faz o trabalho. Escolher o errado é fácil e custoso, então aqui está o guia honesto.
O cache de página e o cache de objeto estão inclusos no seu plano e são alternados na aba «Desempenho». Ideal para a maioria dos sites de conteúdo e institucionais, e não custa nada para você.
Como funciona o cache →Um serviço pontual no qual configuramos o cache de acordo com o seu site real — com as exclusões necessárias e as regras desejadas — e o entregamos funcionando perfeitamente.
Ver os serviços de aceleração →Nossos desenvolvedeurs trabalham no que é realmente lento: uma consulta sem índice, um plugin que executa tarefas pesadas a cada carregamento de página, um tema que renderiza todo o catálogo. O preço varia conforme a complexidade do site.
Otimização especializada de velocidade →O cache de página é do LiteSpeed, e nossa frota executa o LiteSpeed Enterprise. Se você hospeda em outro lugar e deseja o mesmo mecanismo, nós também gerenciamos isso.
LiteSpeed, gerenciado →Uma camada de cache do lado do servidor para o WordPress, gerenciada no nível de hospedagem em vez de por um plugin que você instala e ajusta. Trata-se de um cache de página inteira e um cache de objetos por site, ambos incluídos em seu plano e ambos alternados na aba Performance do site. Não há licença para comprar separadamente nem arquivo de configuração para editar.
Duas camadas de cache, e são opções separadas em vez de uma única configuração. O cache de página entrega páginas renderizadas diretamente do LSCache do LiteSpeed, ignorando totalmente o PHP para visitantes que não estão conectados — o maior ganho isolado para um site de conteúdo ou institucional. O cache de objetos é uma instância do Redis por site que impede o WordPress de reconstruir a mesma consulta de banco de dados a cada requisição. Ambos estão em todos os planos, e desativar o plano pago nunca os remove.
Não. O cache e as otimizações são executados no servidor, abaixo do WordPress. Nós fornecemos o plugin Zinn® Cache como parte da implantação de um site, mas ele é um controlador de cache e não um mecanismo de cache — ele existe para que a publicação de um post limpe exatamente as páginas em que esse post aparece e instrua nossa edge a fazer o mesmo, em vez de você limpar os caches manualmente.
As otimizações são executadas na camada de servidor e de cache e já vêm com padrões seguros, incluindo exclusões para os caminhos do WordPress e do WooCommerce que nunca devem ser armazenados em cache: carrinhos, finalizações de compra, páginas de conta e qualquer conteúdo exibido a um usuário conectado. Se algo precisar ser excluído, o controlador de cache permite que você o exclua em vez de desativar a camada inteira.
A mesma aba mede isso de três maneiras. As Core Web Vitals vêm da experiência real dos visitantes. Os tempos do lado do servidor são solicitações reais atendidas pelo seu site, cronometradas no servidor antes que qualquer coisa chegasse a um navegador. E a criação de perfil em nível de código identifica o plugin, a consulta ou o trecho de código que consumiu o tempo — que é a única das três opções que informa o que realmente deve ser alterado.
Por quem faz o trabalho. O cache nesta página já está ativado e você mesmo o alterna. O serviço de configuração consiste em nós configurarmos adequadamente para o seu site específico, uma única vez. A otimização especializada consiste em nossos desenvolvedores trabalhando nos problemas reais do seu site — imagens, uma consulta lenta, um plugin pesado, um tema realizando algo custoso a cada carregamento de página. Elas não são versões de um único produto; uma delas pode ser exatamente o que você precisa e as outras inúteis.
Cada site WordPress que hospedamos conta com ambas as camadas de cache — elas vêm com a hospedagem, não com um plano específico. O que varia é a máquina subjacente: o cache é executado onde controlamos o servidor, portanto, um site em um pacote gerenciado por fornecedor recebe, em vez disso, o que a plataforma desse fornecedor oferece.
O cache de objetos foi desenvolvido para o WordPress, e é nele que ele faz mais diferença. O cache de página inteira não é específico do WordPress — um aplicativo PHP ou um site estático em nossa frota é atendido pelo mesmo cache de página LiteSpeed, e um site estático é rápido por razões que tornam a maior parte disso irrelevante.
No momento, não. O cache nesta página é o que todos os sites WordPress que hospedamos executam, e ele está incluído. Se suas páginas continuarem lentas depois de ativado, a causa geralmente são imagens, um plugin ou uma consulta, e não o cache — que é o trabalho que a otimização de velocidade especializada faz, manualmente, em seu site específico.
Não há nada para testar: o cache está incluído na hospedagem e já fica ativo desde a primeira implantação. A hospedagem em si inclui um teste de 14 dias sem necessidade de cartão.
Não, e deliberadamente. O AccelerateWP vem com uma CDN integrada e nós nunca a ativamos, porque todo site Zinn® já conta com uma edge escolhida por nós à sua frente — uma segunda CDN à frente significaria dois caches em série, e limpar um deixaria o outro servindo uma página desatualizada. Sua CDN vem da aba CDN do site.
Sim. Ambas as camadas são interruptores na própria aba Desempenho de cada site e são independentes uma da outra — um site que precisa manter o cache de página desativado ainda mantém seu cache de objeto.
Inicie um teste de 14 dias sem cartão. O cache fica ativado desde a primeira implantação — abra a guia Performance e veja o impacto nos seus próprios números.
Comece grátis