O Checklist Definitivo do Core Web Vitals (2026)

Table of Contents!

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

Otimize as Imagens

Imagens grandes na viewport visível, na maioria das vezes, se tornarão o elemento de Largest Contentful Paint. Otimizar as imagens é uma das ações de maior impacto que você pode realizar para o LCP. Use estes itens do checklist do Core Web Vitals para melhorar a velocidade das imagens. Para uma análise profunda, 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 no download de 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 do arquivo da imagem em 50% ou mais sem nenhuma perda visível de qualidade.
• Use lazy loading para imagens abaixo da dobra: O lazy loading atrasa o carregamento de imagens fora da viewport até que elas rolem para a visualização, melhorando o First Contentful Paint (FCP) e a velocidade geral de carregamento da página. Nunca aplique lazy load na imagem de LCP, pois isso a atrasará significativamente.
• Faça preload de imagens visualmente importantes como o elemento de 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 de LCP é referenciada a partir do CSS ou carregada via JavaScript.
• Defina largura e altura: Definir as dimensões da imagem antecipadamente evita mudanças de layout causadas pelo navegador esperando as imagens carregarem. Isso melhora o CLS. Navegadores modernos usam os atributos de largura (width) e altura (height) para calcular a proporção da imagem antes que ela 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 qualidade semelhante, resultando em tempos de carregamento mais rápidos. O WebP normalmente atinge arquivos 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 do navegador.
• Use lazy loading nativo e desative o lazy loading baseado em JavaScript: O lazy loading atrasa o carregamento de imagens fora da viewport até que elas sejam roladas para visualização. O lazy loading nativo oferecido pelos navegadores através do atributo loading="lazy" é geralmente mais eficiente do que depender do 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 o srcset com o atributo sizes para um controle preciso.
• Adicione decoding="async": O atributo decoding="async" impede que o navegador bloqueie outros conteúdos enquanto decodifica uma imagem. Isso permite que o mecanismo de renderização continue pintando 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 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 de LCP: Imagens de fundo referenciadas no CSS são descobertas pelo navegador mais tarde do que os elementos <img> no HTML. Se você precisar usar uma imagem de fundo como elemento de LCP, faça o preload dela com uma tag <link rel="preload"> para garantir a descoberta antecipada. Saiba mais sobre o atraso no carregamento de recursos do LCP.

Otimize as Web Fonts

As web fonts podem atrasar o First Contentful Paint, causar mudanças de layout e competir por recursos de largura de banda iniciais. Use este checklist para garantir uma experiência de web fonts suave. Para as melhores práticas de hospedagem de fontes, consulte nosso guia sobre como hospedar o Google Fonts você mesmo.

• Use font-display: swap para um paint inicial 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 ao carregar a web font em segundo plano. Assim que a fonte estiver pronta, ela a troca perfeitamente. Leia mais sobre como garantir que o texto permaneça visível durante o carregamento da web font.
• Use font-display: optional combinado com preloading para eliminar a mudança de layout causada por fontes: Combinar font-display: optional com preloading oferece um equilíbrio entre velocidade e possíveis mudanças de layout. 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 mais cedo, minimizando o tempo gasto em fontes de fallback e reduzindo as mudanças de layout.
• Use descritores font-face para fazer a fonte de fallback corresponder à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.
• Crie subconjuntos de fontes para incluir apenas os 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 podem ajudar a gerar subconjuntos. Uma fonte com conjunto de caracteres latinos completo pode muitas vezes ser reduzida de 100KB+ para menos de 20KB com a criação de subconjuntos adequados.
• Limite o número de pesos e estilos de fonte: Evite carregar variações excessivas de fonte. Atenha-se a no máximo 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 de tamanho de download.

Otimize os Scripts

Scripts podem causar problemas no Interaction to Next Paint, acionar 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, veja os 14 métodos para adiar o JavaScript.

