First Input Delay (FID)

Compatibilidade com navegadores

  • 76
  • 79
  • 89
  • x

Origem

Todos nós sabemos o quanto é importante causar uma boa primeira impressão. Ela é 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 se tornar um usuário fiel ou deixar alguém e nunca mais voltar. A pergunta é: o que causa uma boa impressão e como medir o tipo de impressão que você está causando nos usuários?

Na Web, as primeiras impressões podem assumir várias formas diferentes. Temos as primeiras impressões do design e do apelo visual de um site, além da primeira impressão que ele tem da velocidade e capacidade de resposta.

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 Primeira exibição de conteúdo (FCP, na sigla em inglês). Mas a rapidez com que seu site mostra pixels na tela é só parte da história. Igualmente importante é a responsividade do seu site quando os usuários tentam interagir com esses pixels.

A métrica de latência na primeira entrada (FID, na sigla em inglês) ajuda a medir a primeira impressão do usuário sobre a interatividade e a capacidade de resposta do site.

O que é FID?

A FID mede o tempo entre o momento em que um usuário interage com a página (ou seja, quando clica em um link, toca em um botão ou usa um controle personalizado com JavaScript) até o momento em que o navegador consegue começar a processar 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 precisam ter uma latência na primeira entrada de 100 milissegundos ou menos. Para garantir que essa meta seja atingida para a maioria dos usuários, um bom limite é o 75o percentil de carregamentos de páginas, segmentado em dispositivos móveis e computadores.

Os valores bons de FID são de 2, 5 segundos ou menos, os ruins são maiores do que 4 segundos e qualquer valor entre eles precisa ser melhorado.

FID em detalhes

Como desenvolvedores que escrevem código que responde a eventos, muitas vezes presumimos que o código será executado imediatamente, assim que o evento ocorrer. Mas, como usuários, todos nós passamos pelo oposto com frequência: carregamos uma página da Web no smartphone, tentamos interagir com ela e ficamos frustrados quando nada aconteceu.

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

Considere o seguinte cronograma de um carregamento típico de página da Web:

Exemplo de trace de carregamento de página

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, elas são processadas na linha de execução principal.

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

Atrasos longos na primeira entrada geralmente ocorrem entre a Primeira exibição de conteúdo (FCP, na sigla em inglês) e o Tempo para interação da página (TTI, na sigla em inglês) 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:

Exemplo de rastreamento de carregamento de página com FCP e TTI

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 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:

Exemplo de rastreamento de carregamento de página com FCP, TTI e FID

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 de FID do usuário na página.

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

A FID mede o delta entre o recebimento de um evento de entrada e o momento em que a linha de execução principal fica a próxima ociosa. Isso significa que a FID é medida mesmo nos casos em que um listener de eventos não foi registrado. O motivo é que 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 abaixo precisam esperar que tarefas em andamento na linha de execução principal sejam concluídas 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 de qualquer entrada possa levar a uma má experiência do usuário, recomendamos medir o atraso na primeira entrada por alguns motivos:

  • O atraso na primeira entrada será a primeira impressão que o usuário terá da capacidade de resposta do site. 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 da Web atualmente ocorrem durante o carregamento da página. Portanto, acreditamos que o foco inicial no aprimoramento da primeira interação do usuário no 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, carregamento de menos JavaScript antecipadamente etc.) não são necessariamente as mesmas soluções para corrigir atrasos lentos na entrada após o carregamento da página. Ao separar essas métricas, podemos oferecer diretrizes de desempenho mais específicas para os 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 pressões.

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 podem ocultar a latência executando-as em uma linha de execução separada.

Em outras palavras, a FID se concentra na R (capacidade de resposta) do modelo de desempenho RAIL, enquanto a rolagem e o zoom estão mais relacionados à A (animação), e as qualidades de desempenho 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 acessam. Nem todas as interações são relevantes para a FID, como mencionado na seção anterior. Além disso, as primeiras interações do usuário serão em momentos ruins, quando a linha de execução principal fica ocupada por um período prolongado, e as primeiras interações de alguns usuários ocorrem em momentos bons (quando a linha de execução principal está completamente inativa).

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

A forma como você rastreia, gera relatórios e analisa a FID provavelmente será um pouco diferente de outras métricas com que você está acostumado. A próxima seção explica a melhor forma de fazer isso.

Por que considerar apenas o atraso de entrada?

Como mencionado acima, a FID mede apenas o "atraso" no processamento do evento. Ela não mede o tempo de processamento do evento nem o tempo que o navegador leva para atualizar a IU depois de executar manipuladores de eventos.

Mesmo que esse tempo seja importante para o usuário e afete a experiência, ele não está incluído nessa métrica porque isso pode incentivar os desenvolvedores a adicionar soluções alternativas que pioram a experiência, ou seja, podem agrupar a lógica do manipulador de eventos em um callback assíncrono (usando 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.

Embora a FID meça apenas a parte de "atraso" da latência do evento, os desenvolvedores que quiserem rastrear 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 a FID

A FID é uma métrica que só pode ser medida no campo, porque exige a interação de um usuário real com a página. É possível medir a FID com as ferramentas a seguir.

Ferramentas de campo

Medir a FID no JavaScript

Para medir a 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 a 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 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, mas essas páginas também precisam ser ignoradas no cálculo da FID (as entradas só vão ser 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 a FID precisa ser medida nesses casos, já que os usuários as veem como visitas distintas à página.
  • A API não informa entradas que ocorrem em iframes, mas a métrica faz 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 a FID, é preciso considerá-los. Os subframes podem usar a API para relatar as entradas first-input ao frame pai para agregação.

Em vez de memorizar todas essas diferenças sutis, os desenvolvedores podem usar a biblioteca JavaScript web-vitals para medir a FID, que processa essas diferenças para você (quando possível, porque o problema do iframe não é abordado):

import {onFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
onFID(console.log);

Consulte o código-fonte de onFID() para ver um exemplo completo de como medir a FID em JavaScript.

Análise e geração de relatórios sobre dados da FID

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

Embora a escolha de percentil para todos os limites das Core Web Vitals seja o 75o, para a FID, em particular, ainda recomendamos analisar os percentis 95o a 99o, porque eles vão corresponder às primeiras experiências particularmente ruins que os usuários estão tendo no site. E ele mostrará as áreas que precisam da maior melhoria.

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

Como melhorar a FID

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

Registro de alterações

Às vezes, são encontrados bugs nas APIs usadas para medir as métricas e, às vezes, nas próprias definições de métricas. Por isso, às vezes é preciso fazer alterações, 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 neste registro de alterações.

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