Benchmark do WordPress: testar o desempenho da hospedagem de forma reproduzível

O que um benchmark do WordPress revela

A Benchmark do WordPress Começa com uma pergunta concreta: uma determinada página carrega rapidamente em condições específicas? Para tal, um navegador carrega HTML, imagens, scripts e outros recursos e apresenta a página. O resultado descreve a interação destes componentes, e não apenas a velocidade do servidor de alojamento.

Uma segunda questão diz respeito ao Comportamento de resposta sob carga: Como é que os tempos de resposta e os erros variam quando chegam pedidos de acordo com um perfil definido? Uma única visualização da página não dá resposta a esta questão. Por outro lado, um teste de carga HTTP não mostra imediatamente a rapidez com que um navegador carrega a página completa de forma visível.

No caso de um artigo de blogue público, um cache de página pode fornecer código HTML já pronto; uma CDN pode disponibilizar recursos ou respostas mais próximas do local de medição. Ao mesmo tempo, o tema, os plugins, as imagens e os scripts externos influenciam o resultado. O artigo sobre explica quais outras causas podem tornar uma página mais lenta Fatores ocultos que prejudicam o desempenho do WordPress.

Para avaliar a influência do alojamento, há duas perguntas comparativas que ajudam. No caso do Comparação de pilhas Adapta o site e as definições tanto quanto possível e regista as diferenças que subsistirem. Ao comparar os pacotes, verifica as configurações disponibilizadas, incluindo as respetivas caches e serviços. Isto é útil para a decisão de compra, mas não isola o desempenho puro do servidor.

Por isso, registe qual a página, qual a tarifa e qual o ambiente a que cada resultado se refere. Uma vantagem para o artigo do blogue testado pode apresentar-se de forma diferente quando visualizado a partir de uma conta registada. A medição aplica-se às condições e ao período por si documentados; não constitui nem um vencedor geral do teste nem uma garantia de desempenho.

Compreender a medição do navegador e os dados de campo

Um teste de velocidade do WordPress com o Lighthouse fornece um Imagem de laboratório da página em determinadas condições de medição. O perfil do navegador, o dispositivo ou a emulação, o perfil de rede, o local da medição e a versão da ferramenta devem, por isso, constar do registo. Só assim será possível avaliar posteriormente se duas execuções são, de facto, comparáveis.

O Lighthouse Performance Score resume vários indicadores de forma ponderada. Pode variar devido a alterações no conteúdo e nas condições de medição e não revela qual das métricas individuais sofreu alterações. Repete a medição com o mesmo perfil e regista os valores individuais de todas as execuções, em vez de selecionares apenas a melhor pontuação.

Entre os indicadores importantes está o LCP: este descreve quando é que o maior elemento de conteúdo relevante fica visivelmente carregado. O CLS regista deslocamentos inesperados no layout durante a utilização. O INP descreve a capacidade de resposta às interações; para tal, são necessárias interações efetivamente registadas e não é determinado apenas por uma simples visualização da página.

O Relatório Chrome UX, ou CrUX, por sua vez, fornece, quando disponíveis, Dados de campo resultantes das visitas de utilizadores reais participantes. Estas experiências dependem, entre outros fatores, dos seus dispositivos e redes. Não estão disponíveis para todas as páginas e respondem a uma questão diferente daquela a que responde um teste de laboratório realizado em condições controladas.

Indique, para cada valor, se este provém do laboratório ou do ambiente real. Uma consulta HTTP simples pode, por exemplo, registar o estado e o tempo de resposta, mas não executa automaticamente a renderização e as interações de um navegador. Por conseguinte, a partir dela não é possível interpretar o LCP, o CLS e o INP como parte da experiência do navegador.

Distinguir corretamente os níveis de cache

A Cache de página pode armazenar código HTML já pronto para pedidos repetidos. Por outro lado, uma cache de objetos armazena dados da aplicação de que o WordPress necessita durante o processamento. Além disso, o navegador pode reutilizar localmente recursos já carregados; uma CDN pode armazenar temporariamente conteúdos num nível adicional, fora do servidor original.

No caso de uma cache de páginas aquecida, acedes repetidamente a uma página pública após um período de aquecimento documentado. Isto é relevante para conteúdos frequentemente visitados, mas pouco revela sobre o custo da sua geração dinâmica. Regista quais as URLs que foram aquecidas e quais as regras de cache e definições de CDN que se aplicaram.

