Ferramenta de Teste de Velocidade Pingdom: Guia Definitivo para 2024

Hoje vamos descobrir como melhor usar e entender os dados da popular ferramenta de teste de velocidade do site Pingdom. Você pode usá-lo para fazer o que chamamos de ”análise em cascata” do seu site WordPress. Isso pode ajudá-lo a diagnosticar rapidamente problemas de desempenho e também a diagnosticar incorretamente um problema.

Muitas vezes vemos os usuários do WordPress interpretando os dados errados na ferramenta de teste de velocidade Pingdom, o que leva algumas vezes a configurar um site para um estado ainda pior do que antes. Lembre-se de que todas as ferramentas como esta devem ser usadas como guias, elas nunca são 100% precisas. O importante é ser consistente e usar a mesma ferramenta em todos os seus testes.

Pingdom

Pingdom é uma empresa sediada fora da Suécia (agora de propriedade da SolarWinds) que oferece uma variedade de serviços diferentes, como monitoramento de tempo de atividade, monitoramento de velocidade de página, monitoramento de transações, monitoramento de servidor e informações sobre visitantes (RUM). Provavelmente, uma das coisas pelas quais eles são mais conhecidos é sua ferramenta gratuita de testes de velocidade para sites. É uma das ferramentas de teste de desempenho mais populares da comunidade WordPress.

Por que é tão popular? Bem, por um lado, é provavelmente a ferramenta de teste de velocidade mais fácil de usar! Nem todo mundo é um especialista em desempenho da Web e portanto, para o típico usuário do WordPress, algumas das outras ferramentas alternativas disponíveis podem ser bastante complicadas. Às vezes, menos é mais como eles dizem. Afinal, você só se preocupa com duas coisas: a rapidez com que o seu site e como você pode torná-lo mais rápido.

Pingdom atualmente permite que você teste a velocidade de qualquer site de 7 locais diferentes (5 continentes) estrategicamente colocados ao redor do globo:

• Ásia – Japão – Tóquio
• Europa – Alemanha – Frankfurt
• Europa – Reino Unido – Londres
• América do Norte – EUA – Washington D.C.
• América do Norte – EUA – San Fransisco
• Pacífico – Austrália – Sydney
• América do Sul – Brasil – São Paulo

Nota: Notamos que, ocasionalmente, nem todos os locais de teste estarão disponíveis. Isso é mais provável porque ele foi interrompido para manutenção ou ficou sobrecarregado com muitas pessoas tentando executar testes nele. Se o local de um site de teste que você está usando não estiver mais lá, verifique novamente em uma ou duas horas. O mais provável é que reapareça.

O local de teste escolhido é na verdade, muito importante no que se refere à localização física de onde seu site está realmente hospedado. É aqui que uma pequena coisa chamada latência de rede que entra em cena. Mas vamos abordar isso com mais detalhes abaixo.

Análise de cascata com a ferramenta de teste de velocidade Pingdom

Uma página da web é composta de diferentes recursos, como HTML, JavaScript, CSS, imagens e vídeos. Cada um deles gera solicitações para processar o que você vê em seu website. Normalmente, quanto mais pedidos você tiver, mais lento seu site será carregado. Isso nem sempre é o caso, mas é verdade na maioria das vezes.

Abaixo, vamos dividir cada seção Pingdom e explicar mais detalhadamente o que a informação significa no que se refere ao desempenho geral do seu site e como fazer uma análise em cascata.

• Índice Pingdom
• Observação de desempenho
• Códigos de resposta
• Tamanho do conteúdo e solicitações por tipo de conteúdo
• Tamanho do conteúdo e solicitações por domínio
• Gráfico de cascata
• Configuração de domínio do estudo de caso

Índice Pingdom

Quando você executa o seu site WordPress através do Pingdom, ele gera uma nota de desempenho, um tempo total de carregamento, o tamanho total da página e o número de solicitações que você tem em seu site. Em nosso exemplo, estamos usando nosso domínio de estudo de caso perfmatters.io, que está hospedado na Kinsta.

Como você pode ver, fizemos nosso primeiro teste e marcamos 88/100 no Pingdom e o tempo total de carga é abaixo de 541 ms. Isso nos permite saber o tamanho total de nossos ativos combinados e o número de solicitações.

