WebPageTest

TL;DR — WebPageTest é uma ferramenta gratuita que carrega sua página em um navegador real em um local real e mostra a você exatamente o que aconteceu durante o carregamento — cada arquivo baixado, em que ordem, e um vídeo quadro a quadro da página aparecendo. É a ferramenta que você usa quando o PageSpeed Insights diz que uma página está lenta, mas você quer ver por quê. Não é um produto do Google, e suas pontuações não afetam seu ranqueamento — é uma ferramenta de diagnóstico.

O que é o WebPageTest

A maioria das ferramentas de velocidade dá a você um número. O WebPageTest dá a você uma história — uma imagem detalhada, passo a passo, de como sua página carregou.

Você vai para webpagetest.org, digita uma URL, escolhe de onde no mundo testar e em que tipo de dispositivo e conexão, e clica em iniciar. Um navegador real em uma máquina real carrega sua página, e o WebPageTest registra tudo: cada imagem, script e fonte que ele buscou, quanto tempo cada um levou, e um filmstrip — um conjunto real de capturas de tela quadro a quadro da página aparecendo na tela.

É gratuito e código aberto. Foi criado por um desenvolvedor chamado Patrick Meenan em 2008, e uma empresa chamada Catchpoint o comprou em 2020 — mas a versão pública gratuita em webpagetest.org continua disponível para qualquer pessoa usar.

Por que você usaria em vez do PageSpeed Insights

O PageSpeed Insights (a ferramenta do Google) é ótimo para dizer a você que uma página está lenta e dar uma pontuação. O WebPageTest é melhor para dizer a você por quê e onde. Se o PSI diz “reduza recursos que bloqueiam a renderização”, o WebPageTest mostra a você o arquivo exato que está bloqueando, em qual segundo, em um gráfico que você pode ler como uma linha do tempo.

A outra coisa que as pessoas erram: as pontuações do WebPageTest não são um fator de ranqueamento. O Google ranqueia parcialmente com base na rapidez com que visitantes reais experimentam seu site (isso é chamado de “dados de campo”, e vem de usuários reais do Chrome). O WebPageTest é um teste de “laboratório” — uma execução controlada em uma máquina. Serve para encontrar e corrigir problemas, não para o número que o Google realmente vê.

As duas visualizações com que a maioria das pessoas começa

• O waterfall. Um gráfico com uma linha por arquivo que sua página carregou, empilhados na ordem em que chegaram. Barras longas e arquivos empilhados no início geralmente são onde sua lentidão está.
• O filmstrip. Uma linha de capturas de tela mostrando a página sendo pintada ao longo do tempo. Você pode literalmente assistir ao momento em que seu conteúdo principal aparece — ou ao momento em que algo pula na página.

Quer a versão completa — a visualização de conexão, a receita exata que uso para caçar mudança de layout, como ela se compara ao Lighthouse e ao CrUX, e como a uso para SEO técnico? Mude para a aba Avançado.

TL;DR — WebPageTest é uma ferramenta de desempenho de laboratório (sintética) gratuita e de código aberto: uma URL, um local de teste distribuído real, um navegador e um perfil de rede na entrada, diagnósticos aprofundados na saída — waterfall (sinalizações de bloqueio de renderização, sequenciamento), filmstrip/vídeo (quadro a quadro, com uma opção de Destacar Mudanças de Layout para CLS), visualização de conexão (DNS/TCP/TLS/TTFB) e Core Web Vitals quadro a quadro. Patrick Meenan o criou em 2008 (uma ferramenta interna da AOL); a Catchpoint o adquiriu em 2020; o código permanece aberto sob a licença Polyform Shield. A espinha dorsal da precisão: ele produz dados de laboratório, não dados de campo, portanto não alimenta o sinal de ranqueamento de CWV do Google (isso é o CrUX de usuários reais). É um diagnóstico, não a pontuação que o Google vê — e não é um concorrente do Lighthouse, porque você pode executar o Lighthouse dentro dele. Recorra a ele quando o PageSpeed Insights disser que uma página está lenta, mas não por quê ou onde no carregamento.

O que realmente é

Todo resultado do WebPageTest é uma execução configurada: uma URL, testada de um local específico, em um navegador e dispositivo específicos, com um perfil de conexão específico, em um momento específico. Não é uma medição universal de “quão rápido seu site é” — é evidência dessa execução, e precisa ser lida como tal.