Para uma consulta sem cache, tens de definir o Contorno da cache verificar de forma compreensível, em vez de simplesmente aceitá-la. Uma sessão registada pode seguir outras regras e apresentar conteúdos personalizados. Verifica a resposta efetiva dessa sessão: uma consulta rápida tem pouco valor se apresentar um conteúdo errado ou desatualizado.

Uma primeira visita num novo estado do navegador não indica necessariamente que a cache do servidor ou da CDN esteja vazia. Da mesma forma, uma falha na CDN não significa automaticamente que a cache da aplicação tenha sido esvaziada. Os cabeçalhos de cache podem fornecer pistas, mas, dependendo do fornecedor, não comprovam o estado de cada nível envolvido; por isso, documente também as configurações e os métodos de verificação disponíveis.

Sem uma extensão persistente adequada, a cache de objetos do WordPress está, em princípio, limitada à respetiva solicitação. A constante WP_CACHE Por si só, não ativa nem o Redis nem uma solução de cache automática. O papel que o Redis e o Memcached podem desempenhar como cache de objetos persistente é explicado no artigo sobre Redis e Memcached na hospedagem do WordPress.

Preparar a comparação e as aprovações

Para comparares serviços de alojamento, precisas, em primeiro lugar, de um estado comparável do site. Crie uma cópia limpa com os mesmos conteúdos, a mesma base de dados, o mesmo tema e os mesmos plugins, incluindo as respetivas versões. Remova ou substitua os dados pessoais e as credenciais de acesso ao ambiente de produção, de forma a que o site de teste continue a refletir o caso de utilização pretendido.

Utilize, na medida do possível, as mesmas versões de PHP e da base de dados, bem como as definições relevantes. Registe as diferenças que não possam ser eliminadas ou que façam parte do pacote contratado. Uma comparação entre os respetivos pacotes padrão responde a uma questão diferente daquela a que responde uma comparação de pilhas o mais harmonizadas possível: o resultado não pode ser facilmente atribuído apenas ao desempenho do servidor.

Antes da primeira execução, defina um plano de medição. Este deve ser suficientemente concreto para que outra pessoa consiga compreender a configuração e identificar eventuais desvios caso a medição venha a ser repetida. A lista de verificação que se segue distingue as características da oferta de alojamento das do site e da medição.

• Plano tarifário, limites de recursos, localização do servidor e versões de software de ambos os ambientes.
• URLs de teste e tipos de páginas, estado de início de sessão, cookies e contas de teste utilizadas.
• CDN, cache de páginas e cache de objetos, incluindo regras, fase de aquecimento e desvio programado.
• Local de medição, versão da ferramenta, perfil do navegador e do dispositivo, condições de rede, horários e repetições.
• Perfil de carga, responsabilidades, janela de teste acordada e limites concretos de interrupção.

Para os testes de carga, deves combinar o Libertação Fala com todos os responsáveis e, se for o caso, com o fornecedor de alojamento, antes de gerares tráfego. Esclarece quem são os contactos, os limites de recursos e o procedimento a seguir em caso de falhas. Exclui serviços externos sem o consentimento destes; evita, em particular, pagamentos reais, encomendas e notificações. Verifica antecipadamente se a cópia de teste impede efetivamente tais operações.

Conceito de medição para páginas típicas

Escolhe a ferramenta com base na questão, e não com base no melhor valor individual possível. Uma Conceito de medição atribui a cada linha um tipo de página e um estado de cache. A tabela mostra quais os resultados que podem ser obtidos com as respetivas abordagens e quais são os seus limites.

Para um artigo de blogue público, mede a mesma URL representativa várias vezes utilizando um perfil fixo de navegador e de rede. Anota se o CDN e a cache da página estão ativados e como a página foi pré-carregada antes dos testes. Desta forma, é possível avaliar a experiência de carregamento desta página pública, e não automaticamente a de uma sessão com início de sessão.

Uma pesquisa dinâmica ou visualização de conta recebe uma série de testes própria com dados de teste disponibilizados e, se necessário, uma conta de teste. Não verifique apenas o código de estado: a resposta tem de corresponder à consulta de pesquisa ou à conta em que se iniciou sessão e estar atualizada. Verifique também se existe um Contorno da cache funciona de facto; um cookie, por si só, não prova isso.