Em seguida, executamos um teste adicional e agora nosso tempo de carregamento total é de 392 ms com o mesmo tamanho de página e número de solicitações! O que é isso tudo? 🤔 Você pode perceber isso se estiver executando o seu site através da ferramenta de teste de velocidade Pingdom várias vezes. Sites maiores notarão diferenças ainda maiores.

Há 3 razões principais para isso: o cache de DNS, cache de CDN e o armazenamento em cache do WordPress. É por isso que você deve sempre executar testes várias vezes. Naturalmente, as chamadas externas para recursos de terceiros e APIs também podem impactar isso. Descubra por que mais abaixo em nossa análise de cascata.

Quer obter uma pontuação melhor no Pingdom em seu site WordPress? Dependendo do site e da configuração, talvez nem sempre seja possível obter um 100/100 perfeito, especialmente para aqueles que estão executando sites de eCommerce e pixels de marketing. Mas simplesmente gastar algum tempo para melhorar sua pontuação é um bom lugar para começar. A velocidade geral é realmente o que é importante.

Às vezes, a experiência do usuário também pode superar alguns dos truques de desempenho da internet que você lê na internet. Você não pode esquecer a experiência do usuário! Mas fique tranquilo, compartilharemos com você algumas dicas e truques mais abaixo sobre como chegamos ao site acima, para continuar lendo.

Melhore o desempenho da página

A seção de Performanceinsights, agora “Melhorar o desempenho da página”, foi atualizada em 2018 e eles removeram alguns itens antigos e adicionaram novos itens. Isso é provável porque algumas das sugestões que eles estavam relatando não são mais tão relevantes quanto costumavam ser. Quando se trata de otimizações de desempenho da Web, as coisas estão sempre mudando. E às vezes pode ser problemático se as pessoas estiverem simplesmente tentando perseguir a pontuação perfeita do Pingdom.

No entanto, estamos deixando esta seção inteira em nosso artigo (algumas antigas e novas) porque é importante entender como essas pontuações são calculadas. Basicamente, todos são baseados nas regras do Google PageSpeed Insight. Geralmente, se você melhorar isso no seu site, deverá ver uma diminuição nos tempos de carregamento geral.

Veja a seguir algumas das categorias das quais a seção do aprimoramento de desempenho da página é composta por:

• Use uma rede de entrega de conteúdo (CDN)
• Evitar erro HTTP 404 (não encontrado)
• Minimizar Redirecionamentos
• Adicionar cabeçalhos expirados
• Remover consulta de recursos estáticos do Query Strings
• Use domínios sem cookies
• Associar Downloads em nomes de host
• Especifique um validador de cache
• Especifique um cabeçalho Vary: Accept-Encoding

Agora verificaremos alguns deles e ver quais ainda são relevantes hoje.

Use uma rede de entrega de conteúdo (CDN)

Um dos serviços mais importantes para implementar em seu site WordPress hoje é o Content Delivery Network (CDN). Estes são rede de servidores (também conhecidos como POPs) localizados em todo o mundo. Eles são projetados para hospedar e fornecer cópias do conteúdo estático (e às vezes dinâmico) do seu site WordPress, como imagens, CSS, JavaScript e fluxos de vídeo.

Se você é um cliente Kinsta, incluímos CDN em todos os nossos planos de hospedagem. Ativá-lo leva alguns cliques. Alguns benefícios de um CDN incluem um aumento de desempenho (menor TTFB e latência de rede), menor largura de banda e custos de hospedagem e até vantagens de SEO.

Os clientes Kinsta também podem desfrutar de um impulso rápido e fácil para a otimização geral do site, minificando seu código usando o recurso de minificação de código embutido no painel MyKinsta. Isso permite aos clientes ativar a minificação automática de CSS e JavaScript com um simples clique, acelerando efetivamente seus sites com zero esforço manual.

Importante: A ferramenta Pingdom recém-atualizada atualmente possui um bug detectando corretamente qualquer provedor de CDN com precisão.

Alguns provedores de CDN de terceiros que recomendamos incluem:

• KeyCDN (isso é o que capacita a Kinsta CDN)
• Cloudflare
• StackPath
• CDN77

