Speed Index e SEO

TL;DR — Speed Index é uma pontuação do Lighthouse para a rapidez com que o conteúdo da sua página aparece enquanto ela carrega. Menor (mais rápido) é melhor, medido em segundos. No celular, abaixo de 3,4 s é bom. Não é um Core Web Vital e não afeta diretamente seus rankings no Google — mas as coisas que o corrigem geralmente ajudam as métricas que afetam.

O que é Speed Index

Quando você executa uma página no Lighthouse ou no PageSpeed Insights, um dos números que você recebe é o Speed Index. Ele responde a uma pergunta simples: com que rapidez a parte visível da sua página é preenchida?

A maioria das métricas de velocidade marca um único momento — como quando o primeiro conteúdo aparece (First Contentful Paint) ou quando o maior elemento aparece (Largest Contentful Paint). O Speed Index é diferente. Ele observa o carregamento inteiro e fornece uma média de quão rapidamente as coisas se tornaram visíveis. Uma página que renderiza tudo quase instantaneamente obtém uma pontuação baixa (boa); uma página que fica em branco e depois vai exibindo o conteúdo aos poucos obtém uma pontuação alta (ruim).

Como interpretar sua pontuação

O Lighthouse classifica o Speed Index no celular assim:

• Bom: 0 – 3,4 s (verde)
• Precisa de melhorias: 3,4 – 5,8 s (laranja)
• Ruim: mais de 5,8 s (vermelho)

O desktop é muito mais rigoroso — bom é aproximadamente abaixo de 1,3 s — porque o Lighthouse testa celular em um dispositivo simulado mais lento. Portanto, não compare um número de desktop com um de celular; eles estão em escalas diferentes.

Isso importa para SEO?

Aqui está a parte que as pessoas erram. Speed Index não é um Core Web Vital e não é um fator de ranqueamento do Google. Os sinais de experiência de página do Google vêm dos Core Web Vitals (LCP, INP e CLS) medidos em usuários reais. O Speed Index não é um deles e nem é medido em usuários reais — ele precisa de uma gravação em vídeo do carregamento, o que só acontece em ferramentas de teste.

Isso não o torna inútil. As correções que melhoram o Speed Index — um servidor mais rápido, menos arquivos que bloqueiam a renderização, texto que permanece visível enquanto as fontes carregam — são as mesmas correções que melhoram o FCP e o LCP. Portanto, um Speed Index melhor geralmente anda alinhado com um LCP melhor, o que importa.

Se você quiser a fórmula, o histórico do WebPageTest, onde ele se encaixa na pontuação do Lighthouse e as limitações a observar, mude para a aba Avançado.

TL;DR — Speed Index mede a rapidez com que o conteúdo é exibido visualmente durante o carregamento da página — o tempo médio em que o conteúdo visível aparece, pontuado em segundos (menor é melhor). Ele é calculado a partir de um vídeo do carregamento somando a área acima da curva de progresso visual, o que o torna uma métrica apenas de laboratório (não está no CrUX, nos dados de campo do PSI ou no Search Console). Ele se originou no WebPageTest (Pat Meenan); o Lighthouse o calcula por meio do módulo de código aberto Speedline. Ele não é um Core Web Vital e não é um fator de ranqueamento — é uma das cinco métricas do Lighthouse, com peso de 10% no Lighthouse 10. Celular: Bom ≤ 3,4 s, Precisa de melhorias ≤ 5,8 s, Ruim > 5,8 s; desktop bom ≤ ~1,3 s. Ele não pode ser mais rápido que o FCP, é dependente do viewport e melhora com as mesmas correções do FCP/LCP.

O que o Speed Index realmente mede

A definição do Google é uma linha: “Speed Index measures how quickly content is visually displayed during page load.” (tradução) «O Speed Index mede a rapidez com que o conteúdo é exibido visualmente durante o carregamento da página.» A palavra-chave é visualmente. O Speed Index não é um único timestamp como First Contentful Paint e Largest Contentful Paint são — é uma pontuação composta que representa o tempo médio em que as partes visíveis da página são exibidas. Menor é melhor, e é relatado em segundos.

