Como verificar a velocidade de um site

O jeito rápido: rode um teste de navegador real

Digite a URL em um teste de velocidade de página e deixe ele carregar a página em um navegador de verdade em vez de estimar. Um bom relatório dá a você uma captura de tela do que renderizou, os tempos gerais, e uma divisão por requisição mostrando qual imagem, script ou chamada de terceiro estava lenta. Essa divisão é o que transforma "a página está lenta" em "esse arquivo de fonte específico bloqueia a renderização por 1,8 segundos".

Rode logo depois de uma implantação, depois de uma atualização de plugin ou tema, e antes de se comprometer com uma mudança de hospedagem ou CDN. Esses são os momentos em que a velocidade muda e ninguém percebe.

Medindo você mesmo pela linha de comando

Para o lado do servidor da história, você não precisa nem de um navegador. O curl consegue imprimir a própria divisão de tempo:

curl -o /dev/null -sS -w   "dns:%{time_namelookup}s connect:%{time_connect}s tls:%{time_appconnect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n"   https://example.com/

Isso mede uma requisição só para o documento HTML, então sempre vai parecer mais rápido do que a página real. É exatamente por isso que é útil: isola o servidor do navegador. Se o ttfb está alto aqui, nenhuma quantidade de otimização de imagem vai ajudar. Se o ttfb está baixo e a página ainda parece lenta, o problema está no que o navegador precisa fazer depois de o HTML chegar.

O que TTFB, LCP e carregamento completo significam

• Tempo até o primeiro byte (TTFB). Quanto tempo o servidor levou para começar a responder, incluindo DNS, estabelecimento de conexão, TLS e o próprio processamento do servidor. Um TTFB alto aponta para hospedagem, consultas de banco de dados ou código de backend, não para os recursos da página.
• Largest contentful paint (LCP). Quando o maior elemento visível na viewport terminou de renderizar, geralmente uma imagem principal, um poster de vídeo ou um grande bloco de texto. Esse é o número mais próximo do que um visitante chamaria de "quando a página apareceu". O Google trata 2,5 segundos ou menos como bom.
• Carregamento / tempo de carregamento completo. Quando o navegador terminou de carregar o documento e os recursos bloqueantes dele. Tudo que o visitante consegue ver normalmente já terminou bem antes disso.
• Tempo total até se estabilizar. Tempo de carregamento mais qualquer coisa ainda rodando depois, como scripts que buscam dados assim que a página parece pronta. Uma página pode parecer terminada e ainda estar ocupada, e esse trabalho compete com o primeiro scroll ou clique do visitante.
• Requisições e bytes transferidos. Quantos arquivos a página puxou e quanto foi baixado. Essas são as alavancas por trás de quase todo número acima.

Leia-os juntos. TTFB baixo com um LCP alto significa que o navegador está fazendo demais: requisições demais, scripts que bloqueiam a renderização, ou uma imagem principal enorme. TTFB alto com tudo o mais normal significa que o servidor é o gargalo, antes mesmo de o navegador entrar em ação.

Por que um teste de um lugar engana

É normal testar a mesma URL duas vezes e obter dois resultados diferentes, e nenhum está errado. Três coisas conduzem a maior parte da dispersão:

• Distância. Um teste rodado perto do servidor tem um caminho de rede mais curto do que um rodado em outro continente. Se os seus visitantes estão na Europa e você testa a partir da mesma cidade do seu servidor, você está medindo o melhor caso, não o típico.
• Perfil de dispositivo. Um teste pode emular um dispositivo móvel com uma viewport menor, um user agent diferente e uma conexão estrangulada. Uma página ajustada para desktop pontua de forma muito diferente sob emulação móvel, de propósito.
• Cache e aquecimento. A primeira requisição pode bater em um cache frio na CDN ou na aplicação; a segunda é servida quente. Rode uma página duas ou três vezes e use o padrão, não a única execução mais rápida.

Um único teste ainda vale a pena rodar. Só significa que um número carrega significado só junto com as condições sob as quais foi medido.

Como ler um waterfall

O waterfall é a linha do tempo por requisição, uma barra por arquivo, ordenada por quando começou. Quatro formatos aparecem repetidamente:

1. Uma primeira barra longa antes de qualquer outra coisa começar. Isso é o TTFB no HTML, e tudo entra na fila atrás dele.
2. Uma escada onde cada requisição só começa quando a anterior termina. Isso é uma cadeia de dependência, geralmente um script que carrega outro script que carrega o conteúdo real. Cadeias são o formato mais caro do gráfico.
3. Uma barra larga no meio de um domínio de terceiro. Anúncios, widgets de chat, analytics e fontes ficam aqui, e um terceiro lento atrasa a sua própria página se for carregado de forma síncrona.
4. Um aglomerado denso de barrinhas. Dezenas de arquivos pequenos, cada um com o próprio overhead de conexão. Arquivos mais poucos, maiores e em cache geralmente vencem muitos pequenos.

Barras em vermelho ou com códigos 4xx e 5xx merecem atenção mesmo quando a página parece bem, porque uma requisição que falha ainda custa tempo antes de falhar.

Pegando uma lentidão que ninguém foi procurar

Um único teste diz como a página se saiu uma vez, de um lugar, em um perfil de dispositivo. É o que você quer ao depurar algo específico. Não é o que você quer quando o objetivo é perceber uma lentidão de qualquer forma: páginas ficam mais pesadas uma atualização de cada vez, e ninguém roda um teste manual em uma terça-feira tranquila. O monitoramento agendado de velocidade de página roda o mesmo teste a partir das mesmas localidades em um intervalo, mantém o histórico, e alerta quando os números ultrapassam um limite. Rode um agora com o teste de velocidade de página, e veja tempo de resposta do servidor se a parte lenta acabar sendo o servidor.