Dentro desse enquadramento, o WebPageTest é a ferramenta de diagnóstico profundo na caixa de ferramentas de desempenho web. O web.dev, o próprio site de desenvolvedores do Google, o enquadra bem: “WebPageTest contains an advanced suite of metrics and trace viewers. It enables deep diving into the performance of your site on real mobile hardware with network conditions.” (tradução) «O WebPageTest contém um conjunto avançado de métricas e visualizadores de rastreamento. Ele permite um mergulho profundo no desempenho do seu site em hardware móvel real com condições de rede.» (web.dev, “How To Think About Speed Tools”)

A página de “auditoria” dele adiciona o ângulo adjacente a SEO: “WebPagetest will also check static-content caching, time to first byte, and if your site makes effective use of CDNs.” (tradução) «O WebPagetest também verificará o cache de conteúdo estático, o tempo até o primeiro byte e se o seu site faz uso eficaz de CDNs.» (web.dev, “Audit performance”)

Onde as ferramentas irmãs deste cluster — Google Lighthouse, PageSpeed Insights e o Chrome UX Report (CrUX) — dão a você uma pontuação ou um aprovado/reprovado, o WebPageTest dá a você a evidência solicitação por solicitação, quadro por quadro, por baixo da pontuação.

Uma breve história — e uma nota de rodapé genuinamente estranha

Patrick Meenan criou e abriu o código do WebPageTest em 2008; ele começou como uma ferramenta de teste interna na AOL. A Catchpoint o adquiriu em 2020. A página Sobre conta a história da origem diretamente: “Catchpoint’s 2020 acquisition of WebPageTest, created and open-sourced by Patrick Meenan in 2008, marked a significant milestone.” (tradução) «A aquisição do WebPageTest pela Catchpoint em 2020, criado e com código aberto por Patrick Meenan em 2008, marcou um marco significativo.» A missão declarada lá é direta: “slow is the new down, and our mission is to empower you to deliver the best experiences to your users.” (tradução) «lento é o novo indisponível, e nossa missão é capacitar você a entregar as melhores experiências aos seus usuários.» (webpagetest.org/about)

Aqui está a nota de rodapé estranha que vale a pena nomear: Meenan agora trabalha no Google com Chrome e desempenho web. E, no entanto, a própria página oficial de ferramentas de Core Web Vitals do Google — web.dev/articles/vitals-tools, a página exata que o documento de Core Web Vitals do Search Central vincula como “as diferentes ferramentas que podem ajudar você a medir e reportar Core Web Vitals” — não menciona o WebPageTest. Ela lista CrUX, PageSpeed Insights, Search Console, Lighthouse, o painel de Performance do DevTools, a biblioteca JS web-vitals e o Lighthouse-CI. A ferramenta construída pela pessoa que agora trabalha lá está ausente.

Leia isso com atenção, no entanto: não é um sinal de que o WebPageTest está obsoleto ou sem endosso. O Google seleciona sua lista de ferramentas de produto próprio; uma ferramenta de código aberto de terceiros simplesmente não está nela. Outras páginas do web.dev (speed-tools, performance-audit-tools) referenciam o WebPageTest positivamente. É uma lacuna de curadoria, não um veredito sobre a ferramenta.

Lab vs. campo — a distinção que mais importa

Esta é a espinha dorsal da precisão de todo o tópico, e é a irmã do ponto de lab-vs-campo que percorre todo o cluster de ferramentas de desempenho web.

O WebPageTest executa dados de lab (sintéticos): um teste controlado e repetível em uma máquina que você configura, em um momento que você escolhe. Isso é um animal diferente dos dados de campo — as medições reais de usuários do Chrome UX Report (CrUX) que o Google Search realmente usa para o sinal de ranqueamento de Core Web Vitals, e que aparecem no PageSpeed Insights e no Search Console.

Então, claramente:

• Uma execução do WebPageTest não alimenta o sinal de ranqueamento do Google. Ela mede as mesmas métricas com as quais o Google se importa (LCP, INP, CLS), mas o número com o qual o Google ranqueia vem dos dados de campo do CrUX, não de nenhuma execução de lab — nem a do WebPageTest, nem a seção de lab do PSI, nem a do Lighthouse.
• O WebPageTest é para diagnóstico: reproduzir um problema, isolá-lo e confirmar uma correção em um loop rápido e controlado. Os dados de campo (CrUX) são a confirmação lenta e autoritativa de que usuários reais sentiram a melhoria — veja Core Web Vitals para saber como esse sinal de ranqueamento funciona.

Em termos simples, um resultado do WebPageTest não é — e não pode substituir — dados de campo do CrUX, números de tráfego de usuários reais ou um ranqueamento no Google Search ou resultado de experiência de página. Esses são conjuntos de dados separados que precisam de suas próprias evidências; uma execução sintética rápida não é prova de que qualquer um deles mudou.

