Primeiro atraso de entrada (FID)

TL;DR — First Input Delay (FID) é uma métrica antiga. Ela media quanto tempo sua página fazia alguém esperar antes de conseguir sequer começar a reagir ao primeiro clique ou toque. O Google a aposentou em março de 2024 e a substituiu pelo INP, depois a removeu completamente das ferramentas em setembro de 2024. Portanto, não há mais nada para corrigir aqui — mas vale saber o que era se você encontrar “FID” em relatórios antigos.

O que era o First Input Delay

Quando você toca em um botão e nada acontece por um instante, a página parece quebrada — mesmo que pareça carregada. First Input Delay (FID) era a maneira que o Google encontrou de transformar essa frustração específica em um número.

O FID media uma coisa bem específica: o intervalo entre sua primeira interação com uma página (um clique, um toque, uma tecla) e o momento em que o navegador estava realmente livre para começar a responder. Se o navegador estivesse ocupado executando JavaScript quando você tocasse, seu toque teria de esperar na fila. Essa espera era o “atraso”.

Duas coisas que ele não media:

• Quanto tempo o código do botão levou para executar depois que começou.
• Quanto tempo a página levou para se atualizar visualmente depois.

Apenas a espera antes de qualquer coisa poder começar. Essa limitação é uma das principais razões pelas quais ele acabou sendo substituído.

O que era uma boa pontuação

O FID era medido em milissegundos:

• Bom: 100 ms ou menos
• Precisa melhorar: 100–300 ms
• Ruim: acima de 300 ms

Por que você não precisa mais se preocupar com ele

Esta é a parte importante para quem estiver lendo isto em 2026: o FID está aposentado. O Google o substituiu como Core Web Vital pelo INP (Interaction to Next Paint) em 12 de março de 2024 — o Search Console deixou de mostrar o FID no mesmo dia. O PageSpeed Insights e a API do CrUX continuaram informando a métrica por um pouco mais de tempo e depois a removeram em 9 de setembro de 2024. Se um tutorial ou painel antigo ainda lista o FID como Core Web Vital atual, esse conteúdo está desatualizado.

O INP faz o mesmo trabalho melhor: em vez de cronometrar apenas a espera da primeira interação, ele mede a responsividade completa de todas as interações durante uma visita. Se você está tentando fazer seu site parecer ágil hoje, acompanhe o INP, não o FID.

Quer o histórico completo — os limites exatos, por que o FID foi projetado de forma tão restrita, onde os dados antigos de FID ainda vivem e como ele se relaciona com o INP? Mude para a aba Avançado.

TL;DR — O FID foi o Core Web Vital de responsividade até ser substituído pelo INP em 12 de março de 2024 — a mesma data em que o Search Console também o removeu do relatório. As ferramentas do Chrome, o PageSpeed Insights e a API CrUX ao vivo mantiveram a métrica por mais algum tempo e a encerraram em 9 de setembro de 2024, cada um em seu próprio cronograma. Ela media somente o atraso de entrada da primeira interação — não o tempo de execução do manipulador nem a repintura — deliberadamente, para evitar incentivos perversos. Limites: bom ≤100 ms, ruim >300 ms no p75, somente em campo (Total Blocking Time era o proxy de laboratório — um diagnóstico correlacionado, não uma fórmula de conversão). Não confunda esses limites com os 200/500 ms do INP e não tente converter o número de uma métrica no da outra. FID ruim vinha da contenção da thread principal — tarefas longas de JavaScript — que é exatamente o que causa INP e TBT ruins, então as correções antigas ainda valem a pena. Os dados históricos de FID sobrevivem no conjunto de dados CrUX BigQuery (até a versão 202409); a métrica desapareceu de todas as ferramentas ao vivo.

O que o FID realmente media

A definição do Google era precisa. Segundo o web.dev: “FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.” Tradução: “O FID mede o tempo desde a primeira interação do usuário com uma página (isto é, quando ele clica em um link, toca em um botão ou usa um controle personalizado baseado em JavaScript) até o momento em que o navegador consegue realmente começar a processar os manipuladores de eventos em resposta a essa interação.”

Leia isso com atenção, porque o escopo conta toda a história. O FID capturava o atraso antes de o processamento começar — e nada depois. Não media quanto tempo o manipulador de eventos executava. Não media quanto tempo a página levava para pintar o resultado. Apenas a espera.

