O Checklist Definitivo de Core Web Vitals (2026)

Table of Contents!

• O Checklist Definitivo de Core Web Vitals
• Checklist de Otimização de Core Web Vitals
  • Otimizar Imagens
  • Otimizar Web Fonts
  • Otimizar Scripts
  • Otimizar Estilos
  • Otimizar Resource Hints
  • Otimizar Ícones
  • Otimizar Tempos de Resposta do Servidor
  • Otimizar Interatividade
  • Monitoramento de Core Web Vitals
  • Otimizar o Caminho de Renderização Crítico
  • Otimizar o Consentimento de Cookies
  • Otimizar Aplicações Single Page
  • Evite Tamanho Excessivo do DOM
  • Otimizar Requisições de API
  • Otimizar Widgets de Chat
  • Otimizar o Desempenho do Service Worker
  • Otimizar Conteúdo de Vídeo

Otimizar Imagens

Imagens grandes na viewport visível, na maioria das vezes, se tornarão o elemento de Largest Contentful Paint. Otimizar imagens é uma das ações de maior impacto que você pode realizar para LCP. Use estes itens do checklist de Core Web Vitals para melhorar a velocidade das imagens. Para a estratégia completa, leia nosso guia sobre como otimizar a imagem de LCP.

• Redimensione as imagens para corresponder às maiores dimensões na tela: Isso garante que bytes nunca sejam desperdiçados baixando imagens maiores que seu tamanho máximo na tela. Combine esta prática com imagens responsivas para tamanhos de tela menores. Servir imagens com o tamanho correto pode reduzir o tamanho dos arquivos de imagem em 50% ou mais sem qualquer perda visível de qualidade.
• Use lazy loading para imagens abaixo da dobra (below-the-fold): O lazy loading atrasa o carregamento de imagens fora da viewport até que elas sejam roladas para a visualização, melhorando o First Contentful Paint (FCP) e a velocidade geral de carregamento da página. Nunca use lazy load na imagem de LCP, pois isso a atrasará significativamente.
• Faça o preload de imagens visualmente importantes, como o elemento LCP: O preload instrui o navegador a buscar imagens críticas antes do restante do conteúdo, priorizando LCP. Use <link rel="preload" as="image"> combinado com fetchpriority="high" para obter os melhores resultados. Isso é especialmente importante quando a imagem de LCP é referenciada via CSS ou carregada via JavaScript.
• Defina width e height: Definir as dimensões da imagem antecipadamente evita layout shifts causados pelo navegador esperando que as imagens carreguem. Isso melhora o CLS. Navegadores modernos usam os atributos width e height para calcular a proporção da imagem antes que ela carregue, reservando a quantidade correta de espaço.
• Use formatos de imagem modernos como WebP ou AVIF: Esses formatos oferecem tamanhos de arquivo menores em comparação com JPEG ou PNG, mantendo qualidade semelhante, resultando em tempos de carregamento mais rápidos. WebP tipicamente atinge arquivos 25-34% menores que JPEG, enquanto AVIF pode reduzir o tamanho do arquivo em até 50%. Use o elemento <picture> com fallbacks de formato para compatibilidade máxima com navegadores.
• Use lazy loading nativo e desative lazy loading baseado em JavaScript: O lazy loading atrasa o carregamento de imagens fora da viewport até que elas sejam roladas para a visualização. O lazy loading nativo oferecido pelos navegadores através do atributo loading="lazy" é geralmente mais eficiente do que depender de JavaScript para essa tarefa, pois não requer análise ou execução extra de scripts.
• Use imagens responsivas com srcset: Este atributo especifica diferentes versões de imagem para vários tamanhos de tela, garantindo que o navegador entregue a imagem ideal para o dispositivo do usuário, reduzindo downloads grandes desnecessários. Combine srcset com o atributo sizes para controle preciso.
• Adicione decoding="async": O atributo decoding="async" impede que o navegador bloqueie outros conteúdos enquanto decodifica uma imagem. Isso permite que a engine de renderização continue fazendo o paint de outros elementos enquanto a decodificação da imagem acontece em paralelo.
• Remova metadados da imagem: Metadados como dados EXIF incorporados em imagens podem adicionar bytes desnecessários. Remover essa informação pode reduzir o tamanho do arquivo sem afetar a qualidade da imagem. Ferramentas como ImageOptim, Squoosh ou Sharp podem automatizar a remoção de metadados como parte do seu processo de build.
• Evite imagens de fundo (background images) em CSS para elementos LCP: Imagens de fundo referenciadas em CSS são descobertas mais tarde pelo navegador do que elementos <img> no HTML. Se você precisar usar uma imagem de fundo como o elemento LCP, faça o preload dela com uma tag <link rel="preload"> para garantir a descoberta antecipada. Saiba mais sobre LCP resource load delay.

