Analisar o atraso de entrada é essencial, pois afeta a experiência do usuário do seu site. Até 25%<\/strong><\/a> dos visitantes deixarão um site se demorar mais de 4 segundos para carregar.<\/p> Neste artigo, abordaremos o first input delay, desde sua definição, importância e otimização até sua relação com outras métricas do Core Web Vitals<\/strong>. Também explicaremos como testar sua pontuação FID e por que ela pode ser baixa.<\/p> \n\n\n O First input delay é uma métrica usada para rastrear o tempo de atraso do navegador até que ele responda à entrada do usuário, incluindo cliques e toques.<\/p>\n <\/div>\n\n\n\n<\/p> Um dos fatores que podem afetar a impressão de um site é o first input delay. Ele costumava ser uma das métricas-base do Core Web Vitals, juntamente com o Largest Contentful Paint<\/strong> (LCP) e o Cumulative Layout Shift<\/strong> (CLS), mas foi substituído pelo Interaction to Next Paint (INP)<\/a>.<\/p> Com o Core Web Vitals, você pode medir o desempenho da sua página, bem como investigar um relatório fornecido para ajudá-lo a melhorar o desempenho do seu site.<\/p> Além disso, essas métricas afetam a experiência do usuário e a classificação de um site, afetando seus esforços otimização para motores de busca (SEO).<\/strong><\/a> A velocidade da página<\/strong><\/a> é um dos principais fatores de classificação do Google.<\/p> Se o site demorar muito para responder às interações de um usuário, isso fará com que ele fique frustrado.<\/p> Como a maioria dos problemas de responsividade ocorre quando uma página da Web está sendo carregada, é vital manter a pontuação de first input delay baixa.<\/p> Tendo explicado por que o first input delay é importante para sua página, é hora de testá-lo para melhorar o desempenho do seu site para uma melhor interação do usuário.<\/p> Ao contrário da mudança de layout cumulativa e da maior pintura de conteúdo, o first input delay só pode ser medido com interação real do usuário na página.<\/p> Aqui está a lista de ferramentas que você pode usar para testar seu first input delay:<\/p> Por exemplo, se você quiser usar o PageSpeed Insights para testar seu first input delay, basta inserir um URL na caixa de pesquisa.<\/p> Feito isso, você receberá uma avaliação dos Core Web Vitals da sua página, assim como sugestões para melhorá-la. Você também pode ver quanto tempo o atraso de entrada tem em sua página da web.<\/p> Geralmente, 0,1 segundo é o limite para que o usuário sinta que o sistema está reagindo instantaneamente.<\/p> Portanto, um site precisa de um FID inferior a 100 ms<\/strong> se quiser obter uma boa pontuação de first input delay e uma resposta rápida para o usuário. Idealmente, o resultado deve ser menor que 100 ms<\/strong> para 75%<\/strong> de todos os carregamentos de página, incluindo dispositivos móveis e desktop.<\/p> O gráfico abaixo mostra como uma pontuação de first input delay pode ser categorizada como boa (good), assim como se precisa de melhorias (needs improvement) ou se é ruim (poor).<\/p> O Max Potential First Input Delay (MPFID) é a tarefa mais longa de uma página. O MPFID mede o tempo de resposta de uma página enquanto a tarefa mais longa está em execução. Observe que a medição começa somente após o cálculo da primeira pintura com conteúdo.<\/p> Os resultados da pontuação são obtidos a partir da comparação do tempo máximo de FID potencial com os tempos de FID máximos potenciais em sites reais. Por exemplo, se você obtiver uma pontuação verde no seu MPFID, isso significa que sua página tem um desempenho melhor do que 90%<\/strong> dos sites reais.<\/p> Quando você obtiver uma pontuação baixa de atraso na primeira entrada, identifique quais partes da página precisam ser aprimoradas para que ela funcione melhor.<\/p> Uma das principais causas que tornam os navegadores incapazes de responder prontamente às interações do usuário é o bloqueio de entradas. Isso ocorre quando o thread principal do navegador está ocupado fazendo outras tarefas.<\/p> Essas tarefas geralmente incluem lidar com HTML, CSS e JavaScript, tornando-os sobrecarregados. Uma tarefa JavaScript longa é um erro comum que causa atraso no thread principal, fazendo com que ouvintes de eventos não possam ser executados na página.<\/p> Para encontrar esse problema, use o PageSpeed Insights e consulte a seção de auditoria de Evitar tarefas longas da linha de execução principal.<\/strong><\/p> Depois de aprender a testar sua pontuação FID e descobrir as possíveis causas, é hora de otimizá-la.<\/p> Normalmente, o JavaScript tem o impacto mais significativo na sua pontuação FID. Por esse motivo, é essencial otimizar seu código JavaScript.<\/p> Siga as sugestões abaixo para fazer isso:<\/p> Nível de dificuldade:<\/strong> fácil<\/p> Impacto:<\/strong> alto<\/p> Quando o thread principal do navegador está ocupado e bloqueado, as solicitações do usuário não podem ser processadas. Isso faz com que a página não responda. A capacidade de resposta inadequada é causada por uma tarefa com mais de 50 ms<\/strong>.<\/p> As tarefas JavaScript consomem muitos recursos que podem afetar o desempenho da velocidade da sua página. Para resolver esse problema, as remova ou divida tarefas longas em tarefas menores e assíncronas. Pelo menos uma tarefa deve levar menos de 50 ms<\/strong>.<\/p> Você pode usar a função setTimeout<\/strong> para dividir tarefas longas em tarefas menores, pois fará com que o thread principal responda às entradas do usuário sem demora.<\/p> Nível de dificuldade:<\/strong> médio<\/p> Impacto:<\/strong> alto<\/p> Ter um site de carregamento rápido pode melhorar a experiência do usuário. Muitos componentes, como imagens grandes ou tarefas JavaScript, tornam os navegadores mais lentos.<\/p> Para resolver esse problema, crie um código de carregamento progressivo agrupando todos os seus arquivos JavaScript em bundle.js<\/strong>. Para isso, você pode usar um webpack<\/strong><\/a>.<\/p> O agrupamento também ajuda a minimizar o tamanho da página e remover código não utilizado — ou ao menos minificá-lo mais facilmente. Além disso, faz com que o navegador carregue apenas componentes da interface do usuário quando necessário.<\/p> Nível de dificuldade:<\/strong> difícil<\/p> Impacto:<\/strong> alto<\/p> O Server-side rendering (SSR) refere-se à exibição de páginas da Web no servidor.<\/p> Com a renderização do lado do servidor, sua página é exibida rapidamente sem ter que esperar que os recursos fiquem disponíveis. Isso pode resolver problemas de páginas indexadas e de orçamento de rastreamento (também conhecido como crawl budget<\/em>), beneficiando seu SEO.<\/p> Além disso, a renderização do lado do servidor pode aumentar a velocidade da primeira pintura de conteúdo e o tempo até interatividade (TTI), evitando o envio de grandes arquivos JavaScript para o cliente. Como resultado, o carregamento da sua página da web será executado mais rapidamente.<\/p> Você pode renderizar a versão do lado do servidor usando estruturas de front-end como Vue<\/strong>, React<\/strong><\/a> ou Svelte<\/strong>. Antes de usar esses aplicativos, certifique-se de ter instalado o Node.js<\/strong><\/a> para executar o JavaScript no servidor.<\/p> Nível de dificuldade:<\/strong> médio<\/p> Impacto:<\/strong> alto<\/p> Ao contrário da renderização do servidor, a renderização estática gera uma única página HTML preparada uma vez no momento da compilação. Isso ajuda o usuário a acessar a página com antecedência.<\/p> Você pode usar um gerador de site estático, como Gatsby<\/strong><\/a>, para criar páginas HTML estáticas a partir de dados, conteúdo e modelos. Em seguida, ele gerará uma visualização de uma página que pode ser veiculada aos usuários.<\/p> Observe que a renderização estática não é adequada para sites grandes que contêm muitas páginas ou exigem alterações de resposta em cada solicitação. Ao gerar todo o seu conteúdo, o site precisa ser implantado e testado, afetando as atualizações em tempo real. Além disso, sua implantação pode se tornar impraticável.<\/p> Nível de dificuldade:<\/strong> difícil<\/p> Impacto:<\/strong> alto<\/p> Um tempo de carregamento lento da página pode ser causado por um script de terceiros que adiciona funcionalidades aos sites — como bate-papo ao vivo, anúncios e análises.<\/p> O código de terceiros pode causar problemas, como processar muitas solicitações de rede para diferentes servidores, enviando grandes tarefas JavaScript ou arquivos de imagens que bloqueiam o thread principal.<\/p> Para revisar seus scripts de terceiros, você pode testar seu site no PageSpeed Insights. Ele mostrará listas dos recursos de terceiros carregados, juntamente do tamanho da transferência e o tempo de bloqueio do encadeamento principal.<\/p> Use atributos assíncronos ou adiados para melhorar seus tempos de carregamento nos scripts de terceiros. Isso ajudará você a eliminar o problema de bloqueio de renderização e acionar um processo de carregamento de página da Web mais rápido.<\/p> Scripts importantes, que são vitais para o carregamento da página, não devem usar atributos assíncronos ou adiados. Isso só deve ser feito com scripts externos.<\/p> Nível de dificuldade:<\/strong> difícil<\/p> Impacto:<\/strong> alto<\/p> Os <\/strong>web workers<\/strong><\/a> ajudam a reduzir o tempo de bloqueio do encadeamento principal e a melhorar a pontuação FID do seu site. Eles permitem que você coloque tarefas longas num thread de segundo plano sem interferir na interface do usuário, tornando seu site mais responsivo.<\/p> Use o código Worker(“path\/to\/worker\/script”)<\/strong> para criar um worker. Ele pode enviar mensagens para o código JavaScript. Isso é feito ao postar para um manipulador de eventos especificado por esse código, e vice-versa.<\/p> Além disso, um web worker pode executar tarefas de entrada ou saída usando XMLHttpRequest<\/a><\/strong> ou um fetch<\/strong><\/a>.<\/p> Para ajudá-lo a usar um web worker, confira as seguintes bibliotecas:<\/p> Nível de dificuldade:<\/strong> difícil<\/p> Impacto:<\/strong> alto<\/p> Muitas tarefas JavaScript levarão um longo tempo para serem analisadas e executadas. Como resultado, o tempo de resposta do navegador será atrasado.<\/p> O navegador fará uma pausa quando encontrar uma tag de script vinculada ao código JavaScript externo. É por isso que é importante executar apenas o código necessário.<\/p> Existem algumas opções para otimizar o JavaScript, como divisão de código e o adiamento de qualquer JavaScript não crítico. Antes disso, você pode usar a guia Coverage<\/strong><\/a> no Chrome DevTools para ver quanto JavaScript não utilizado existe em sua página da web.<\/p> A divisão de código permite que você divida um pacote JavaScript em partes e ajude sua página a carregar somente quando necessário. Isso também é conhecido como lazy loading<\/strong><\/a>. Enquanto isso, para adiar qualquer tarefa JavaScript não crítica, sempre use os recursos async ou defer<\/strong><\/a> para scripts que não são vitais para o caminho de renderização crítico<\/strong><\/a> ou acima da dobra<\/strong><\/a>.<\/p> Nível de dificuldade:<\/strong> difícil<\/p> Impacto:<\/strong> baixo<\/p> Polyfill é um código usado para rodar recursos modernos em navegadores mais antigos que não o suportam nativamente. Por exemplo, ao usar a sintaxe JavaScript moderna e APIs de navegador para criar código, você precisará transpilá-lo e entregar polyfills para que os recursos modernos sejam executados em navegadores mais antigos.<\/p> O uso de polyfills criará mais pacotes que levarão mais tempo para carregar no navegador. Portanto, é essencial minimizar os polyfills não utilizados e usá-los apenas quando necessário.<\/p> Para reduzir o tempo de carregamento necessário para sua página da web, você pode usar um compilador JavaScript, como Babel. Então, use @babel\/preset-env<\/strong><\/a> para incluir os polyfills necessários para navegadores mais antigos.<\/p>![\"\"](\"https:\/\/imagedelivery.net\/LqiWLm-3MGbYHtFuUbcBtA\/wp-content\/uploads\/sites\/53\/2022\/12\/eBook_-Speed-Up-your-website-BR.png\/public\")
<\/a><\/figure>O que É o First Input Delay (FID)?<\/h4>\n
Por Que o First Input Delay é Importante?<\/strong><\/h2>
![\"\"](\"https:\/\/imagedelivery.net\/LqiWLm-3MGbYHtFuUbcBtA\/wp-content\/uploads\/sites\/53\/2023\/02\/BR-Web-hosting_in-text-banner.png\/public\")
<\/a><\/figure>Como Testar seu First Input Delay<\/strong><\/h2>
\n
\n
![\"teste](\"https:\/\/imagedelivery.net\/LqiWLm-3MGbYHtFuUbcBtA\/wp-content\/uploads\/sites\/53\/2022\/05\/image.png\/public\")
<\/figure><\/div>O que é uma boa pontuação FID?<\/strong><\/h3>
![\"classificações](\"https:\/\/imagedelivery.net\/LqiWLm-3MGbYHtFuUbcBtA\/wp-content\/uploads\/sites\/53\/2022\/05\/image-1.png\/public\")
<\/figure><\/div>Max Potential First Input Delay<\/strong><\/h3>
![\"tabela](\"https:\/\/imagedelivery.net\/LqiWLm-3MGbYHtFuUbcBtA\/wp-content\/uploads\/sites\/53\/2022\/05\/image-2.png\/public\")
<\/figure><\/div>Como Encontrar a Causa de Uma Baixa Pontuação FID<\/strong><\/h2>
![\"Evitar](\"https:\/\/imagedelivery.net\/LqiWLm-3MGbYHtFuUbcBtA\/wp-content\/uploads\/sites\/53\/2022\/05\/image-3.png\/public\")
<\/figure>8 Maneiras de Otimizar seu First Input Delay (FID)<\/strong><\/h2>
1. Divida as Tarefas Longas em Tarefas Menores<\/strong><\/h3>
2. Implemente o Carregamento Progressivo<\/strong><\/h3>
3. Mova a Lógica para o Lado do Servidor<\/strong><\/h2>
4. Gere Conteúdo Estático<\/strong><\/h3>
5. Revise a Execução de Script de Terceiros<\/strong><\/h3>
6. Utilize Web Workers<\/strong><\/h3>
\n
7. Otimize JavaScript Não Utilizado e Não Crítico<\/strong><\/h3>
8. Revisar o Uso de Polyfills<\/strong><\/h3>