• Remova 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 guia 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 mudanças na viewport visível devem bloquear a renderização. Scripts importantes devem ser adiados (defer) ou carregados de forma assíncrona (async). Scripts menos importantes devem ser carregados quando o navegador estiver ocioso. Veja nosso guia de priorização de recursos para uma estratégia detalhada.
• Divisão de código (code splitting) e lazy loading: Divida grandes pacotes de JavaScript em partes menores e carregue-os 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 baseada 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 sua necessidade e explore alternativas, se possível. Cada script de terceiros adiciona pesquisas de DNS, sobrecarga de conexão e tempo de processamento na thread principal. Audite os scripts de terceiros regularmente usando o painel Network do Chrome DevTools.
• Carregue scripts de terceiros de forma assíncrona: Por causa da natureza imprevisível dos 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 acompanhar o impacto no mundo real de scripts de terceiros no INP e LCP. Defina orçamentos de desempenho para JavaScript de terceiros e revise-os regularmente.

Otimize os 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 estilo da sua página web. CSS que bloqueia a renderização impacta diretamente tanto o First Contentful Paint quanto o atraso na renderização do elemento de 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ços em branco, comentários e formatação dos arquivos CSS. Arquivos minificados são menores, levando a 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 o código CSS que não é usado nas suas páginas da web. Isso reduz a quantidade de dados que o navegador precisa baixar e analisar, melhorando o desempenho. Ferramentas como PurgeCSS ou a guia Coverage do Chrome DevTools ajudam a identificar CSS não utilizado.
• Faça o inline do CSS crítico: Sirva os 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 ao eliminar a ida e volta necessária 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 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 os Resource Hints

Resource hints (dicas de recursos) ajudam a priorizar downloads de recursos críticos. Recursos com preload costumam entrar na fila de download e ficar disponíveis para o navegador muito antes do que ficariam sem o preload. O uso eficaz de resource hints pode reduzir significativamente o atraso no carregamento de recursos do LCP. Para implementação avançada, leia sobre o 103 Early Hints.

• Remova resource hints não críticos: Remova as dicas de preload de 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 iniciais de largura de banda limitados. Cada preload desnecessário consome largura de banda que poderia ser usada para recursos genuinamente críticos.
• Faça preconnect para domínios críticos: Estabeleça conexões com domínios importantes (como redes de distribuição de conteúdo ou provedores de fontes) desde o início. Isso acelera o download de recursos críticos desses domínios ao concluir antecipadamente os handshakes de DNS, TCP e TLS. 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 dá uma dica ao navegador sobre 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 a sobrecarga da conexão completa do preconnect não se justificar.
• Faça preload do elemento de LCP: O LCP mede quanto tempo o conteúdo principal demora para carregar. Fazer o preload do elemento de LCP instrui o navegador a priorizar o download desse 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 preload das fontes críticas: O preload de fontes críticas garante que o navegador as busque com antecedência, prevenindo atrasos na exibição do texto e melhorando as mudanças de layout (cumulative layout shifts) causadas pela troca de fontes. Use <link rel="preload" as="font" type="font/woff2" crossorigin> para suas tipografias mais importantes.
• Prefira o 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 alternativa. Uma entrega mais cedo de dicas significa uma descoberta mais rápida dos recursos.
• Faça o preload das 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 das 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 mudanças de layout.

Otimize os Ícones

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

• Evite ícones SVG inline em HTML: Inserir (inline) í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 ícones (com cautela) para minimizar o tamanho do HTML e permitir o armazenamento em cache dos ícones no navegador. Um sprite sheet SVG externo geralmente é o melhor equilíbrio entre desempenho e flexibilidade.
• Evite grandes fontes de ícones: Nunca use grandes conjuntos de ícones como o Font Awesome em sua totalidade. 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 completo do Font Awesome pode exceder 100KB, enquanto um subconjunto com 20 ícones pode ter menos de 5KB.
• Reserve largura e altura para os ícones: Semelhante às imagens, especificar a largura e a altura para os ícones ajuda o navegador a reservar espaço e previne mudanças de layout enquanto eles carregam. Use os atributos width e height em elementos SVG ou defina dimensões explícitas no CSS.
• Despriorize conjuntos de ícones não críticos: Se os ícones não são 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 do Core Web Vitals. Use lazy loading ou carregue as folhas de estilo dos ícones assincronamente após o primeiro paint.

