Você ainda não sabe como testar seu host WordPress? Dê uma olhada nos bastidores em como testamos o desempenho de hospedagem em alguns dos maiores hosts WordPress da web!

O que começou como um simples exercício interno para ver como hospedagens estavam indo, rapidamente se tornou uma viagem fascinante de autodescoberta.

Uma jornada que decidimos compartilhar com vocês, queridos leitores do blog.

Afinal, temos orgulho de nossa honestidade e integridade por aqui. E assim que decidimos que o levaríamos para um passeio – um dos principais objetivos era ser completamente aberto e transparente. Tanto com os resultados publicados, quanto com nossos métodos de teste.

Uma visão interna de como um de nossos especialistas internos testou a hospedagem em algumas das plataformas mais populares do mercado.

Acompanhe e sinta-se à vontade para recriar a metodologia para você.

* Por falar nisso, todas as ferramentas mencionadas neste artigo são totalmente gratuitas!

Veja como tudo aconteceu …

 

Dev Man tem seu trabalho difícil para ele nesta batalha dos anfitriões.

Dev Man tem seu trabalho difícil para ele nesta batalha dos anfitriões.

 

A primeira etapa foi obviamente criar contas com os provedores de hospedagem com os quais queríamos confrontar.

Falando nisso, aqui estão os bravos provedores de hospedagem DEV que lutaram nesta comparação:

Escolhemos esses oito hosts, porque eles são simplesmente alguns dos maiores nomes da hospedagem WP e porque são as plataformas que sempre parecem estar na língua de nossos membros em conversas e pesquisas.

Também estamos cientes de que não importa com quem escolhermos comparar, nunca agradará a todos. Portanto, se você tiver alguma sugestão de hosts que devemos comparar, informe-nos e faremos o possível para incluí-los em nossa próxima rodada de testes.

Para tornar o teste o mais justo possível, comparamos os planos de nível básico de cada provedor de hospedagem.

Também usamos o mesmo site de teste básico e o adicionamos a cada plano de hospedagem.

Aqui está uma olhada no site de teste que usamos ( amantes de cães, preparem-se para “awwww” ):

 

É hora de fazer o teste [host]!

Depois de estabelecermos os pontos de comparação básicos (e justos), era hora de iniciar o processo de teste.

Queríamos ver como cada servidor de hospedagem funcionava sob pressão. Afinal, a última coisa que você deseja é que seu servidor falhe se houver um fluxo repentino de visitantes.

Também queríamos testar a velocidade de cada host WordPress, pois é importante atender seus clientes em tempo hábil ou eles podem ficar frustrados e clicarem para longe.

Portanto, executamos dois testes principais de desempenho em cada host WordPress:

  1. Um teste de carga de hospedagem.
  2. Um teste de velocidade (TTFB).

Veja como os dois testes se desenvolveram, começando com o teste de carga de hospedagem:

Testar quantos usuários paralelos cada servidor de hospedagem pode controlar.

Para este teste de carga, usamos “ https://loader.io/ ” um serviço de teste de carga gratuito que permite que você teste de estresse seus aplicativos da web e APIs com milhares de conexões simultâneas.

 

Loader.io é o lugar a visitar se você quiser ver do que realmente é feito o seu anfitrião.

Loader.io é o lugar a visitar se você quiser ver do que realmente é feito o seu anfitrião.

 

Loader.io permite que você execute três tipos diferentes de testes :

1. ”Clientes por teste” – Você especifica o número total de clientes a se conectar durante o teste.

 

 

2. ”Clientes por segundo” – Semelhante a “Clientes por teste”, mas em vez de especificar o total, você especifica o número de clientes para iniciar a cada segundo.

 

 

3. ”Manter a carga do cliente” – Este teste permite que você especifique um de X para Y clientes.

 

 

Como nosso objetivo era testar como cada servidor de hospedagem lidou com a pressão do usuário, optamos por executar o teste “Manter a carga do cliente” .

Conforme mencionado, este teste funciona permitindo que você especifique um de X para Y clientes.

O que isso significa é que se você especificar “0” e “2000”, por exemplo, o teste começará com 0 clientes e aumentará para 2.000 clientes simultâneos no final.

Definir os limites do teste de carga do cliente.

Ao executar cada teste de carga, definimos um limite máximo de 5.000 clientes . Achamos que este é um limite apropriado – já que a maioria dos hosts não chega a atingir 1000 clientes de qualquer maneira.

Todos os testes foram executados por 5 minutos e a falha de erro foi definida como 1% assim que os erros começaram a aparecer. Esses erros incluem tempos limite, 400/500 e erros de rede (todos acumulando até 1%).

Escolhemos 1% como o menor valor possível para que o teste parasse imediatamente e fornecesse a leitura mais precisa do máximo de clientes paralelos.

Isso é importante porque se tivéssemos a configuração de falha em 50%, por exemplo, o número de clientes paralelos seria muito mais alto, mas apenas porque mais usuários estão sendo permitidos (devido à configuração de erro mais alta).

Quando, na realidade, eles não deveriam ser contabilizados, pois teriam uma resposta de erro – significando que eram essencialmente visitantes perdidos.

As medições que levamos em consideração.

Com esse teste específico, estávamos mais preocupados com as métricas “ Contagem de respostas” e “Cliente paralelo” .

A contagem de respostas mostra as respostas gerais de sucesso / falha:

 

 

Os clientes paralelos medem a quantidade de usuários que o servidor pode gerenciar de uma vez antes de atingir o limite máximo:

 

 