O modelo mental que considero mais claro: desenhe um gráfico com o tempo no eixo X e “percentual da página visualmente completa” no eixo Y, subindo de 0% a 100%. O Speed Index é a área acima dessa curva. Quanto mais rápido a curva sobe até 100%, menor a área, melhor a pontuação. Uma página que fica em branco por um tempo deixa um grande retângulo de área vazia acima da linha; uma página que renderiza rápido deixa quase nenhum.

Como é calculado

O Lighthouse captura um vídeo do carregamento da página e calcula a progressão visual entre os quadros. Cada intervalo de tempo é ponderado por quão incompleta a página ainda está naquele momento — um quadro totalmente em branco conta como 100%, um quadro quase renderizado conta muito pouco. A fórmula original do WebPageTest é:

Speed Index = Σ ( interval × (1 − visual completeness% / 100) )

Um exemplo prático torna isso concreto. O DebugBear detalha um carregamento assim:

• 0% completo (0–253 ms) → contribuição de 253,0 ms
• 43% completo (253–403 ms) → contribuição de 85,5 ms
• 98% completo (403–536 ms) → contribuição de 2,7 ms
• 99% completo (536–653 ms) → contribuição de 1,2 ms
• Total: 342,3 ms

Observe o primeiro trecho: enquanto nada está visível, todo esse tempo contribui com peso total. É por isso que o Speed Index nunca pode ser mais rápido que o First Contentful Paint — cada milissegundo antes do primeiro conteúdo ser pintado é contado como 100%.

O Lighthouse não implementa isso do zero. Ele executa o módulo open-source Speedline (originalmente de Paul Irish), que aplica a mesma metodologia de progressão visual a partir de vídeo do WebPageTest, trabalhando com rastros do Chrome DevTools com capturas de tela habilitadas. O Speedline pode calcular um Speed Index padrão (diferença de histograma entre o quadro atual e o final) ou uma variante perceptual usando SSIM; o padrão é o que você normalmente vê.

O que é uma boa pontuação

O Lighthouse 10 avalia o Speed Index com base em dados de sites reais do HTTP Archive, e os limites diferem bastante por dispositivo, pois o Lighthouse simula um dispositivo móvel de médio porte com throttling por padrão:

Se você já viu o antigo benchmark “menos de 1.000 ms é bom” por aí, isso é uma diretriz legada do WebPageTest para uma era e um perfil de conexão específicos — não é a barra atual do Lighthouse para mobile. Sempre saiba qual ferramenta e quais configurações de dispositivo/rede produziram o número que você está vendo, porque a mesma página pontua diferente no Lighthouse, no WebPageTest e no GTmetrix.

Onde ele se encaixa na pontuação do Lighthouse

O Speed Index é uma das cinco métricas na pontuação de Performance do Lighthouse 10, e tem peso de 10% — empatado com o FCP como o menor peso:

A conclusão prática: buscar o Speed Index isoladamente tem baixo ROI. O Total Blocking Time (30%) e o LCP e o CLS (25% cada) movem a pontuação geral muito mais. A menos que o Speed Index seja especificamente o que está falhando, você geralmente ganha mais corrigindo LCP e TBT — e o Speed Index melhora como efeito colateral de qualquer forma. No PageSpeed Insights, você encontra o Speed Index na seção de laboratório (Lighthouse), não na seção de dados de campo no topo.

O Speed Index é um Core Web Vital ou um fator de ranqueamento?

Não em ambos os casos, e a distinção importa quando você está explicando um relatório para uma parte interessada.

• Não é um Core Web Vital. Os Core Web Vitals são LCP, INP e CLS, medidos em usuários reais via CrUX. O Speed Index não está nesse conjunto e não aparece no relatório de Core Web Vitals do Search Console.
• Não é um fator de ranqueamento direto. O sinal de experiência de página do Google usa dados de campo dos Core Web Vitals. O Speed Index é um diagnóstico apenas de laboratório que o Google não coleta de usuários reais, então não há um caminho direto do seu número de Speed Index para os ranqueamentos.

A relação com os ranqueamentos é indireta: os problemas que produzem um Speed Index ruim — TTFB lento, CSS/JS que bloqueiam a renderização, texto invisível durante a troca de fonte — são os mesmos que produzem um FCP e LCP ruins. Corrija-os e um Speed Index melhor geralmente acompanha um LCP melhor, que é a parte que o Google realmente recompensa.