Otimize 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 paint. 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 a 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, e não alegações de marketing baseadas em dados sintéticos.
• Otimize o código do lado do servidor e as consultas de banco de dados: Registre frequentemente (log) o tempo de execução do código e o tempo de consulta ao banco de dados para encontrar gargalos e melhorar a velocidade geral. Use ferramentas de criação de perfil de consulta e de monitoramento de desempenho de aplicativos (APM) para identificar endpoints lentos.
• Implemente estratégias de cache: Utilize cache no navegador e cache no lado do servidor 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 completa pode reduzir o TTFB de segundos para menos de 100ms. Saiba mais sobre otimização de duração do cache.
• Renderização do lado do cliente ou de borda para personalização: Considere a renderização do lado do cliente ou na borda (edge rendering) para pequenas personalizações, como contagem de carrinho, status de login ou pequenas alterações no menu, a fim de manter a funcionalidade do cache da página completa. Isso evita quebrar o cache de toda a página por conta de pequenos elementos dinâmicos.
• Otimize as configurações do servidor: Revise e ajuste as configurações do seu servidor web para desempenho. Isso inclui as configurações de keep-alive de conexões, contagens de processos de trabalho (workers), alocação de memória e valores de tempo limite (timeout). Servidores mal configurados podem desperdiçar recursos e aumentar os tempos de resposta.
• Use uma Rede de Distribuição de Conteúdo (CDN): Uma CDN distribui o conteúdo estático do seu site por vários nós de borda (servidores). Isso reduz a distância física que os usuários precisam percorrer para acessar seu conteúdo, levando a tempos de carregamento mais rápidos para o público global. Além disso, CDNs são geralmente mais bem configuradas do que o seu próprio servidor. Veja nosso guia sobre como configurar a Cloudflare para um passo a passo prático de configuração.
• Reduza o processamento no lado do servidor: Minimize a quantidade de trabalho que o seu servidor realiza por requisição. Pré-calcule operações custosas, use algoritmos eficientes e mova o processamento não essencial para processos (jobs) em segundo plano. Analise o ciclo de vida das requisições 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 mais 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 do Core Web Vitals (LCP, INP, CLS). Saiba 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 as diferentes partes de sua página levam para serem processadas no servidor. Com esses dados, você pode localizar gargalos e áreas para melhoria, concentrando-se especificamente em melhorar o Largest Contentful Paint (LCP). Cabeçalhos Server-Timing são visíveis no painel Network do Chrome DevTools e podem ser capturados por ferramentas RUM como CoreDash.
• Registre consultas lentas no banco de dados e otimize-as regularmente: Habilite os registros de consultas lentas no seu banco de dados (MySQL, PostgreSQL, MongoDB) e as analise semanalmente. A otimização de índice, 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 novo 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. O Brotli normalmente alcança de 15 a 20% mais compressão que o GZIP. Tamanhos de arquivo menores se traduzem em tempos de carregamento mais rápidos.

Otimize a Interatividade

O Interaction to Next Paint (INP) mede quão rápido seu site responde às interações do usuário. Interatividade deficiente é frequentemente causada por tarefas JavaScript de longa duração que bloqueiam a thread principal. Para uma análise completa das três fases do INP, veja nossos guias sobre atraso de entrada (input delay), tempo de processamento (processing time) e atraso de apresentação (presentation delay).