Otimizar Web Fonts

Web fonts podem atrasar o First Contentful Paint, causar layout shifts e competir por recursos de largura de banda iniciais. Use este checklist para garantir uma experiência fluida com web fonts. Para melhores práticas de hospedagem de fontes, consulte nosso guia sobre como fazer o self-hosting de Google Fonts.

• Use font-display: swap para um first paint mais rápido: Defina a propriedade font-display como swap em suas declarações @font-face. Isso garante que o navegador exiba uma fonte de fallback imediatamente enquanto carrega a web font em segundo plano. Assim que a fonte estiver pronta, ele a substitui sem problemas. Leia mais sobre como garantir que o texto permaneça visível durante o carregamento de webfonts.
• Use font-display: optional combinado com preloading para eliminar layout shifts causados por fontes: Combinar font-display: optional com preloading oferece um equilíbrio entre velocidade e potenciais layout shifts. O valor optional oculta o texto brevemente (cerca de 100ms) antes de usar uma fonte de fallback. O preloading instrui o navegador a buscar a web font antecipadamente, minimizando o tempo gasto em fontes de fallback e reduzindo layout shifts.
• Use descritores de font-face para fazer com que a fonte de fallback corresponda às dimensões da web font: Isso garante o mínimo de CLS quando a web font for trocada. Ao especificar métricas semelhantes usando size-adjust, ascent-override, descent-override e line-gap-override para a fonte de fallback, você pode evitar que o conteúdo pule enquanto a fonte é carregada.
• Faça o subset das fontes para incluir apenas os caracteres necessários: Reduza o tamanho do arquivo da fonte fazendo o subset das fontes para incluir apenas os caracteres necessários para o seu conteúdo. Ferramentas como Font Squirrel, pyftsubset ou glyphhanger podem ajudar a gerar subsets. Uma fonte completa do conjunto de caracteres latinos frequentemente pode ser reduzida de 100KB+ para menos de 20KB com um subset adequado.
• Limite o número de pesos e estilos de fonte: Evite carregar variações de fontes excessivas. Limite-se a um máximo de 2 fontes críticas (geralmente com preloading) e 2 fontes de carregamento tardio (carregadas após a renderização inicial). Cada peso de fonte adicional adiciona de 15 a 50KB no tamanho do download.

Otimizar Scripts

Scripts podem causar problemas de Interaction to Next Paint, desencadear Cumulative Layout Shifts ou atrasar o Largest Contentful Paint. Mesmo scripts iniciais otimizados e relativamente inofensivos podem competir por recursos e atrasar as métricas de paint (LCP e FCP). Para um guia completo, consulte 14 métodos para adiar JavaScript.

• Remova JavaScript desnecessário: Identifique e elimine código JavaScript não utilizado para minimizar a quantidade de código que precisa ser baixada e executada. Use a aba de Coverage do Chrome DevTools para encontrar código não utilizado. Remover dead code reduz tanto o tempo de download quanto o processamento na main thread.
• Priorize scripts com base em sua função e importância: Scripts que fazem grandes alterações na viewport visível devem bloquear a renderização. Scripts importantes devem ser adiados ou carregados de forma assíncrona. Scripts não essenciais devem ser carregados quando o navegador estiver ocioso. Consulte nosso guia de priorização de recursos para uma estratégia detalhada.
• Code splitting e lazy loading: Divida grandes bundles de JavaScript em chunks menores e carregue-os apenas quando necessário. Isso reduz o tempo de carregamento inicial. Bundlers modernos como webpack, Rollup e esbuild suportam code splitting automático com base em imports dinâmicos.
• Minifique e recompile arquivos JavaScript: Sempre minifique e recompile seus arquivos JavaScript com uma ferramenta de minificação como SWC, Terser ou esbuild. A minificação normalmente reduz o tamanho do arquivo JavaScript em 30 a 50%.
• Limite scripts de terceiros: Scripts de terceiros podem introduzir uma sobrecarga de desempenho significativa. Avalie sua necessidade e explore alternativas, se possível. Cada script de terceiros adiciona consultas DNS, sobrecarga de conexão e tempo de processamento na main thread. Audite scripts de terceiros regularmente usando o painel de Network do Chrome DevTools.
• Carregue scripts de terceiros de forma assíncrona: Devido à natureza imprevisível de scripts de terceiros, nunca permita que a renderização seja bloqueada por um terceiro. Use o atributo async ou defer em todas as tags de scripts de terceiros.
• Monitore o desempenho de scripts de terceiros: Use a Long Animation Frames (LoAF) API ou CoreDash para rastrear o impacto no mundo real de scripts de terceiros sobre o INP e LCP. Defina budgets de desempenho para JavaScript de terceiros e revise-os regularmente.

