# 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](https://full.services/glossario/inp-interaction-to-next-paint/). ## 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](https://full.services/glossario/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](https://full.services/glossario/inp-interaction-to-next-paint/). ## 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](https://full.services/glossario/cls/) e [LCP](https://full.services/glossario/lcp/) para uma experiência completa. O caminho número cinco é cache de objeto e [Lighthouse](https://full.services/glossario/lighthouse/) contínuo para auditar mudanças. Combine com monitoramento dos [Core Web Vitals](https://full.services/glossario/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](https://full.services/glossario/inp-interaction-to-next-paint/) para entender a nova métrica e como melhorar. **Também conhecido como:** first input delay, atraso de primeira interação ## Termos relacionados - [Core Web Vitals](https://full.services/glossario/core-web-vitals/) - [LCP (Largest Contentful Paint)](https://full.services/glossario/lcp/) - [CLS (Cumulative Layout Shift)](https://full.services/glossario/cls/) - [Lighthouse](https://full.services/glossario/lighthouse/) --- Glossário WordPress da FULL Services: [FID (First Input Delay)](https://full.services/glossario/fid/)