Interaction to Next Paint (INP): O Que É, Como Medir e Melhorar

Interaction to Next Paint (INP) é uma Core Web Vital que mede a rapidez com que uma página da web responde às interações do usuário, como cliques, toques e pressionamentos de tecla. O INP captura a latência total desde a entrada do usuário, passando pelo processamento do JavaScript, até a atualização visual final na tela. Uma boa pontuação de INP é de 200 milissegundos ou menos no 75º percentil. O INP substituiu o First Input Delay (FID) como uma Core Web Vital em março de 2024.

O que é o Interaction to Next Paint (INP)?

O Interaction to Next Paint (INP) é uma métrica Core Web Vital que mede a responsividade de uma página da web durante toda a visita de um usuário. Ao contrário do seu antecessor, First Input Delay (FID), que media apenas o atraso antes do início do manipulador de eventos da primeira interação, o INP avalia todas as interações que um usuário faz com a página e relata um único valor que representa a responsividade geral da página.

Toda vez que um usuário clica em um botão, toca em um link, pressiona uma tecla no teclado ou interage com um controle personalizado, o navegador mede o tempo total desde o momento da entrada até quando o próximo quadro é renderizado (painted) na tela. O INP seleciona uma das interações mais lentas como a pontuação de responsividade da página. Para páginas com menos de 50 interações no total, o INP relata a única pior interação. Para páginas com muitas interações, o INP normalmente usa o 98º percentil para filtrar valores discrepantes ocasionais.

Um INP baixo significa que a página responde de forma confiável e oportuna à entrada do usuário. Um INP alto significa que a página parece lenta, sem resposta ou "janky" porque o navegador não consegue processar as interações e atualizar a tela com rapidez suficiente.

INP vs FID: O que mudou e por quê

O INP substituiu oficialmente o First Input Delay (FID) como uma Core Web Vital em março de 2024. O Google aposentou o FID porque ele tinha duas limitações fundamentais que o tornavam uma medida incompleta da responsividade da página.

Primeiro, o FID mediu apenas a primeira interação em uma página. Se o primeiro clique de um usuário fosse rápido, mas as interações subsequentes fossem lentas, o FID relataria uma pontuação de aprovação, apesar da experiência ruim. O INP mede todas as interações ao longo da sessão, fornecendo uma imagem muito mais precisa da responsividade real.

Segundo, o FID mediu apenas a fase de input delay, o que significa que capturou o tempo que o navegador passou esperando antes de começar a processar o evento. Ele ignorou completamente o tempo gasto na execução do código do manipulador de eventos (processing time) e o tempo necessário para pintar (paint) o resultado visual na tela (presentation delay). O INP captura todas as três fases, dando aos desenvolvedores uma visão completa da latência da interação.

A transição do FID para o INP causou uma queda de cerca de 5 pontos percentuais nas taxas de aprovação do Core Web Vitals em dispositivos móveis, de acordo com o HTTP Archive Web Almanac 2024. Isso aconteceu porque muitos sites que pareciam responsivos no FID tiveram interações posteriores lentas que o INP agora captura.

Quais interações o INP mede?

O INP mede apenas interações que envolvem entradas discretas do usuário que o navegador pode observar por meio de manipuladores de eventos. Entender quais interações contam é essencial para uma depuração e otimização precisas.

Interações que contam para o INP

• Cliques do mouse (incluindo cliques em botões, links, caixas de seleção e controles personalizados)
• Toques em telas sensíveis ao toque (equivalente a cliques em dispositivos móveis)
• Pressionamentos de teclas em um teclado físico ou na tela (incluindo digitação em campos de formulário, pressionar Enter, usar atalhos de teclado)

Interações que NÃO contam para o INP

• Rolagem (Scrolling) não conta porque é controlada pela thread do compositor (compositor thread) do navegador e normalmente não bloqueia a main thread
• Passar o mouse (Hovering) não conta porque o hover é um estado contínuo do ponteiro, não uma interação discreta do usuário
• Gestos de arrastar (Drag) não contam, embora o pointerdown inicial que inicia um arrasto possa desencadear uma entrada INP
• Transições e animações CSS que ocorrem sem a entrada do usuário não são interações