• Implemente um padrão idle-until-urgent para scripts custosos: Esta 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 de longa duração. Use requestIdleCallback para agendar trabalho não urgente. Saiba mais sobre como otimizar o tempo de processamento.
• Divida tarefas longas cedendo controle para a thread principal: Tarefas JavaScript complexas podem bloquear a thread principal, atrasando a capacidade de resposta. Dividir essas tarefas em partes menores e ceder o controle de volta à thread principal entre as partes permite que o navegador lide com as interações do usuário e mantenha uma experiência de usuário suave. Use scheduler.yield() (onde for suportado) ou setTimeout(0) para dividir tarefas longas. Veja nosso guia sobre como melhorar o INP abandonando a rolagem (scrolling) via JavaScript.
• Forneça feedback imediato após a entrada do usuário: Os usuários esperam capacidade de resposta imediata após interagir com seu site. Forneça dicas visuais ou reconheça a entrada do usuário prontamente, mesmo enquanto tarefas longas são processadas em segundo plano. Use transições CSS e a pseudoclasse :active para obter um feedback visual instantâneo. Isso ajuda a manter um senso de interatividade e impede que os usuários sintam que o site está congelado.
• Use passive event listeners para scroll e touch: Adicione { passive: true } aos seus event listeners (ouvintes de eventos) de scroll e touch. Ouvintes passivos avisam ao navegador que o handler nunca chamará preventDefault(), permitindo que ele inicie a rolagem imediatamente sem esperar pelo JavaScript. Isso é especialmente impactante em dispositivos móveis e melhora diretamente o INP para interações relacionadas à rolagem.

Monitoramento do Core Web Vitals

Monitorar o seu Core Web Vitals continuamente é essencial para perceber regressões logo no início e validar que as otimizações tiveram o impacto esperado. Use uma combinação de ferramentas de laboratório (lab data), dados de campo (field data) e monitoramento de usuários reais (RUM) para ter uma visão completa.

• 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 o Core Web Vitals diretamente em um contexto de usuário real, é uma ótima ferramenta para testar e comparar seu site periodicamente sob condições regulamentadas e padronizadas. Execute o Lighthouse nas pipelines de CI/CD para detectar regressões antes da implantação.
• Verifique os dados históricos do CrUX regularmente: 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 usada pelo Google para determinar se você passa ou não no Core Web Vitals. Use os dados históricos para detectar regressões rapidamente. Você pode acessar dados do CrUX por meio do PageSpeed Insights, do CrUX Dashboard ou da API do CrUX.
• Configure o rastreamento RUM: RUM (Real User Monitoring) envolve o rastreamento das experiências de usuários reais no seu site. Ferramentas RUM coletam dados sobre quanto tempo as páginas demoram para carregar para os seus visitantes em diferentes locais e em vários dispositivos. Isso fornece valiosos insights sobre o desempenho no mundo real, complementando os dados simulados do Lighthouse e CrUX. Nós recomendamos o CoreDash como a sua ferramenta de rastreamento RUM para obter dados detalhados de atribuição do Core Web Vitals.
• Defina orçamentos de desempenho: Orçamentos de desempenho definem alvos específicos (por exemplo, LCP abaixo de 2,5 segundos, INP abaixo de 200ms, CLS abaixo de 0,1) para diferentes métricas. Eles agem como referências para orientar os seus esforços de otimização. Verificar o seu desempenho regularmente em relação a esses orçamentos ajuda a identificar áreas que precisam de atenção imediata e a priorizar as otimizações.
• Use segmentação: Use a segmentação para rastrear os seus tipos de visitantes mais valiosos e diferentes tipos de página. Do contrário, um volume maior de tráfego pode mascarar problemas de desempenho que afetam especificamente esses grupos vitais. Segmente por tipo de dispositivo, velocidade da conexão, geografia e template da página para descobrir problemas ocultos.

Otimize o Caminho Crítico de Renderização

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