Por que é apenas de laboratório

O Speed Index precisa de um vídeo quadro a quadro do renderização da página e, em seguida, de processamento de imagem para calcular a completude visual em cada quadro. Isso é caro demais para ser executado em cada visitante real, então ele só existe em ferramentas sintéticas/de laboratório — Lighthouse, WebPageTest, GTmetrix. O Real User Monitoring e o conjunto de dados CrUX simplesmente não o incluem. Se você precisa de dados de desempenho de campo, use Core Web Vitals; o Speed Index serve para diagnosticar a renderização em um teste controlado.

De onde veio

O Speed Index se originou no WebPageTest, que Pat Meenan criou e disponibilizou como código aberto em 2008 (a métrica em si foi adicionada por volta de 2012). Ele foi projetado para preencher uma lacuna real nas métricas da época:

• Início da renderização podia disparar em um único pixel ou em uma cor de fundo — não em conteúdo significativo.
• Documento completo (onload) inclui recursos abaixo da dobra e irrelevantes.

O Speed Index dividiu a diferença medindo a completude visual acima da dobra ao longo do tempo — um proxy melhor para o que o usuário realmente percebe. O Lighthouse adotou essa metodologia por meio do módulo Speedline, e é por isso que os números do WebPageTest e do Lighthouse compartilham uma linhagem, mesmo com limitações de throttling diferentes.

Como melhorar

Não há truque específico para o Speed Index — a orientação do próprio Google é que qualquer coisa que você fizer para melhorar a velocidade de carregamento da página melhorará sua pontuação de Speed Index. Na prática:

• Reduza o tempo de resposta do servidor (TTFB). Cada milissegundo antes do primeiro byte é tempo de página em branco contado com peso total.
• Elimine CSS e JavaScript que bloqueiam a renderização. Eles atrasam a primeira pintura, que é a parte mais cara da curva. Coloque o CSS crítico inline e adie o restante.
• Corrija o carregamento de fontes. Durante uma troca de fonte, o texto pode ficar invisível — contando como 0% completo nesse intervalo. font-display: swap (ou optional) mantém o texto visível. Esta é uma das auditorias que o Lighthouse sinaliza explicitamente para o Speed Index.
• Minimize o trabalho na thread principal e reduza o tempo de execução do JavaScript — os outros dois diagnósticos que o Lighthouse aponta como de alto impacto para o Speed Index.
• Priorize o conteúdo acima da dobra. O Speed Index só se importa com a viewport visível, então fazer a primeira tela ser pintada rapidamente é o jogo inteiro.

Essas ações se sobrepõem quase completamente à otimização de FCP e LCP — e é exatamente por isso que trato o Speed Index como um sinal corroborativo, não como uma lista de tarefas separada. Antes de agir com base em qualquer número isolado, observe o filmstrip de carregamento (o Lighthouse e o WebPageTest geram um) para confirmar o que está realmente sendo pintado cedo versus tarde, e compare algumas execuções repetidas e equivalentes em vez de um único teste — veja a nota sobre variabilidade entre execuções abaixo.

Limitações que vale a pena conhecer

