O Checklist Definitivo das Core Web Vitals (2026)

Table of Contents!

• O Checklist Definitivo das Core Web Vitals
• Checklist de Otimização das Core Web Vitals
  • Otimizar Imagens
  • Otimizar Web Fonts
  • Otimizar Scripts
  • Otimizar Estilos
  • Otimizar Dicas de Recursos (Resource Hints)
  • Otimizar Ícones
  • Otimizar os Tempos de Resposta do Servidor
  • Otimizar Interatividade
  • Monitoramento das Core Web Vitals
  • Otimizar o Caminho Crítico de Renderização
  • Otimizar o Consentimento de Cookies
  • Otimizar Single Page Applications
  • Evitar Tamanho Excessivo do DOM
  • Otimizar as Requisições de API
  • Otimizar Widgets de Chat
  • Otimizar a Performance do Service Worker
  • Otimizar o Conteúdo de Vídeo

Otimizar Imagens

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

• Redimensione as imagens para corresponder às maiores dimensões na tela: Isso garante que bytes nunca sejam desperdiçados no download de imagens maiores do que seu tamanho máximo na tela. Combine esta prática com imagens responsivas para tamanhos de tela menores. Servir imagens no tamanho correto pode reduzir o tamanho dos arquivos de imagem em 50% ou mais, sem qualquer perda de qualidade visível.
• Use lazy loading para imagens abaixo da dobra: O lazy loading atrasa o carregamento de imagens fora da viewport até que elas sejam roladas para a área de visualização, melhorando o First Contentful Paint (FCP) e a velocidade geral de carregamento da página. Nunca use lazy load na imagem 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 o LCP. Use <link rel="preload" as="image"> combinado com fetchpriority="high" para obter os melhores resultados. Isso é especialmente importante quando a imagem LCP é referenciada a partir do CSS ou carregada via JavaScript.
• Defina largura e altura: 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 de largura (width) e altura (height) para calcular a proporção antes que a imagem seja carregada, 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 a mesma qualidade, o que leva a tempos de carregamento mais rápidos. O WebP normalmente atinge arquivos de 25-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 com navegadores.
• Use o lazy loading nativo e desative o lazy loading baseado em JavaScript: O lazy loading atrasa o carregamento de imagens fora da viewport até que sejam roladas para a área de 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 e desnecessários. Combine srcset com o atributo sizes para um 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 pintando outros elementos enquanto a decodificação da imagem ocorre em paralelo.
• Remova os metadados da imagem: Metadados como dados EXIF embutidos nas imagens podem adicionar bytes desnecessários. Remover essas informações 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 em CSS para elementos LCP: Imagens de fundo referenciadas em CSS são descobertas mais tarde pelo navegador do que os elementos <img> em HTML. Se você precisar usar uma imagem de fundo como o elemento LCP, faça o preload com uma tag <link rel="preload"> para garantir a descoberta antecipada. Saiba mais sobre o atraso no carregamento de recursos LCP.

Otimizar Web Fonts

As 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 melhores práticas na hospedagem de fontes, consulte nosso guia sobre como auto-hospedar o Google Fonts.

• 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, ela é trocada perfeitamente. Leia mais sobre como garantir que o texto permaneça visível durante o carregamento da webfont.
• Use font-display: optional combinado com preload para eliminar o layout shift causado por fontes: Combinar font-display: optional com preload 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 preload instrui o navegador a buscar a web font antecipadamente, minimizando o tempo gasto nas fontes de fallback e reduzindo os layout shifts.
• Use descritores de font-face para fazer a fonte de fallback corresponder às dimensões da web font: Isso garante um 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 carrega.
• Faça o subset das fontes para incluir apenas os caracteres necessários: Reduza o tamanho do arquivo da fonte fazendo um subset 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 com conjunto de caracteres latinos completo pode ser frequentemente reduzida de 100KB+ para menos de 20KB com o subset adequado.
• 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 adiciona de 15 a 50KB ao tamanho do download.

Otimizar Scripts

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