Em nossos próprios testes de velocidade de CDN, descobrimos que um CDN pode reduzir os tempos de carregamento da página em mais de 50% em alguns casos!

Evitar erro HTTP 404 (não encontrado)

Esta seção foi chamada anteriormente de “evitar pedidos incorretos”. E isso é sempre relevante! Esse aviso é como parece, é uma solicitação que não pôde ser concluída com sucesso. Isso geralmente acontece quando você vincula manualmente a um ativo ou imagem que foi excluído, resultando em um erro 404. Isso aparece como um círculo laranja no Pingdom, junto com um 404 no status do cabeçalho de resposta.

Certifique-se sempre de que todas as solicitações no seu site retornem com o status de sucesso. Isso garantirá que não haja consultas geradas para ativos que não existem mais.

Minimizar Redirecionamentos

Muitos redirecionamentos são sempre algo que você precisa observar. Redirecionamentos simples como um único redirecionamento 301, HTTP para HTTPS ou www para não-www (vice-versa) são bons. E muitas vezes isso é necessário em determinadas áreas do seu site. No entanto, cada um deles tem um custo no desempenho do seu site. E se você começar a empilhar redirecionamentos um em cima do outro, é importante perceber como eles afetam o desempenho do seu site. Isso se aplica a redirecionamentos de página e artigo, redirecionamentos de imagem, tudo.

Um redirecionamento aparece como um círculo azul no Pingdom, com um 301 ou 302 no status do cabeçalho de resposta.

Quanto os redirecionamentos afetam seu site? Vamos fazer um pequeno teste. Primeiro, realizamos um teste de velocidade na nossa página de contato: https://perfmatters.io/contact/. Como você pode ver abaixo, obtemos um tempo total de carregamento de 417 ms.

Em seguida, modificamos a URL ligeiramente e executamos outro teste de velocidade para ver o impacto de vários redirecionamentos. www.perfmatters.io/contact. Como você pode ver, a mesma página agora leva 695 ms para carregar. Isso é um aumento de 66%. Caramba!

Confira nossa postagem detalhada sobre redirecionamentos do WordPress e as práticas recomendadas para um desempenho mais rápido.

Adicionar cabeçalhos expirados

Esta sugestão foi chamada anteriormente de cache do navegador. Para colocá-lo em termos leigos, cada script em seu site WordPress precisa ter um cabeçalho de cache HTTP anexado a ele (ou deveria). Isso determina quando o cache no arquivo expira. Para corrigir isso, certifique-se de que seu provedor de hospedagem de sites de WordPress tenha os cabeçalhos cache-control apropriados e configuração de cabeçalhos expires. Kinsta tem esses cabeçalhos instalados em todos os servidores. Confira os passos sobre como adicionar cabeçalhos de cache ao seu servidor manualmente e leia nosso guia sobre como adicionar cabeçalhos expirados.

A outra questão é que, quando você carrega scripts de terceiros, não tem acesso para adicionar os cabeçalhos de armazenamento em cache, já que você não tem controle sobre os servidores da Web deles. Os culpados comuns incluem o script do Google Analytics e os pixels de marketing, como o Facebook e o Twitter. Para corrigir isso, você pode hospedar seu script do Google Analytics localmente (embora isso não seja oficialmente suportado) com um plugin como o Perfmatters. WP Rocket também tem uma opção para hospedar seu pixel de marketing do Facebook localmente.

Mover scripts localmente pode variar em termos de quanto afeta o desempenho do seu site. A única vantagem é que você tem controle total sobre o arquivo e pode atendê-lo no seu próprio CDN. Isso também remove outra solicitação de DNS de terceiros. No entanto, também é importante lembrar que esses arquivos podem estar armazenados em cache nos navegadores das pessoas.

Veja nossa postagem detalhada sobre como corrigir o aviso de cache do navegador leverage

Remover consulta de recursos estáticos do Query Strings

Outro problema comum é lidar com strings de consulta. Seus arquivos CSS e JavaScript geralmente têm a versão do arquivo no final de seus URLs, como https://domain.com/file.min.css?ver=4.5.3. Alguns servidores e servidores proxy não conseguem armazenar em cache as strings de consulta. Então, removendo-os, você pode melhorar o seu cache.