• 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: Garanta que o CSS crítico e as fontes carreguem primeiro, seguidos pelas imagens acima da dobra e depois os scripts adiados. Use o atributo fetchpriority e dicas de priorização de recursos para comunicar a 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 o trabalho de layout. Tente manter uma profundidade máxima de 32 níveis e menos de 1.500 elementos do DOM no total, sempre que possível. Uma estrutura do DOM mais plana melhora o desempenho da pintura (paint) e diminui o atraso de apresentação do INP.
• Dê preferência a classes e IDs em vez de tags de elementos e atributos: Em vez de p.important, use .important. Isso reduz a necessidade de o navegador procurar por todos os elementos daquele tipo para combinar os estilos, resultando em recalculo de estilo mais rápido.
• Evite aninhar seletores profundamente: Quanto mais fundo você aninha seletores CSS, mais cálculos o navegador precisa fazer. Tente reestruturar o seu HTML para reduzir o aninhamento ou use classes mais específicas próximas ao elemento. Limite a profundidade dos seletores em 3 níveis no máximo.
• Minimize os seletores descendentes: Seletores como .container > .content forçam o navegador a checar cada elemento dentro do container. Se possível, use uma classe mais direta no elemento de conteúdo para que a combinação com o seletor seja mais rápida.
• Consolide seletores com os mesmos estilos: Se vários elementos compartilham os mesmos estilos, agrupe-os em uma única classe ou use a convenção de nomenclatura BEM (Block Element Modifier) para obter melhor manutenibilidade e uma saída de CSS menor.

Otimize o Consentimento de Cookies

Banners de consentimento de cookies são exigidos pelo GDPR e por regulamentações similares, mas eles podem ter um grande impacto no Core Web Vitals se não forem implementados cuidadosamente. Um banner de consentimento carregado de forma ineficiente pode atrasar o LCP, causar CLS e aumentar o INP. Para mais detalhes, leia sobre como otimizar widgets de terceiros para o 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 renderize o banner de consentimento na resposta HTML inicial geralmente é mais rápido que carregar uma solução separada baseada em JavaScript. Isso elimina a requisição de rede extra e a sobrecarga de avaliação do script.
• Carregue scripts de consentimento de cookies de forma assíncrona em páginas em cache: Para páginas em cache, carregue o script de consentimento de forma assíncrona 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 do consentimento curto para evitar interferência no LCP: Textos longos em avisos de cookies podem assumir o lugar do elemento de LCP porque o navegador considera o maior bloco de texto visível como um potencial candidato a LCP. Considere escrever textos mais curtos ou dividir os textos em vários parágrafos com área visível menor.
• Hospede você mesmo (self-host) os scripts de notificação de cookies: Faça cache e hospede os scripts e folhas de estilo de notificação de cookies sempre que possível. Isso elimina pesquisas de DNS e a sobrecarga de conexão com plataformas de gerenciamento de consentimento de terceiros, dando a você controle total sobre o comportamento de carregamento.

Otimize Single Page Applications

Single Page Applications (SPAs) desenvolvidas com React, Vue, Angular ou frameworks similares enfrentam desafios únicos com o Core Web Vitals. A renderização no lado do cliente pode atrasar tanto o FCP quanto o LCP, enquanto a hidratação pode bloquear o INP.

• Sempre use renderização no lado do servidor ou prerendering: SPAs que dependem somente da renderização no 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 prerendering estático para servir um HTML inicial que o navegador possa renderizar imediatamente.
• Prefira prerenders estáticos em vez de geração dinâmica: Os prerenders estáticos (gerados no momento da compilação - build time) são muito mais rápidos que os prerenders gerados dinamicamente porque podem ser servidos diretamente de uma CDN sem qualquer processamento no servidor. Use a geração estática para páginas que não precisam de dados por requisição.
• Carregue scripts de terceiros após a hidratação: Durante a hidratação, o framework já está consumindo um tempo significativo da thread principal para tornar a página interativa. Carregar scripts de terceiros simultaneamente agrava o problema e piora o atraso de entrada (input delay). Adie todos os scripts não essenciais até que o processo de hidratação seja concluído.

Evite Tamanho Excessivo do DOM

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