O facto de os tempos de resposta variarem não significa que a causa já tenha sido identificada. A lógica da aplicação, os acessos à base de dados, um cache de objetos persistente e o ambiente de alojamento podem, cada um deles, contribuir para esse resultado. Documenta as diferenças na estrutura e analisa-as posteriormente de forma específica, em vez de considerares uma única consulta lenta como prova de um determinado gargalo.

Aumentar a carga de forma controlada

Comece numa página de teste expressamente autorizada, com um número reduzido de consultas individuais. Verifique o estado e o conteúdo e certifique-se de que não surgem efeitos secundários indesejáveis. Só depois disso se realiza um teste de carga acordado separadamente, por exemplo, para páginas de produtos autorizadas de uma loja online. Encomendas, pagamentos e notificações reais continuam a estar excluídos.

Planeia uma carga gradual com nível inicial, duração e incrementos. Acorda antecipadamente limites de interrupção mensuráveis para erros, tempos de resposta ou outros valores operacionais disponíveis, bem como um contacto para a interrupção. Limita-te aos processos expressamente autorizados; uma visualização do produto não fornece qualquer informação sobre um processo de checkout não testado.

No modelo de carga fechada, uma instância virtual de utilizador aguarda o fim da sua iteração atual antes de iniciar a seguinte. Se a aplicação ficar mais lenta, a carga oferecida pode diminuir em consequência disso. Este modelo é adequado para processos em que essa espera faz precisamente parte do processo; no entanto, não mantém uma taxa de chegada fixa.

A modelo de carga aberto Por outro lado, planeia novas iterações independentemente de as anteriores terem sido concluídas. Para tal, o gerador de carga deve dispor de capacidade suficiente e de instâncias virtuais de utilizador disponíveis. Se não for possível iniciar as iterações, o teste não atinge o perfil planeado; por isso, documente também estas iterações que não foram iniciadas.

Registe tanto a taxa definida como a taxa efetivamente atingida. As iterações por segundo só correspondem a pedidos por segundo se cada iteração gerar exatamente um pedido. Registe também a distribuição dos tempos de resposta, os erros e os tempos de espera, bem como a verificação da correção dos conteúdos: um elevado débito com respostas erradas não constitui um teste de carga bem-sucedido.

Analisar séries de medições de forma compreensível

Uma série de medições só é significativa se for considerada no seu conjunto. Por isso, registe, para cada página testada e cada etapa de carga, o número de pedidos analisados, bem como o número de erros e de tempos de espera excedidos. Distinga as respostas bem-sucedidas das que falharam, sem omitir as falhas do relatório: um tempo de resposta baixo acompanhado de muitos erros não indica um serviço fiável e rápido.

O Mediana descreve o valor médio das medições bem-sucedidas ordenadas. O percentil 95, abreviado p95, indica adicionalmente um limiar abaixo do qual se situam aproximadamente 95 por cento destes valores de medição. Quando o número de consultas é reduzido, o p95 depende fortemente de observações individuais; por isso, deve sempre indicar a dimensão da amostra e interpretar as diferenças com cautela.

Regista também, para cada execução, o modelo de carga e a taxa efetivamente atingida. Uma taxa configurada, por si só, não indica se o gerador conseguiu iniciar todas as iterações planeadas. O modelo seguinte permanece em branco até à medição; cada execução tem o seu próprio registo.

Guarde os dados brutos, o script de teste e a configuração juntamente com o registo. Desta forma, será possível verificar posteriormente quais as consultas que foram incluídas numa análise e se duas séries são, de facto, comparáveis. Não selecione posteriormente apenas a execução mais rápida: se os resultados se sobreporem significativamente, a diferença observada pode estar dentro das variações.

Além dos indicadores, inclua também anomalias no conteúdo, como, por exemplo, uma página de início de sessão inesperada em vez da visualização da conta esperada. Um estado de sucesso técnico não prova, por si só, que a página correta tenha sido apresentada. Esses desvios devem ser incluídos separadamente na descrição do erro e podem tornar uma série de medições inutilizável para a decisão planeada.

Identificar as causas e voltar a medir