Você pode usar um plugin premium, como o Perfmatters, que possui uma opção simples de um clique para remover as strings de consulta.

Ou você pode adicionar o código a seguir manualmente ao arquivo functions.php do seu tema. Uma alternativa melhor seria usar um plugin gratuito como Code Snippets para adicionar o código. Dessa forma, você não precisa editar diretamente seu tema.

function remove_query_strings() {
 if(!is_admin()) {
 add_filter('script_loader_src', 'remove_query_strings_split', 15);
 add_filter('style_loader_src', 'remove_query_strings_split', 15);
 }
}
function remove_query_strings_split($src){
 $output = preg_split("/(&ver|\?ver)/", $src);
 return $output[0];
}
add_action('init', 'remove_query_strings');

No entanto, antes de você remover as strings de consulta imediatamente em seu site, é importante saber por que as strings de consulta são usadas. O controle de versão em arquivos é normalmente usado por desenvolvedores de WordPress para solucionar problemas de armazenamento em cache.

Por exemplo, se eles enviarem uma atualização e alterarem style.css de ?ver=4.6 para ?ver=4.7, ela será tratada como um URL completamente novo e não será armazenada em cache. Se você remover as strings de consulta e atualizar um plugin, isso poderá fazer com que a versão em cache continue sendo veiculada. Em alguns casos, isso pode interromper a aparência do site até que o recurso em cache expire ou o cache seja completamente liberado.

Além disso, alguns CDNs podem armazenar em cache as strings de consulta. O CDN da Kinsta pode e faz por padrão. Então, se você é um cliente Kinsta, as strings de consulta já estão armazenadas em cache nos seus recursos.

Veja nosso tutorial detalhado sobre como remover strings de consulta de recursos estáticos.

Use domínios sem cookies

Temos um artigo detalhado sobre como lidar com o conteúdo estático de um aviso de domínio sem cookies. Muitas vezes você pode ignorar esse aviso, pois novos protocolos, como o HTTP/2, tornam isso menos importante. O custo de uma nova conexão é geralmente mais caro do que transmitir tudo pela mesma conexão. No entanto, duas maneiras de resolver isso é usar um provedor CDN que exclua os cookies ou crie um domínio e/ou subdomínio separados.

Componentes de Compressão com GZIP

O aviso “Compress Components with GZIP” ocorre quando o Pingdom detecta um ativo que não foi comprimido com GZIP. GZIP é um método de compressão utilizado para reduzir o tamanho de arquivos baseados em texto, como documentos HTML e arquivos CSS/JS. A compressão GZIP é ativada no servidor e comprime páginas da web e ativos antes de enviá-los a um visitante. A partir de nossos testes, vimos que a ativação da compressão GZIP reduziu o tamanho do arquivo de uma solicitação em mais de 78%.

 

Na Kinsta, você não terá que se preocupar em habilitar o GZIP manualmente porque ele já está habilitado por padrão em todos os nossos servidores. Se você notar que o seu provedor de hospedagem de sites não ativou o GZIP, recomendamos que procure a equipe de suporte deles para ativá-lo imediatamente, pois pode ter um grande impacto na velocidade da sua página. Se você ainda ver o “Compress Components with GZIP” após habilitar o GZIP em seu servidor, é possível que um servidor que hospeda um ativo externo exigido por seu site não tenha o GZIP habilitado. Se este for o caso, não há nada que você possa fazer para mudar o comportamento do servidor.

Associar downloads em hostnames

O aviso “Parallelize Downloads Across Hostnames” ocorre devido a uma limitação do HTTP / 1.1 e dos navegadores da Web sendo limitados ao número de conexões simultâneas que podem fazer em um provedor de hospedagem de sites; que é tipicamente 6 conexões. Esse aviso é normalmente visto em sites com um grande número de solicitações. Antes, a única maneira de contornar essa limitação era implementando o que eles chamam de sharding de domínio. No entanto, se você estiver usando um provedor de hospedagem de sites ou Provedor CDN que suporta HTTP / 2, você pode ignorar isso com segurança agora, pois agora vários recursos podem ser carregados em paralelo em uma única conexão. Mas você também pode conferir nosso tutorial sobre como corrigir os downloads de paralelização através do aviso de hostnames implementando o domínio sharding.

