First Input Delay (FID)

Philip Walton

Todos sabemos como é importante causar uma boa primeira impressão. É importante conhecer novas pessoas e também 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 é uma boa impressão e como você mede o tipo de impressão que provavelmente está causando nos usuários?

Na Web, as primeiras impressões podem ter muitas formas diferentes. Temos primeiras impressões sobre o design e o apelo visual de um site, bem como primeiras impressões sobre a velocidade e a capacidade de resposta dele.

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

A primeira impressão que os usuários têm sobre a rapidez com que o site é carregado pode ser medida com a First Contentful Paint (FCP). No entanto, a velocidade com que seu site pode pintar pixels na tela é apenas parte da história. Outro ponto importante é a capacidade de resposta do seu site 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 site.

O que é FID?

O FID mede o tempo entre a primeira interação do 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 de primeira entrada 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ódigo que responde a eventos, muitas vezes presumimos que nosso código será executado imediatamente, assim que o evento acontecer. Mas, como usuários, muitas vezes já passamos pelo oposto: carregamos uma página da Web no smartphone, tentamos interagir com ela e ficamos frustrados quando nada acontece.

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. Por isso, ela ainda não pode responder ao usuário. Uma razão comum para isso acontecer é que o navegador está ocupado analisando e executando um arquivo JavaScript grande carregado pelo app. Enquanto ele faz isso, ele não pode executar nenhum listener de eventos porque o JavaScript que está carregando pode pedir para ele fazer outra coisa.

Considere a linha do tempo a seguir de um carregamento típico de página da Web:

A visualização acima mostra uma página que está fazendo algumas solicitações de rede para recursos (provavelmente arquivos CSS e JS) e, depois que o download desses recursos é concluído, eles são processados na linha de execução principal.

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

Longos atrasos de entrada geralmente ocorrem entre a First Contentful Paint (FCP) e o Tempo para interação da página (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, a FCP e o TTI foram adicionados à linha do tempo:

Você pode ter notado que há um bom tempo (incluindo três tarefas longas) entre a FCP e o TTI. Se um usuário tentar interagir com a página durante esse tempo (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 puder 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á executando uma tarefa, ele precisa aguardar a conclusão da tarefa para responder à entrada. O tempo de espera é o valor do FID para esse usuário nessa página.

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

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

Por exemplo, todos os elementos HTML a seguir 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 do usuário, recomendamos medir o primeiro atraso de entrada por alguns motivos:

• O primeiro atraso de entrada será a primeira impressão do usuário sobre a responsividade do site, e as primeiras impressões são essenciais para moldar nossa impressão geral sobre a qualidade e a confiabilidade de um site.
• Os maiores problemas de interatividade que encontramos na Web hoje ocorrem durante o carregamento da página. Portanto, acreditamos que se concentrar inicialmente em melhorar a 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 de entrada altos (divisão de código, carregamento de menos JavaScript antecipadamente etc.) não são necessariamente as mesmas para corrigir atrasos de entrada lentos após o carregamento da 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-as em uma linha de execução separada.

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

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

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

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á bastante diferente de outras métricas com que você está acostumado. 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 só mede 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 afeta a experiência, ele não é incluído nessa métrica porque isso poderia incentivar os desenvolvedores a adicionar soluções alternativas que realmente pioram a experiência. Ou seja, eles poderiam agrupar a lógica do manipulador de eventos em um callback assíncrono (usando setTimeout() ou requestAnimationFrame()) para separá-lo da tarefa associada ao evento. O resultado seria uma melhoria na pontuação da métrica, mas uma resposta mais lenta, como percebida pelo usuário.

No entanto, embora a FID meça apenas a parte de "atraso" da latência do evento, os desenvolvedores que querem 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 no campo, porque 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 no JavaScript

Para medir o FID em JavaScript, use a API Event Timing. O exemplo a seguir mostra como criar um PerformanceObserver que ouve 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 tomando o delta entre os carimbos de data/hora startTime e processingStart da entrada. Na maioria dos casos, esse é o valor do 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 serão ignoradas ao calcular o FID.
• A API também vai enviar entradas first-input se a página estiver em segundo plano antes da primeira entrada, mas essas páginas também precisam 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 de first-input quando a página é restaurada do cache de ida/volta, mas o FID precisa ser medido nesses casos, já que os usuários os consideram como visitas diferentes à página.
• A API não informa entradas que ocorrem em iframes, mas a métrica informa, porque elas fazem parte da experiência do usuário na página. Isso pode mostrar uma diferença entre o CrUX e o RUM. Para medir corretamente o FID, considere esses fatores. Os subframes podem usar a API para informar as entradas first-input ao frame pai para agregação.

Como 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 a FID, recomendamos olhar para os percentis 95 a 99, já que eles correspondem às primeiras experiências particularmente ruins que os usuários estão tendo com seu site. E vai mostrar as áreas que precisam de mais melhorias.

Isso é válido mesmo se você segmentar 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 que mais importa em computadores precisa ser o percentil 95 a 99 dos usuários de computadores, e o valor de FID que mais importa em dispositivos móveis precisa ser o percentil 95 a 99 dos usuários de dispositivos móveis.

Como melhorar o FID

Um guia completo sobre como otimizar o FID está disponível para orientar você sobre as técnicas para melhorar essa métrica.

Registro de alterações

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

Para ajudar você a gerenciar isso, todas as mudanças na implementação ou definição dessas métricas serão exibidas no Registro de alterações.

Se você tiver feedback sobre essas métricas, envie-o no grupo de feedback do Web Vitals no Google.