• Somente em laboratório — nunca reflete a experiência real do usuário, apenas a do ambiente de teste.
• Depende do viewport — mede a área visível, então mobile e desktop dão resultados muito diferentes (daí os limites tão diferentes).
• Ponto cego para SPA/AJAX — aplicativos de página única podem parecer artificialmente rápidos: o shell é pintado rapidamente enquanto o conteúdo real carrega depois, sem atualização de página.
• Carrosséis, vídeo em autoplay e overlays de consentimento — qualquer coisa que continue mudando pixels após o carregamento do conteúdo significativo pode ser penalizada por continuar registrando como “incompleto”, o mesmo mecanismo que penaliza carrosséis com rotação automática.
• Não é uma métrica de “carregamento completo” — mede a progressão visual acima da dobra, não quando cada script, imagem ou elemento abaixo da dobra termina. A métrica separada Visually Complete do WebPageTest (sempre ≥ Speed Index) é a que captura um widget carregado tardiamente de forma lazy.
• Progresso visual não é prova de utilidade. O Speed Index apenas mede a mudança de pixels em relação a um quadro final — ele não sabe se o que está na tela é legível, corretamente ordenado, acessível ou realmente interativo. Um esqueleto ou shell que pinta rápido pode pontuar bem enquanto o conteúdo real (e a capacidade de usá-lo) chega depois; esse é o mesmo modo de falha do anti-padrão “pintura inicial sem sentido” acima, apenas descrito do lado da métrica.
• Variabilidade entre execuções. Como é derivado de um único carregamento gravado, o Speed Index varia com as condições do teste — as próprias diretrizes de pontuação do Google listam diferenças de dispositivo, extensões de navegador, software antivírus e até mudanças de anúncios/testes A/B como fontes de flutuação de pontuação que não têm nada a ver com seu código. Compare distribuições de execuções repetidas e comparáveis, não números isolados.

Métricas relacionadas

O Speed Index está no mesmo cluster de desempenho web que o hub de Core Web Vitals e seus vizinhos. Ele é mais próximo do First Contentful Paint (o Speed Index não pode ser menor que o FCP) e do Largest Contentful Paint (mesmas correções, mesmas causas raiz), fica ao lado do Total Blocking Time na pontuação do Lighthouse, e você o encontrará dentro do Lighthouse e do PageSpeed Insights. Para as métricas de campo que realmente impulsionam o ranqueamento, comece pelo hub de Core Web Vitals.

Resumo de IA

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

• Speed Index = rapidez com que o conteúdo é exibido visualmente durante o carregamento — uma pontuação composta (tempo médio em que o conteúdo visível aparece), não um único timestamp. Relatado em segundos; quanto menor, melhor.
• Modelo mental: a área acima da curva de progresso visual (tempo vs. % visualmente completo). Calculado a partir de um vídeo do carregamento, ponderando cada intervalo pelo quão incompleta a página ainda está.
• Somente em laboratório: precisa de capturas de tela quadro a quadro, então não está no CrUX, nos dados de campo do PageSpeed Insights ou no Search Console. Use Core Web Vitals para dados de campo.
• Origem: WebPageTest (Pat Meenan, 2008; métrica ~2012). O Lighthouse o calcula via módulo open-source Speedline — mesma metodologia do WebPageTest.
• Não é um Core Web Vital, não é um fator de ranqueamento. Os CWVs são LCP, INP, CLS. A ligação com o ranqueamento é indireta: corrigir o Speed Index geralmente melhora FCP/LCP.
• Peso no Lighthouse 10: 10% — empatado com FCP como o menor. TBT (30%) e LCP/CLS (25% cada) importam muito mais, então focar apenas no Speed Index tem baixo ROI.
• Limites (mobile): Bom ≤ 3,4 s, Precisa de melhorias ≤ 5,8 s, Ruim > 5,8 s; bom no desktop ≤ ~1,3 s. Ele não pode ser mais rápido que o FCP e depende do viewport.
• Correções = correções de FCP/LCP: TTFB mais rápido, menos recursos que bloqueiam a renderização, font-display: swap, menos trabalho na thread principal/JS, priorizar o conteúdo acima da dobra.
• Limitações: SPAs podem pontuar artificialmente bem; carrosséis, vídeo em autoplay e overlays de consentimento podem ser penalizados; não é uma medida de “carregamento completo”; progresso visual não é prova de que o conteúdo é legível, acessível ou utilizável; e uma única execução pode ser afetada por dispositivo, extensões ou mudanças de anúncios/testes A/B que não têm nada a ver com seu código.

Documentação oficial

Documentação de fonte primária para o Speed Index.

Google / Lighthouse

• Speed Index (auditoria do Lighthouse) — a referência canônica: definição, como o Lighthouse o calcula via Speedline, limites de pontuação e as auditorias de otimização.
• Pontuação de desempenho do Lighthouse — onde estão o peso de 10% do Speed Index e o detalhamento completo das métricas.
• Minimize o trabalho da thread principal — uma das três auditorias que o Lighthouse sinaliza como de alto impacto para o Speed Index.
• Reduza o tempo de execução do JavaScript — a segunda auditoria sinalizada.
• Garanta que o texto permaneça visível durante o carregamento da webfont (font-display) — a terceira auditoria sinalizada.