Otimizar Estilos

Estilos bloqueiam a renderização por padrão. Otimizar estilos resultará em métricas de paint otimizadas. Siga o checklist para melhorar o desempenho de estilos da sua página web. O CSS que bloqueia a renderização impacta diretamente tanto o First Contentful Paint quanto o atraso de renderização do elemento LCP. Para dicas sobre como limpar estilos não utilizados, veja como remover CSS não utilizado.

• Minifique arquivos CSS: Remova caracteres desnecessários como espaços em branco, comentários e formatação de arquivos CSS. Arquivos minificados são menores em tamanho, resultando em tempos de carregamento mais rápidos. Ferramentas como cssnano, PostCSS ou a compressão nativa do seu pré-processador CSS podem automatizar isso.
• Remova CSS não utilizado: Identifique e elimine código CSS que não é usado em suas páginas web. Isso reduz a quantidade de dados que o navegador precisa baixar e analisar, melhorando o desempenho. Ferramentas como PurgeCSS ou a aba de Coverage do Chrome DevTools ajudam a identificar CSS não utilizado.
• Faça o inline de CSS crítico: Sirva estilos essenciais para a renderização do conteúdo inicial da página diretamente no HTML para melhorar as métricas de paint. Considere servir o CSS crítico apenas para novos visitantes e usar folhas de estilo externas em cache para visitantes recorrentes. Essa técnica pode reduzir o FCP eliminando o round trip necessário para buscar uma folha de estilo externa.
• Distribua igualmente os tamanhos dos arquivos CSS: Embora possa parecer eficiente combinar todo o CSS em um único arquivo, arquivos excessivamente grandes podem desacelerar os tempos de download. Considere dividir o CSS em arquivos menores com uma distribuição de tamanho mais uniforme (10 a 15KB cada) para otimizar o carregamento e permitir que o navegador processe os estilos de forma incremental.
• Carregue estilos offscreen de forma assíncrona: Para estilos que se aplicam a elementos fora da viewport inicial, considere usar o carregamento assíncrono através do padrão media="print" onload="this.media='all'". Isso permite que o navegador busque esses estilos em paralelo com outros recursos sem bloquear a renderização inicial da página.

Otimizar Resource Hints

Resource hints ajudam a priorizar downloads de recursos críticos. Recursos com preloading geralmente são enfileirados para download e disponibilizados para o navegador muito antes do que estariam sem o preloading. O uso eficaz de resource hints pode reduzir significativamente o atraso de carregamento de recursos LCP. Para implementações avançadas, leia sobre 103 Early Hints.

• Remova resource hints não críticos: Remova hints de preload para recursos que não são essenciais para o carregamento inicial da página. Isso evita downloads desnecessários ou conexões de rede que competem por esses recursos iniciais e de largura de banda limitada. Cada preload desnecessário consome largura de banda que poderia ser usada para recursos críticos.
• Faça o preconnect para domínios críticos: Estabeleça conexões com domínios importantes (como Content Delivery Networks ou provedores de fontes) desde cedo. Isso acelera o download de recursos críticos desses domínios completando os handshakes DNS, TCP e TLS antecipadamente. Use <link rel="preconnect" href="https://example.com"> para origens críticas de terceiros.
• Considere DNS prefetch como uma alternativa ao preconnect: Semelhante ao preconnect, o DNS prefetch sugere ao navegador sobre potenciais conexões. No entanto, o preconnect prioriza o estabelecimento da conexão completa, enquanto o DNS prefetch apenas diz ao navegador para resolver o nome de domínio antecipadamente. Use <link rel="dns-prefetch"> quando a sobrecarga de conexão completa do preconnect não for justificada.
• Faça o preload do elemento LCP: O LCP mede quanto tempo leva para o conteúdo principal carregar. Fazer o preload do elemento LCP instrui o navegador a priorizar o download deste recurso crítico, acelerando o tempo que os usuários levam para ver o conteúdo principal. Isso é especialmente importante para imagens referenciadas em CSS ou carregadas via JavaScript.
• Faça o preload de fontes críticas: Fazer o preload de fontes críticas garante que o navegador as busque precocemente, evitando atrasos na exibição de texto e melhorando os layout shifts causados pela troca de fontes. Use <link rel="preload" as="font" type="font/woff2" crossorigin> para os seus typefaces mais importantes.
• Prefira 103 Early Hints para resource hints: O código de status HTTP 103 Early Hints permite que o servidor envie resource hints antes que a resposta completa esteja pronta. Se o seu servidor não suportar o 103, use cabeçalhos de resposta Link em vez disso. Se cabeçalhos não estiverem disponíveis, adicione elementos <link> no <head> da página como fallback. A entrega mais rápida de hints significa uma descoberta mais rápida de recursos.
• Faça o preload de fontes antes que arquivos CSS as descubram: Fontes referenciadas em CSS só são descobertas depois que o arquivo CSS foi baixado e analisado. Ao fazer o preload das fontes diretamente no <head> do HTML, você elimina a dependência da análise do CSS e permite que as fontes carreguem em paralelo, reduzindo tanto o FCP quanto o risco de layout shift.