Um equívoco comum é que a rolagem afeta o INP. Não afeta. No entanto, se sua página usar rolagem baseada em JavaScript em vez de rolagem nativa do navegador, esses manipuladores de rolagem (scroll handlers) do JavaScript poderão acionar retornos de chamada (callbacks) de eventos que o navegador mede como interações. Esta é uma das razões pelas quais a rolagem CSS nativa supera consistentemente a rolagem JavaScript para responsividade.

As Três Fases de uma Interação INP

Cada interação medida pelo INP consiste em três fases sequenciais. O valor total do INP é a soma de todas as três. Entender cada fase é fundamental porque a estratégia de otimização é diferente para cada uma.

1. Input Delay

O input delay é o tempo entre quando o usuário interage com a página e quando o navegador começa a executar os manipuladores de eventos associados. Esse atraso ocorre porque a main thread do navegador pode estar ocupada com outro trabalho, como a análise de JavaScript, a execução de tarefas agendadas anteriormente ou o processamento de outros retornos de chamada (callbacks) de eventos.

O input delay é especialmente problemático durante a fase de carregamento da página, quando muitos scripts estão sendo analisados e executados simultaneamente. Os dados do CoreDash mostram que as interações durante a fase de carregamento têm um INP no p75 de 132ms, em comparação com apenas 50ms para interações após a conclusão do carregamento da página. Isso é uma diferença de 2,6x. Reduzir a contenção na main thread durante a inicialização da página é uma das maneiras mais eficazes de melhorar o INP.

Na mediana, o input delay é a menor subparte do INP. Mas no 90º percentil, o input delay se torna o contribuinte dominante porque long tasks na main thread podem atrasar o processamento de eventos em centenas de milissegundos. O HTTP Archive Web Almanac 2024 descobriu que menos de 25% dos sites mantêm a duração das tarefas abaixo do limite recomendado de 50ms.

2. Processing Time

O processing time é o tempo total que o navegador gasta executando todos os callbacks dos manipuladores de eventos associados à interação. Isso inclui qualquer JavaScript executado em resposta ao evento, desde a validação de formulários até atualizações de estado para chamadas de rastreamento de análises (analytics).

O processing time é responsável por uma parte significativa do INP total. Se um manipulador de eventos executar operações custosas no DOM, fizer chamadas de API síncronas ou executar loops ineficientes, o processing time aumentará. Um padrão comum que infla o processing time é a execução de código não essencial (como eventos de análise ou callbacks de tags de terceiros) no mesmo manipulador de eventos que a atualização visual crítica.

3. Presentation Delay

O presentation delay é o tempo entre o momento em que todos os manipuladores de eventos terminam a execução e o momento em que o navegador apresenta o próximo quadro contendo a atualização visual. Essa fase inclui recálculo de estilo, computação de layout, pintura (paint) e composição.

Na mediana, o presentation delay é a maior subparte do INP porque cada interação requer pelo menos uma passagem de renderização. Páginas com um DOM grande ou profundamente aninhado levam mais tempo para recalcular estilos e executar o layout. Os Single Page Applications que renderizam novamente grandes árvores de componentes após alterações de estado são particularmente suscetíveis a altos presentation delay.

O que são Pontuações INP Boas e Ruins?

Para passar na avaliação do Core Web Vitals para a métrica Interaction to Next Paint, o 75º percentil de todas as interações registradas no campo (field) deve ficar abaixo de 200 milissegundos:

• Um INP abaixo ou igual a 200 milissegundos significa que sua página tem boa responsividade.
• Um INP entre 200 e 500 milissegundos significa que a responsividade da sua página precisa de melhorias.
• Um INP acima de 500 milissegundos significa que sua página tem baixa responsividade.

É importante entender que o INP usa o 75º percentil, não a média. Isso significa que 75% de seus usuários reais devem ter interações mais rápidas do que 200ms. A metodologia do 75º percentil garante que a métrica reflita a experiência de usuários em dispositivos e conexões mais lentos, e não apenas aqueles com hardware de ponta.

Como Medir o Interaction to Next Paint (INP)