Por que o navegador alguma vez ficava “incapaz de começar”? O web.dev é direto sobre a causa: “In general, input delay (a.k.a. input latency) happens because the browser’s main thread is busy doing something else, so it can’t (yet) respond to the user.” Tradução: “Em geral, o atraso de entrada (também chamado de latência de entrada) acontece porque a thread principal do navegador está ocupada fazendo outra coisa e ainda não consegue responder ao usuário.” Há uma única thread principal e, se ela estiver no meio da análise ou execução de JavaScript quando o usuário agir, a interação ficará na fila até essa tarefa terminar. Eu defendo o mesmo ponto no meu guia de FID da Ahrefs: existe uma única thread principal, o JavaScript compete para executar tarefas nela e, enquanto uma tarefa está em execução, a página não consegue responder à entrada — essa parada é o atraso que o usuário realmente sente.

Por que o FID media apenas o atraso (não a interação inteira)

Isso parece uma falha de projeto até você entender o raciocínio. O Google media somente o atraso de entrada de propósito. Incorporar o tempo de execução do manipulador e a repintura à métrica poderia, como explica o web.dev, incentivar os desenvolvedores a manipulá-la — eles poderiam envolver a lógica do manipulador de eventos em um callback assíncrono para separá-la da tarefa da interação e fazer o número parecer melhor enquanto a experiência real ficava pior. Por isso, o FID permaneceu restrito.

Essa restrição também é a limitação fatal do FID. Uma página poderia apresentar um FID ótimo e ainda parecer lenta, porque toda interação depois da primeira ficava sem medição, e a parte lenta de uma interação muitas vezes é o processamento e a repintura que o FID ignorava. É justamente essa lacuna que o INP foi criado para fechar.

Os limites — e aquele que você verá as pessoas confundirem

Medido no percentil 75 dos carregamentos de página, segmentado entre dispositivos móveis e desktop. A orientação do web.dev era simplesmente que os sites deveriam buscar um First Input Delay de 100 milissegundos ou menos. Meu próprio artigo sobre FID usa os mesmos números — bom ≤100 ms, precisa melhorar >100 ms e ≤300 ms, ruim >300 ms.

O erro comum: confundir os limites do FID com os do INP. São números diferentes para métricas diferentes. FID = 100 ms bom / 300 ms ruim. INP = 200 ms bom / 500 ms ruim. Vários resumos de terceiros — e até passagens de conteúdo automatizadas — misturam os dois; portanto, se você vir “200 ms” citado como o limite bom do FID, está errado.

O FID era uma métrica exclusivamente de campo

Você nunca conseguiria obter FID no Lighthouse ou em qualquer ferramenta de laboratório, porque ele exigia a primeira interação real de um usuário real — o web.dev afirma claramente que o FID só pode ser medido em campo, pois requer que um usuário real interaja com a página. As ferramentas de laboratório não clicam, então não havia nada para o FID cronometrar.

O substituto de laboratório sempre foi o Total Blocking Time (TBT). Como explico no meu guia do PageSpeed Insights, você não encontrará FID nem INP nos dados de laboratório — eles exigem cliques na página que os testes de laboratório não reproduzem — então usa o Total Blocking Time como métrica proxy para trabalhar na melhoria. Essa relação sobreviveu ao FID: hoje o TBT é o proxy de laboratório do INP.

Vale deixar uma ressalva clara: o TBT é um diagnóstico correlacionado, não uma fórmula de conversão. Nunca existiu uma equação que transformasse um número de TBT em um número exato de FID, e também não existe uma para INP — uma pontuação ruim de TBT indica que o trabalho na thread principal é um provável culpado, não qual teria sido o seu FID ou INP em campo.

Por que o FID foi aposentado: a transição para o INP

A substituição do FID foi anunciada com bastante antecedência. Segundo o web.dev, o INP tornou-se oficialmente um Core Web Vital e substituiu o FID em 12 de março de 2024, quando o FID foi descontinuado e removido do programa. O motivo declarado pelo Google: com o tempo, ficou claro que era necessária uma nova métrica para capturar aspectos da interatividade que o FID não capturava.

A linha do tempo teve dois marcos distintos — vale mantê-los separados, porque é fácil (e comum, até em conteúdo automatizado) reduzi-los a uma única data:

1. 12 de março de 2024 — aposentado como Core Web Vital. O INP assumiu o lugar; o FID deixou de fazer parte do conjunto principal relevante para ranking. O Search Console removeu o FID do relatório de Core Web Vitals no mesmo dia.
2. 9 de setembro de 2024 — removido das ferramentas, em cronogramas específicos de cada produto. Segundo o web.dev, a partir dessa data o FID deixou de ser compatível com as ferramentas do Chrome. O PageSpeed Insights parou de exibir dados de FID de usuários reais e a API do CrUX deixou de fornecer a métrica; o conjunto de dados CrUX BigQuery deixou de adicionar novos campos de FID a partir da versão 202409, embora os meses anteriores continuassem consultáveis.

Não é correto dizer que toda superfície do Google abandonou o FID em 9 de setembro — o corte do Search Console ocorreu seis meses antes, ligado à substituição pelo INP, não à limpeza posterior das ferramentas.

O próprio artigo do web.dev sobre FID agora começa com o aviso de aposentadoria: First Input Delay não é mais um Core Web Vital e foi substituído pela métrica Interaction to Next Paint (INP). A documentação atual do Google Search Central sobre Core Web Vitals também não menciona o FID — cobre apenas LCP, INP e CLS. Quando o documento oficial de ranking deixa de nomear uma métrica, ela está tão aposentada quanto possível.

FID versus INP: o que mudou

As duas métricas medem coisas genuinamente diferentes, por isso você não pode simplesmente mapear uma na outra:

A linha central é esta: o FID cronometrava a porta de entrada de uma interação; o INP cronometra a jornada inteira de todas as interações. Não há fórmula que converta um número antigo de FID em um INP equivalente, e o FID de uma página em relação a outras não prevê sua posição no ranking de INP em relação às mesmas páginas — eles medem conjuntos de interações diferentes contra limites diferentes, então qualquer semelhança entre os dois números em uma página é coincidência, não regra. Consulte Interaction to Next Paint para o tratamento completo da métrica que o substituiu.

Onde os dados antigos de FID ainda vivem

A aposentadoria não vaporizou o registro histórico. O que desapareceu e o que permaneceu:

• Desapareceu (ao vivo e voltado ao presente): o relatório de Core Web Vitals do Search Console deixou de exibir o FID em 12 de março de 2024, quando o INP assumiu. A interface do PageSpeed Insights e a API CrUX ao vivo continuaram informando a métrica por um pouco mais de tempo e pararam em 9 de setembro de 2024.
• Ainda existe (histórico): dados de FID anteriores ao corte continuam consultáveis no conjunto de dados público CrUX BigQuery — mas somente até o conjunto de dados 202409; o BigQuery deixou de adicionar novos campos de FID a partir dessa versão, embora os meses anteriores permaneçam disponíveis. Se você precisar reconstruir o histórico de responsividade de um site, é ali que deve procurar — não nas ferramentas ao vivo. Fixe o mês do conjunto de dados ao citar um número, rotule-o como histórico e não trate uma cifra antiga de FID como numericamente comparável a uma cifra atual de INP — não há conversão entre elas (consulte a tabela de comparação acima).

O FID ainda importa hoje?

Diretamente, não — não há mais nada a medir ou relatar, portanto não há nada para “corrigir”. Mas as causas de um FID ruim e as causas de um INP ruim são quase idênticas: tarefas longas de JavaScript ocupando a thread principal. Assim, qualquer trabalho que você já tenha feito para melhorar o FID não foi desperdiçado. Como observo no meu guia de FID, embora o FID tenha sido substituído pelo INP em março de 2024, ainda vale trabalhar nos mesmos problemas subjacentes — muitas coisas que melhoram o TBT e o FID também melhoram o INP.

As correções que reduziam o FID são as mesmas que ajudam o INP e o TBT agora:

• Reduza a quantidade de JavaScript que você envia.
• Carregue o JavaScript mais tarde quando possível (async/defer).
• Divida tarefas longas com divisão de código para que nenhuma tarefa monopolize a thread principal.
• Mova o trabalho para fora da thread principal usando web workers.
• Use renderização no servidor ou prerenderização para reduzir o trabalho no cliente.

O FID chegou a ser um grande fator de ranking?