Especifique um Validador de Cache

Este aviso indica os cabeçalhos de cache HTTP ausentes que devem ser incluídos em todas as respostas do servidor de origem, pois ambos validam e definem o comprimento do cache. Se os cabeçalhos não forem encontrados, gerará uma nova solicitação para o recurso todas às vezes, o que aumentará a carga no seu servidor. Esses cabeçalhos incluem last-modified, ETag, Cache-Control, e Expires. Assim como o aviso de cache de navegador de alavancagem, esses cabeçalhos devem ser automaticamente adicionados pelo seu provedor de hospedagem de sites de WordPress. Se você tem solicitações de terceiros, não há nada que possa fazer porque não tem controle sobre os servidores da Web.

Leia nosso artigo detalhado sobre como corrigir o aviso “especificar um validador de cache”

Especifique um cabeçalho Vary: Accept-Encoding

Temos um artigo detalhado sobre como reparar um aviso Specify a Vary: Cabeçalho Accept-Encoding. Este é um cabeçalho HTTP e deve ser incluído em todas as respostas do servidor de origem, pois informa ao navegador se o cliente pode ou não manipular versões compactadas do conteúdo. Isso é automaticamente adicionado a todos os servidores da Kinsta.

Códigos de resposta Pingdom

TA próxima seção na ferramenta de teste de velocidade Pingdom é os códigos de resposta. Códigos de resposta, também conhecidos como HTTP status codes são como uma breve nota do servidor da web colocado no topo de uma página. É uma mensagem do servidor da web informando o desempenho quando a solicitação para visualizar a página foi recebida. Alguns comuns são:

• 200: “Tudo está OK”. Esse é o código que é entregue quando uma página da Web ou um recurso funciona exatamente da maneira esperada.

  

• 301: “O recurso solicitado foi movido permanentemente.” Esse código é entregue quando uma página da Web ou um recurso foi substituído permanentemente por um recurso diferente. É usado para redirecionamento permanente de URL.

  

• 404: “O recurso solicitado não foi encontrado.” A mensagem de erro mais comum. Esse código significa que o recurso solicitado não existe e que o servidor não sabe se ele existiu.

  

Você pode ler mais sobre todos os diferentes códigos de resposta em nosso artigo detalhado sobre os HTTP status codes.

Tamanho do Conteúdo e Solicitações por Tipo de Conteúdo

As próximas seções são o tamanho do conteúdo por tipo de conteúdo e as solicitações por tipo de conteúdo. Cada uma delas é útil para ver rapidamente o que está ocupando mais recursos na sua página da web. De acordo com o arquivo HTTP, as imagens geralmente representam 43% do tamanho total médio de uma página da web. No entanto, como você pode ver abaixo neste site, nem sempre é o caso.

Para otimizar suas imagens, recomendamos vivamente a leitura do nosso artigo detalhado sobre como otimizar imagens para a web e sobre o WebP.

Para otimizar suas imagens, recomendamos vivamente a leitura do nosso artigo detalhado sobre como otimizar imagens para a web e sobre o WebP. Há muitas ótimas ferramentas e plugins disponíveis para compactar ainda mais suas imagens e garantir que elas não sejam a maior parte do carregamento de páginas do seu site. E no nosso caso acima, o site perfmatters.io está aproveitando o uso de ícones incríveis de fontes grandes no lugar das imagens. Essa pode ser uma ótima estratégia que faz uma enorme diferença. E, claro, temos algumas dicas adicionais em nosso guia de velocidade da página sobre como diminuir ainda mais o tamanho do seu conteúdo.

Tamanho do Conteúdo e Solicitações por Domínio

O tamanho do conteúdo e as solicitações por seção de domínio são uma boa maneira de ver rapidamente quais serviços e scripts externos no seu website. Em nosso exemplo, todos os nossos ativos estão sendo carregados do nosso CDN. Em seguida, há o carregamento inicial do DOC em HTML para o site no servidor da Web e uma chamada externa para o domínio do Google Analytics. Dependendo do seu site, você pode ter muito mais serviços externos, como o Facebook, o Twitter, o Hotjar, o SumoMe, o AdRoll, o New Relic, o CrazyEgg, etc.