Otimizar Ícones

Ícones podem adicionar um peso significativo à sua página se não forem otimizados. Grandes ícones SVG inline incham o seu HTML, enquanto icon fonts geralmente incluem milhares de glifos não utilizados. A otimização de ícones impacta tanto o LCP (peso reduzido de HTML/CSS) quanto o CLS (reserva adequada de dimensão).

• Evite ícones SVG inline em HTML: Fazer o inline de grandes ícones SVG pode aumentar o tamanho do seu código HTML e atrasar o carregamento da página. Considere métodos alternativos como servi-los como arquivos separados ou usar icon fonts (com cautela) para minimizar o tamanho do HTML e permitir que o navegador faça o cache dos ícones. Uma sprite sheet de SVG externa costuma ser o melhor equilíbrio entre desempenho e flexibilidade.
• Evite grandes icon fonts: Nunca use conjuntos de ícones grandes como o Font Awesome em sua totalidade. Use subsetting para criar icon fonts otimizados ou SVGs individuais para reduzir o tamanho geral da página web e melhorar a velocidade de carregamento. Um conjunto completo do Font Awesome pode exceder 100KB, enquanto um subset com 20 ícones pode ter menos de 5KB.
• Reserve width e height para ícones: Semelhante às imagens, especificar width e height para ícones ajuda o navegador a reservar espaço e evita layout shifts à medida que carregam. Use os atributos width e height em elementos SVG ou defina dimensões explícitas em CSS.
• Despriorize conjuntos de ícones não críticos: Se os ícones não forem críticos para a renderização inicial da sua página, considere carregá-los com prioridade mais baixa. Isso garante que o conteúdo essencial carregue primeiro e minimiza o impacto nas métricas de Core Web Vitals. Use lazy loading ou carregue stylesheets de ícones de forma assíncrona após o paint inicial.

Otimizar Tempos de Resposta do Servidor

Tempos de resposta do servidor, medidos pelo Time to First Byte (TTFB), têm uma relação direta com todas as métricas de paint. Uma resposta lenta do servidor atrasa tudo o que vem depois. Para estratégias detalhadas de otimização, explore nossos guias sobre como diagnosticar problemas de TTFB e como configurar o Cloudflare para desempenho.

