First Input Delay (FID)

Philip Walton

Todos sabemos como é importante causar uma boa primeira impressão. É importante ao conhecer novas pessoas e também ao criar experiências na Web.

Na Web, uma boa primeira impressão pode fazer a diferença entre alguém se tornar um usuário fiel ou sair e nunca mais voltar. A questão é: o que causa uma boa impressão e como medir o tipo de impressão que você provavelmente está causando nos usuários?

Na Web, as primeiras impressões podem ter muitas formas diferentes. Temos as primeiras impressões do design e da aparência visual de um site, bem como as primeiras impressões da velocidade e da capacidade de resposta dele.

Embora seja difícil medir o quanto os usuários gostam do design de um site com APIs da Web, medir a velocidade e a capacidade de resposta não é!

A primeira impressão que os usuários têm da velocidade de carregamento do seu site pode ser medida com a First Contentful Paint (FCP). Mas a velocidade com que seu site pode pintar pixels na tela é apenas parte da história. Também é importante saber como seu site responde quando os usuários tentam interagir com esses pixels.

A métrica First Input Delay (FID) ajuda a medir a primeira impressão do usuário sobre a interatividade e a capacidade de resposta do seu site.

O que é FID?

O FID mede o tempo entre a primeira interação de um usuário com uma página (ou seja, quando ele clica em um link, toca em um botão ou usa um controle personalizado com tecnologia JavaScript) e o momento em que o navegador começa a processar os manipuladores de eventos em resposta a essa interação.

O que é uma boa pontuação de FID?

Para oferecer uma boa experiência ao usuário, os sites devem ter um atraso do primeiro input de 100 milissegundos ou menos. Para garantir que essa meta seja atingida para a maioria dos usuários, um bom limite é o 75º percentil de carregamentos de página, segmentado em dispositivos móveis e computadores.

FID em detalhes

Como desenvolvedores que escrevem códigos que respondem a eventos, muitas vezes presumimos que nosso código será executado imediatamente, assim que o evento acontecer. Mas, como usuários, todos nós já passamos pela situação oposta: carregamos uma página da Web no smartphone, tentamos interagir com ela e ficamos frustrados quando nada aconteceu.

Em geral, o atraso de entrada (também conhecido como latência de entrada) acontece porque a linha de execução principal do navegador está ocupada fazendo outra coisa e, portanto, não pode (ainda) responder ao usuário. Um motivo comum para isso acontecer é que o navegador está ocupado analisando e executando um arquivo JavaScript grande carregado pelo app. Enquanto isso, ele não pode executar nenhum listener de eventos porque o JavaScript que está carregando pode dizer para fazer outra coisa.

Considere a seguinte linha do tempo de um carregamento de página típico:

A visualização acima mostra uma página que está fazendo algumas solicitações de rede para recursos (provavelmente arquivos CSS e JS). Depois que esses recursos terminam de ser baixados, eles são processados na linha de execução principal.

Isso resulta em períodos em que a linha de execução principal fica momentaneamente ocupada, o que é indicado pelos blocos de tarefas na cor bege.

Atrasos longos na primeira entrada geralmente ocorrem entre o First Contentful Paint (FCP) e o Time to Interactive (TTI) porque a página renderizou parte do conteúdo, mas ainda não é interativa de forma confiável. Para ilustrar como isso pode acontecer, o FCP e o TTI foram adicionados à linha do tempo:

Você pode ter notado que há um tempo considerável (incluindo três tarefas longas) entre o FCP e o TTI. Se um usuário tentar interagir com a página durante esse período (por exemplo, clicando em um link), haverá um atraso entre o momento em que o clique é recebido e quando a linha de execução principal consegue responder.

Considere o que aconteceria se um usuário tentasse interagir com a página perto do início da tarefa mais longa:

Como a entrada ocorre enquanto o navegador está no meio da execução de uma tarefa, ele precisa esperar até que a tarefa seja concluída antes de responder à entrada. O tempo de espera é o valor de FID para esse usuário na página.

E se uma interação não tiver um listener de eventos?

O FID mede o delta entre o momento em que um evento de entrada é recebido e o momento em que a thread principal fica inativa. Isso significa que o FID é medido mesmo nos casos em que um listener de evento não foi registrado. Isso acontece porque muitas interações do usuário não exigem um listener de eventos, mas exigem que a linha de execução principal fique inativa para ser executada.

Por exemplo, todos os seguintes elementos HTML precisam aguardar a conclusão das tarefas em andamento na linha de execução principal antes de responder às interações do usuário:

• Campos de texto, caixas de seleção e botões de opção (<input>, <textarea>)
• Selecionar menus suspensos (<select>)
• links (<a>)

Por que considerar apenas a primeira entrada?

Embora um atraso em qualquer entrada possa levar a uma experiência ruim para o usuário, recomendamos medir o atraso da primeira entrada por alguns motivos:

• O primeiro atraso de entrada será a primeira impressão do usuário sobre a capacidade de resposta do seu site, e as primeiras impressões são essenciais para moldar nossa impressão geral da qualidade e confiabilidade de um site.
• Os maiores problemas de interatividade que vemos na Web hoje ocorrem durante o carregamento da página. Por isso, acreditamos que focar inicialmente na melhoria da primeira interação do usuário com o site terá o maior impacto na melhoria da interatividade geral da Web.
• As soluções recomendadas para corrigir atrasos altos no First Input Delay (divisão de código, carregamento de menos JavaScript antecipadamente etc.) não são necessariamente as mesmas para corrigir atrasos lentos na entrada após o carregamento de página. Ao separar essas métricas, poderemos fornecer diretrizes de desempenho mais específicas para desenvolvedores da Web.

O que conta como uma primeira entrada?