Por que o número de clientes paralelos que um servidor pode controlar é importante?

Antes de continuar, vamos quebrar essa ideia de “clientes paralelos” um pouco mais…

Em termos simples, o número máximo de clientes paralelos é o número de pessoas que podem enviar a primeira solicitação HTTP para o seu site exatamente ao mesmo tempo.

Por exemplo, digamos que seu número máximo de clientes paralelos seja 50. Isso significa que 50 pessoas podem acessar o site ao mesmo tempo antes que o servidor trave.

Portanto, se 60 pessoas tentarem acessar ao mesmo tempo, o servidor será reiniciado e mostrará um erro interno do servidor pelos próximos minutos enquanto ele volta a funcionar – o que significa que você perderá visitantes

Aqui está uma boa analogia que gostamos de usar:

“Se você preferir ter um bar servindo cerveja para 10 clientes e depois fechá-lo porque o 11 começou um incêndio, tudo bem.”

“Preferiríamos um bar que atendesse 140 pessoas em tempo hábil. Mesmo que seja um pouco mais lento. ”

Basicamente, vale a pena ter um host WordPress com um número maior de clientes paralelos (mesmo que o tempo de resposta seja um pouco mais lento) porque ter menos recursos de clientes paralelos coloca você em maior risco de falha do servidor e perda de visitantes.

Assista a uma simulação de um dos testes de carga.

Outra coisa legal do Loader.io é que ele permite que você assista a uma simulação de cada teste e como tudo correu.

Veja um exemplo de como o teste de carga resultou aqui .

 

 

Em seguida, testamos a velocidade de cada host.

Para testar a velocidade, usamos a ferramenta de teste de desempenho do KeyCDN .

Em suma, a ferramenta testa e mede o desempenho de qualquer URL em 10 locais diferentes em todo o mundo.

O teste em si não é muito complicado, basta colar a URL que deseja testar e clicar no botão. Lembre-se de que também é gratuito, portanto, você pode usá-lo para seus próprios testes.

 

A ferramenta de teste de desempenho do KeyCDN oferece uma maneira simples de testar o TTFB de cada host.

A ferramenta de teste de desempenho do KeyCDN oferece uma maneira simples de testar o TTFB de cada host WordPress.

 

Os resultados que você obtém fornecem uma análise dos tempos de carregamento e cabeçalhos de resposta HTTP. Como abaixo:

 

Um bom detalhamento da velocidade e do desempenho do seu host WordPress por local.

 

Olhando para a tabela acima, a métrica na qual estávamos mais interessados ​​para este teste foi “TTFB”.

O TTFB mede o tempo desde que um cliente faz uma solicitação HTTP até o recebimento do primeiro byte de dados do servidor.

O grande problema em comparar os resultados do TTFB …

O único problema é que o TTFB (ou a velocidade de um host em geral) não é tão simples de comparar. Isso ocorre porque a velocidade irá variar dependendo da localização do servidor hosts WordPress em relação ao usuário.

Por exemplo, se o servidor que você escolheu para seu site hospedado estiver localizado na Holanda, a leitura do TTFB de Amsterdã sempre será melhor.

Portanto, para sermos justos com todos os anfitriões envolvidos, optamos por apresentar as leituras do TTFB de duas maneiras diferentes:

  1. ”TTFB médio” (geo-otimizado) – Esta foi a leitura TTFB mais baixa (AKA melhor) de todos os locais testados.
  2. ”TTFB médio” (em todos os locais) – O tempo TTFB médio em todos os locais testados.

Nivelando o campo de jogo ainda mais.

Outro aspecto importante sobre nossos testes é o fato de todos os testes terem sido executados SEM levar o cache em consideração.

Basicamente, isso significa que testamos os próprios servidores de hospedagem, sem levar em consideração qualquer cache ou implementações de CDN que cada host WordPress possa ter. Isso foi feito forçando o WP a estar logado para que tudo fosse ignorado.

Por que achamos que é melhor testar sem cache (ou CDN) habilitado.

 

Desculpe Dev Man, nenhum cache permitido com esses testes.

Desculpe Dev Man, nenhum cache permitido com esses testes.

 

Em nossa opinião, comparar o desempenho do cache de página inteira não é uma boa ideia em uma situação como essa.

Acreditamos que isso seja verdade por alguns motivos:

  1. Ignorar o cache permite que você teste o desempenho dos próprios servidores de hospedagem. Isso é importante porque significa que você não precisa depender de mecanismos de cache (mais informações sobre por que isso é importante a seguir).
  2. O teste com cache não leva em consideração as ações “dinâmicas” do site.

Qualquer plataforma de hospedagem pode colocar um CDN na frente de seu site, instruí-lo a armazenar tudo em cache e, então, alegar que oferece sites incrivelmente rápidos e escaláveis.

O problema é que isso geralmente não é prático no mundo real como o WordPress, e muitos de seus plug-ins foram concebidos para serem dinâmicos.

Por exemplo, o cache é uma ótima maneira de acelerar sites ou páginas simples. Como uma “Página Sobre” – que raramente muda e na maioria das vezes não teria muita ação ao vivo ou dinâmica acontecendo.

Basicamente, seu amigo, o Sr. Cache, nem sempre estará lá para salvá-lo, então é melhor ver isso como um benefício adicional e ainda garantir que seu servidor será capaz de lidar por conta própria.

E por fim, se precisar de ajuda especializada com qualquer coisa relacionada ao WordPress, entre em contato com nossa equipe de suporte especializado em WordPress.