Origem / implementação

• Speedline (paulirish/speedline) — o módulo de código aberto que o Lighthouse usa para calcular o Speed Index a partir de traces do DevTools.
• Código-fonte do Lighthouse — speed-index.js — a constante de descrição da auditoria.
• WebPageTest — Sobre — Pat Meenan criou e disponibilizou como código aberto o WebPageTest, onde o Speed Index se originou.

Citações da fonte

Declarações registradas. Cada link do Google/Lighthouse é um link profundo que salta para o trecho citado.

Google — o que o Speed Index mede

• “Speed Index measures how quickly content is visually displayed during page load.” (tradução) «O Speed Index mede a rapidez com que o conteúdo é exibido visualmente durante o carregamento da página.» Ir para a citação

Google — como a pontuação é definida

• “Your Speed Index score is a comparison of your page’s speed index and the speed indexes of real websites, based on data from the HTTP Archive.” (tradução) «Sua pontuação de Speed Index é uma comparação entre o speed index da sua página e os speed indexes de sites reais, com base em dados do HTTP Archive.» Ir para a citação

Fontes repassadas (parafraseadas de documentação secundária, não citadas textualmente)

• O Lighthouse captura um vídeo do carregamento da página, calcula a progressão visual entre os quadros e gera a pontuação com o módulo Speedline — com base nos mesmos princípios do Speed Index original do WebPageTest. (Auditoria de Speed Index do Lighthouse, seção de cálculo.)
• Quanto mais tempo um quadro fica visível e menos completa a página está nesse ponto, mais esse quadro contribui para a pontuação — e como todo o tempo antes do FCP conta como 100%, o Speed Index não pode ser mais rápido que a First Contentful Paint. (DebugBear, documentação do Speed Index.)
• O Speed Index só está disponível em testes sintéticos/de laboratório por causa do custo do processamento de capturas de tela quadro a quadro. (DebugBear, documentação do Speed Index.)
• A métrica foi adicionada ao WebPageTest por volta de 2012, sobre a ferramenta que Pat Meenan disponibilizou como código aberto em 2008. (KeyCDN; página Sobre do WebPageTest.)

Folha de referência do Speed Index

Limites (Lighthouse 10)

Pesos de desempenho do Lighthouse 10

Fatos rápidos

• Mede a completude visual ao longo do tempo (área acima da curva de progresso), não um único timestamp. Quanto menor, melhor.
• Somente em laboratório — não está no CrUX, nos dados de campo do PSI ou no Search Console.
• Não é um Core Web Vital; não é um fator de ranqueamento direto.
• Nunca pode ser mais rápido que o FCP (o tempo antes do FCP conta como 100%).
• Depende da viewport — as pontuações para mobile e desktop diferem bastante.
• Calculado pelo Speedline; originou-se no WebPageTest (Pat Meenan).

Melhore-o (igual ao FCP/LCP)

• Reduza o TTFB (resposta mais rápida do servidor).
• Remova CSS/JS que bloqueiam a renderização; incorpore o CSS crítico.
• Use font-display: swap / optional para que o texto permaneça visível.
• Minimize o trabalho na thread principal e o tempo de execução de JS.
• Priorize a renderização acima da dobra.

Não se engane

• “Abaixo de 1.000 ms” é uma orientação antiga do WebPageTest, não o limite do Lighthouse para mobile.
• SPAs podem obter pontuações artificialmente boas; carrosséis podem ser penalizados.

Ferramentas que relatam o Índice de Velocidade

• Lighthouse (no Chrome DevTools, na CLI ou no módulo Node) — relata o Índice de Velocidade como uma das cinco métricas de Performance, calculado via Speedline.
• PageSpeed Insights — executa o Lighthouse e mostra o Índice de Velocidade na seção lab (Diagnósticos). Observação: a seção de dados de campo no topo usa Core Web Vitals, então o Índice de Velocidade nunca aparece lá.
• WebPageTest — onde a métrica se originou; relata o Índice de Velocidade junto com as visualizações Visually Complete e filmstrip, com perfis de conexão configuráveis.
• GTmetrix — exibe o Índice de Velocidade em sua interface, usando dados do WebPageTest; seus números não corresponderão aos do Lighthouse devido a diferentes simulações de dispositivo/rede.
• DebugBear — monitoramento sintético com uma análise clara quadro a quadro de como a pontuação do Índice de Velocidade foi calculada.