• Remova o JavaScript desnecessário: Identifique e elimine o 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 thread principal.
• Priorize scripts com base em sua função e importância: Scripts que fazem grandes alterações na viewport visível devem ser bloqueadores de renderização. Scripts importantes devem ser adiados (defer) ou carregados de forma assíncrona (async). Scripts do tipo "bom ter" devem ser carregados 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 os carregue apenas quando necessário. Isso reduz o tempo de carregamento inicial. Bundlers modernos como webpack, Rollup e esbuild suportam divisão automática de código com base em importações dinâmicas.
• Minifique e recompile os 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 os scripts de terceiros: Scripts de terceiros podem introduzir uma sobrecarga de desempenho significativa. Avalie a necessidade deles e explore alternativas, se possível. Cada script de terceiro adiciona pesquisas de DNS, sobrecarga de conexão e tempo de processamento na thread principal. Audite regularmente os scripts de terceiros usando o painel Network do Chrome DevTools.
• Carregue scripts de terceiros de forma assíncrona: Devido à natureza imprevisível dos 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 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 dos scripts de terceiros no INP e no LCP. Estabeleça orçamentos de desempenho para JavaScript de terceiros e os analise regularmente.

Otimizar Estilos

Estilos são bloqueadores de renderização por padrão. A otimização dos estilos resultará em métricas de pintura otimizadas. Siga o checklist para melhorar o desempenho de estilo da sua página web. O CSS que bloqueia a renderização afeta diretamente tanto o First Contentful Paint quanto o atraso de renderização do elemento LCP. Para dicas sobre a limpeza de 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 têm tamanhos menores, levando a tempos de carregamento mais rápidos. Ferramentas como cssnano, PostCSS ou a compressão embutida do seu pré-processador CSS podem automatizar isso.
• Remova o CSS não utilizado: Identifique e elimine o código CSS que não é usado nas 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 Coverage do Chrome DevTools ajudam a identificar o CSS não utilizado.
• Insira o CSS crítico inline: Sirva os estilos essenciais para renderizar o conteúdo inicial da página diretamente no HTML para melhorar as métricas de pintura. Considere servir CSS crítico apenas para novos visitantes e usar folhas de estilo externas em cache para visitantes recorrentes. Esta 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 retardar o tempo 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.
• Carregamento assíncrono para estilos fora da tela: Para estilos que se aplicam a elementos fora da viewport inicial, considere o carregamento assíncrono usando o 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 Dicas de Recursos (Resource Hints)

As dicas de recursos (resource hints) ajudam a priorizar o download 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 dicas de recursos pode reduzir significativamente o atraso no carregamento de recursos LCP. Para implementações avançadas, leia sobre os 103 Early Hints.

• Remova as dicas de recursos 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 desnecessários ou conexões de rede que competem por aqueles recursos limitados de largura de banda inicial. Cada preload desnecessário consome largura de banda que poderia ser usada para recursos críticos.
• Preconnect para domínios críticos: Estabeleça conexões com domínios importantes (como redes de entrega de conteúdo ou provedores de fontes) logo no início. Isso acelera o download de recursos críticos desses domínios, completando a resolução de DNS, TCP e handshakes TLS com antecedência. 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 avisa o navegador sobre potenciais conexões. No entanto, o preconnect prioriza o estabelecimento de toda a conexão, enquanto o DNS prefetch apenas diz ao navegador para resolver o nome de domínio antecipadamente. Use <link rel="dns-prefetch"> quando a sobrecarga da 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 desse recurso crítico, acelerando o tempo para que os usuários vejam o conteúdo principal. Isso é especialmente importante para imagens referenciadas no 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 antecipadamente, evitando atrasos na exibição de texto e melhorando os layout shifts cumulativos causados ​​pela troca de fontes. Use <link rel="preload" as="font" type="font/woff2" crossorigin> para os seus tipos de fontes mais importantes.
• Prefira os 103 Early Hints para dicas de recursos: O código de status HTTP 103 Early Hints permite que o servidor envie dicas de recursos antes que a resposta completa esteja pronta. Se o seu servidor não suportar 103, use os cabeçalhos de resposta Link. Se os cabeçalhos não estiverem disponíveis, adicione os elementos <link> na <head> da página como um fallback. A entrega mais cedo de dicas significa uma descoberta mais rápida de recursos.
• Faça o preload das fontes antes que os arquivos CSS as descubram: As fontes referenciadas em CSS só são descobertas depois que o arquivo CSS foi baixado e analisado. Fazendo o preload de fontes diretamente na <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 embutidos inflam seu HTML, enquanto fontes de ícone muitas vezes incluem milhares de glifos não utilizados. A otimização dos ícones impacta tanto o LCP (peso HTML/CSS reduzido) quanto o CLS (reserva de dimensão adequada).