Se você só levar uma coisa desta página: O WebPageTest diz o que corrigir; o CrUX diz se o sinal de ranqueamento do Google mudou.

Como executar um teste básico

O fluxo principal é deliberadamente simples:

1. URL. A página pública que você quer testar (ela precisa ser publicamente acessível).
2. Local do teste. O WebPageTest é executado em máquinas reais fisicamente distribuídas ao redor do mundo — escolha uma perto do seu público, porque a distância e as condições de rede mudam o resultado.
3. Navegador / dispositivo. O Chrome oferece mais dados. Você também pode emular dispositivos móveis.
4. Perfil de conexão. Uma rede com limitação de banda (por exemplo, uma conexão móvel lenta) para que você teste condições realistas, não a fibra do seu escritório.
5. Execuções repetidas. Este é o que os iniciantes pulam. O desempenho varia de execução para execução (instabilidade de rede, carga do servidor, contenção de CPU), então o WebPageTest executa vários testes e relata uma mediana. Nunca confie em uma única execução — leia a mediana. Apenas tenha em mente que a mediana ainda é uma amostra sintética da sua configuração escolhida, não uma medição em nível de população do que visitantes reais experimentam — é para isso que servem os dados de campo (CrUX).

Cada uma dessas configurações faz parte do experimento, não é um detalhe incidental. Se você está comparando dois testes — antes/depois de uma correção, ou seu site contra o de um concorrente — a comparação só faz sentido quando você registra as configurações e as mantém constantes: mesmo local, mesmo navegador, mesmo perfil de conexão, mesmo estado de cache (primeira visita vs. visita repetida) e aproximadamente o mesmo número de execuções e janela de tempo. Se você mudar qualquer um desses entre as execuções, pode facilmente confundir a deriva da configuração do teste com uma diferença real de desempenho.

Lendo os resultados

O gráfico de cascata

A cascata é uma linha do tempo de solicitação por solicitação: uma linha por recurso, em ordem de carregamento, cada barra mostrando as fases de DNS/conexão/TLS/espera/download. Ela sinaliza recursos que bloqueiam a renderização, mostra cadeias de redirecionamento como saltos extras e torna óbvio quando um punhado de recursos no topo está bloqueando tudo atrás deles. É aqui que “reduzir recursos que bloqueiam a renderização” deixa de ser uma abstração e se torna “aquele arquivo CSS, naquele segundo.”

A visão de conexão

Agrupada por conexão em vez de por solicitação, esta visão expõe a consulta DNS, a conexão TCP, a negociação TLS e o tempo até o primeiro byte (TTFB) por host. É a maneira mais rápida de ver se a sua lentidão é do lado do servidor/rede (TTFB lento, muitas conexões separadas) versus do lado do conteúdo.

A visão de tira de filme / vídeo — e minha receita para caçar CLS

A tira de filme é uma sequência de capturas de tela da página sendo pintada ao longo do tempo; a visão de vídeo a reproduz. É assim que você vê — não infere — quando seu conteúdo principal aparece e quando algo na página pula.

Este é o recurso do WebPageTest em que mais confio, e já o abordei repetidamente em palestras e no meu guia de Core Web Vitals da Ahrefs. Para caçar Cumulative Layout Shift, a receita exata que uso: “In Filmstrip View, use the following options: Highlight Layout Shifts, Thumbnail Size: Huge, Thumbnail Interval: 0.1 secs.” (tradução) «Na visão de tira de filme, use as seguintes opções: destacar mudanças de layout, tamanho da miniatura: enorme, intervalo de miniatura: 0,1 s.» Isso transforma a tira de filme em uma linha do tempo de alta resolução onde uma mudança é impossível de passar despercebida. No exemplo real desse guia, o culpado era uma troca de fonte — “Notice how our font restyles between 5.1 secs and 5.2 secs, shifting the layout as our custom font is applied.” (tradução) «Observe como nossa fonte é reestilizada entre 5,1 s e 5,2 s, mudando o layout conforme nossa fonte personalizada é aplicada.» Fontes da web, imagens de carregamento tardio e anúncios injetados são os suspeitos usuais de CLS, e a tira de filme os pega visualmente em flagrante.

Um alerta: um recurso que termina de carregar no waterfall no mesmo momento em que o filmstrip mostra um salto é uma forte evidência circunstancial, não uma prova — é uma hipótese. Confirme isolando o suspeito (bloqueie esse domínio/solicitação, ou adie-o) e re-executando a mesma configuração; se a mudança desaparecer, você confirmou a causa em vez de apenas correlacionar duas linhas do tempo.

