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
  • Otimize Imagens
  • Otimize Web Fonts
  • Otimize Scripts
  • Otimize Estilos
  • Otimize Resource Hints
  • Otimize Ícones
  • Otimize os Tempos de Resposta do Servidor
  • Otimize a Interatividade
  • Monitoramento de Core Web Vitals
  • Otimize o Critical Rendering Path
  • Otimize o Cookie Consent
  • Otimize as Single Page Applications
  • Evite um Tamanho Excessivo do DOM
  • Otimize as Requisições de API
  • Otimize Widgets de Chat
  • Otimize o Desempenho do Service Worker
  • Otimize Conteúdo em Vídeo

Otimize Imagens

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

• Redimensione imagens para corresponder às maiores dimensões na tela: Isso garante que bytes nunca sejam desperdiçados baixando imagens maiores que o tamanho máximo delas na tela. Combine essa prática com imagens responsivas para tamanhos de tela menores. Servir imagens do 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: O lazy loading atrasa o carregamento de imagens fora do viewport até que a página seja rolada até elas, melhorando o First Contentful Paint (FCP) e a velocidade geral de carregamento da página. Nunca faça lazy loading da imagem de LCP, pois isso a atrasará significativamente.
• Faça 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 o LCP. Use <link rel="preload" as="image"> combinado com fetchpriority="high" para os melhores resultados. Isso é especialmente importante quando a imagem de LCP for referenciada pelo CSS ou carregada via JavaScript.
• Defina largura e altura: Definir as dimensões da imagem antecipadamente previne layout shifts causados pelo navegador aguardando as imagens carregarem. Isso melhora o CLS. Navegadores modernos usam os atributos width e height para calcular a proporção antes da imagem carregar, reservando a quantidade correta de espaço.
• Use formatos modernos de imagem como WebP ou AVIF: Esses formatos oferecem tamanhos de arquivo menores comparados a JPEG ou PNG, mantendo qualidade semelhante, resultando em tempos de carregamento mais rápidos. O WebP geralmente atinge arquivos de 25% a 34% menores que o JPEG, enquanto o AVIF pode reduzir o tamanho do arquivo em até 50%. Use o elemento <picture> com fallbacks de formato para máxima compatibilidade do navegador.
• Use o lazy loading nativo e desative o lazy loading baseado em JavaScript: O lazy loading atrasa o carregamento de imagens fora do viewport até que a página seja rolada até elas. O lazy loading nativo oferecido pelos navegadores via atributo loading="lazy" é geralmente mais eficiente do que depender de JavaScript para essa tarefa, pois não requer análise sintática (parsing) nem execução de script extra.
• Use imagens responsivas com srcset: Esse atributo especifica versões diferentes 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 outro conteúdo enquanto decodifica uma imagem. Isso permite que a engine de renderização continue a pintar outros elementos enquanto a decodificação da imagem acontece em paralelo.
• Remova metadados das imagens: Metadados como dados EXIF embutidos nas 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 no CSS para elementos LCP: Imagens de fundo referenciadas no CSS são descobertas mais tarde pelo navegador do que elementos <img> no HTML. Se você precisar usar uma imagem de fundo como elemento LCP, faça preload dela com uma tag <link rel="preload"> para garantir descoberta antecipada. Leia mais sobre LCP resource load delay.

Otimize Web Fonts

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