• Use um provedor de hospedagem rápido e confiável: Um provedor de hospedagem rápido com uma infraestrutura forte pode melhorar significativamente os tempos de resposta do servidor e o desempenho geral do site. Faça benchmark de provedores de hospedagem usando medições reais de TTFB, não alegações sintéticas de marketing.
• Otimize o código no lado do servidor e consultas de banco de dados: Registre frequentemente a execução de código e o tempo de consultas ao banco de dados para encontrar gargalos e melhorar a velocidade geral. Use query profiling e ferramentas de monitoramento de desempenho de aplicativos (APM) para identificar endpoints lentos.
• Implemente estratégias de cache: Utilize cache de navegador e cache no lado do servidor para armazenar dados acessados frequentemente, reduzindo a necessidade de recuperação repetida de dados e melhorando os tempos de carregamento. O cache de página inteira pode reduzir o TTFB de segundos para menos de 100ms. Saiba mais sobre otimização da duração de cache.
• Client-side ou edge rendering para personalização: Considere renderização no client-side ou na edge de pequenas personalizações como contagem do carrinho, status de login ou pequenas alterações de menu para manter a funcionalidade do cache de página inteira. Isso evita o cancelamento do cache de toda a página para elementos dinâmicos menores.
• Otimize configurações do servidor: Revise e ajuste as configurações do seu servidor web para desempenho. Isso inclui configurações de conexão keep-alive, contagens de processos worker, alocação de memória e valores de timeout. Servidores mal configurados podem desperdiçar recursos e aumentar os tempos de resposta.
• Use uma Content Delivery Network (CDN): Uma CDN distribui o conteúdo estático do seu site através de múltiplos edge nodes (servidores). Isso reduz a distância física que os usuários precisam para acessar seu conteúdo, resultando em tempos de carregamento mais rápidos para o público global. Além disso, as CDNs são geralmente mais bem configuradas do que o seu próprio servidor. Veja nosso guia sobre como configurar o Cloudflare para um tutorial passo a passo prático de configuração.
• Reduza o processamento no lado do servidor: Minimize a quantidade de trabalho que o seu servidor faz por requisição. Calcule antecipadamente operações pesadas, use algoritmos eficientes e mova o processamento não essencial para background jobs. Analise o ciclo de vida da requisição da sua aplicação para encontrar e eliminar etapas de processamento desnecessárias.
• Use HTTP/3: O HTTP/3 é a versão mais recente do Protocolo de Transferência de Hipertexto. O HTTP/3 é mais rápido e eficiente que o HTTP/2 e significativamente mais rápido que o HTTP/1.1. Atualizar para o HTTP/3 pode melhorar os tempos gerais de carregamento da página e, potencialmente, todas as três métricas de Core Web Vitals (LCP, INP, CLS). Saiba mais sobre otimização da duração da conexão.
• Configure os cabeçalhos Server-Timing: Esses cabeçalhos fornecem informações detalhadas sobre quanto tempo diferentes partes da sua página levam para serem processadas no servidor. Com esses dados, você pode identificar gargalos e áreas para melhoria, concentrando-se especificamente em melhorar o Largest Contentful Paint (LCP). Os cabeçalhos Server-Timing são visíveis no painel de Network do Chrome DevTools e podem ser capturados por ferramentas de RUM como o CoreDash.
• Registre consultas lentas de banco de dados e otimize-as regularmente: Ative o registro de consultas lentas em seu banco de dados (MySQL, PostgreSQL, MongoDB) e revise os logs semanalmente. A otimização de índices, reestruturação de consultas e adição de camadas de cache para consultas frequentes podem reduzir drasticamente o TTFB.
• Use a compressão GZIP ou Brotli: GZIP, ou o mais recente Brotli, oferece compressão on the fly de recursos baseados em texto (HTML, CSS, JavaScript) antes da transmissão, resultando em tamanhos de arquivo cerca de 70% menores. Brotli tipicamente atinge de 15 a 20% melhor compressão do que o GZIP. Tamanhos de arquivos menores se traduzem em tempos de carregamento mais rápidos.

Otimizar Interatividade

O Interaction to Next Paint (INP) mede a rapidez com que seu site responde às interações do usuário. A baixa interatividade é frequentemente causada por tarefas JavaScript de longa duração que bloqueiam a main thread. Para um detalhamento completo das três fases do INP, veja nossos guias sobre input delay, tempo de processamento e atraso de apresentação.

• Implemente o padrão idle-until-urgent para scripts pesados: Essa abordagem envolve priorizar tarefas críticas e adiar a execução de JavaScript não essencial até que a main thread do navegador esteja ociosa. Isso garante que tarefas críticas como renderização e interações do usuário não sejam bloqueadas por scripts de longa duração. Use requestIdleCallback para agendar trabalhos não urgentes. Saiba mais sobre como otimizar o tempo de processamento.
• Divida tarefas longas fazendo o yielding para a main thread: Tarefas JavaScript complexas podem bloquear a main thread, atrasando a capacidade de resposta. Dividir essas tarefas em chunks menores e fazer o yielding do controle de volta para a main thread entre os chunks permite que o navegador lide com interações do usuário e mantenha uma user experience fluida. Use scheduler.yield() (onde suportado) ou setTimeout(0) para quebrar tarefas longas. Veja nosso guia sobre como melhorar o INP descartando scroll via JavaScript.
• Forneça feedback imediato após o input: Os usuários esperam capacidade de resposta imediata após interagir com seu site. Forneça sinais visuais ou reconheça a entrada do usuário prontamente, mesmo enquanto tarefas de longa duração estão sendo processadas em segundo plano. Use transições CSS e a pseudo-classe :active para um feedback visual instantâneo. Isso ajuda a manter uma sensação de interatividade e evita que os usuários sintam que o site está travado.
• Use passive event listeners para scroll e touch: Adicione { passive: true } em event listeners de scroll e touch. Listeners passivos dizem ao navegador que o handler nunca chamará preventDefault(), permitindo que ele comece o scroll imediatamente sem esperar pelo JavaScript. Isso é especialmente impactante em dispositivos móveis e melhora diretamente o INP para interações adjacentes ao scroll.

Monitoramento de Core Web Vitals

Monitorar os seus Core Web Vitals continuamente é essencial para detectar regressões precocemente e validar que as otimizações têm o impacto esperado. Use uma combinação de ferramentas de laboratório, dados de campo e real user monitoring para ter uma visão completa.