O Interaction to Next Paint só pode ser medido com ferramentas de campo (field tools) que capturam interações de usuários reais. Ao contrário das métricas de laboratório que simulam um único carregamento de página, o INP requer visitantes reais clicando, tocando e digitando em suas páginas. Não há como obter uma pontuação INP significativa de um teste sintético porque o INP depende do comportamento humano real.

Obtenha as Métricas Oficiais do INP

Você pode obter as métricas oficiais do INP no PageSpeed Insights ou no painel do CrUX e no Google BigQuery. O PageSpeed Insights relata a pontuação do 75º percentil com base nos últimos 28 dias de dados de usuários do Chrome. O Google BigQuery fornece mais contexto histórico e permite consultas personalizadas em todo o conjunto de dados do CrUX.

O Google Search Console também relata problemas de INP na seção Core Web Vitals, agrupando URLs afetados e sinalizando páginas que precisam de melhorias ou que têm baixa responsividade.

Monitore o INP com Real User Monitoring (RUM)

Embora o conjunto de dados oficial do CrUX seja a fonte definitiva para as pontuações do Core Web Vitals, ele é altamente anonimizado e não oferece suporte a monitoramento em tempo real ou filtragem detalhada. É por isso que os profissionais de desempenho da web confiam em ferramentas de Real User Monitoring (RUM), como o CoreDash, para obter dados INP acionáveis e em tempo real. As ferramentas de RUM coletam medições de INP de cada carregamento de página, atribuem-nas a elementos específicos, estados de carregamento e tipos de dispositivos e permitem que você diagnostique exatamente quais interações estão causando problemas.

Meça o INP para a Sessão Atual

A maneira mais simples de depurar o INP durante o desenvolvimento é através do Chrome DevTools. Abra o painel Performance e use o modo "timespan" no Lighthouse para registrar interações e ver sua latência. Você também pode usar a extensão Core Web Vitals Visualizer, que sobrepõe as pontuações do INP na página conforme você interage com ela.

Para depuração prática, use a Biblioteca JavaScript Web Vitals do Google para registrar interações individuais no console:

Registre o INP no console com a biblioteca JavaScript Web Vitals

<script type="module">
 import {onINP}
 from 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.js?module';
 onINP(console.log);
</script>

Como Melhorar o Interaction to Next Paint

Melhorar o Interaction to Next Paint exige otimizar todas as três fases: input delay, processing time e presentation delay. Sua página pode responder instantaneamente à maioria das interações, mas se apenas uma interação for lenta, ela poderá definir a pontuação inteira do INP. É por isso que uma abordagem sistemática é necessária.

DICA PageSpeed: na maioria das vezes, o INP será muito pior quando um usuário interagir com a página durante o estágio de inicialização do carregamento da página. É por isso que, ao depurar o INP, faz sentido registrar todas as interações, bem como o estado de carregamento da página!

1. Minimize o Input Delay: Evite Long Tasks na Main Thread

Geralmente, qualquer página é menos responsiva durante a fase de inicialização da página, quando ocorre a maior parte do trabalho da main thread (análise, decodificação, renderização e scripts). Para manter a main thread o mais livre possível:

• Remova código não utilizado. Use tree shaking para remover código morto e code splitting para dividir seu pacote (bundle) em blocos menores que são carregados sob demanda. Audite a cobertura do seu código usando o Chrome DevTools para identificar scripts que carregam, mas nunca são executados.
• Carregue o código não essencial durante o tempo ocioso (idle) do navegador. Você realmente precisa de um widget de chat durante os primeiros 500ms de carregamento da página? Agende scripts não críticos com requestIdleCallback() para serem executados apenas quando o navegador estiver ocioso.
• Identifique e reescreva scripts lentos que consomem recursos excessivos da CPU. Use o painel Performance do Chrome para encontrar scripts com longos tempos de execução e os direcione para otimização.
• Mantenha sua página fácil de renderizar. Evite tamanhos grandes de DOM, imagens em excesso, muitos vídeos e animações CSS que exigem muito da CPU.
• Use async e defer nas tags de script para evitar que o JavaScript bloqueie o analisador (parser) de HTML. Considere adiar (defer) o JavaScript não crítico totalmente até depois que a página se torne interativa.

Divida Long Tasks com scheduler.yield()