Core Web Vitals, quadro a quadro

O WebPageTest relata LCP, CLS e (com interação real) INP juntamente com TTFB, FCP e Speed Index — e permite que você veja onde no carregamento cada um aconteceu, em vez de apenas um valor final. Quando os dados de campo do CrUX estão disponíveis, eles podem ser exibidos junto com os resultados de laboratório, mas os diagnósticos profundos são a execução de laboratório.

Recursos avançados

• Scripting / fluxos de várias etapas. Teste páginas atrás de um login, ou um fluxo de carrinho/checkout — escreva os scripts das etapas para que o WebPageTest meça uma jornada real, não apenas uma homepage fria. Controle e anote do que o script depende: a conta/credenciais de teste usadas, o estado em que a conta está, qualquer conteúdo dinâmico na página e sua cota de API — um script não documentado é tão difícil de comparar entre execuções quanto um teste manual não documentado.
• Bloqueio de domínio / solicitação. Bloqueie um domínio de terceiros específico e re-execute para medir exatamente quanto aquele widget de chat ou script de anúncio está custando para você. Isso é algo que o PSI simplesmente não consegue fazer.
• Lighthouse dentro do WebPageTest. “WebPageTest vs. Lighthouse” é uma dicotomia falsa — você pode executar uma auditoria do Lighthouse de dentro do WebPageTest. Vale a pena ser preciso sobre o que isso significa: a auditoria do Lighthouse é seu próprio relatório distinto e versionado — sua própria pontuação de 0–100 e sua própria lista de auditorias — gerada dentro da sessão de teste mais ampla do WebPageTest, não mesclada nas métricas nativas de waterfall/filmstrip do WebPageTest. Como eu disse no guia da Ahrefs, a maioria das ferramentas de velocidade usa o Lighthouse internamente: “The exception is WebPageTest, although you can also run Lighthouse tests with it as well.” (tradução) «A exceção é o WebPageTest, embora você também possa executar testes do Lighthouse com ele.» (Ahrefs — Core Web Vitals)
• Opportunities & Experiments. Um recurso de comparação antes/depois de mudanças em HTML, sem código, que permite comparar dois estados de uma página sem tocar na produção — introduzido por volta de 2022, de acordo com a cobertura contemporânea de Detlef Johnson no Search Engine Land (esse artigo específico foi retirado do site desde então, e não consegui re-confirmar de forma independente o nome ou a disponibilidade atual do recurso contra uma sessão ao vivo do WebPageTest durante esta passagem de atualização — vale uma verificação nova antes de construir um fluxo de trabalho em torno dele com esse nome).
• API / automação e instâncias privadas. Existe uma API para testes programáticos e, como o código é open source, você pode montar sua própria instância privada.

Usando o WebPageTest para SEO técnico

Este é o ângulo que a maioria dos guias do WebPageTest ignora, e é por isso que a ferramenta pertence ao kit de um profissional de SEO técnico:

• Teste como Googlebot. Você pode definir um user agent do Googlebot e observar como o JS que bloqueia a renderização se comporta — uma aproximação útil (não uma réplica perfeita) de como o renderizador do Google pode experimentar a página. O guia de WebPageTest para SEO técnico da MobileMoxie enquadra bem o valor para SEO: “The tool provides detailed information about the health of your pages and helps analyze things like round trip requests, asset errors, redirects, caching concerns, security information, and more.” (tradução) «A ferramenta fornece informações detalhadas sobre a saúde das suas páginas e ajuda a analisar coisas como solicitações de ida e volta, erros de ativos, redirecionamentos, preocupações com cache, informações de segurança e muito mais.»
• Audite cadeias de redirecionamento. O waterfall expõe cada salto de redirecionamento, então uma cadeia de redirecionamento inchada (cada um é uma ida e volta) fica visível em vez de oculta.
• Verifique a eficácia de cache e CDN. De acordo com o web.dev acima, o WebPageTest verifica o cache de conteúdo estático, TTFB e uso de CDN — o encanamento que governa a rapidez com que bots e usuários recebem seus bytes.
• Diagnostique problemas de renderização por JS. Se o conteúdo só aparece depois que o JavaScript é executado, o filmstrip e o waterfall mostram quando (e se) ele foi pintado.
• Evidência de antes/depois para stakeholders. Um filmstrip lado a lado da página atual versus uma correção proposta é um artefato muito mais persuasivo para um cliente ou equipe de engenharia do que um número do Lighthouse que caiu seis pontos.

Preços e acesso