• Reduza elementos do DOM desnecessários: Audite o seu HTML em busca de elementos de encapsulamento (wrappers) que não tem propósito estrutural ou de estilo. Substitua estruturas <div> profundamente aninhadas por elementos HTML semânticos. Considere usar virtualização para listas longas usando bibliotecas como react-window ou virtual-scroller para manter o DOM ativo pequeno.
• Use seletores de CSS e JavaScript eficientes: Seletores CSS complexos e consultas DOM no JavaScript (como querySelectorAll com padrões amplos) se tornam exponencialmente mais lentos à medida que o tamanho do DOM cresce. Use seletores de classe específicos e limite o escopo de consultas ao DOM para subárvores sempre que possível.
• Use content-visibility: auto para conteúdo fora da tela: A propriedade CSS content-visibility: auto diz ao navegador para pular a renderização de elementos fora da tela até que eles rolem para a visualização. Isso pode reduzir drasticamente o trabalho de renderização inicial para páginas com longas seções de conteúdo.

Otimize as Requisições de API

Requisições de API que bloqueiam a renderização ou atrasam o conteúdo podem afetar negativamente o LCP e o TTFB. A busca 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 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 agrupamento em lote de dados (combinar múltiplas requisições em uma) e GraphQL podem reduzir o número de idas e vindas.
• Use APIs eficientes e otimizadas: O design e a implementação das APIs em si podem impactar a performance. Assegure-se de que você esteja usando APIs bem projetadas e otimizadas para velocidade e eficiência. Implemente mecanismos de cache no lado da API para reduzir tempos de resposta para dados solicitados frequentemente.
• Faça preload nas requisições de API críticas: Semelhante ao preloading de recursos críticos como imagens, o preloading 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. Veja nosso guia de priorização de recursos para mais técnicas.

Otimize os Widgets de Chat

Widgets de chat são uma causa comum de mudanças de layout 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 um Core Web Vitals perfeito.

• Carregue widgets de chat depois que o conteúdo principal for carregado: Ninguém na história da internet jamais precisou conversar antes que o conteúdo principal da página estivesse carregado. Adie a inicialização do widget de chat até que a página tenha terminado sua renderização inicial, usando requestIdleCallback ou um gatilho baseado em rolagem.
• Evite as mudanças de layout provocadas por widgets de chat: Se os widgets de chat causam uma mudança de layout, geralmente é uma boa ideia ocultá-los com opacity: 0 até que tenham sido totalmente renderizados na página. Isso permite que o widget se organize em segundo plano sem fazer com que o conteúdo visível pule. Use uma transição CSS para fazer o widget aparecer (fade in) de forma suave.
• Escolha provedores de widget 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 pacote JavaScript, o número de requisições de rede e o impacto no INP de diferentes provedores antes de se comprometer.

Otimize o Desempenho do Service Worker

Service workers podem melhorar significativamente o desempenho para visitantes recorrentes, fazendo o cache de assets e até de respostas completas da página, reduzindo o TTFB para visitantes que retornam. No entanto, um service worker mal implementado pode até diminuir a velocidade de navegação. Saiba mais sobre otimização de duração de 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 o 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 complexa de roteamento, o uso excessivo de event.waitUntil() e manifests grandes de precache que atrasam a instalação. Use o padrão stale-while-revalidate para recursos que mudam frequentemente mas não exigem atualização imediata.

Otimize o Conteúdo em Vídeo

Elementos de vídeo podem se tornar o elemento de LCP se 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 a codificação em duas passagens (two-pass encoding) para obter a melhor proporção entre qualidade e 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 que reproduzem automaticamente por imagens de poster e carregue o vídeo somente quando o usuário rolar para 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 dedicada a vídeo ou um serviço de hospedagem (como Cloudflare Stream, Mux ou Bunny.net) que forneça streaming com taxa de bits adaptável, distribuição geográfica e entrega otimizada.
• Use imagens de poster para elementos de vídeo: Sempre defina um atributo poster em elementos <video>. A imagem do poster dá ao navegador algo para pintar imediatamente enquanto o vídeo carrega, o que pode servir como elemento de LCP. Otimize a imagem do poster da mesma forma que qualquer outra imagem de LCP.