Mesmo quando estava ativo, o FID — como parte dos Core Web Vitals — nunca foi um sinal de ranking forte. Representantes do Google caracterizaram repetidamente os Core Web Vitals como algo mais próximo de um desempate do que de um sinal primário, aplicado apenas quando os demais fatores são aproximadamente iguais. Minha própria leitura, no meu guia de Core Web Vitals, é a mesma: “I don’t think Core Web Vitals have much impact on SEO and, unless you are extremely slow, I generally won’t prioritize fixing them.” Tradução: “Não acho que os Core Web Vitals tenham muito impacto no SEO e, a menos que você seja extremamente lento, em geral não vou priorizar corrigi-los.” O FID raramente era destacado sozinho nos comentários de representantes — quase sempre era discutido como parte do conjunto de Core Web Vitals, não como uma alavanca de ranking independente.

Bing e FID

Não há efetivamente um ângulo específico do Bing aqui. O Bing nunca adotou os Core Web Vitals como um sinal de ranking nomeado da forma como o Google fez e nunca publicou limites próprios de FID (ou INP). O Bing se importa com páginas rápidas e responsivas em termos gerais, mas o FID foi uma métrica do ecossistema do Google do início ao fim.

Para onde ir agora

O FID fica sob a iniciativa Web Vitals, no cluster de Web Performance. As métricas mais relevantes para o FID são:

• Interaction to Next Paint — o Core Web Vital que o substituiu e aquele que você deve realmente otimizar agora.
• Total Blocking Time — o proxy de laboratório que representava o FID (e agora representa o INP) quando não era possível medir interações reais.
• Core Web Vitals — o trio relevante para ranking (LCP, INP, CLS) ao qual o FID costumava pertencer.

Resumo de IA

Uma síntese concisa da versão Avançada:

• FID = um Core Web Vital aposentado de responsividade. Media apenas o atraso de entrada da primeira interação — a espera antes de o navegador poder começar a processar o manipulador de eventos — não o tempo de execução do manipulador nem a repintura.
• Limites: bom ≤ 100 ms, precisa melhorar 100–300 ms, ruim > 300 ms, no percentil 75, com separação entre dispositivos móveis e desktop. Somente campo — nunca mensurável no Lighthouse; o Total Blocking Time era o proxy de laboratório.
• Não confunda os limites: FID = 100/300 ms; INP = 200/500 ms. Métricas diferentes, números diferentes.
• Causa do FID ruim: contenção da thread principal — tarefas longas de JavaScript. A mesma causa raiz do INP e do TBT ruins.
• Linha do tempo da aposentadoria: substituído pelo INP em 12 de março de 2024 — no mesmo dia em que o Search Console removeu o FID do relatório. As ferramentas do Chrome, o PageSpeed Insights e a API CrUX ao vivo deixaram de oferecer suporte em 9 de setembro de 2024, cada uma em seu próprio cronograma — não houve um único corte universal. O documento atual do Google Search Central sobre CWV já não o menciona.
• FID versus INP: o FID cronometrava o atraso da primeira interação; o INP mede a latência completa de todas as interações (atraso + processamento + apresentação). Não há fórmula que converta o número de uma métrica no da outra.
• Dados antigos: desapareceram das ferramentas ao vivo; os dados de FID anteriores ao corte ainda vivem no conjunto de dados CrUX BigQuery até a versão 202409 — fixe o mês do conjunto e não compare numericamente com o INP atual.
• Nunca houve conversão: o TBT é um proxy de laboratório correlacionado para FID e INP, não uma fórmula que traduza um no outro.
• Ainda importa? Não há nada para corrigir diretamente, mas as correções de JS (reduzir/adiar JS, dividir tarefas longas, web workers, SSR) passam diretamente para INP e TBT.
• Peso no ranking: pequeno mesmo quando ativo — os CWV eram tratados como desempate; Patrick: não priorize isso a menos que você esteja extremamente lento. O Bing não tem equivalente ao FID.

Documentação oficial

Documentação de fontes primárias sobre o FID e sua aposentadoria.

Google / web.dev