O serviço público gratuito em webpagetest.org historicamente ofereceu na ordem de centenas de execuções de teste por mês, além de uma chave de API gratuita com limites diários. Um nível pago do WebPageTest Pro desbloqueia mais volume de API, testes privados e prioridade na fila de testes. E como tudo é open source sob a licença Polyform Shield — o enquadramento da Catchpoint é que “the WebPageTest code remains freely accessible under the Polyform Shield license, permitting its use for internal or non-competing commercial projects” (tradução) «o código do WebPageTest permanece livremente acessível sob a licença Polyform Shield, permitindo seu uso para projetos comerciais internos ou não concorrentes» (webpagetest.org/about) — você também pode hospedar uma instância privada por conta própria.

Limitações honestas

• Curva de aprendizado. A interface é densa; um waterfall é intimidante antes de ser útil.
• Conta necessária para resultados salvos/privados. Testes avulsos casuais são abertos, mas salvar e testar de forma privada exigem uma conta.
• Ele diagnostica, não corrige. O WebPageTest mostra o problema em detalhes requintados; ele não vai segurar sua mão durante a correção como algumas ferramentas de pontuação tentam.
• Variabilidade de execução única. Uma única execução pode enganar. Use várias execuções e leia a mediana — a ferramenta usa esse padrão por um motivo.

Uma nota sobre o Bing

Não há documentação do Bing ou da Microsoft que posicione o WebPageTest como um input de ranqueamento ou recomendação de primeira parte. O Bing Webmaster Tools tem seu próprio Site Scan e recomendações relacionadas à velocidade, mas nada específico do WebPageTest — e o Core Web Vitals em si continua sendo principalmente uma construção do Google. (Não confunda o WebPageTest com o bing.com/tools/speedtest do Bing, que é um teste de velocidade de rede, não uma ferramenta de desempenho de página.)

Onde isso se encaixa

Este é o membro de diagnóstico profundo do cluster de ferramentas de desempenho web. Seus irmãos têm cada um um trabalho diferente: o Google Lighthouse é a auditoria de laboratório que produz a pontuação de 0–100 (e que muitas outras ferramentas executam nos bastidores); o PageSpeed Insights mostra dados de campo do CrUX e uma execução de laboratório do Lighthouse em uma única interface; o Chrome UX Report (CrUX) é o conjunto de dados de campo de usuários reais no qual o Google realmente ranqueia. Para as métricas que todas essas ferramentas medem e os limites que o Google usa, comece no hub de Core Web Vitals. Para todo o pipeline no qual essas ferramentas se inserem, veja o cluster de desempenho web.

Resumo de IA

Uma visão condensada da versão Avançada:

• WebPageTest = a ferramenta de desempenho baseada em laboratório, de diagnóstico profundo. Gratuita e de código aberto; criada por Patrick Meenan em 2008 (uma ferramenta interna da AOL), adquirida pela Catchpoint em 2020, código sob a licença Polyform Shield.
• Cada resultado é uma execução configurada — uma URL, um local, um navegador, um perfil de conexão, um momento no tempo — não uma medição universal. Comparações só fazem sentido quando você registra essas configurações e as mantém constantes.
• Laboratório, não campo. Produz dados sintéticos de laboratório e não alimenta o sinal de ranqueamento do Core Web Vitals do Google — isso é o CrUX de usuários reais (visto no PageSpeed Insights e no Search Console). Uma execução do WebPageTest também não estabelece tráfego de usuários reais ou um resultado de ranqueamento/experiência de página — é para diagnóstico, não para o número que o Google usa para ranquear.
• O fluxo: URL → local de teste distribuído real → navegador/dispositivo → rede com limitação → várias execuções repetidas, leia a mediana (nunca uma única execução — embora até a mediana ainda seja uma amostra sintética, não dados de campo).
• Visualizações principais: waterfall (solicitação por solicitação, sinalizações de bloqueio de renderização, cadeias de redirecionamento), filmstrip/vídeo (quadro a quadro; uma opção Highlight Layout Shifts para CLS), visualização de conexão (DNS/TCP/TLS/TTFB) e Core Web Vitals quadro a quadro. Alinhar um evento do waterfall com um quadro do filmstrip é uma hipótese forte, não uma prova — confirme isolando o recurso e testando novamente.
• Receita de CLS: Filmstrip View → Highlight Layout Shifts ativado, Thumbnail Size Huge, Thumbnail Interval 0,1 s — a maneira de capturar uma troca de fonte ou uma mudança tardia de imagem no ato.
• Não é um concorrente do Lighthouse — você pode executar uma auditoria do Lighthouse de dentro do WebPageTest, mas é um relatório próprio, distinto e versionado (pontuação própria, auditorias próprias), não mesclado nas métricas nativas do WebPageTest. Outros recursos avançados: script/fluxos de várias etapas (documentar credenciais/estado/cotas), bloqueio de domínios de terceiros, um recurso de comparação antes/depois sem código introduzido por volta de 2022 (seu nome/disponibilidade atual não foi reconfirmado de forma independente nesta passagem), uma API e auto-hospedagem.
• Usos de SEO: testar como Googlebot, auditar cadeias de redirecionamento, verificar cache/CDN/TTFB, diagnosticar renderização de JS e produzir evidências antes/depois para as partes interessadas.
• Nota de rodapé curiosa: Meenan agora trabalha no Google, mas a própria página oficial de ferramentas de CWV do Google (web.dev/articles/vitals-tools) não lista o WebPageTest. Isso é uma lacuna de curadoria para uma ferramenta de terceiros, não um sinal de que está obsoleta.
• Limitações: UI densa/curva de aprendizado, conta necessária para testes salvos/privados, diagnostica em vez de remediar, e execuções únicas podem enganar.