O JavaScript é executado na main thread do navegador usando um modelo "run to completion" (executar até a conclusão): assim que uma tarefa é iniciada, ela bloqueia a main thread até terminar. Long tasks (mais de 50ms) impedem o navegador de responder à entrada do usuário. A API scheduler.yield() permite criar pontos de interrupção explicitamente em códigos de longa execução, dando ao navegador a oportunidade de processar as interações pendentes do usuário antes de continuar.

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  // Fallback para navegadores sem scheduler.yield()
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

// Uso: divida uma long task em pedaços menores
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // Ceda o controle a cada 5 itens para que o navegador lide com a entrada do usuário
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

Adie o Trabalho Não Crítico com requestIdleCallback

Use requestIdleCallback() para agendar tarefas não essenciais (análises, telemetria, prefetching) para quando o navegador estiver ocioso. Isso mantém a main thread livre para interações do usuário e reduz diretamente o input delay.

// Em vez de executar análises de forma síncrona:
document.querySelector('.cta-button').addEventListener('click', (e) => {
  // Crítico: atualize a UI imediatamente
  showConfirmation();

  // Não crítico: envie análises durante o tempo ocioso
  requestIdleCallback(() => {
    sendAnalyticsEvent('cta_clicked', { page: location.pathname });
  }, { timeout: 2000 });
});

Use Passive Event Listeners

Para eventos que não precisam chamar preventDefault(), marque seus ouvintes de eventos (event listeners) como passivos. Isso informa ao navegador que ele não precisa esperar que seu manipulador decida se deve cancelar o comportamento padrão, permitindo uma rolagem mais suave e uma resposta de toque mais rápida.

// Listener passivo: o navegador não espera por preventDefault()
document.addEventListener('touchstart', handleTouch, { passive: true });
document.addEventListener('wheel', handleWheel, { passive: true });

2. Minimize o Processing Time: Forneça Feedback Imediato

Quando um visitante realiza uma ação como enviar um formulário ou adicionar um item a uma cesta, não espere pela confirmação do servidor antes de atualizar a interface do usuário (UI). Forneça feedback visual imediato ("Enviando formulário...", "Adicionando item à cesta...") e, em seguida, conclua a operação em segundo plano.

Além disso, ceda o controle à main thread o mais rápido possível após a atualização visual crítica. Como o JavaScript segue um modelo "run to completion", ele bloqueia a main thread até que todo o código no callback seja executado. Você pode criar manualmente um ponto de interrupção (yield point) em que o navegador possa atualizar o layout e, em seguida, continuar executando o código não crítico restante.

const formfeedbackEl = document.getElementById("formfeedback");
const formEl = document.getElementById("form");

formEl.addEventListener("submit", (evt) => {
  evt.preventDefault();
  formfeedbackEl.innerText = "Enviando formulário ... aguarde";

  let headers = new Headers({ Accept: "application/json" });
  let formData = new FormData(formEl);
  fetch("/form-endpoint", { method: "POST", headers, body: formData })
    .then(function (response) {
      return response.json();
    })
    .then(function (jsonData) {
      formEl.reset();
      formfeedbackEl.innerText = jsonData.message;
    });
   setTimeout(other_code_that_needs_to_run(), 0);
});

3. Minimize o Presentation Delay: Mantenha as Coisas Simples

Quando a página precisa ser atualizada após uma interação, o navegador deve recalcular estilos, executar o layout, pintar (paint) os pixels alterados e compor o resultado. A complexidade e o tamanho do seu DOM determinam diretamente quanto tempo esse trabalho de renderização leva.

Alguns ambientes de Single Page Applications (SPA) mal otimizados renderizam novamente muito conteúdo após cada interação. Por exemplo, ao atualizar um contador, certifique-se de atualizar apenas o elemento do contador, não toda a árvore de componentes.

Siga estas duas regras de ouro para renderização mais rápida:

1. Mantenha o DOM pequeno e simples. É muito mais fácil para um navegador renderizar uma página com menos elementos do DOM (nós HTML) do que uma página com estruturas de DOM complicadas e profundamente aninhadas. Procure ter menos de 1.400 elementos no total no DOM e evite aninhar mais de 32 níveis.
2. Use content-visibility para renderizar de forma preguiçosa (lazy-render) o conteúdo fora da tela. A propriedade CSS content-visibility: auto acelera a renderização inicial, adiando a renderização de conteúdo fora da tela até que o usuário role próximo a ele.

