Hot News
O Lighthouse do Google não usa a métrica Interaction to Next Paint (INP) em seus testes padrão, apesar do INP ser um dos Core Web Vitals.
Barry Pollard, defensor do desenvolvedor de desempenho da Web no Google Chrome, explicou o raciocínio por trás disso e ofereceu insights sobre como medir o INP.
O Lighthouse mede carregamentos de páginas, não interações
O Lighthouse mede o carregamento de uma página simples e captura várias características durante esse processo.
Ele pode estimar o Largest Contentful Paint (LCP) e a Cumulative Layout Shift (CLS) sob condições de carga específicas, identificar problemas e aconselhar sobre como melhorar essas métricas.
No entanto, o INP é diferente porque depende das interações do usuário.
Pollard explicou:
“O problema é que o Lighthouse, novamente como muitas ferramentas de desempenho da web, normalmente apenas carrega a página e não interage com ela. Sem interações = Sem INP para medir!”
Fluxos de usuário personalizados permitem medição de INP
Embora o Lighthouse não possa medir o INP, conhecer as jornadas comuns dos usuários permite que você use “fluxos de usuários” para medir o INP.
Pollard acrescentou:
“Se você, como proprietário do site, conhece as jornadas comuns do usuário, pode medi-las no Lighthouse usando ‘fluxos de usuário’ que IRÁ medir o INP.”
Essas jornadas comuns do usuário podem ser automatizadas em um ambiente de integração contínua, permitindo que os desenvolvedores testem o INP em cada commit e identifiquem possíveis regressões.
Tempo total de bloqueio como proxy INP
Embora o Lighthouse não possa medir o INP sem interações, ele pode medir causas prováveis, especialmente longas, de bloqueio de tarefas JavaScript.
É aqui que entra em jogo a métrica Tempo Total de Bloqueio (TBT).
De acordo com Pollard:
“TBT (Tempo Total de Bloqueio) mede o tempo total de todas as tarefas maiores que 50ms. A teoria é:
- Muitas tarefas longas e bloqueadoras = alto risco de INP!
- Poucas tarefas longas e bloqueadoras = baixo risco de INP!”
Limitações do TBT como substituto do INP
O TBT tem limitações como substituto do INP.
Pollard observou:
“Se você não interagir durante tarefas longas, talvez não tenha problemas de INP. Além disso, as interações podem carregar MAIS JavaScript que não é medido pelo Lighthouse.”
Ele acrescenta:
“Portanto, é uma pista, mas não um substituto para realmente medir o INP.”
Otimizando para pontuações do Lighthouse versus experiência do usuário
Alguns desenvolvedores otimizam as pontuações do Lighthouse sem considerar o impacto do usuário.
Pollard adverte contra isso, afirmando:
“Um padrão comum que vejo é atrasar TODO JS até que o usuário interaja com uma página: ótimo para pontuações do Lighthouse! Muitas vezes terrível para os usuários 😢:
- Às vezes, nada carrega até você mover o mouse.
- Muitas vezes, sua primeira interação sofre um atraso maior.”
Postagem completa de Pollard
Por que isso é importante
Compreender os relacionamentos Lighthouse, INP e TBT é necessário para otimizar a experiência do usuário.
Reconhecer as limitações na medição do INP ajuda a evitar otimizações equivocadas.
O conselho de Pollard para medir o INP é focar nas interações reais do usuário para garantir que as melhorias de desempenho melhorem a UX.
Como o INP continua sendo um Core Web Vital, compreender suas nuances é essencial para mantê-lo dentro de um limite aceitável.
Aplicações Práticas
Para monitorar o desempenho do site e o INP:
- Use os “fluxos de usuários” do Lighthouse para medição de INP em jornadas comuns.
- Automatize os fluxos de usuários no CI para monitorar o INP e capturar regressões.
- Use o TBT como proxy INP, mas entenda suas limitações.
- Priorize medições de campo para obter dados INP precisos.
- Equilibre otimizações de desempenho com considerações de UX.
Imagem em destaque: Ye Liew/Shutterstock
#hotnews #noticias #tecnologia #AtualizaçõesDiárias #SigaHotnews #FiquePorDentro #ÚltimasNotícias #InformaçãoAtual