Documentação oficial

Documentação de fonte primária (menções do Google ao WebPageTest, documentação própria do WebPageTest e uma nota sobre o Bing).

WebPageTest / Catchpoint

• WebPageTest — About — a história de origem Meenan/Catchpoint, a declaração de missão e a licença Polyform Shield.
• WebPageTest — o serviço público gratuito de teste, incluindo o formulário de teste, a interface de resultados/filmstrip e a API para testes programáticos.

Google (onde referencia o WebPageTest — e onde notavelmente não o faz)

• web.dev — How To Think About Speed Tools — situa o WebPageTest como a opção avançada de diagnóstico em laboratório e observa que você pode executar o Lighthouse dentro dele.
• web.dev — Audit performance — WebPageTest para verificações de cache/TTFB/CDN.
• web.dev — Core Web Vitals tools — o resumo das próprias ferramentas de CWV do Google, que não menciona o WebPageTest (a nota de rodapé da lacuna de curadoria).
• Google Search Central — Core Web Vitals — links para web.dev para recomendações de ferramentas em vez de nomear uma ferramenta de laboratório de terceiros.

Bing / Microsoft

• Nenhuma documentação do Bing/Microsoft referencia o WebPageTest como um fator de ranqueamento ou recomendação de primeira parte. O próprio Site Scan do Bing Webmaster Tools é o análogo de primeira parte mais próximo. Consulte as diretrizes do Bing Webmaster para obter orientações gerais.

Citações da fonte

Declarações registradas sobre o WebPageTest. Quando um link inclui uma âncora #:~:text=, ele salta para a passagem citada na página de origem.

Google / web.dev — onde o WebPageTest se encaixa

• “WebPageTest contains an advanced suite of metrics and trace viewers. It enables deep diving into the performance of your site on real mobile hardware with network conditions.” (tradução) «O WebPageTest contém um conjunto avançado de métricas e visualizadores de rastreamento. Ele permite um mergulho profundo no desempenho do seu site em hardware móvel real com condições de rede.» — web.dev, “How To Think About Speed Tools.” Ir para a citação
• “WebPagetest will also check static-content caching, time to first byte, and if your site makes effective use of CDNs.” (tradução) «O WebPagetest também verificará o cache de conteúdo estático, o tempo até o primeiro byte e se o seu site faz uso eficaz de CDNs.» — web.dev, “Audit performance.” Ir para a citação

WebPageTest / Catchpoint — história, missão, licença

• “Catchpoint’s 2020 acquisition of WebPageTest, created and open-sourced by Patrick Meenan in 2008, marked a significant milestone.” (tradução) «A aquisição do WebPageTest pela Catchpoint em 2020, criado e de código aberto por Patrick Meenan em 2008, marcou um marco significativo.» — webpagetest.org/about. Fonte
• “slow is the new down, and our mission is to empower you to deliver the best experiences to your users.” (tradução) «lento é o novo indisponível, e nossa missão é capacitar você a entregar as melhores experiências aos seus usuários.» — webpagetest.org/about. Fonte
• “The WebPageTest code remains freely accessible under the Polyform Shield license, permitting its use for internal or non-competing commercial projects.” (tradução) «O código do WebPageTest permanece livremente acessível sob a licença Polyform Shield, permitindo seu uso para projetos comerciais internos ou não concorrentes.» — Catchpoint, webpagetest.org/about. Fonte

Patrick Stox (eu) / Ahrefs — a técnica de filmstrip de CLS

