Todos nós sabemos como é importante causar uma boa primeira impressão. É importante ao conhecer novas pessoas, e também é importante ao construir experiências na Web.
Na Web, uma boa primeira impressão pode fazer a diferença entre alguém se tornarem usuários leais ou deixarem e nunca mais voltarem. A pergunta é: o que causa uma boa impressão e como você avalia o tipo de impressão você provavelmente ganha com os usuários?
Na Web, a primeira impressão pode assumir várias formas diferentes, as primeiras impressões do design e do apelo visual de um site, bem como impressões de sua velocidade e capacidade de resposta.
Embora seja difícil medir o quanto os usuários gostam do design de um site com as APIs da Web, e medir a velocidade e capacidade de resposta dela não é.
A primeira impressão que os usuários têm da velocidade de carregamento do site pode ser medida com o First Contentful Paint (FCP, na sigla em inglês). Mas a rapidez com que seu site pinta pixels para a tela é apenas parte da história. Igualmente importante é quão em 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 a interatividade e a capacidade de resposta do seu site.
O que é a FID?
A FID mede o tempo a partir do momento em que um usuário interage com uma página pela primeira vez, ou seja, eles clicam em um link, tocam em um botão ou usam um controle personalizado com tecnologia JavaScript) até o momento em que o navegador pode começar a processar os manipuladores de eventos em resposta a essa interação.
O que é uma boa pontuação FID?
Para oferecer uma boa experiência ao usuário, os sites devem ter uma Primeira entrada. Atraso de 100 milissegundos ou menos. Para garantir que você esteja atingindo essa meta para a maioria dos usuários, um bom limite para medir é o 75o percentil de carregamentos de página, segmentados em dispositivos móveis e desktop.
FID em detalhes
Como desenvolvedores que escrevem código que responde a eventos, muitas vezes presumimos que nosso código será feita imediatamente, assim que o evento ocorrer. Mas, como usuários, todos nós presenciamos o oposto: carregamos uma página da Web do celular, tentamos interagir com ele e depois ficamos frustrados quando nada acontecido.
Em geral, o atraso de entrada (ou latência de entrada) ocorre porque o erro A linha de execução principal está ocupada fazendo outra coisa e, por isso, (ainda) não pode responder ao usuário. Um motivo comum para isso acontecer é porque o navegador está ocupado analisando e executando um grande arquivo JavaScript carregado pelo app. Enquanto está fazendo isso, ele não pode ser executado qualquer listener de eventos, porque o JavaScript que está carregando pode instruí-lo a 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 desses recursos, após a conclusão do download, 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, ou seja, indicado pelo campo bege tarefa blocos.
Atrasos longos na primeira entrada normalmente ocorrem entre a First Contentful Paint (FCP) e Tempo para interação da página (TTI) porque a página tem renderizado parte do conteúdo, mas ainda não é interativo de forma confiável. Para ilustrar como isso pode acontecer, FCP e TTI foram adicionados ao cronograma:
Você deve ter notado que há bastante tempo (incluindo três longos tarefas) entre FCP e TTI, se um usuário tentar interagir com a página durante esse tempo (por exemplo, clicando em um link), haverá uma de atraso entre o momento em que o clique é recebido e quando a linha de execução principal consegue responder.
Pense no que aconteceria se um usuário tentasse interagir com a página próxima ao início da tarefa mais longa:
Como a entrada ocorre enquanto o navegador executa uma tarefa, ele precisa esperar até que a tarefa seja concluída antes de responder à entrada. A o tempo que ele precisa esperar é 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 é a próxima inatividade. Isso significa que a FID é medida mesmo nos casos em que um evento listener 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 ociosa para ser executado.
Por exemplo, todos os elementos HTML a seguir precisam aguardar tarefas em andamento na linha de execução principal precisam ser concluídas antes de responder ao usuário interações:
- 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 má experiência do usuário, principalmente recomendamos medir o First Input Delay por alguns motivos:
- O First Input Delay será a primeira impressão que o usuário terá dos anúncios capacidade de resposta, e as primeiras impressões são fundamentais para definir da qualidade e confiabilidade de um site.
- Atualmente, os maiores problemas de interatividade na Web ocorrem durante carregar. Por isso, acreditamos que nosso foco inicial é melhorar a experiência de interação terão o maior impacto na melhoria do interatividade 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 de entrada lentos após o carregamento da página. Ao separar essas métricas, poderemos fornecer informações de desempenho diretrizes para desenvolvedores 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, concentra-se apenas em eventos de entrada de ações distintas, como cliques, toques e teclas pressionamentos.
Outras interações, como rolagem e zoom, são ações contínuas e têm restrições de desempenho completamente diferentes (os navegadores muitas vezes e ocultar a latência ao executá-las em uma linha de execução separada).
Em outras palavras, a FID se concentra no R (capacidade de resposta) do RAIL de espetáculos modelo, enquanto rolagem e zoom estão mais relacionados a A (animação), e ao desempenho e qualidades 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 interações são relevantes para FID, conforme mencionado na seção anterior. Em Além disso, as primeiras interações de alguns usuários serão em momentos ruins (quando o principal linha de execução fica ocupada por um longo período), e a primeira tarefa as interações serão em bons momentos (quando a linha de execução principal estiver completamente ociosa).
Isso significa que alguns usuários não terão valores de FID, e outros terão um valor baixo de FID. e alguns usuários provavelmente terão valores de FID altos.
A forma de rastrear, gerar relatórios e analisar a FID provavelmente será um pouco diferente. de outras métricas com as quais você esteja acostumado. A próxima seção explica a melhor forma isso.
Por que só considerar o atraso de entrada?
Como mencionado acima, a FID mede apenas o "atraso" no processamento de eventos. não medem a duração total do processamento do evento nem o tempo necessário o navegador para atualizar a IU após a execução de manipuladores de eventos.
Mesmo que esse tempo seja importante para o usuário e afeta a experiência,
não é incluída nessa métrica porque isso pode incentivar os desenvolvedores
adicionar soluções alternativas que realmente piorem a experiência, ou seja,
poderiam encapsular a lógica do manipulador de eventos em um callback assíncrono (via
setTimeout() ou requestAnimationFrame()) para separá-lo do
tarefa associada ao evento. O resultado seria uma melhoria na métrica
mas uma resposta mais lenta conforme percebida pelo usuário.
No entanto, enquanto a FID mede apenas o "atraso" parte da latência do evento, os desenvolvedores que desejarem acompanhar mais partes do ciclo de vida do evento poderão fazê-lo usando o campo Tempo do evento API. Consulte o guia sobre campanhas personalizadas métricas para saber mais detalhes.
Como medir a FID
A FID é uma métrica que só pode ser medida no , já que ela exige uma string que o usuário interaja com sua página. É possível medir a FID com as ferramentas a seguir.
Ferramentas de campo
- Experiência do usuário no Chrome Relatório
- PageSpeed Insights
- Search Console (Core Web Vitals) do Google Ads)
- Biblioteca JavaScript
web-vitals
Medir a FID no JavaScript
Para medir a FID em JavaScript, use a coluna Tempo do evento
API. O exemplo abaixo mostra como
crie um
PerformanceObserver
que ouve
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 pela
ver o delta entre o startTime e o processingStart da entrada
carimbos de data/hora. Na maioria dos casos, será o valor do FID. No entanto, nem todos
Entradas 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-inputpara páginas carregadas em uma guia em segundo plano, mas essas páginas precisam ser ignoradas ao calcular a FID. - A API também vai enviar entradas
first-inputse a página estiver em segundo plano antes da primeira entrada, mas essas páginas também devem ser ignoradas ao calcular a FID (as entradas só serão consideradas se a página estava no primeiro plano o tempo todo). - A API não informa entradas
first-inputquando a página é restaurada de cache de avanço e retorno, mas a FID precisa ser medido nesses casos, já que os usuários os veem como páginas distintas. visitas. - A API não informa entradas que ocorrem em iframes, mas a métrica sim
já que fazem parte da experiência do usuário na página. Isso pode
aparecem como uma diferença entre CrUX e RUM.
Considere essas informações para medir corretamente a FID. Subframes podem usar a API
para relatar as entradas
first-inputpara o 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 lida com 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);
Você pode consultar o código-fonte
onFID()
para um exemplo completo de como medir a FID no JavaScript.
Como analisar e gerar relatórios sobre dados da FID
Devido à variação esperada nos valores da FID, é essencial que, ao gerar relatórios Na FID, você analisa a distribuição dos valores e se concentra nos percentis mais altos.
Embora a escolha de percentil para todos os limites das Core Web Vitals é o 75o. Para FID, ainda é altamente recomendamos observar os percentis 95o a 99o, pois eles correspondem à primeiras experiências particularmente ruins que os usuários estão tendo com seu site. E vai vão mostrar as áreas que precisam de mais melhorias.
Isso é válido mesmo que você segmente seus relatórios por categoria ou tipo de dispositivo. Para exemplo, se você gerar relatórios separados para computador e dispositivo móvel, o valor de FID que você que mais importam para computadores devem ser o 95o a 99o percentil dos usuários de computador, e o valor de FID mais importante para dispositivos móveis deve estar entre 95 e 99 de 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, é preciso fazer alterações algumas vezes e elas podem aparecer como melhorias ou regressões nos seus relatórios e painéis internos.
Para ajudar você a gerenciar isso, todas as alterações na implementação ou na definição dessas métricas serão exibidas neste registro de alterações.
Se você tiver feedback sobre essas métricas, envie no Grupo do Google web-vitals-feedback.