Geralmente, quanto menos solicitações externas você puder fazer melhor, cada serviço externo apresentará sua própria latência, atrasos de handshake de TLS, DNS lookups, etc. Certifique-se de ler o nosso artigo sobre como identificar e analisar serviços externos no seu site WordPress.

Geralmente é melhor reduzir o número de solicitações o máximo possível e hospedar os recursos em um só lugar, como movê-los para o servidor da Web ou CDN. Um exemplo seria font awesome. Em vez de ligar para o script externo para fonte impressionante, baixe-o e sirva diretamente.

Quadro de Cascata Pingdom

E por último, mas não menos importante, temos a seção de solicitações de ferramenta de teste de velocidade Pingdom que gera um gráfico em cascata de todas as solicitações individuais em sua página da web (como mostrado abaixo). Você pode analisar cada solicitação para ver o que está causando atrasos e problemas de desempenho em seu site. Isto é o que queremos dizer quando dizemos que estamos fazendo uma análise em cascata. Abaixo está um resumo mais detalhado e / ou definição do que cada cor de status significa.

DNS (Pink)

Então, o que é DNS? Bem, pense nisso como uma lista telefônica. Existem servidores chamados Domain Name Servers (Servidores de Nomes de Domínio) que contêm as informações sobre o seu site e para qual IP eles devem ser roteados. Quando você executa seu site pela primeira vez através do Pingdom, ele executa uma pesquisa nova e precisa consultar os registros DNS para obter as informações de IP. Isso resulta em algum tempo de pesquisa adicional.

Quando você executa seu site por meio do Pingdom mais de uma vez, ele armazena em cache o DNS porque ele já conhece as informações de IP e não precisa realizar a pesquisa novamente. Esse é um dos motivos pelos quais seu site aparece mais rápido após executá-lo por meio do Pingdom várias vezes.

Como você pode ver na tela abaixo, no segundo teste, o tempo de pesquisa de DNS na carga DOC inicial é de 0 ms. Esta é uma área que muitas pessoas interpretam erroneamente! Além disso, você pode otimizar ainda mais usando um serviço DNS premium service, além disso, ele vem com muitos benefícios extras.

Além disso, você pode otimizá-lo ainda mais usando um serviço de DNS premium, além de oferecer muitos benefícios extras. O DNS gratuito do nosso Cloudflare também é rápido! Confira a Otimização Automática da Plataforma Cloudflare.

Há também outras razões pelas quais seu site pode aparecer mais rapidamente após vários testes. Um deles é se você estiver usando uma content delivery network (Rede de entrega de conteúdo). Para aqueles que não estão familiarizados com um CDN é uma rede de servidores globais que armazenam em cache seu conteúdo (JS, CSS, Imagens, etc.) em locais mais próximos do visitante. Quando você executa seu site pela primeira vez através de Pingdom, ele pode ter que pegar os ativos do CDN recente. Um cache de CDN funciona como o DNS, uma vez que é armazenado em cache é muito mais rápido em cargas consecutivas.

Outra dica sobre como acelerar o DNS é usar a pré-busca de DNS. Isso permite que o navegador realize pesquisas de DNS em uma página em segundo plano. Você pode fazer isso adicionando algumas linhas de código ao cabeçalho do seu site WordPress. Veja alguns exemplos abaixo.

<!-- Prefetch DNS for external assets -->
 <link rel="dns-prefetch" href="//fonts.googleapis.com">
 <link rel="dns-prefetch" href="//www.google-analytics.com"> 
 <link rel="dns-prefetch" href="//cdn.domain.com">

Ou se você estiver executando o WordPress versão 4.6 ou mais recente, você pode querer usar dicas de recursos. Os desenvolvedores podem usar o filtro wp_resource_hints para adicionar domínios personalizados e URLs para dns-prefetch, preconnect, prefetch or prerender.

SSL (Purple)