• Verifique o Lighthouse regularmente: O Lighthouse é uma ferramenta de auditoria gratuita e open-source do Google que ajuda a identificar problemas de desempenho nas suas páginas web. Embora o Lighthouse não meça os Core Web Vitals diretamente em um contexto de usuário real, é uma ótima ferramenta para testar e comparar periodicamente o seu site sob condições reguladas e padronizadas. Execute o Lighthouse em pipelines de CI/CD para detectar regressões antes do deploy.
• Verifique os dados históricos do CrUX regularmente: O CrUX (Chrome User Experience Report) é um conjunto de dados público do Google que fornece dados de desempenho no mundo real. O CrUX é a fonte de dados usada pelo Google para determinar se você passa ou não nos Core Web Vitals. Use os dados históricos para identificar regressões rapidamente. Você pode acessar os dados do CrUX através do PageSpeed Insights, o Dashboard do CrUX ou a API do CrUX.
• Configure o rastreamento via RUM: O RUM (Real User Monitoring) envolve o rastreamento das experiências reais de usuários no seu site. Ferramentas RUM coletam dados sobre quanto tempo as páginas realmente levam para carregar para os seus visitantes em diferentes locais e em vários dispositivos. Isso fornece insights valiosos sobre o desempenho no mundo real, complementando os dados simulados do Lighthouse e do CrUX. Recomendamos o CoreDash como a sua ferramenta de rastreamento RUM para obter dados detalhados de atribuição de Core Web Vitals.
• Defina performance budgets: Performance budgets definem metas de desempenho específicas (por exemplo, LCP abaixo de 2,5 segundos, INP abaixo de 200ms, CLS abaixo de 0,1) para diferentes métricas. Eles atuam como benchmarks para guiar seus esforços de otimização. Verificar regularmente seu desempenho em relação a esses budgets ajuda você a identificar áreas que precisam de atenção imediata e a priorizar as otimizações.
• Use segmentação: Use a segmentação para rastrear seus tipos de visitantes mais valiosos e os diferentes tipos de página. Grandes volumes de tráfego poderiam, caso contrário, mascarar problemas de desempenho que afetam especificamente esses grupos vitais. Segmente por tipo de dispositivo, velocidade de conexão, geografia e template de página para descobrir problemas ocultos.

Otimizar o Caminho de Renderização Crítico

O caminho de renderização crítico é a sequência de etapas que o navegador realiza para converter HTML, CSS e JavaScript em pixels visíveis. A otimização desse caminho melhora diretamente o First Contentful Paint e o atraso de renderização do elemento LCP. Veja também como evitar tamanho excessivo do DOM.

• Minimize o número de recursos críticos: Cada recurso que bloqueia a renderização (CSS e JavaScript síncrono) deve ser baixado e processado antes que o navegador possa fazer o paint. Reduza o número de recursos críticos adiando scripts não essenciais e carregando de forma assíncrona as folhas de estilo não críticas.
• Otimize a ordem de carregamento de recursos: Certifique-se de que o CSS crítico e as fontes carreguem primeiro, seguidos por imagens acima da dobra, e em seguida, os scripts adiados. Use o atributo fetchpriority e dicas de priorização de recursos para comunicar a importância para o navegador.
• Reduza a profundidade da árvore do DOM: Árvores do DOM profundamente aninhadas aumentam o tempo de cálculo de estilo e o trabalho de layout. Aponte para uma profundidade máxima de 32 níveis e menos de 1.500 elementos DOM totais onde for possível. Uma estrutura de DOM mais plana melhora tanto o desempenho de paint quanto o atraso de apresentação do INP.
• Favoreça classes e IDs em vez de tags e atributos de elementos: Em vez de p.important, use .important. Isso reduz a necessidade do navegador de pesquisar através de todos os elementos daquele tipo para aplicar estilos, resultando em recálculos de estilo mais rápidos.
• Evite aninhar seletores profundamente: Quanto mais profundo você aninhar seletores CSS, mais cálculos o navegador precisará realizar. Tente reestruturar seu HTML para reduzir o aninhamento ou use classes mais específicas próximas ao elemento. Limite a profundidade do seletor a um máximo de 3 níveis.
• Minimize seletores descendentes: Seletores como .container > .content forçam o navegador a verificar cada elemento dentro do container. Se possível, use uma classe mais direta no elemento de conteúdo para um matching de seletores mais rápido.
• Consolide seletores com os mesmos estilos: Se múltiplos elementos compartilham os mesmos estilos, agrupe-os em uma única classe ou use uma convenção de nomenclatura BEM (Block Element Modifier) para melhor manutenibilidade e menor output de CSS.

Otimizar o Consentimento de Cookies

