FID (First Input Delay)

FID First Input Delay é a métrica que media o tempo entre a primeira interação do usuário com uma página (clique, toque, tecla) e o momento em que o navegador conseguia processar essa interação. Foi parte oficial do Core Web Vitals do Google de 2020 a março de 2024, quando foi substituída pela métrica INP (Interaction to Next Paint), considerada mais completa para medir interatividade real ao longo de toda a sessão.

Atenção — métrica descontinuada: o FID foi substituído pelo INP (Interaction to Next Paint) em 12 de março de 2024 como métrica oficial do Core Web Vitals. Este verbete é mantido para fins históricos e educacionais. Para a métrica atual, consulte nosso guia completo do INP.

O que era o FID

O fid first input delay capturava um momento muito específico: a primeira vez que o usuário tocava em algo na página depois que ela carregou. Pode ser clicar em um menu, tocar em um botão, digitar em um campo de busca. O FID media quanto tempo o navegador demorou para começar a processar essa ação — não o tempo total de execução, só o atraso inicial.

A meta oficial era manter FID abaixo de 100ms para considerar bom. Entre 100ms e 300ms era “precisa melhorar”. Acima de 300ms era ruim. O Google usava esses limiares como sinal de ranqueamento, parte do conjunto de métricas que avaliam experiência do usuário em sites móveis e desktop.

Por que essa métrica importava: quando o usuário interage e o site demora para responder, a sensação é de travamento. Mesmo 200ms já gera percepção de lentidão. Sites com FID alto tipicamente sofrem de JavaScript pesado bloqueando a thread principal do navegador no exato momento que o usuário tenta interagir.

O FID era medido em campo (dados reais do CrUX, Chrome User Experience Report) e em laboratório como TBT (Total Blocking Time), uma proxy. A ferramenta Lighthouse não mediu FID diretamente — mediu TBT, porque FID exige interação humana real, impossível de simular em testes sintéticos.

Como FID era calculado

O cálculo do first input delay seguia uma lógica clara: o navegador registra o timestamp T1 quando o usuário inicia a primeira interação. Em seguida, marca o timestamp T2 quando consegue iniciar o handler dessa interação (depois que terminou outras tarefas que estavam ocupando a thread). FID = T2 – T1.

O detalhe importante é que o FID só media o atraso de início, não a duração da execução. Se o handler demorasse 2 segundos para terminar, mas começasse 50ms depois do clique, o FID era 50ms — bom. Isso virou crítica recorrente: a métrica não capturava o sofrimento do usuário com handlers lentos, só com início lento.

Outra característica: o FID só capturava a primeira interação da sessão. Se o usuário interagisse 20 vezes ao longo da visita, só a primeira contava para a métrica. Isso fazia sentido como simplificação inicial, mas deixava de fora muito do que é interatividade real — usuários interagem dezenas de vezes, não uma só.

A medição em campo dependia da Web Vitals JavaScript Library do Google, que captura dados de interação real e envia para sistemas de analytics. Sites usando Google Analytics 4 ou ferramentas como Vercel Analytics tinham acesso direto aos números. O Google Search Console exibia o agregado por site na seção Core Web Vitals.

Substituição pelo INP em 2024

Em março de 2024, o Google substituiu oficialmente o FID pelo INP (Interaction to Next Paint) como métrica de interatividade dos Core Web Vitals. A mudança foi anunciada com mais de um ano de antecedência para dar tempo aos sites se adaptarem. Quem otimizava bem o FID, geralmente já tinha INP em níveis aceitáveis — mas não sempre.

O INP corrige as duas limitações principais do FID. Primeiro: mede todas as interações da sessão, não só a primeira. Segundo: mede o tempo total da interação até a próxima pintura visual, não só o atraso de início. Isso captura experiência real muito melhor — se o usuário clica e o site congela por 800ms antes de mostrar resposta, isso aparece no INP, mas não aparecia no FID.

A discussão fid vs inp é direta: FID era uma métrica simples, fácil de explicar, fácil de otimizar para sites com início rápido. INP é mais difícil de otimizar porque cobre mais casos — mas reflete melhor a experiência. Sites que pareciam bons no FID e ruins na percepção do usuário foram justamente os que falharam quando o INP virou padrão.

A meta para INP é ficar abaixo de 200ms (bom), entre 200-500ms (precisa melhorar), acima de 500ms (ruim). O cálculo considera o percentil 98 das interações da sessão — pega a interação mais lenta entre as 50 melhores, em sites com muitas interações, ou a interação mais lenta em sites com poucas. Captura o pior caso típico, não a média. Para entender a métrica em detalhes, veja nosso guia completo do INP.

Como otimizar interatividade

O caminho número um é reduzir JavaScript executado durante o carregamento. Cada milissegundo de JS executando bloqueia a thread principal e atrapalha tanto FID quanto INP. Plugins WordPress costumam carregar scripts globais em todas as páginas mesmo quando só são usados em uma — auditar e desabilitar onde não precisa é ganho imediato.

O caminho número dois é adiar JS não-crítico. Use defer ou async em scripts que não são essenciais para o conteúdo above-the-fold. Plugins como Perfmatter, Asset CleanUp e WP Rocket têm controles granulares para mover JavaScript para o rodapé, atrasar carregamento até interação ou desativar em páginas específicas.

O caminho número três é otimizar Long Tasks. Tasks que ocupam a thread principal por mais de 50ms aparecem como Long Tasks no Lighthouse e são a causa direta de INP alto. Quebre tarefas pesadas em chunks menores usando requestIdleCallback ou setTimeout para liberar a thread entre processamentos.

O caminho número quatro é preferir CSS para animações sempre que possível. CSS animations rodam em thread separada (compositor), não bloqueando a thread principal. Animações JS podem bloquear interações se feitas em propriedades de layout. Combine isso com tratamento adequado de CLS e LCP para uma experiência completa.

O caminho número cinco é cache de objeto e Lighthouse contínuo para auditar mudanças. Combine com monitoramento dos Core Web Vitals via Search Console. Para sites que precisam manter interatividade abaixo dos limites do INP sem virar trabalho de tuning manual, a FULL Services entrega o Perfmatter já licenciado e configurado dentro da stack profissional, com controle granular de JS por página, lazy loading inteligente e tuning específico para reduzir Long Tasks. É a forma de manter os Core Web Vitals dentro do verde mesmo em sites WordPress complexos com muitos plugins ativos.

FID foi substituído pelo INP em 2024

Em 12 de março de 2024, o Google anunciou a substituição oficial do FID pelo INP no Core Web Vitals. A mudança aconteceu porque o FID media apenas a primeira interação do usuário — geralmente o melhor caso — enquanto o INP captura a pior interação relevante durante toda a sessão, refletindo melhor a experiência real.

Se você está otimizando seu site WordPress hoje, foque no INP. O FID não é mais usado para ranking. Quem ainda fala de FID em conteúdo técnico está com material desatualizado. Veja nosso guia completo do INP para entender a nova métrica e como melhorar.