A cor do status purple representa o tempo que o seu navegador leva para fazer um handshake SSL/TLS. Sempre que você executar um site em HTTPS, significa que há um certificado SSL envolvido e tempo extra envolvido devido ao processo de criptografia (handshake SSL/TLS). Em nosso domínio de exemplo, temos um certificado em nosso servidor da Web na Kinsta e em nosso CDN, KeyCDN. Portanto, há um tempo de negociação de SSL no carregamento de doc HTML inicial do servidor da Web e de nossos recursos.

Embora haja uma pequena sobrecarga para executar o HTTPS é muito insignificante agora graças ao HTTP/2, que é um novo protocolo que ajuda a acelerar a Web! Devido ao suporte do navegador, o HTTPS é necessário para utilizar o HTTP/2. Cheque nosso guia para HTTP/2.

Também é importante observar que, mesmo em 2018, nem todos os provedores ainda oferecem suporte a HTTP/2. Isso inclui tanto o lado da hospedagem quanto o lado da CDN. Então, quando você está procurando por hospedagem e CDNs, certifique-se de que ambos suportem isso! Kinsta tem o orgulho de oferecer suporte ao HTTP/2 para todos os seus clientes do WordPress.

Em meados de 2018, a Pingdom finalmente atualizou sua ferramenta para usar o Chrome 60 e superior. Você pode ver o user-agent sendo usado no cabeçalho da solicitação. Anteriormente, eles estavam usando o Chrome 39 e o Chrome não suportava HTTP/2 até a versão 49. Por isso, estamos felizes em dizer que a ferramenta Pingdom agora mostra todas as vantagens do HTTP/2 ao executar testes! 👏

Conexão (Teal)

O tempo de conexão no Pingdom está se referindo à conexão TCP ou ao tempo total necessário para criar uma conexão TCP. Você não precisa entender como isso funciona, mas isso é simplesmente um método de comunicação entre o host/cliente e o servidor que deve ocorrer.

Wait (Yellow)

O tempo de espera no Pingdom está se referindo ao tempo para o primeiro byte, também conhecido como o TTFB  em algumas ferramentas. O TTFB é uma medida usada como uma indicação da capacidade de resposta de um servidor da web ou outro recurso de rede. Geralmente, qualquer coisa abaixo de 100 ms é aceitável e boa TTFB. Se você está se aproximando do intervalo de 300-400 ms, você pode ter algo configurado incorretamente em seu servidor ou talvez seja hora de atualizar para um servidor melhor.

A maneira mais fácil de diminuir seu TTFB? As duas melhores maneiras são o armazenamento em cache efetivo do WordPress e um CDN. Então, vamos fazer alguns testes.

TTFB sem cache da hospedagem WordPress

Primeiro, fizemos um teste após limpar o cache em nosso site WordPress. Isso significa que tem que pré-carregar o cache novamente. Como você pode ver, nosso tempo de carregamento total foi de 541 ms e o TTFB (tempo de espera) em nossa solicitação inicial foi de 185,2 ms.

TTFB com cache de hospedagem WordPress

Em seguida, fizemos o teste novamente. Agora ele está sendo veiculado diretamente do cache. Como você pode ver, nossos tempos totais de carga caíram para 392 ms e o TTFB no pedido inicial é agora de 52,8 ms! Essa é a diferença que o cache faz.

Se você tem um site que atende visitantes em diferentes partes do país, ou em todo o mundo, a outra maneira fácil de diminuir drasticamente o seu TTFB é usar um CDN. Nós novamente fizemos alguns testes para mostrar a diferença.

TTFB sem CDN

Primeiro fizemos um teste com nosso CDN desativado e como você pode ver, nosso tempo de carregamento total foi de 1,93 s e nosso TTFB médio em um ativo foi de aproximadamente 176 ms.

TTFB com CDN

Em seguida, ativamos nosso CDN e fizemos o teste novamente. Como você pode ver, nossos tempos totais de carregamento caíram para 1,21 s e nosso TTFB médio em um ativo CDN agora é de 4,6 ms! Quanta diferença um CDN pode fazer.

Outra coisa importante a notar é que escolhemos o local “Pacific – Australia – Sydney” para realizar este teste. Por quê? Porque queríamos mostrar a melhoria real que pode ser obtida. Nosso site WordPress neste exemplo é hospedado pela Kinsta no Google Cloud e localizado em um local central nos EUA. Ao realizar o teste contra a Austrália, podemos mostrar como o cache Kinsta CDN aumenta a velocidade e reduz o TTFB.