• “In Filmstrip View, use the following options: Highlight Layout Shifts, Thumbnail Size: Huge, Thumbnail Interval: 0.1 secs.” (tradução) «Na Visualização de Filmstrip, use as seguintes opções: Destacar Mudanças de Layout, Tamanho da Miniatura: Enorme, Intervalo da Miniatura: 0,1 s.» — do meu guia de Core Web Vitals da Ahrefs. Fonte
• “The exception is WebPageTest, although you can also run Lighthouse tests with it as well.” (tradução) «A exceção é o WebPageTest, embora você também possa executar testes do Lighthouse com ele.» — eu, sobre como o WebPageTest difere das ferramentas baseadas no Lighthouse. Fonte

MobileMoxie — o ângulo de SEO técnico

• “The tool provides detailed information about the health of your pages and helps analyze things like round trip requests, asset errors, redirects, caching concerns, security information, and more.” (tradução) «A ferramenta fornece informações detalhadas sobre a saúde das suas páginas e ajuda a analisar coisas como solicitações de ida e volta, erros de ativos, redirecionamentos, preocupações com cache, informações de segurança e muito mais.» — MobileMoxie, sobre o WebPageTest para SEO técnico. Fonte

Folha de dicas do WebPageTest

Onde ele se encaixa vs. as outras ferramentas

As visualizações

Receita para caçar CLS (minha)

• Filmstrip View → Highlight Layout Shifts ativado → Thumbnail Size: Huge → Thumbnail Interval: 0,1 secs. Observe o quadro em que o layout pula (geralmente uma troca de fonte da web ou um anúncio/imagem tardio).

Fatos rápidos

• Lab, não campo — não alimenta o sinal de ranqueamento de CWV do Google (isso é o CrUX).
• Leia a mediana, nunca uma única execução — o desempenho varia de execução para execução.
• Você pode executar o Lighthouse dentro do WebPageTest — não é um ou outro.
• Código aberto sob a licença Polyform Shield; é possível auto-hospedar.
• Meenan (criador) agora trabalha no Google, mas web.dev/articles/vitals-tools não lista o WebPageTest — uma lacuna de curadoria, não uma descontinuação.

Uma execução do WebPageTest — checklist

Obtenha um resultado confiável e útil em vez de um enganoso:

• Local de teste definido perto do seu público real (a distância muda os números).
• Perfil de dispositivo + conexão correspondem aos seus usuários (por exemplo, celular emulado em uma rede limitada), não à sua fibra do escritório.
• Múltiplas execuções repetidas ativadas — e você está lendo a mediana, não uma única execução.
• Verificou o waterfall para recursos que bloqueiam a renderização e saltos de redirecionamento perdidos.
• Verificou a visualização de conexão para um TTFB lento ou muitas conexões separadas.
• Executou o filmstrip para ver quando o conteúdo principal é pintado — e, para CLS, ativou Highlight Layout Shifts em intervalos de 0,1s, miniaturas Huge.
• Confirmou que está tratando o resultado como dados de lab — verificou o sinal de ranqueamento real em relação ao CrUX (PageSpeed Insights / Search Console).
• Para um terceiro suspeito, usou bloqueio de domínio/solicitação para medir seu custo real.
• Para fluxos de login/checkout, usou script em vez de testar uma página inicial fria.
• Salvou um filmstrip antes/depois se você está propondo uma correção às partes interessadas.

Ferramentas que combinam com o WebPageTest

• O próprio WebPageTest (webpagetest.org) — a ferramenta pública gratuita de lab, além da API e um nível Pro pago para volume/testes privados.
• PageSpeed Insights — a maneira rápida de verificar os dados de campo (CrUX) que o WebPageTest não pode gerar, para você saber se o sinal de ranqueamento realmente mudou.
• Google Search Console — relatório de Core Web Vitals — encontre grupos de páginas com falha em escala no site e, em seguida, leve uma URL representativa ao WebPageTest para diagnosticar.
• Painel Performance do Chrome DevTools — o companheiro local, amigável para login, para criação de perfil de lab quando você não precisa de locais distribuídos.
• Google Lighthouse — executável de dentro do WebPageTest, ou autônomo no DevTools/CLI para a auditoria de 0 a 100.
• CrUX Vis (cruxvis.withgoogle.com) — visualize a tendência de campo de usuários reais ao longo do tempo para confirmar que uma correção diagnosticada pelo WebPageTest funcionou para usuários reais. (Veja o Chrome UX Report (CrUX).)

Erros do WebPageTest que criam falsa confiança

Tratando uma execução de laboratório como o veredito de campo do Google

O WebPageTest é um dado sintético do dispositivo, local, navegador e perfil de rede que você selecionou. Use-o para diagnosticar causas; use o CrUX ou RUM de primeira parte para descrever usuários reais e a avaliação de CWV do Google.