• First Input Delay (FID) — definição da métrica, limites, motivo de medir apenas o atraso de entrada e aviso de aposentadoria (Philip Walton; atualizado em 2024-10-06).
• Chrome ends support for First Input Delay — remoção em setembro de 2024 das ferramentas do Chrome, do PSI e da API CrUX (Rick Viscomi).
• Interaction to Next Paint becomes a Core Web Vital on March 12 — anúncio de que o INP substituiria o FID (Jeremy Wagner, Rick Viscomi).
• Understanding Core Web Vitals and Google Search results — documento atual de ranking, que agora lista apenas LCP, INP e CLS (sem FID).
• Interaction to Next Paint (INP) — a métrica que substituiu o FID.

MDN

• First Input Delay (FID) glossary — uma breve definição de referência.

Bing / Microsoft

• Nenhuma fonte específica sobre FID. O Bing nunca publicou limites de FID nem nomeou os Core Web Vitals como sinal de ranking próprio.

Citações da fonte

Declarações registradas na documentação oficial do Google no web.dev. Cada link é um link profundo que salta até o trecho citado na página de origem.

Google / web.dev — o que o FID media

• “FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.” Jump to quote Tradução: “O FID mede o tempo desde a primeira interação do usuário com uma página (isto é, quando ele clica em um link, toca em um botão ou usa um controle personalizado baseado em JavaScript) até o momento em que o navegador consegue realmente começar a processar os manipuladores de eventos em resposta a essa interação.”
• “In general, input delay (a.k.a. input latency) happens because the browser’s main thread is busy doing something else, so it can’t (yet) respond to the user.” Jump to quote Tradução: “Em geral, o atraso de entrada (também chamado de latência de entrada) acontece porque a thread principal do navegador está ocupada fazendo outra coisa e ainda não consegue responder ao usuário.”

Google / web.dev — o limite “bom”

• “To provide a good user experience, sites should strive to have a First Input Delay of 100 milliseconds or less.” Tradução: “Para oferecer uma boa experiência ao usuário, os sites devem buscar um First Input Delay de 100 milissegundos ou menos.” Jump to quote

Folha de consulta do First Input Delay

Status: aposentado. Guarde isto para ler dados históricos e relatórios antigos — não como alvo de otimização.

FID em resumo

FID versus INP — não misture os dois

Datas importantes

• 12 de março de 2024 — o INP substitui o FID como Core Web Vital; o Search Console remove o FID do relatório no mesmo dia.
• 9 de setembro de 2024 — as ferramentas do Chrome, o PageSpeed Insights e a API CrUX ao vivo deixam de oferecer suporte ao FID, cada um em seu próprio cronograma (não na mesma data que o GSC).

Onde estão os dados do FID agora

• Ferramentas ao vivo (interface do PSI, GSC, API CrUX): desapareceram (GSC desde 12 de março de 2024; PSI/CrUX desde 9 de setembro de 2024).
• Histórico anterior ao corte: conjunto de dados CrUX BigQuery, até a versão 202409. Não compare seus números diretamente com o INP atual — não há conversão.

Corrigindo o problema subjacente (ajuda INP/TBT agora)

• Reduza JavaScript · adie/carregue de forma assíncrona · divida tarefas longas (divisão de código) · web workers · SSR/prerenderização.

Erros a evitar com dados históricos de FID

Tratar o FID como Core Web Vital atual

O FID foi substituído pelo INP em março de 2024 e removido das superfícies atuais de relatório do Chrome mais tarde naquele ano. Use o INP para o trabalho atual de responsividade; mantenha o FID apenas ao interpretar conjuntos de dados históricos.

Comparar FID e INP usando os mesmos limites

Os limites históricos de Bom/Ruim do FID eram 100/300 ms; os do INP são 200/500 ms. Os números não são intercambiáveis porque o FID media apenas o atraso antes do manipulador, enquanto o INP cobre a interação até a próxima pintura.

Procurar FID em um teste de laboratório

O FID exigia uma primeira entrada real do usuário e era exclusivo de campo. O Total Blocking Time era o proxy de laboratório; um resultado do Lighthouse nunca foi uma observação direta de FID.

Otimizar uma pontuação aposentada em vez do problema do usuário

Não mantenha um painel de FID como objetivo. Divida tarefas longas da thread principal e reduza o JavaScript que bloqueia, depois meça a responsividade atual com INP em campo.

Teste seus conhecimentos: First Input Delay (FID)

Cinco perguntas rápidas sobre o que o FID media e por que foi aposentado. Escolha uma resposta para cada pergunta e depois confira.

Registro de alterações