E, claro, ter um bom apresentador do WordPress com uma arquitetura cuidadosamente pensada também é crucial para diminuir o seu TTFB.

Enviar (Orange) e Receber (Green)

Os status de envio e recebimento no Pingdom não precisam de muita explicação. O tempo de envio é simplesmente o tempo que o navegador da Web leva para enviar dados ao servidor. E o tempo de recebimento é o tempo que leva para o navegador da Web receber dados do servidor. Ambos geralmente serão muito baixos ou inexistentes em seus testes.

Cabeçalhos de Resposta HTTP

Você também pode clicar em uma solicitação individual durante a análise da cascata e ver os cabeçalhos de resposta HTTP. Isso fornece informações valiosas. Na tela abaixo podemos ver instantaneamente coisas como o gzip está ativado no servidor da web, e está sendo servido do cache (HIT, iria mostrar MISS de outra maneira), os cabeçalhos de controle de cache, os cabeçalhos de expiração, o agente de usuário do navegador e muito mais.

Configuração de domínio do estudo de caso

Se você chegou até aqui no nosso post de análise de cascata, então você vai ter uma surpresa. É chato ver pessoas compartilharem dicas e estudos de caso, mas depois não compartilharem como chegaram lá. Então, abaixo está nossa configuração exata para o domínio do estudo de caso usado acima! Sinta-se à vontade para reproduzir.

Arquitetura

• O domínio do estudo de caso (perfmatters.io) é hospedado com a Kinsta no Google Cloud Platform nos EUA (Council Bluffs, Iowa, EUA (us-central1). Atualmente, Kinsta oferece 19 data centers diferentes para escolher. A rede de nível premium do GCP é incluído com todos os planos para latência de rede rápida como um raio.
• Kinsta usa HTTP/2, Nginx, MariaDB, que contribuem para os tempos de carregamento rápidos.
• O site está usando o KeyCDN, que alimenta o CDN da Kinsta. A largura de banda CDN gratuita está incluída em todos os planos de hospedagem.
• O site não está usando nenhum plugin de armazenamento em cache. Kinsta armazena tudo em cache no nível do servidor, o que simplifica muito as coisas!
• O site está usando o PHP 7.3. Versões mais recentes do PHP sempre mostraram grandes melhorias no desempenho. Confira esses PHP Benchmarks. Kinsta permite alternar entre os dois com apenas um clique.

WordPress Plugins e Tema

Aqui está uma lista dos plugins que afetam o desempenho que está sendo usado no site de comércio eletrônico WordPress.

• O plugin premium Perfmatters, desenvolvido por um membro da equipe da Kinsta. Isso elimina solicitações HTTP desnecessárias, como incorporações, emojis, e também possui um gerenciador de scripts para ativar/desativar determinados scripts de carregamento em uma base por página/postagem/site.
• O plugin premium Imagify é usado para comprimir imagens.
• O plugin Safe SVG gratuito é usado para carregar imagens SVG para o site WordPress.
• O tema premium GeneratePress WordPress foi usado para construir o site EDD.

Tutoriais Recomendados para Leitura:

• Como eliminar JavaScript e CSS de bloqueio de renderização
• Como desativar emojis no WordPress
• Como desativar as incorporações no WordPress
• Como pontuar 100/100 no Google PageSpeed Insights com o WordPress
• Como diagnosticar o alto uso de Admin-Ajax no seu site WordPress

Resumo

Como você pode ver, saber como a ferramenta de teste de velocidade Pingdom funciona um pouco melhor e o que todos os gráficos significam pode ajudar você a tomar uma decisão mais orientada a dados quando se trata de desempenho. Uma análise em cascata, como a chamamos, é crucial para saber como seus ativos individuais são carregados e como eles são afetados pelo seu provedor de hospedagem de sites de WordPress, como o local físico, CDN, etc. Você recebeu outras ótimas dicas sobre o Pingdom?

Se você gostaria de ver artigos mais detalhados como o acima, deixe-nos saber nos comentários abaixo.