Começa a procura de erros pela resposta fornecida: o conteúdo, o estado da sessão e o URL testado estão corretos? Em seguida, verifica o documentado Estado da cache e o ambiente de medição. Cookies diferentes, um local de medição distinto ou uma regra de CDN alterada podem fazer com que duas execuções sejam diferentes, sem que o desempenho da pilha de aplicações propriamente dita tenha sofrido alterações.

Só depois disso é que os dados operacionais disponíveis ajudam a identificar o problema: a ocupação de recursos e as filas de espera podem indicar pontos de estrangulamento, enquanto as informações da aplicação ou da base de dados podem indicar um processamento demorado. Um único valor HTTP lento não identifica a causa. O WordPress refere, para além do alojamento, também o software, a configuração e os conteúdos como fatores que influenciam o desempenho.

Para uma comparação «antes e depois», altera deliberadamente apenas uma configuração, como, por exemplo, a integração de um cache de objetos persistente. O estado do site, a página de teste, o perfil de carga e o local de medição devem permanecer, na medida do possível, inalterados; documenta também o tempo de aquecimento do cache em cada caso. Sem uma implementação persistente adequada, o cache de objetos do WordPress está limitado a cada pedido individual, pelo que é necessário verificar a sua integração efetiva.

Realiza várias execuções antes e depois da alteração e distribui-as ao longo do tempo. Desta forma, poderás perceber melhor se uma diferença ocorre de forma recorrente ou se pode estar relacionada com flutuações normais. Ao fazê-lo, compara não só a mediana e o p95, mas também os erros, o conteúdo das respostas e a taxa alcançada; caso contrário, uma aparente aceleração pode dever-se a alterações nas condições do teste.

Mesmo uma comparação minuciosa não controla todos os fatores. No caso do alojamento partilhado, outros utilizadores e infraestruturas não visíveis podem influenciar o resultado. Se te faltarem dados sobre recursos ou filas, regista expressamente essa lacuna e formula uma causa presumida como hipótese, em vez de a apresentares como um resultado comprovado.

Interpretar corretamente o resultado do alojamento

Baseia a tua decisão sobre o alojamento nas páginas e nos processos que são importantes para o teu site. Um artigo de blogue público com um cache de página ativo pode gerar uma carga diferente da de uma visualização de conta de utilizador registado. Por isso, bons resultados de cache em páginas públicas não garantem respostas personalizadas rápidas nem um processo de checkout robusto.

Antes da comparação, defina quais os tempos de resposta, as taxas de erro e o perfil de carga que são aceitáveis para cada processo. Verifique, em seguida, se as séries de medições documentadas cumprem estes requisitos nas condições acordadas. Isto inclui também conteúdos corretos e um funcionamento estável; uma elevada taxa de consultas, por si só, não constitui uma base de decisão suficiente.

Conjunto utilizadores virtuais não são equivalentes aos visitantes reais que se encontram presentes ao mesmo tempo. O seu comportamento resulta do script de teste e do modelo de carga: no modelo fechado, uma instância aguarda o fim da sua iteração antes de iniciar a seguinte. Por conseguinte, sem um modelo de comportamento adequado, não é possível deduzir um número real de visitantes a partir do seu número.

Relata o resultado juntamente com a tarifa, o estado do site, os URLs testados, as regras de cache e CDN, o local de medição e o período. Distingue também se comparaste pilhas (stacks) o mais semelhantes possível ou os pacotes completos oferecidos em cada caso. Na comparação de pacotes, as diferenças de configuração podem influenciar o resultado; esta comparação não isola automaticamente o desempenho puro do servidor.

Se as séries se sobreporem significativamente ou se não for possível controlar suficientemente o ambiente, a afirmação „não foi comprovada qualquer diferença significativa“ é uma conclusão possível e útil. Isso não significa que ambas as ofertas tenham a mesma velocidade em todas as condições. Significa apenas que o teste em questão não permite estabelecer a distinção pretendida.

Para os controlos operacionais, guarda o perfil de medição e repete medições selecionadas do navegador e da carga após alterações significativas ou em intervalos acordados. Compara os novos resultados apenas com séries anteriores adequadas e documenta as alterações no conteúdo, nas versões e nas regras de cache. Os testes de carga continuam a exigir um intervalo de tempo aprovado e limites de interrupção acordados.