• Evite ícones SVG embutidos em HTML: Embutir ícones SVG grandes pode aumentar o tamanho do seu código HTML e retardar o carregamento da página. Considere métodos alternativos, como servi-los como arquivos separados ou usar fontes de ícone (com cuidado) para minimizar o tamanho do HTML e permitir que o navegador armazene os ícones em cache. Uma folha de sprite SVG externa geralmente é o melhor equilíbrio entre desempenho e flexibilidade.
• Evite fontes de ícones grandes: Nunca use conjuntos de ícones grandes como Font Awesome na sua totalidade. Use o subsetting para criar fontes de ícones otimizadas 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 largura e altura para os ícones: Semelhante às imagens, especificar largura e altura para os ícones ajuda o navegador a reservar espaço e evita layout shifts enquanto 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 uma prioridade menor. Isso garante que o conteúdo essencial seja carregado primeiro e minimiza o impacto nas métricas Core Web Vitals. Use lazy loading ou carregue folhas de estilo de ícone assincronamente após o paint inicial.

Otimizar os Tempos de Resposta do Servidor

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

• Use um provedor de hospedagem rápido e confiável: Um provedor de hospedagem rápido com infraestrutura robusta 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 afirmações de marketing sintéticas.
• Otimize o código do lado do servidor e as consultas ao banco de dados: Registre com frequência o tempo de execução do código e da consulta ao banco de dados para encontrar gargalos e melhorar a velocidade geral. Use ferramentas de perfilamento de consultas e monitoramento de desempenho de aplicativos (APM) para identificar endpoints lentos.
• Implemente estratégias de cache: Utilize o cache do navegador e o cache do servidor para armazenar dados frequentemente acessados, 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 do cache.
• Renderização do lado do cliente ou edge (borda) para personalização: Considere a renderização no lado do cliente ou no edge para pequenas personalizações, como contagem de carrinhos, status de login ou pequenas alterações no menu, para manter a funcionalidade do cache de página inteira. Isso evita a quebra do cache da página inteira por conta de elementos dinâmicos menores.
• Otimize as configurações do servidor: Revise e ajuste as configurações do seu servidor web para obter desempenho. Isso inclui configurações de conexão keep-alive, contagens de processos do worker, alocação de memória e valores de timeout. Servidores mal configurados podem desperdiçar recursos e aumentar o tempo de resposta.
• Use uma Content Delivery Network (CDN): Uma CDN distribui o conteúdo estático do seu site em vários nós da borda (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 públicos globais. Além disso, os CDNs geralmente estão melhor configurados do que o seu próprio servidor. Veja nosso guia sobre como configurar o Cloudflare para um tutorial 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. Pré-calcule operações caras, use algoritmos eficientes e transfira o processamento não essencial para jobs em segundo plano. Analise o ciclo de vida da requisição do seu aplicativo para encontrar e eliminar etapas de processamento desnecessárias.
• Use o HTTP/3: HTTP/3 é a versão mais recente do Protocolo de Transferência de Hipertexto. O HTTP/3 é mais rápido e mais eficiente que o HTTP/2 e significativamente mais rápido que o HTTP/1.1. A atualização para HTTP/3 pode melhorar o tempo de carregamento geral da página e possivelmente todas as três métricas Core Web Vitals (LCP, INP, CLS). Saiba mais sobre otimização da duração da conexão.
• Configure os cabeçalhos de Server-Timing: Esses cabeçalhos fornecem informações detalhadas sobre quanto tempo as diferentes partes da sua página levam para processar no servidor. Com esses dados, você pode identificar gargalos e áreas para melhorias, focando especificamente na melhoria do Largest Contentful Paint (LCP). Os cabeçalhos de Server-Timing são visíveis no painel Network do Chrome DevTools e podem ser capturados por ferramentas de RUM, como o CoreDash.
• Registre consultas lentas de banco de dados e as otimize regularmente: Habilite os registros de consultas lentas no seu banco de dados (MySQL, PostgreSQL, MongoDB) e analise os logs semanalmente. A otimização de índices, a reestruturação de consultas e a adição de camadas de cache para consultas frequentes podem reduzir drasticamente o TTFB.
• Use compressão GZIP ou Brotli: GZIP, ou o mais recente Brotli, oferece compressão em tempo real de recursos baseados em texto (HTML, CSS, JavaScript) antes da transmissão, resultando em arquivos de tamanho cerca de 70% menores. O Brotli normalmente alcança de 15 a 20% a mais em eficiência de compressão do que o GZIP. Tamanhos de arquivo 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. Interatividade ruim costuma ser causada por tarefas longas de JavaScript que bloqueiam a thread principal. Para um detalhamento completo das três fases do INP, consulte 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 thread principal 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 longos. Use o requestIdleCallback para agendar o trabalho que não é urgente. Saiba mais sobre como otimizar o tempo de processamento.
• Divida tarefas longas fazendo yielding para a thread principal: Tarefas complexas de JavaScript podem bloquear a thread principal, atrasando a responsividade. Dividir essas tarefas em partes menores e devolver (yielding) o controle à thread principal entre as partes permite que o navegador lide com as interações do usuário e mantenha uma experiência fluida. Use scheduler.yield() (onde for suportado) ou setTimeout(0) para dividir as tarefas longas. Veja o nosso guia sobre como melhorar o INP abandonando o scroll por JavaScript.
• Forneça feedback imediato após o input: Os usuários esperam responsividade imediata após interagirem com o seu site. Forneça sinais visuais ou reconheça prontamente o input do usuário, mesmo que tarefas longas estejam sendo processadas em segundo plano. Use transições CSS e a pseudo-classe :active para um feedback visual instantâneo. Isso ajuda a manter a sensação de interatividade e impede que os usuários sintam que o site travou.
• Use event listeners passivos para scroll e toque: Adicione { passive: true } aos event listeners de scroll e toque. Listeners passivos indicam ao navegador que o handler nunca irá chamar o preventDefault(), o que permite que ele inicie o scroll imediatamente sem aguardar o JavaScript. Isso tem um impacto ainda maior nos dispositivos móveis e melhora diretamente o INP para interações adjacentes ao scroll.

Monitoramento das Core Web Vitals

Monitorar suas Core Web Vitals continuamente é essencial para capturar as regressões cedo e validar que as otimizações tiveram o impacto esperado. Use uma combinação de ferramentas de laboratório, dados de campo e monitoramento de usuários reais para obter um quadro completo.

• Verifique o Lighthouse regularmente: O Lighthouse é uma ferramenta de auditoria gratuita e de código aberto do Google que ajuda a identificar problemas de desempenho nas suas páginas da web. Embora o Lighthouse não meça as Core Web Vitals diretamente no contexto de usuários reais, é uma excelente ferramenta para testar e comparar seu site sob condições reguladas e padronizadas periodicamente. Rode o Lighthouse em pipelines CI/CD para pegar 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 utilizada pelo Google para determinar se você passa ou não nas Core Web Vitals. Use os dados históricos para localizar rapidamente as regressões. Você pode acessar os dados do CrUX via PageSpeed Insights, no Painel do CrUX ou pela API CrUX.
• Configure o rastreamento RUM: RUM (Real User Monitoring) envolve o monitoramento de experiências de usuários reais no seu site. As ferramentas de RUM coletam dados sobre quanto tempo as páginas realmente levam para carregar para seus visitantes em diferentes locais e em vários dispositivos. Isso fornece insights valiosos sobre o desempenho do 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.
• Estabeleça orçamentos de desempenho: Orçamentos de desempenho definem alvos específicos (por exemplo, LCP inferior a 2,5 segundos, INP abaixo de 200ms, CLS menor que 0,1) para diferentes métricas. Eles funcionam como benchmarks para orientar seus esforços de otimização. Verificar regularmente seu desempenho comparando-o com esses orçamentos ajuda a identificar áreas que exigem atenção imediata e priorizar melhorias.
• Use a segmentação: Utilize a segmentação para monitorar seus tipos de visitantes mais importantes e os diferentes tipos de página. Grandes volumes de tráfego podem esconder problemas de desempenho que afetam grupos vitais específicos. Segmente por tipo de dispositivo, velocidade da conexão, geografia e template da página para revelar problemas ocultos.

Otimizar o Caminho Crítico de Renderização

O caminho crítico de renderização (critical rendering path) é a sequência de etapas que o navegador realiza para converter HTML, CSS e JavaScript em pixels visíveis. A otimização deste 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 renderizar. Reduza o número de recursos críticos adiando scripts não essenciais e carregando folhas de estilo não críticas de forma assíncrona.
• 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, por último, os scripts com defer. Use o atributo fetchpriority e dicas de priorização de recursos para informar ao navegador o que é mais importante.
• Reduza a profundidade da árvore do DOM: Árvores de DOM com muitos níveis de aninhamento aumentam o tempo de cálculo de estilos e o trabalho de layout. Busque 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 da renderização quanto o atraso de apresentação do INP.
• Prefira classes e IDs em vez de tags e atributos: Em vez de p.important, use .important. Isso diminui a necessidade do navegador procurar em todos os elementos daquele tipo para a correspondência de estilos, o que resulta em um recálculo de estilos mais rápido.
• Evite aninhar seletores profundamente: Quanto mais fundo você aninha os seletores de CSS, mais cálculos o navegador precisa executar. Tente reestruturar o seu HTML para reduzir o aninhamento ou use classes mais específicas mais perto do elemento. Limite a profundidade do seletor a um máximo de 3 níveis.
• Minimize os seletores de descendentes: Seletores como .container > .content forçam o navegador a verificar cada elemento dentro do contêiner. Se for possível, use uma classe mais direta no elemento de conteúdo para que o casamento de seletores seja mais rápido.
• Consolide seletores com os mesmos estilos: Se vários elementos compartilharem os mesmos estilos, agrupe-os em uma única classe ou use a convenção de nomenclatura BEM (Block Element Modifier) para obter melhor capacidade de manutenção e saída de CSS menor.

Otimizar o Consentimento de Cookies

Os banners de consentimento de cookies são exigidos pelo GDPR e regulações similares, mas podem ter um impacto significativo nas Core Web Vitals se não forem implementados com cautela. Um banner de consentimento com carregamento inadequado pode atrasar o LCP, causar CLS e aumentar o INP. Para saber mais detalhes, leia sobre como otimizar widgets de terceiros para as Core Web Vitals.

• Considere o 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 no lado do servidor que exibe o banner de consentimento na resposta HTML inicial geralmente é mais rápido do que carregar uma solução baseada em JavaScript separada. Isso elimina a requisição de rede extra e a sobrecarga de avaliação do script.
• Carregue os scripts de consentimento de cookies de forma assíncrona em páginas em cache: Para páginas com cache, faça o carregamento assíncrono (async) do script de consentimento e considere adicionar fetchpriority="high" para assegurar que ele carregue cedo o suficiente a fim de 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 lugar do elemento LCP, porque o navegador considera o bloco de texto visível maior como um candidato a LCP. Considere escrever textos mais curtos ou dividi-los em vários parágrafos com uma área de visualização menor.
• Auto-hospede scripts de notificação de cookies: Faça cache e auto-hospede scripts e folhas de estilo de notificação de cookies sempre que for possível. Isso elimina pesquisas de DNS e a sobrecarga de conexão para plataformas de gerenciamento de consentimento de terceiros, oferecendo controle total sobre o comportamento do carregamento.

Otimizar Single Page Applications

Single Page Applications (SPAs) construídas com React, Vue, Angular ou frameworks parecidos têm desafios únicos com as Core Web Vitals. A renderização do lado do cliente pode atrasar tanto o FCP quanto o LCP, enquanto a hidratação (hydration) pode bloquear o INP.

• Sempre use a renderização do lado do servidor ou o pré-render: SPAs que se baseiam apenas na renderização do lado do cliente forçam o navegador a baixar, analisar e executar o JavaScript antes que qualquer conteúdo fique visível. Use SSR (Next.js, Nuxt, SvelteKit) ou a pré-renderização estática para fornecer um HTML inicial que o navegador possa pintar de imediato.
• Prefira pré-renderizadores estáticos em vez da geração dinâmica: Os pré-renderizadores estáticos (gerados na fase de build) são consideravelmente mais rápidos do que aqueles criados dinamicamente porque eles podem ser distribuídos diretamente de uma CDN sem nenhum processamento do servidor. Use geração estática em páginas que não exigem dados de requisição individuais.
• Carregue scripts de terceiros após a hidratação (hydration): Durante a hidratação, o framework já está ocupando grande parte do tempo da thread principal para tornar a página interativa. O carregamento de scripts de terceiros ao mesmo tempo agrava o problema e prejudica o input delay. Atrase o carregamento de todos os scripts não essenciais até que o processo de hidratação seja concluído.

Evitar Tamanho Excessivo do DOM

Um DOM gigante (com mais de 1.500 elementos ou com profundidade maior que 32 níveis) aumenta o uso de memória, diminui a velocidade no recálculo de estilo e provoca layouts e reflows custosos. Isso tem efeito direto tanto no atraso de apresentação do INP quanto nas métricas de paint. Veja como resolver o problema de tamanho excessivo do DOM.

• Reduza elementos desnecessários do DOM: Audite o seu HTML atrás de elementos wrappers que não exercem finalidade de estilo ou de estrutura. Substitua as estruturas <div> altamente aninhadas por elementos HTML semânticos. Considere a virtualização de listas maiores com bibliotecas como react-window ou virtual-scroller, de forma a preservar o DOM pequeno.
• Use seletores CSS e JavaScript mais eficientes: A consulta do DOM em JavaScript (como o querySelectorAll) e os seletores em CSS tornam-se consideravelmente mais lentos conforme o tamanho do DOM cresce. Use seletores de classes específicos para que você não fuja do escopo da sua sub-árvore na hora de consultar o DOM, o máximo que você puder.
• Use content-visibility: auto para conteúdos que estão fora da tela: A propriedade CSS content-visibility: auto informa o navegador a pular os elementos que não estão visíveis na tela no processo de pintura do DOM até que a barra de rolagem chegue neles. Isso costuma aliviar severamente a dor de cabeça de renderizar longas seções de conteúdo das páginas pela primeira vez.

Otimizar as 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. O fetching de dados no lado do cliente é uma fonte comum de LCP lento em single page applications.

• Minimize o número de requisições de API: Cada requisição de API adiciona ao 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 (combinar várias requisições em uma) e GraphQL podem reduzir os round trips.
• Use APIs eficientes e otimizadas: O design e a implementação das próprias APIs podem impactar o desempenho. Certifique-se de que você está usando APIs bem projetadas e otimizadas para velocidade e eficiência. Implemente mecanismos de cache no lado da API para reduzir os tempos de resposta de dados frequentemente solicitados.
• Faça o preload de requisições de API críticas: Semelhante ao preload de recursos críticos, como imagens, o preload de requisições essenciais de API pode melhorar significativamente o desempenho percebido. Use <link rel="preload" as="fetch"> para instruir o navegador a buscar APIs críticas antecipadamente, minimizando os atrasos quando elas forem necessárias para renderizar o conteúdo inicial. Veja nosso guia de priorização de recursos para mais técnicas.

Otimizar Widgets de Chat

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

• Carregue widgets de chat depois que o conteúdo principal tiver carregado: Ninguém na história da internet já precisou conversar antes do conteúdo principal da página ter carregado. Atrase a inicialização do widget de chat até que a página tenha finalizado sua renderização inicial, usando requestIdleCallback ou um gatilho baseado em scroll.
• Evite layout shifts causados por widgets de chat: Se os widgets de chat causarem um layout shift, geralmente é uma boa ideia escondê-los com opacity: 0 até que eles tenham sido totalmente renderizados na página. Isso permite que o widget seja desenhado em segundo plano sem fazer com que o conteúdo visível pule. Use uma transição CSS para fazer o widget aparecer suavemente (fade in).
• Escolha provedores de widgets de chat leves: Pesquise bem. Alguns widgets de chat são muito 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 diferentes provedores antes de se comprometer.

Otimizar a Performance do Service Worker

Service workers podem melhorar significativamente o desempenho de visitas recorrentes, armazenando assets em cache e até respostas de páginas inteiras, reduzindo o TTFB para visitantes que retornam. No entanto, um service worker mal implementado pode, na verdade, retardar a navegação. Saiba mais sobre a otimização da duração do cache.

• Faça 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 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 enxuto e eficiente. Evite lógica de roteamento complexa, uso excessivo de event.waitUntil() e manifestos de precache grandes que atrasam a instalação. Use o padrão stale-while-revalidate para recursos que mudam frequentemente, mas não exigem atualização (freshness) imediata.

Otimizar o 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 adequadas. Reduza a resolução do 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 codificação em dois passos (two-pass encoding) para a melhor proporção de qualidade para tamanho do arquivo.
• Use lazy loading para vídeos: Para vídeos abaixo da dobra, use o atributo loading="lazy" nos elementos <iframe> ou atrase o carregamento do vídeo com a API Intersection Observer. Substitua vídeos de fundo com reprodução automática (auto-playing) por imagens de pôster e carregue o vídeo apenas quando o usuário rolar para perto dele.
• Hospede os vídeos em uma CDN rápida: Arquivos de vídeo são grandes e se beneficiam enormemente da distribuição CDN. Use uma CDN de vídeo dedicada ou serviço de hospedagem (como Cloudflare Stream, Mux ou Bunny.net) que fornece adaptive bitrate streaming, distribuição geográfica e entrega otimizada.
• Use imagens de pôster para elementos de vídeo: Sempre defina um atributo poster nos elementos <video>. A imagem de pôster dá ao navegador algo para pintar imediatamente enquanto o vídeo carrega, que pode servir como o elemento LCP. Otimize a imagem de pôster assim como faria com qualquer outra imagem LCP.