• Use font-display: swap para um first paint mais rápido: Defina a propriedade font-display como swap nas 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 de forma transparente. Leia mais sobre como garantir que o texto permaneça visível durante o carregamento da web font.
• Use font-display: optional combinado com preload para eliminar layout shifts causados por fontes: Combinar font-display: optional com preload oferece um equilíbrio entre velocidade e possíveis layout shifts. O valor optional oculta o texto brevemente (cerca de 100ms) antes de usar uma fonte de fallback. O preload instrui o navegador a buscar a web font mais cedo, minimizando o tempo gasto em fontes de fallback e reduzindo os layout shifts.
• Use descritores do font-face para fazer a fonte de fallback corresponder às dimensões da web font: Isso garante um CLS mínimo 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ê previne que o conteúdo pule enquanto a fonte carrega.
• Crie subconjuntos de fontes para incluir apenas caracteres necessários: Reduza o tamanho do arquivo da fonte criando subconjuntos para incluir apenas os caracteres necessários para o seu conteúdo. Ferramentas como Font Squirrel, pyftsubset ou glyphhanger ajudam a gerar subconjuntos. Uma fonte com um conjunto completo de caracteres latinos frequentemente pode ser reduzida de 100KB+ para menos de 20KB com a criação correta de subconjuntos.
• Limite o número de pesos e estilos de fonte: Evite carregar variações excessivas de fontes. Limite-se a um máximo de 2 fontes críticas (geralmente com preload) e 2 fontes de carregamento tardio (carregadas após a renderização inicial). Cada peso de fonte adicional acrescenta de 15 a 50KB de tamanho de download.

Otimize Scripts

Scripts podem causar problemas de Interaction to Next Paint, disparar Cumulative Layout Shifts ou atrasar o Largest Contentful Paint. Até 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, veja os 14 métodos para adiar o 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 Coverage do Chrome DevTools para encontrar código não utilizado. A remoção de código morto 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 mudanças no viewport visível devem ser render blocking. Scripts importantes devem ser adiados ou carregados em async. Scripts não essenciais devem carregar quando o navegador estiver ocioso. Veja nosso guia de priorização de recursos para uma estratégia detalhada.
• Code splitting e lazy loading: Divida pacotes grandes de JavaScript em pedaços 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 de 30% a 50%.
• Limite scripts de terceiros: Scripts de terceiros podem introduzir um overhead de desempenho significativo. Avalie sua necessidade e explore alternativas, se possível. Cada script de terceiro adiciona pesquisas de DNS, overhead de conexão e tempo de processamento da main thread. Audite scripts de terceiros regularmente usando o painel 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 terceiros. Use o atributo async ou defer em todas as tags de script de terceiros.
• Monitore o desempenho de scripts de terceiros: Use a API Long Animation Frames (LoAF) ou o CoreDash para rastrear o impacto no mundo real de scripts de terceiros no INP e no LCP. Defina orçamentos de desempenho para JavaScript de terceiros e revise-os regularmente.

Otimize Estilos

Estilos são render blocking 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. CSS render blocking 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 os arquivos CSS: Remova caracteres desnecessários como espaço em branco, comentários e formatação dos 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 embutida do seu pré-processador CSS podem automatizar isso.
• Remova CSS não utilizado: Identifique e elimine o código CSS que não é usado em suas páginas da web. Isso reduz a quantidade de dados que o navegador precisa baixar e analisar (parse), melhorando o desempenho. Ferramentas como PurgeCSS ou a aba Coverage do Chrome DevTools ajudam a identificar CSS não utilizado.
• Faça o inline do CSS crítico: Sirva estilos essenciais para renderizar o 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 atrasar 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 do viewport inicial, considere usar o carregamento assíncrono por meio 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.

Otimize Resource Hints

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