Um lembrete ao comparar ferramentas: a mesma página produz valores diferentes de Índice de Velocidade entre Lighthouse, WebPageTest e GTmetrix devido às diferentes suposições de throttling e dispositivo. Compare coisas semelhantes.

Erros de Índice de Velocidade que desperdiçam tempo de otimização

• Chamar o Índice de Velocidade de Core Web Vital. É uma métrica de progresso visual somente de laboratório, não um sinal de ranqueamento de campo. Use-o para diagnosticar como uma página é preenchida e depois verifique os Core Web Vitals reais separadamente.
• Comparar limites de mobile e desktop. O Lighthouse usa curvas de pontuação e condições de teste diferentes. Acompanhe um perfil ao longo do tempo em vez de tratar as duas pontuações como intercambiáveis.
• Melhorar o número com uma pintura inicial sem significado. Um shell de cabeçalho pode fazer o progresso visual começar mais cedo enquanto o conteúdo principal permanece em branco. Revise o filmstrip de carregamento junto com a métrica.
• Otimizar cada imagem antes de verificar o caminho crítico. TTFB lento, CSS que bloqueia a renderização, fontes e JavaScript síncrono podem atrasar toda a sequência visual. Encontre o primeiro gargalo no waterfall e rastreie.
• Esperar um valor estável de execução única. O Índice de Velocidade é derivado de um vídeo sintético e muda com o ambiente de teste. Repita execuções comparáveis antes de declarar uma regressão ou vitória.

Teste-se: Índice de Velocidade

Cinco perguntas rápidas sobre o que o Índice de Velocidade mede. Escolha uma resposta para cada uma e depois confira.

Recursos que valem seu tempo

Oficial

• Speed Index — auditoria do Lighthouse — a definição canônica, limites e auditorias de otimização.
• Pontuação de performance do Lighthouse — os pesos das métricas, incluindo os 10% do Índice de Velocidade.
• WebPageTest — Sobre — a origem da métrica.

Implementação

• paulirish/speedline — o módulo de código aberto que o Lighthouse usa para calcular o Índice de Velocidade.

De outros

• DebugBear — Speed Index — o exemplo prático passo a passo mais claro do cálculo e da relação com o FCP.
• KeyCDN — Speed Index — contexto histórico e a fórmula do WebPageTest.
• Catchpoint — Speed Index — sucessor do blog do WebPageTest; fórmula de progresso visual e as limitações de SPA/carrossel.
• Google Search Central — Core Web Vitals — confirma que LCP, INP e CLS são os sinais de ranqueamento; o Speed Index não é listado, reforçando que ele não tem impacto direto no ranqueamento.
• web.dev — Visão geral das Vitals — a definição autoritativa de Core Web Vitals (LCP, INP, CLS); o Speed Index está ausente, útil ao explicar por que ele não afeta o ranqueamento.
• WebPageTest — Documentação do Speed Index — contexto sobre a criação do WebPageTest por Pat Meenan (código aberto em 2008) e onde a métrica Speed Index se originou.

Números que valem a pena citar

• Peso do Lighthouse: 10% da pontuação de Performance no Lighthouse 10 — empatado com o FCP pelo menor peso, bem atrás do TBT (30%) e LCP/CLS (25% cada). Fonte
• “Bom” no mobile ≤ 3,4 s; “bom” no desktop ≤ 1,3 s — limites do Lighthouse 10, calibrados com dados de sites reais do HTTP Archive. Fonte
• Speed Index ≥ FCP, sempre — todo o tempo antes da primeira pintura de conteúdo contribui com 100%, então o Speed Index não pode ser mais rápido que a First Contentful Paint. Fonte
• Origem: WebPageTest, ~2012 — adicionado sobre a ferramenta que Pat Meenan tornou de código aberto em 2008. Fonte

Registro de alterações