Comparando execuções com configurações de teste diferentes

Uma mudança de local, conexão, navegador, estado de cache ou número de execuções pode superar a mudança de código que está sendo testada. Salve a configuração e compare coisas semelhantes.

Otimizando a pontuação principal em vez do waterfall

O valor do WebPageTest está no sequenciamento de requisições, configuração de conexão, filmstrips e temporização de métricas. Rastreie a métrica lenta até uma requisição concreta ou evento de thread principal em vez de ajustar uma nota isoladamente.

Julgando uma mudança a partir de uma única execução

Testes de laboratório variam. Execute vários testes sob o mesmo perfil e compare resultados representativos; investigue outliers em vez de selecionar a execução mais rápida.

Testando apenas a página inicial

Templates diferentes têm elementos de LCP, scripts, terceiros e comportamento de cache diferentes. Inclua as páginas onde os usuários e os dados de campo mostram o problema real.

Prove uma mudança de desempenho no WebPageTest

Teste controlado de antes/depois

Teste a executar: salve uma configuração de local/navegador/rede/cache e execute vários testes para as versões inalterada e alterada. Resultado esperado: a métrica alvo e sua causa no waterfall melhoram em execuções representativas. Interpretação de falha: a mudança é ineficaz ou a variância do teste excede o efeito. Janela de monitoramento: resultado de laboratório imediato. Gatilho de reversão: uma regressão consistente na métrica alvo ou em um Core Web Vital adjacente.

Teste de sequenciamento de requisições

Teste a executar: compare waterfalls após alterar preload, prioridade, CSS/JS bloqueante ou cache. Resultado esperado: a requisição pretendida começa mais cedo, transfere menos bytes ou evita a rede no estado de cache esperado. Interpretação de falha: a dica/configuração não foi aplicada ou outra dependência controla a sequência. Janela de monitoramento: imediata. Gatilho de reversão: a mudança atrasa uma requisição mais crítica ou cria erros.

Teste de correção visual

Teste a executar: inspecione o filmstrip/vídeo e o destaque de mudança de layout para o mesmo perfil de antes/depois. Resultado esperado: renderização mais rápida não introduz conteúdo ausente, flashes ou novas mudanças. Interpretação de falha: a melhoria numérica trocou a correção visual. Janela de monitoramento: cada viewport representativo antes do lançamento. Gatilho de reversão: conteúdo quebrado ou nova instabilidade visível.

Recursos que valem seu tempo

Meus escritos relacionados

• Core Web Vitals: A Complete Guide (Ahrefs) — inclui minha receita de Filmstrip do WebPageTest para diagnosticar Cumulative Layout Shift, o enquadramento WebPageTest-vs-Lighthouse e as métricas que o WebPageTest mede, além de como o lado do ranqueamento funciona. (Esta página absorveu meu post anterior “Advanced Guide to PageSpeed Insights”, que agora redireciona para cá.)
• The Beginner’s Guide to Technical SEO (Ahrefs) — onde o desempenho web se encaixa no panorama geral.

Minhas palestras

• Page Experience Update — TMC, June 2021 (SlideShare) — cobre a mesma técnica de Filmstrip/CLS do WebPageTest em formato de palestra.
• A Crash Course in Technical SEO — Beer & SEO Meetup, May 2019 (SlideShare) — WebPageTest como parte do kit de ferramentas de SEO técnico, lá em 2019.

Do setor

• WebPageTest — Sobre — a fonte primária para a história, missão e licença Polyform Shield.
• Como pensar em ferramentas de velocidade (web.dev) — o próprio posicionamento do Google sobre o WebPageTest entre as ferramentas de teste em laboratório.
• Auditar desempenho (web.dev) — WebPageTest para verificações de cache, TTFB e CDN.
• Como configurar o WebPageTest para avaliar SEO técnico (MobileMoxie) — o guia de configuração mais próximo existente com foco em SEO (UA do Googlebot, redirecionamentos, cache, erros de ativos).
• Um guia completo para usar o WebPageTest (Kinsta) — o explicador geral mais abrangente (história, configuração, interpretação de resultados, preços).
• WebPageTest: um guia para testes de desempenho web (DebugBear) — escrito pelo fornecedor, mas com uma boa análise da média de múltiplas execuções, visualizações de waterfall/filmstrip/conexão e script.

Teste-se: WebPageTest

Cinco perguntas rápidas sobre o que é o WebPageTest, como lê-lo e onde ele se encaixa. Escolha uma resposta para cada uma e depois confira.

Registro de alterações