• Remova resource hints não críticos: Remova dicas de preload para recursos que não são essenciais para o carregamento inicial da página. Isso evita downloads ou conexões de rede desnecessários que competem por aqueles recursos iniciais de largura de banda limitada. Cada preload desnecessário consome largura de banda que poderia ser usada para recursos críticos.
• Faça preconnect para domínios críticos: Estabeleça conexões com domínios importantes (como CDNs ou provedores de fontes) logo no início. Isso acelera o download de recursos críticos desses domínios concluindo os handshakes de DNS, TCP e TLS antecipadamente. Use <link rel="preconnect" href="https://example.com"> para origens de terceiros críticas.
• Considere DNS prefetch como uma alternativa ao preconnect: Semelhante ao preconnect, o DNS prefetch sugere ao navegador possíveis 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 o overhead de conexão completa do preconnect não for justificado.
• Faça preload do elemento LCP: O LCP mede quanto tempo leva para o conteúdo principal carregar. Fazer preload do elemento LCP instrui o navegador a priorizar o download deste recurso crítico, acelerando o tempo que leva para os usuários verem o conteúdo principal. Isso é especialmente importante para imagens referenciadas no CSS ou carregadas via JavaScript.
• Faça preload de fontes críticas: Fazer preload de fontes críticas garante que o navegador as busque cedo, evitando atrasos na exibição de texto e melhorando os cumulative layout shifts causados pela troca de fontes. Use <link rel="preload" as="font" type="font/woff2" crossorigin> para os seus tipos de fonte 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 seu servidor não suportar 103, use cabeçalhos de resposta Link. Se cabeçalhos não estiverem disponíveis, adicione elementos <link> ao <head> da página como um fallback. A entrega mais cedo de dicas significa descoberta de recursos mais rápida.
• Faça preload de fontes antes que os arquivos CSS as descubram: Fontes referenciadas no CSS só são descobertas depois que o arquivo CSS foi baixado e analisado. Ao fazer o preload de fontes diretamente no <head> do HTML, você elimina a dependência do parsing de CSS e permite que as fontes carreguem em paralelo, reduzindo tanto o FCP quanto o risco de layout shift.

Otimize Ícones

Ícones podem adicionar um peso significativo à sua página se não forem otimizados. Grandes ícones SVG inline inflam o seu HTML, enquanto fontes de ícones costumam incluir milhares de glifos não utilizados. Otimizar ícones impacta tanto o LCP (peso reduzido de HTML/CSS) quanto o CLS (reserva correta de dimensões).

• Evite ícones SVG inline no HTML: Fazer o inline de ícones SVG grandes pode aumentar o tamanho do seu HTML e atrasar o carregamento da página. Considere métodos alternativos como servi-los em arquivos separados ou usar fontes de ícones (com cuidado) para minimizar o tamanho do HTML e permitir o cache dos ícones pelo navegador. Um sprite sheet SVG externo é frequentemente o melhor equilíbrio entre desempenho e flexibilidade.
• Evite fontes de ícones grandes: Nunca use conjuntos de ícones grandes como o Font Awesome na íntegra. Use a criação de subconjuntos para criar fontes de ícones otimizadas ou SVGs individuais para reduzir o tamanho geral da página da web e melhorar a velocidade de carregamento. Um conjunto Font Awesome completo pode passar de 100KB, enquanto um subconjunto com 20 ícones pode ficar abaixo de 5KB.
• Reserve largura e altura para ícones: Assim como para as imagens, especificar a largura e a altura para os ícones ajuda o navegador a reservar espaço e previne layout shifts enquanto eles carregam. Use os atributos width e height nos elementos SVG ou defina dimensões explícitas no 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 as folhas de estilo de ícones de forma assíncrona após o paint inicial.

Otimize os 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 de servidor lenta atrasa tudo o que vem a seguir. Para estratégias de otimização detalhadas, explore nossos guias sobre diagnosticar problemas de TTFB e configurar o Cloudflare para desempenho.