A FID é uma métrica que mede a capacidade de resposta de uma página durante o carregamento. Por isso, ele se concentra apenas em eventos de entrada de ações discretas, como cliques, toques e pressionamentos de tecla.

Outras interações, como rolagem e zoom, são ações contínuas e têm restrições de desempenho completamente diferentes. Além disso, os navegadores geralmente conseguem ocultar a latência executando essas ações em uma linha de execução separada.

Em outras palavras, o FID se concentra na R (responsividade) do modelo de desempenho RAIL, enquanto rolagem e zoom estão mais relacionados à A (animação), e as qualidades de desempenho deles devem ser avaliadas separadamente.

E se um usuário nunca interagir com seu site?

Nem todos os usuários interagem com seu site a cada visita. Além disso, nem todas as interações são relevantes para o FID, como mencionado na seção anterior. Além disso, algumas primeiras interações dos usuários vão ocorrer em momentos ruins (quando a linha de execução principal estiver ocupada por um período prolongado), e outras vão ocorrer em momentos bons (quando a linha de execução principal estiver completamente inativa).

Isso significa que alguns usuários não terão valores de FID, outros terão valores baixos e outros terão valores altos.

A forma como você rastreia, gera relatórios e analisa o FID provavelmente será bem diferente de outras métricas que você já conhece. A próxima seção explica como fazer isso da melhor maneira.

Por que considerar apenas o atraso de entrada?

Como mencionado acima, o FID mede apenas o "atraso" no processamento de eventos. Ele não mede a duração total do processamento de eventos nem o tempo que o navegador leva para atualizar a interface depois de executar os manipuladores de eventos.

Embora esse tempo seja importante para o usuário e afete a experiência, ele não é incluído nessa métrica. Isso porque pode incentivar os desenvolvedores a adicionar soluções alternativas que pioram a experiência. Ou seja, eles podem encapsular a lógica do manipulador de eventos em um callback assíncrono (via setTimeout() ou requestAnimationFrame()) para separá-la da tarefa associada ao evento. O resultado seria uma melhoria na pontuação da métrica, mas uma resposta mais lenta, conforme percebido pelo usuário.

No entanto, embora a FID meça apenas a parte de "atraso" da latência do evento, os desenvolvedores que quiserem acompanhar mais do ciclo de vida do evento podem fazer isso usando a API Event Timing. Consulte o guia sobre métricas personalizadas para mais detalhes.

Como medir o FID

A FID é uma métrica que só pode ser medida em campo, já que exige que um usuário real interaja com sua página. É possível medir o FID com as seguintes ferramentas.

Ferramentas de campo

• Relatório de experiência do usuário do Chrome
• PageSpeed Insights
• Search Console (relatório Core Web Vitals)
• Biblioteca JavaScript web-vitals

Medir o FID em JavaScript

Para medir o FID em JavaScript, use a API Event Timing. O exemplo a seguir mostra como criar um PerformanceObserver que detecta entradas first-input e as registra no console:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

No exemplo acima, o valor de atraso da entrada first-input é medido usando o delta entre os carimbos de data/hora startTime e processingStart da entrada. Na maioria dos casos, esse será o valor de FID. No entanto, nem todas as entradas de first-input são válidas para medir o FID.

A seção a seguir lista as diferenças entre o que a API informa e como a métrica é calculada.

Diferenças entre a métrica e a API

• A API vai enviar entradas first-input para páginas carregadas em uma guia em segundo plano, mas essas páginas precisam ser ignoradas ao calcular o FID.
• A API também vai despachar entradas first-input se a página tiver sido colocada em segundo plano antes da primeira entrada, mas essas páginas também devem ser ignoradas ao calcular o FID. As entradas só são consideradas se a página estiver em primeiro plano o tempo todo.
• A API não informa entradas first-input quando a página é restaurada do cache de avanço e retorno, mas o FID precisa ser medido nesses casos, já que os usuários os vivenciam como visitas distintas à página.
• A API não informa entradas que ocorrem em iframes, mas a métrica faz isso porque elas fazem parte da experiência do usuário na página. Isso pode aparecer como uma diferença entre CrUX e RUM. Para medir corretamente o FID, considere esses fatores. Os subframes podem usar a API para informar as entradas first-input ao frame principal para agregação.

Analisar e gerar relatórios sobre dados de FID

Devido à variação esperada nos valores de FID, é fundamental que, ao gerar relatórios sobre o FID, você analise a distribuição de valores e se concentre nos percentis mais altos.

Embora a escolha do percentil para todos os limites das Core Web Vitals seja o 75º, para o FID em particular, ainda recomendamos fortemente analisar os percentis de 95 a 99, já que eles correspondem às primeiras experiências particularmente ruins que os usuários estão tendo com seu site. e mostrar as áreas que precisam de mais melhorias.

Isso é válido mesmo que você segmente seus relatórios por categoria ou tipo de dispositivo. Por exemplo, se você gerar relatórios separados para computadores e dispositivos móveis, o valor de FID mais importante para você em computadores será o percentil 95 a 99 dos usuários de computadores, e o valor de FID mais importante para você em dispositivos móveis será o percentil 95 a 99 dos usuários de dispositivos móveis.

Como melhorar o FID

Um guia completo sobre otimização do FID está disponível para orientar você sobre técnicas de melhoria dessa métrica.

Registro de alterações

Às vezes, bugs são descobertos nas APIs usadas para medir métricas e, às vezes, nas próprias definições das métricas. Como resultado, às vezes é necessário fazer mudanças, que podem aparecer como melhorias ou regressões nos seus relatórios e painéis internos.

Para ajudar você a gerenciar isso, todas as mudanças na implementação ou na definição dessas métricas vão aparecer neste registro de alterações.

Se você tiver feedback sobre essas métricas, envie no grupo do Google web-vitals-feedback.