Banners de consentimento de cookies são exigidos pela GDPR e regulamentações semelhantes, mas eles podem impactar significativamente os Core Web Vitals se não forem implementados com cuidado. Um banner de consentimento mal carregado pode atrasar o LCP, causar CLS e aumentar o INP. Para obter mais detalhes, leia sobre como otimizar widgets de terceiros para Core Web Vitals.

• Considere consentimento de cookies no lado do servidor para páginas dinâmicas: Para páginas renderizadas dinamicamente no lado do servidor, implementar uma solução server-side que renderiza o banner de consentimento na resposta HTML inicial costuma ser mais rápido do que carregar uma solução separada baseada em JavaScript. Isso elimina o overhead extra de requisição de rede e avaliação de scripts.
• Carregue scripts de consentimento de cookies de forma assíncrona em páginas em cache: Para páginas em cache, faça o load de forma assíncrona do seu script de consentimento de cookies e considere adicionar fetchpriority="high" ao script para garantir que ele carregue cedo o suficiente para ser exibido antes da interação do usuário.
• Mantenha o texto de consentimento curto para evitar interferência no LCP: Textos longos de aviso de cookies podem assumir o elemento LCP porque o navegador considera o maior bloco de texto visível como um potencial candidato a LCP. Considere escrever textos mais curtos ou quebrar o texto em vários parágrafos com uma área visível menor.
• Faça o self-hosting de scripts de notificação de cookies: Faça o cache e self-hosting de scripts de notificação de cookies e stylesheets sempre que possível. Isso elimina pesquisas DNS e overhead de conexão para plataformas de terceiros de gestão de consentimento e dá a você controle total sobre o comportamento de carregamento.

Otimizar Aplicações Single Page

Aplicações Single Page (SPAs) construídas com React, Vue, Angular ou frameworks semelhantes enfrentam desafios únicos com os Core Web Vitals. A renderização no lado do cliente pode atrasar tanto o FCP quanto o LCP, enquanto a hydration pode bloquear o INP.

• Sempre use server-side rendering ou prerendering: SPAs que dependem inteiramente do client-side rendering forçam o navegador a baixar, analisar e executar JavaScript antes que qualquer conteúdo seja visível. Use SSR (Next.js, Nuxt, SvelteKit) ou prerendering estático para servir HTML inicial que o navegador possa fazer o paint imediatamente.
• Prefira prerenders estáticos a geração dinâmica: Os prerenders estáticos (gerados no momento do build) são muito mais rápidos que prerenders gerados dinamicamente porque podem ser servidos diretamente de uma CDN sem nenhum processamento server-side. Use geração estática para páginas que não requerem dados a cada requisição.
• Carregue scripts de terceiros após a hydration: Durante a hydration, o framework já está consumindo um tempo significativo da main thread para tornar a página interativa. O carregamento de scripts de terceiros simultaneamente agrava o problema e piora o input delay. Adie todos os scripts não essenciais até após a conclusão do processo de hydration.

Evite Tamanho Excessivo do DOM

Um DOM grande (mais de 1.500 elementos ou uma profundidade excedendo 32 níveis) aumenta o uso de memória, atrasa cálculos de estilo e causa layout reflows custosos. Isso impacta diretamente tanto o atraso de apresentação do INP quanto as métricas de paint. Veja como corrigir tamanho excessivo do DOM.

• Reduza os elementos DOM desnecessários: Audite o seu HTML em busca de elementos wrapper que não servem para propósitos estruturais ou de estilo. Substitua estruturas <div> profundamente aninhadas por elementos HTML semânticos. Considere a virtualização de listas longas usando bibliotecas como react-window ou virtual-scroller para manter o DOM ativo pequeno.
• Use seletores de JavaScript e CSS eficientes: Seletores de CSS e consultas de DOM do JavaScript (como querySelectorAll com padrões amplos) tornam-se exponencialmente mais lentos conforme o tamanho do DOM cresce. Use seletores de classe específicos e limite o escopo de consultas do DOM para subárvores sempre que possível.
• Use content-visibility: auto para conteúdos off-screen: A propriedade de CSS content-visibility: auto informa ao navegador para ignorar a renderização de elementos off-screen até que eles sejam rolados para o campo de visão. Isso pode reduzir drasticamente o trabalho de renderização inicial para páginas com longas seções de conteúdo.

Otimizar Requisições de API

Requisições de API que bloqueiam a renderização ou atrasam o conteúdo podem impactar negativamente o LCP e o TTFB. A busca de dados no client-side é uma fonte comum de LCP lento em aplicações single page.