• Use um provedor de hospedagem rápido e confiável: Um provedor de hospedagem rápido com forte infraestrutura pode melhorar significativamente os tempos de resposta do servidor e o desempenho geral do site. Compare os provedores de hospedagem usando medições reais de TTFB, não alegações de marketing sintéticas.
• Otimize o código server-side e as consultas de banco de dados: Registre frequentemente a execução de código e o tempo de consulta de banco de dados para encontrar gargalos e melhorar a velocidade geral. Use ferramentas de criação de perfil de consultas (query profiling) e monitoramento de desempenho de aplicações (APM) para identificar endpoints lentos.
• Implemente estratégias de cache: Utilize cache de navegador e cache server-side para armazenar dados acessados com frequência, reduzindo a necessidade de recuperação repetida de dados e melhorando os tempos de carregamento. O cache de página inteira (full-page caching) pode reduzir o TTFB de segundos para menos de 100ms. Aprenda mais sobre otimização da duração de cache.
• Renderização client-side ou na edge para personalização: Considere a renderização client-side ou na edge de pequenas personalizações como contagem de carrinho, status de login ou alterações menores de menu para manter a funcionalidade de cache de página inteira. Isso evita a invalidação de cache (cache busting) da página inteira para elementos dinâmicos menores.
• Otimize as 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, contagem 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 em vários nós de edge (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 geralmente são mais bem configuradas que o seu próprio servidor. Veja nosso guia sobre configurar o Cloudflare para um passo a passo prático de configuração.
• Reduza o processamento server-side: Minimize a quantidade de trabalho que o seu servidor faz por requisição. Pré-compute operações custosas, use algoritmos eficientes e mova processamentos não essenciais para background jobs. Analise o ciclo de vida de requisição da sua aplicação para encontrar e eliminar etapas de processamento desnecessárias.
• Use HTTP/3: HTTP/3 é a versão mais recente do Hypertext Transfer Protocol. O HTTP/3 é mais rápido e mais eficiente do que o HTTP/2 e significativamente mais rápido que o HTTP/1.1. A atualização para 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). Aprenda mais sobre otimização da duração da conexão.
• Configure cabeçalhos Server-Timing: Esses cabeçalhos fornecem informações detalhadas sobre quanto tempo diferentes partes da sua página levam para processar no servidor. Com esses dados, você consegue identificar gargalos e áreas de melhoria, focando especificamente em melhorar o Largest Contentful Paint (LCP). Os cabeçalhos Server-Timing são visíveis no painel Network do Chrome DevTools e podem ser capturados por ferramentas RUM como o CoreDash.
• Registre consultas de banco de dados lentas e otimize-as regularmente: Ative o log de consultas lentas no seu banco de dados (MySQL, PostgreSQL, MongoDB) e revise os logs semanalmente. Otimização de índices, reestruturação de consultas e adição de camadas de cache para consultas frequentes podem reduzir drasticamente o TTFB.
• Use compressão GZIP ou Brotli: O GZIP, ou o mais novo Brotli, oferece compressão on the fly de recursos baseados em texto (HTML, CSS, JavaScript) antes da transmissão, resultando em arquivos com tamanho cerca de 70% menores. O Brotli normalmente atinge uma compressão 15% a 20% melhor que o GZIP. Tamanhos menores de arquivo se traduzem em tempos de carregamento mais rápidos.

Otimize a Interatividade

O Interaction to Next Paint (INP) mede a rapidez com que seu site responde às interações do usuário. Interatividade ruim é muitas vezes causada por tarefas de JavaScript demoradas que bloqueiam a main thread. Para um detalhamento completo das três fases do INP, veja nossos guias sobre input delay, processing time e presentation delay.

• Implemente um 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 fique ociosa. Isso garante que tarefas críticas como renderização e interações do usuário não sejam bloqueadas por scripts demorados. Use requestIdleCallback para agendar trabalho não urgente. Aprenda mais sobre otimizar o processing time.
• Divida uma long task fazendo yielding para a main thread: Tarefas complexas de JavaScript podem bloquear a main thread, atrasando a responsividade. Dividir essas tarefas em pedaços menores e fazer o yielding do controle de volta para a main thread entre os pedaços permite ao navegador processar interações de usuário e manter uma experiência de usuário fluida. Use scheduler.yield() (onde suportado) ou setTimeout(0) para quebrar uma long task. Veja nosso guia sobre melhorar o INP abandonando o JavaScript scrolling.
• Forneça feedback imediato após o input: Usuários esperam responsividade imediata após interagirem com seu site. Forneça sinais visuais ou reconheça o input do usuário prontamente, mesmo enquanto tarefas demoradas processam em segundo plano. Use transições CSS e a pseudo-classe :active para feedback visual instantâneo. Isso ajuda a manter a sensação de interatividade e previne que os usuários sintam que o site travou.
• Use event listeners passivos para scroll e touch: Adicione { passive: true } em event listeners de scroll e touch. Listeners passivos dizem ao navegador que o manipulador nunca chamará preventDefault(), permitindo que o scroll inicie imediatamente sem esperar o JavaScript. Isso é especialmente impactante em dispositivos móveis e melhora diretamente o INP para interações adjacentes a scroll.

