First Input Delay (FID)

Philip Walton

Todos nós 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). Mas 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 de 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 é a FID?

A 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) até o momento em que o navegador pode começar a processar manipuladores de eventos em resposta a essa interação.

Qual é 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, ocorre porque a linha de execução principal do navegador está ocupada fazendo outra tarefa e, por isso, não pode (ainda) 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 seguinte linha do tempo 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.

Geralmente, atrasos longos na primeira entrada ocorrem entre a 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, 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 esperar até que a tarefa seja concluída antes de 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?

A FID mede o delta entre o momento em que um evento de entrada é recebido e o momento em que a linha de execução principal fica ociosa. Isso significa que a FID é medida mesmo nos casos em que um listener de eventos 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 executadas.

Por exemplo, todos os elementos HTML abaixo precisam aguardar a conclusão de 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:

• A First Input Delay será a primeira impressão que o usuário terá da capacidade de resposta do seu site, e as primeiras impressões são essenciais para moldar nossa impressão geral da qualidade e confiabilidade dele.
• Atualmente, os maiores problemas de interatividade na Web ocorrem durante o carregamento da página. Portanto, acreditamos que focar inicialmente em melhorar a primeira interação do usuário do site terá o maior impacto na melhoria da interatividade geral da Web.
• As soluções recomendadas sobre como os sites precisam corrigir altos atrasos na primeira entrada (divisão de código, carregar menos JavaScript antecipadamente etc.) não são necessariamente as mesmas soluções 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 a 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 esconder a latência executando-as em uma linha de execução separada.

Em outras palavras, a FID se concentra no R (capacidade de resposta) no modelo de desempenho RAIL, enquanto a rolagem e o zoom estão mais relacionados a 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 vão interagir com seu site sempre que o acessarem. E nem todas as interações são relevantes para o FID (como mencionado na seção anterior). Além disso, as primeiras interações de alguns usuários serão em momentos ruins (quando a linha de execução principal estiver ocupada por um longo período), e as primeiras interações de alguns usuários serão 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 provavelmente terão valores de FID altos.

A forma como você rastreia, informa 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 só considerar o atraso de entrada?

Como mencionado acima, a FID mede apenas o "atraso" no processamento do evento. Ele não mede a duração total do processamento de eventos nem o tempo que o navegador leva para atualizar a IU depois de executar 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 gerenciador 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 do "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 a página. É possível medir o FID com as seguintes ferramentas.

Ferramentas de campo

• Chrome User Experience Report (link em inglês)
• PageSpeed Insights
• Search Console (relatório Core Web Vitals)
• Biblioteca JavaScript web-vitals

Medir a 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 usando o delta entre os carimbos de data/hora startTime e processingStart da entrada. Na maioria dos casos, ele será o valor da FID. No entanto, nem todas as entradas de first-input são válidas para a medição da FID.

Na seção a seguir, listamos 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 elas precisam ser ignoradas no cálculo da FID.
• A API também vai enviar entradas first-input se a página estiver em segundo plano antes da primeira entrada. No entanto, essas páginas também precisam ser ignoradas no cálculo da FID. As entradas só serã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 da 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 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 computadores será o 95o a 99o percentil dos usuários de computadores, e o valor de FID mais importante para dispositivos móveis será o 95o a 99o percentil dos usuários de dispositivos móveis.

Como melhorar a FID

Um guia completo sobre como otimizar a FID está disponível com orientações sobre as técnicas para melhorar essa métrica.

Registro de alterações

Às vezes, eles são descobertos nas APIs usadas para medir as 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 seus 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 no Grupo do Google web-vitals-feedback.