• Minimize o número de requisições de API: Cada requisição de API aumenta o tempo geral de carregamento da página. Avalie a funcionalidade do seu site e identifique oportunidades para reduzir o número de requisições de API necessárias para renderizar o conteúdo inicial. Técnicas como data batching (combinando múltiplas requisições em uma) e GraphQL podem reduzir round trips.
• Use APIs eficientes e otimizadas: O design e a implementação das próprias APIs podem impactar o desempenho. Garanta que você está usando APIs bem projetadas, otimizadas para velocidade e eficiência. Implemente mecanismos de cache no lado da API para reduzir os tempos de resposta para dados solicitados com frequência.
• Faça o preload de requisições de API críticas: Semelhante ao preloading de recursos críticos como imagens, fazer o preload de requisições de API essenciais pode melhorar significativamente o desempenho percebido. Use <link rel="preload" as="fetch"> para instruir o navegador a buscar APIs críticas antecipadamente, minimizando atrasos quando elas são necessárias para renderizar o conteúdo inicial. Consulte o nosso guia de priorização de recursos para ver mais técnicas.

Otimizar Widgets de Chat

Widgets de chat são uma causa comum de layout shifts e podem até mesmo causar problemas com o LCP se eles forem carregados precocemente. Para uma abordagem passo a passo, leia sobre como implementar um widget de chat com Core Web Vitals perfeitos.

• Carregue os widgets de chat depois que o conteúdo principal tiver carregado: Ninguém na história da internet já precisou conversar no chat antes de o conteúdo principal da página carregar. Adie a inicialização do widget de chat até que a página tenha terminado o seu render inicial, usando requestIdleCallback ou um trigger baseado no scroll.
• Evite layout shifts do widget de chat: Se widgets de chat causarem um layout shift, geralmente é uma boa ideia ocultá-los com opacity: 0 até que eles tenham sido totalmente renderizados na página. Isso permite que o widget se posicione em segundo plano sem fazer com que o conteúdo visível pule. Use uma transição de CSS para aparecer o widget gradualmente.
• Escolha fornecedores de widgets de chat leves: Pesquise. Alguns widgets de chat são muito mais leves e causam muito menos problemas de Core Web Vitals do que outros. Compare o tamanho do bundle de JavaScript, o número de requisições de rede e o impacto no INP de diferentes fornecedores antes de se comprometer.

Otimizar o Desempenho do Service Worker

Os service workers podem melhorar significativamente o desempenho de visitas recorrentes ao fazer o cache de assets e até respostas de página inteira, reduzindo o TTFB para visitantes que retornam. No entanto, um service worker mal implementado pode, na verdade, atrasar a navegação. Saiba mais sobre otimização da duração do cache.

• Faça o cache de assets críticos no service worker: Use uma estratégia cache-first para assets estáticos como CSS, JavaScript, fontes e imagens. Isso permite que visitantes recorrentes carreguem seu site quase instantaneamente pelo cache local. Faça o precache dos recursos mais importantes durante o evento de install do service worker.
• Otimize o código do service worker: Mantenha seu service worker enxuto e eficiente. Evite lógica complexa de roteamento, o uso excessivo de event.waitUntil() e manifestos de precache muito grandes que atrasam a instalação. Use o padrão stale-while-revalidate para recursos que mudam frequentemente, mas que não requerem frescor imediato.

Otimizar Conteúdo de Vídeo

Elementos de vídeo podem se tornar o elemento LCP se eles forem o maior conteúdo visível na viewport. Vídeos grandes e não otimizados também competem por largura de banda com outros recursos críticos.

• Comprima e otimize os vídeos: Use codecs modernos como H.264, VP9 ou AV1 com configurações de qualidade apropriadas. Reduza a resolução de vídeo para corresponder ao tamanho máximo de exibição. Um vídeo que aparece com 400px de largura não precisa ser codificado em 1920px. Use uma codificação de dois passos para ter a melhor relação de qualidade e tamanho de arquivo.
• Use lazy loading para vídeos: Para vídeos abaixo da dobra, use o atributo loading="lazy" em elementos <iframe> ou atrase o carregamento do vídeo com a Intersection Observer API. Substitua vídeos de fundo com reprodução automática por poster images e carregue o vídeo apenas quando o usuário rolar perto dele.
• Hospede vídeos em uma CDN rápida: Arquivos de vídeo são grandes e se beneficiam enormemente da distribuição via CDN. Use uma CDN de vídeo dedicada ou serviço de hospedagem (como Cloudflare Stream, Mux ou Bunny.net) que forneça streaming de bitrate adaptável, distribuição geográfica e entrega otimizada.
• Use poster images para elementos de vídeo: Sempre defina um atributo poster nos elementos <video>. A poster image dá ao navegador algo para fazer o paint imediatamente enquanto o vídeo carrega, o que pode servir como o elemento LCP. Otimize a poster image exatamente como qualquer outra imagem de LCP.