Monitoramento de Core Web Vitals

Monitorar seus Core Web Vitals continuamente é essencial para capturar regressões cedo e validar que as otimizações tiveram o impacto esperado. Use uma combinação de ferramentas de lab, field data e real user monitoring para um quadro completo.

• Verifique o Lighthouse regularmente: O Lighthouse é uma ferramenta gratuita e de código aberto do Google que ajuda você a identificar problemas de desempenho nas suas páginas. Embora o Lighthouse não meça os Core Web Vitals diretamente em contexto de usuário real, é uma ótima ferramenta para testar e comparar seu site periodicamente 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 do mundo real. O CrUX é a fonte de dados que o Google usa para determinar se você passa ou não nos Core Web Vitals. Use os dados históricos para localizar regressões rapidamente. Você pode acessar os dados do CrUX por meio do PageSpeed Insights, do CrUX Dashboard ou da CrUX API.
• Configure o rastreamento via RUM: RUM (Real User Monitoring) envolve rastrear as experiências de usuário reais no seu site. Ferramentas RUM coletam dados sobre quanto tempo de fato leva para as páginas carregarem para os seus visitantes em locais diferentes e em vários dispositivos. Isso fornece insights valiosos de desempenho no mundo real, complementando os dados simulados do Lighthouse e do CrUX. Nós recomendamos o CoreDash como sua ferramenta de rastreamento RUM para dados detalhados de atribuição de Core Web Vitals.
• Defina orçamentos de desempenho: Orçamentos de desempenho (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 métricas diferentes. Eles atuam como benchmarks para guiar seus esforços de otimização. Verificar seu desempenho regularmente em relação a esses orçamentos ajuda a identificar áreas que precisam de atenção imediata e priorizar otimizações.
• Use segmentação: Use segmentação para rastrear seus tipos de visitante mais valiosos e tipos de página diferentes. Do contrário, grandes quantidades de tráfego podem mascarar problemas de desempenho que afetam grupos vitais específicos. Segmente por tipo de dispositivo, velocidade da conexão, geografia e template de página para descobrir problemas ocultos.

Otimize o Critical Rendering Path

O critical rendering path é a sequência de etapas que o navegador realiza para converter HTML, CSS e JavaScript em pixels visíveis. Otimizar esse caminho melhora diretamente o First Contentful Paint e o atraso de renderização do elemento LCP. Veja também como evitar DOM excessivamente grande.

• Minimize o número de recursos críticos: Todo recurso render blocking (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 folhas de estilo não críticas.
• Otimize a ordem de carregamento de recursos: Garanta que CSS crítico e fontes carreguem primeiro, seguidos por imagens acima da dobra, e depois scripts adiados. Use o atributo fetchpriority e dicas de priorização de recursos para comunicar importância ao navegador.
• Reduza a profundidade da árvore do DOM: Árvores do DOM profundamente aninhadas aumentam o tempo de cálculo de estilo e trabalho de layout. Busque uma profundidade máxima de 32 níveis e menos de 1.500 elementos no total do DOM onde possível. Uma estrutura de DOM mais plana melhora tanto o desempenho de paint quanto o presentation delay do INP.
• Dê preferência a classes e IDs em vez de tags e atributos de elemento: Em vez de p.important, use .important. Isso reduz a necessidade do navegador pesquisar em todos os elementos daquele tipo para corresponder ao estilo, resultando em recálculo de estilo mais rápido.
• Evite aninhar seletores profundamente: Quanto mais fundo você aninha seletores CSS, mais cálculos o navegador precisa realizar. Tente reestruturar seu HTML para reduzir o aninhamento ou usar classes mais específicas próximas ao elemento. Limite a profundidade do seletor a um máximo de 3 níveis.
• Minimize os seletores descendentes: Seletores como .container > .content forçam o navegador a checar todo elemento dentro do contêiner. Se possível, use uma classe mais direta no elemento de conteúdo para que a correspondência de seletores seja mais rápida.
• Consolide seletores com os mesmos estilos: Se vários elementos compartilharem os mesmos estilos, agrupe-os numa única classe ou use a convenção de nomenclatura BEM (Block Element Modifier) para melhor manutenção e uma saída de CSS menor.

Otimize o Cookie Consent

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

• Considere cookie consent server-side para páginas dinâmicas: Para páginas renderizadas de forma dinâmica no server-side, implementar uma solução server-side que renderiza o banner de consentimento na resposta HTML inicial é frequentemente mais rápido que carregar uma solução baseada em JavaScript em separado. Isso elimina a requisição de rede extra e o overhead da avaliação do script.
• Carregue de forma assíncrona os scripts de cookie consent em páginas com cache: Para páginas com cache, carregue seu script de cookie consent em async e considere adicionar fetchpriority="high" ao script para garantir que ele carregue cedo o suficiente para ser exibido antes de uma interação do usuário.
• Mantenha o texto do consentimento curto para evitar interferência no LCP: Textos longos de aviso de cookie podem tomar conta do elemento LCP, pois o navegador considera o maior bloco de texto visível como potencial candidato a LCP. Considere escrever textos mais curtos ou dividi-los em múltiplos parágrafos com uma área visível menor.
• Faça a hospedagem (self-host) dos scripts de notificação de cookie: Faça cache e hospede localmente seus scripts de notificação de cookie e folhas de estilo sempre que possível. Isso elimina pesquisas de DNS e o overhead de conexão a plataformas terceiras de gerenciamento de consentimento, além de lhe dar controle total sobre o comportamento do carregamento.

Otimize as Single Page Applications

Single Page Applications (SPAs) construídas com React, Vue, Angular ou frameworks similares enfrentam desafios únicos de Core Web Vitals. Renderização client-side pode atrasar tanto o FCP quanto o LCP, enquanto a hidratação (hydration) pode bloquear o INP.

• Sempre use server-side rendering ou prerendering: SPAs que dependem exclusivamente de renderização client-side forçam o navegador a baixar, analisar e executar JavaScript antes de haver qualquer conteúdo visível. Use SSR (Next.js, Nuxt, SvelteKit) ou prerendering estático para servir HTML inicial que o navegador possa pintar de imediato.
• Prefira prerenders estáticos a geração dinâmica: Prerenders estáticos (gerados no build time) são muito mais rápidos que prerenders gerados dinamicamente porque podem ser servidos de forma direta por uma CDN sem nenhum processamento server-side. Use geração estática em páginas que não exigem dados por requisição.
• Carregue scripts de terceiros após a hidratação: Durante a hidratação (hydration), o framework já consome um tempo considerável de main thread para deixar a página interativa. Carregar scripts de terceiros em simultâneo agrava o problema e piora o input delay. Adie todo script não essencial para depois que o processo de hidratação for concluído.

Evite um Tamanho Excessivo do DOM

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

• Reduza elementos desnecessários no DOM: Audite seu HTML em busca de elementos wrapper que não servem a nenhum propósito estrutural ou de estilo. Substitua estruturas <div> muito 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 CSS e JavaScript eficientes: Seletores CSS complexos e queries de DOM em 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 das queries de DOM a sub-árvores sempre que possível.
• Use content-visibility: auto para conteúdo off-screen: A propriedade CSS content-visibility: auto informa ao navegador para ignorar a renderização de elementos off-screen até que haja scroll em direção a eles. Isso pode reduzir drasticamente o trabalho de renderização inicial para páginas que tenham seções de conteúdo longas.

Otimize as Requisições de API

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

• Minimize o número de requisições de API: Cada requisição de API adiciona tempo ao carregamento geral da página. Avalie a funcionalidade do seu site e identifique oportunidades para diminuir o número de requisições de API necessárias para renderizar o conteúdo inicial. Técnicas como data batching (combinar várias requisições em uma) e GraphQL podem reduzir o número de round trips.
• Use APIs eficientes e otimizadas: O design e a própria implementação de APIs podem impactar o desempenho. Certifique-se de que está usando APIs bem desenhadas e otimizadas para velocidade e eficiência. Implemente mecanismos de cache no lado da API para reduzir tempos de resposta no caso de dados solicitados com frequência.
• Faça preload de requisições críticas de API: Similar ao preload de recursos críticos como imagens, o preload de requisições essenciais de API pode melhorar o desempenho percebido de forma considerável. Use <link rel="preload" as="fetch"> para instruir o navegador a buscar APIs críticas mais cedo, minimizando o atraso ao usá-las na renderização do conteúdo inicial. Veja nosso guia de priorização de recursos para mais técnicas.

Otimize Widgets de Chat

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

• Carregue widgets de chat depois que o conteúdo principal carregou: Na história da internet, ninguém jamais precisou conversar em um chat antes do conteúdo principal da página carregar. Adie a inicialização do widget de chat até a página finalizar o render inicial, usando requestIdleCallback ou um trigger baseado em scroll.
• Previna layout shifts no widget de chat: Se widgets de chat causam um layout shift, geralmente é uma boa ideia ocultá-los com opacity: 0 até que estejam completamente renderizados na página. Isso permite ao widget montar o layout no background sem fazer o conteúdo visível pular. Use uma transição CSS para o widget aparecer de forma suave.
• Escolha fornecedores de widgets de chat leves: Pesquise. Alguns widgets de chat são bem mais leves e causam menos problemas de Core Web Vitals do que outros. Compare o tamanho do bundle JavaScript, o número de requisições de rede e o impacto no INP de provedores diferentes antes de assumir um compromisso.

Otimize o Desempenho do Service Worker

Service workers podem melhorar o desempenho de visitas repetidas consideravelmente armazenando em cache os ativos e até respostas da página inteira, reduzindo o TTFB de visitantes que retornam. No entanto, um service worker mal implementado pode acabar atrasando a navegação. Aprenda mais sobre otimização da duração de cache.

• Faça cache dos ativos críticos no service worker: Use uma estratégia cache-first em ativos estáticos como CSS, JavaScript, fontes e imagens. Isso permite a visitantes que retornam carregar o site quase de forma instantânea através do cache local. Faça precache dos recursos mais importantes durante o evento de instalação do service worker.
• Otimize o código do service worker: Mantenha seu service worker limpo e eficiente. Evite lógicas complexas de roteamento, uso excessivo de event.waitUntil() e manifestos grandes de precache que tornem a instalação lenta. Use o padrão stale-while-revalidate em recursos que mudam com frequência, mas não requerem frescor imediato.

Otimize Conteúdo em Vídeo

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

• Comprima e otimize vídeos: Use codecs modernos como H.264, VP9 ou AV1 com configurações adequadas de qualidade. Reduza a resolução de vídeo para corresponder ao tamanho de exibição máximo. Um vídeo exibido com 400px de largura não precisa ser codificado em 1920px. Use codificação em dois passos (two-pass encoding) para obter a melhor proporção de qualidade para 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 de vídeo com a Intersection Observer API. Substitua os vídeos de background em autoplay por imagens poster e carregue o vídeo somente quando o usuário fizer scroll para perto dele.
• Hospede vídeos em uma CDN rápida: Arquivos de vídeo são grandes e obtêm enorme benefício com a distribuição em CDN. Use uma CDN dedicada de vídeo ou serviço de hospedagem (como Cloudflare Stream, Mux ou Bunny.net) que proporcione adaptive bitrate streaming, distribuição geográfica e entrega otimizada.
• Use imagens poster em elementos de vídeo: Sempre configure o atributo poster em elementos <video>. A imagem poster dá ao navegador algo para pintar de imediato enquanto o vídeo carrega, que pode atuar como o elemento LCP. Otimize a imagem poster como qualquer outra imagem de LCP.