Por Que Uma Página Parece Lenta Quando Toda Métrica de Servidor Diz Que É Rápida

Alguém diz que seu site é lento. Você abre o painel e tudo está verde. Tempos de resposta em centenas baixas de milissegundos, sem erros, sem saturação, nada acima do limite em lugar nenhum.

Ambos estão certos, e a razão não é sutil quando você a vê: suas métricas de servidor e seu visitante estão medindo duas coisas diferentes, e a sobreposição entre elas é menor do que quase ninguém espera.

Dois relógios, iniciados em momentos diferentes

O relógio do seu servidor começa quando uma solicitação chega e para quando termina de escrever uma resposta. Esse intervalo é o que seu monitoramento relata, e é uma medição real de algo real.

O relógio do visitante começa quando ele clica, e não para até que a página tenha desenhado algo pelo qual ele veio. Entre esses dois momentos estão: uma busca DNS, uma conexão TCP, um aperto de mão TLS, o trabalho do seu servidor, a resposta voltando, a análise de HTML, as folhas de estilo e fontes e scripts que o HTML pede a seguir, cada um dos quais repete a maior parte do acima, e finalmente a renderização.

Seu servidor foi envolvido em uma etapa disso. Uma página pode gastar 80 milissegundos no seu servidor e quatro segundos se tornando útil, e nada no seu monitoramento de aplicação está errado quando diz 80 milissegundos.

O número que descreve o servidor, e os que descrevem a experiência

O número do lado do servidor é Time to First Byte, que Google descreve como medindo “o tempo entre começar a navegar para uma página e quando o primeiro byte de uma resposta começa a chegar”. Suas orientações dizem que “a maioria dos sites deve se esforçar para ter um TTFB de 0,8 segundos ou menos”.

Mas eles são explícitos sobre seus limites: “Como TTFB não é uma métrica Core Web Vitals, não é absolutamente necessário que os sites atendam ao limite de TTFB ‘bom’, desde que não impeça sua capacidade de pontuar bem nas métricas que importam.”

As métricas que importam são os três Core Web Vitals, e cada um responde a uma pergunta que uma pessoa realmente reconheceria.

Largest Contentful Paint é quando a maior coisa na tela termina de desenhar, que é o proxy mais próximo para “a página apareceu”. O alvo é que “LCP deve ocorrer dentro de 2,5 segundos de quando a página começa a carregar”.

Interaction to Next Paint é quanto tempo a página leva para responder visivelmente depois que alguém interage com ela: “as páginas devem ter um INP de 200 milissegundos ou menos”. Ele substituiu First Input Delay como um Core Web Vital estável em 2024, e a mudança importa, porque FID media apenas o atraso antes do processamento começar, enquanto INP mede todo o caminho até a próxima pintura. Uma página que aceitava seu clique instantaneamente e depois congelava, pontuava bem na métrica antiga.

Cumulative Layout Shift não é sobre velocidade. Mede o quanto a página se move enquanto carrega, e o alvo é “0,1 ou menos”. Está nesta lista porque uma página que pula sob seu dedo parece quebrada de uma maneira que parece lenta para a pessoa, mesmo quando nada estava.

O detalhe que resolve a maioria dessas discussões

Core Web Vitals são avaliados no “75º percentil de carregamentos de página, segmentados em dispositivos móveis e de desktop”.

Não a média. O 75º percentil, o que significa que uma visita em quatro é pior do que o número que você está vendo, e é deliberado: uma média é dominada pelas pessoas que já estavam se divertindo bem. Suas próprias visitas estão nessa maioria confortável quase por construção, já que você está perto de seus servidores, em uma boa conexão, em uma máquina rápida, com um cache quente.

Então, quando um visitante diz que o site é lento e seu painel diz que é rápido, a leitura honesta não é que um de vocês está errado. É que você está olhando para a média de uma distribuição cuja cauda é toda a reclamação.

Fraco

"Site é lento." Consultei o painel, tempo de resposta p50 90ms, fechando como não pode reproduzir.

Melhor

"Lento na página de produtos, cerca de 6 segundos antes de algo aparecer, em dados móveis." LCP é a métrica; TTFB estava bem, então o tempo está indo para algum lugar depois que a resposta chega.

Onde o tempo realmente vai

Assim que você aceita que o intervalo é real, há apenas alguns lugares onde ele se esconde, e eles são os mesmos poucos sempre.

Recursos que bloqueiam renderização. O HTML chegou rápido e pediu uma folha de estilo, e o navegador não vai pintar até tê-la. Cada solicitação bloqueadora no cabeçalho é adicionada ao tempo antes de qualquer coisa aparecer.

Fontes. Uma fonte da web que não é pré-carregada pode deixar o texto invisível ou restyled bem depois que o layout está pronto, o que atrasa a maior pintura e, se refluir, alimenta a mudança de layout.

Imagens sem dimensões. A causa mais comum de mudança de layout. O navegador não pode reservar o espaço, então tudo abaixo se move quando a imagem chega.

JavaScript, em um dispositivo lento. Isso é invisível em uma máquina de desenvolvimento por construção. Analisar e executar um grande pacote custa uma fração de segundo em um laptop e vários segundos em um telefone de gama média, e a página não responde aos toques por tudo isso.

A distância. Um visitante do outro lado do mundo paga a viagem de ida e volta várias vezes antes mesmo de seu servidor rápido ser solicitado, que é a mesma razão pela qual uma degradação upstream cai em você em vez de em quem a causou.

O que pedir em vez de “você pode ser mais específico”

“É lento” não pode ser agido, mas as três coisas que o tornam acionável são todas fáceis de pedir, e nenhuma delas requer que o relator entenda qualquer coisa do acima.

• Qual página, e pelo que estavam esperando. Lento para aparecer de forma geral, lento para responder depois de um toque, ou se movendo enquanto carregava. Essas são três métricas diferentes e três causas diferentes.
• Em qual dispositivo, e em qual conexão. Um Android de cinco anos em dados móveis e um desktop em fibra não são o mesmo site.
• Aproximadamente quanto tempo, e se é sempre. A diferença entre “sempre cerca de seis segundos” e “às vezes trava” é a diferença entre uma página pesada e uma falha intermitente, e elas não compartilham nenhuma solução.

E o que remove a adivinhação completamente é um registro das solicitações conforme realmente aconteceram em sua máquina, porque o registro de rede mostra onde os segundos foram em vez de onde você assume que foram.

O que tirar disso

Um painel verde não é evidência de que o site é rápido. É evidência de que a parte que você instrumentou é rápida, e essa parte é uma etapa em uma sequência que o visitante experimenta totalmente.

Meça o que eles experimentam, no percentil onde as reclamações vivem em vez de na média, e trate sua própria experiência de seu próprio site como o ponto de dados menos representativo que você tem acesso.