/* Aplique content-visibility a seções fora da tela */
.below-the-fold {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

Depurando INP com a API Long Animation Frames (LoAF)

A API Long Animation Frames (LoAF) é uma ferramenta poderosa para diagnosticar problemas de INP. Ela fornece informações detalhadas sobre os quadros (frames) que levam mais de 50ms para serem renderizados, incluindo dados de atribuição de script que indicam exatamente quais scripts estão contribuindo para interações lentas.

Ao contrário da antiga Long Tasks API, o LoAF captura o tempo de renderização, bem como o tempo de execução do script, o que o torna particularmente útil para diagnosticar problemas de presentation delay. As entradas do LoAF incluem a duração do quadro (frame duration), a duração do bloqueio (blocking duration) e um array de entradas de script (script entries) que mostram a URL de origem, o nome da função e o tempo de execução de cada script que foi executado durante o quadro.

// Observe Long Animation Frames para encontrar gargalos no INP
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Observe apenas frames com mais de 100ms
    if (entry.duration > 100) {
      console.log('Frame longo:', entry.duration + 'ms');

      // Registre cada script que contribuiu
      for (const script of entry.scripts) {
        console.log(
          'Script:', script.sourceURL,
          'Função:', script.sourceFunctionName,
          'Duração:', script.duration + 'ms'
        );
      }
    }
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

Ferramentas RUM como o CoreDash integram dados de LoAF automaticamente, correlacionando long animation frames com interações específicas do usuário para que você possa identificar exatamente qual script, em qual página, para qual tipo de interação, está causando as piores pontuações do INP.

INP e LCP: A Conexão com Long Tasks

Long tasks na main thread afetam tanto o INP quanto o Largest Contentful Paint (LCP). Uma tarefa JavaScript que bloqueia a main thread por 200ms atrasa o processamento do evento (piorando o INP) e também atrasa o navegador de renderizar o elemento LCP (piorando o LCP). Ao otimizar a main thread, dividindo as long tasks, adiando o JavaScript não crítico e reduzindo o tempo de execução do script, você melhora ambas as métricas simultaneamente.

Estudos de Caso: Melhorias de INP em Produção

redBus: 80 a 100% de Melhoria na Conversão Mobile

O redBus, uma das maiores plataformas de reserva de passagens de ônibus online do mundo, investiu em otimização de Core Web Vitals em todos os seus mercados globais. Seu foco em reduzir o tempo de execução do JavaScript e otimizar os manipuladores de eventos contribuiu para uma melhoria de 80 a 100% nas taxas de conversão mobile em todos os seus mercados. As melhorias foram impulsionadas por uma combinação de redução do tempo de bloqueio da main thread, otimização do carregamento de scripts de terceiros e implementação de code splitting para reduzir a quantidade de JavaScript analisada durante a inicialização da página.

Preply: INP de 250ms para 185ms, $200K por Ano em Economia Estimada em SEO

A Preply, uma plataforma de tutoria de idiomas online, melhorou o INP de sua página inicial de aproximadamente 250ms para 185ms e o INP da sua página de pesquisa de aproximadamente 250ms para 175ms. A equipe alcançou esses ganhos fazendo a criação de perfil (profiling) da sua aplicação React, identificando e eliminando re-renderizações desnecessárias e adiando callbacks de eventos não críticos. As melhores pontuações no Core Web Vitals correlacionaram-se com classificações de pesquisa mais altas, traduzindo-se em cerca de US$ 200.000 por ano em valor estimado de pesquisa orgânica.

O que Dados Reais Mostram Sobre o INP

A Lacuna de INP entre Mobile e Desktop

Os dados do CoreDash revelam que o INP no mobile (131ms no p75) é 2,8 vezes pior que o INP no desktop (48ms no p75). Esta é a maior diferença entre dispositivos de qualquer métrica de Core Web Vital. Dispositivos móveis têm processadores mais lentos, menos memória e maior latência de rede, todos os quais contribuem para tempos de bloqueio mais longos da main thread e processamento de eventos mais lento. No desktop, 95,6% das interações alcançam uma pontuação INP "boa", enquanto que no mobile esse número cai para 88,0%. Os usuários mobile também enfrentam 5 vezes mais eventos de INP "ruins" (9,6% vs 1,9%).

Teclado vs Interações de Ponteiro

Os dados do CoreDash mostram que as interações do teclado (75ms no p75) são 56% mais lentas do que as interações de ponteiro (49ms no p75). Os eventos de teclado também têm um número significativamente maior de experiências ruins: 7,4% das interações com o teclado resultam em um INP ruim, em comparação com apenas 1,4% para interações de ponteiro. Essa diferença ocorre provavelmente porque eventos de teclado, especialmente em campos de formulário, acionam processamentos mais complexos, como validação de input, sugestões de preenchimento automático (autocomplete) e atualizações de estado.

Interações Durante o Carregamento vs Após o Carregamento

Interações que ocorrem durante o carregamento da página têm um INP drasticamente maior em comparação com aquelas que acontecem depois que a página foi totalmente carregada. Os dados do CoreDash indicam que interações durante a fase de "loading" (carregamento) possuem um INP no p75 de 132ms, contra apenas 50ms das interações pós-carregamento. Isso é uma diferença de 2,6 vezes. Mesmo interações durante a fase "dom-content-loaded" (75ms) mostram um INP elevado, uma vez que scripts assíncronos e sub-recursos continuam sendo processados. Tais dados corroboram enfaticamente com a recomendação de adiar (defer) JavaScript não crítico para atenuar a contenção da main thread durante a inicialização da página.

Taxas de Aprovação Globais de INP

Segundo o HTTP Archive Web Almanac 2024, 74% de todas as páginas móveis atingem um INP "bom" (contra 55% em 2022). No entanto, somente 53% dos 1.000 sites mais visitados conseguem a aprovação no INP. Sites de alto tráfego costumam ter JavaScript mais complexo, mais scripts de terceiros e estruturas de DOM mais complexas, os quais contribuem para piorar a responsividade. No desktop, 97% das páginas alcançam um INP bom, enfatizando a grande discrepância de performance entre mobile e desktop. A mediana do Total Blocking Time em testes de laboratório é de 67ms em desktop, porém é de 1.209ms em dispositivos móveis.

Perguntas Frequentes

Aprofundamentos Relacionados

Esta página central (hub page) abrange os fundamentos do Interaction to Next Paint. Para orientação aprofundada a respeito de aspectos específicos da otimização do INP, explore esses artigos dedicados:

• Encontre e Corrija Problemas de INP: Uma metodologia passo a passo para o diagnóstico com o uso do Search Console, dados RUM e do Chrome DevTools para identificar exatamente as interações que geram as suas piores pontuações no INP.
• INP Input Delay: Mergulho profundo (deep dive) na primeira fase do INP. Aprenda de que maneira as long tasks na main thread acabam bloqueando o processamento de eventos e como você pode reduzir o input delay com a ajuda do agendamento de tarefas (task scheduling), da divisão de código (code splitting) e do uso de web workers.
• INP Processing Time: Mergulho profundo (deep dive) na segunda fase do INP. Saiba de que maneira você deve otimizar os callbacks dos manipuladores de eventos, dar prioridade ao código crítico, adiar os trabalhos não essenciais e se utilize das funcionalidades de concorrência que o React oferece visando reduzir o processing time.
• INP Presentation Delay: Mergulho profundo (deep dive) na terceira fase do INP. Aprenda como a dimensão do DOM (DOM size), a repetição constante de layout (layout thrashing) e a renderização do lado do cliente (client-side rendering) contribuem para tornar muito lentas as atualizações visuais, e de que modo as reduzir e diminuir o presentation delay.

Você pode também achar esses guias de otimização de velocidade de página (PageSpeed) de grande utilidade com a finalidade de melhorar o seu INP:

• Improve INP: Ditch JavaScript Scrolling
• Async vs Defer: JavaScript Loading Strategies
• 14 Methods to Defer JavaScript
• Chat Widget with Perfect Core Web Vitals
• Fix: Avoid Excessive DOM Size