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

Otimize Imagens

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

• Redimensione as imagens para corresponderem às maiores dimensões na tela: Isso garante que nenhum byte seja desperdiçado baixando imagens maiores que seu tamanho máximo em tela. Combine esta prática com imagens responsivas em telas menores. Servir imagens no tamanho correto pode reduzir o tamanho do arquivo em 50% ou mais sem perda visível de qualidade.
• Use lazy loading para imagens abaixo da dobra: O lazy loading atrasa o carregamento das imagens fora do viewport até o usuário rolar a tela até elas. Isso melhora o First Contentful Paint (FCP) e a velocidade geral de carregamento da página. Nunca faça lazy loading na imagem do LCP. Isso atrasará o carregamento dela significativamente.
• Faça o preload de imagens visualmente importantes, como o elemento do LCP: O preload instrui o navegador a buscar imagens críticas antes do resto do conteúdo, priorizando o LCP. Use <link rel="preload" as="image"> combinado com fetchpriority="high" para obter os melhores resultados. Isso é muito importante quando a imagem do LCP é referenciada no CSS ou carregada via JavaScript.
• Defina width e height: Definir as dimensões da imagem antecipadamente evita os layout shifts causados pelo navegador esperando as imagens carregarem. Isso melhora o CLS. Navegadores modernos usam os atributos width e height para calcular a proporção da imagem antes dela carregar, reservando a quantidade correta de espaço.
• Use formatos modernos de imagem como WebP ou AVIF: Estes formatos oferecem tamanhos de arquivo menores que JPEG ou PNG mantendo qualidade similar. Isso resulta em tempos de carregamento mais rápidos. O WebP geralmente atinge arquivos de 25% a 34% menores que o JPEG. O AVIF pode reduzir o tamanho do arquivo em até 50%. Use o elemento <picture> com fallbacks de formato para compatibilidade máxima do navegador.
• Use lazy loading nativo e desative o lazy loading via JavaScript: O lazy loading atrasa o carregamento das imagens fora do viewport até o usuário rolar a tela até elas. O lazy loading nativo oferecido pelos navegadores via atributo loading="lazy" é geralmente mais eficiente que depender do JavaScript para esta tarefa. Ele não exige parse 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. Ele garante 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 a engine de renderização continue pintando outros elementos enquanto a decodificação da imagem ocorre em paralelo.
• Remova os metadados das imagens: Metadados como dados EXIF embutidos nas imagens podem adicionar bytes desnecessários. Remover essa informação reduz o tamanho do arquivo sem afetar a qualidade da imagem. Ferramentas como ImageOptim, Squoosh ou Sharp podem automatizar a remoção de metadados no seu processo de build.
• Evite background images no CSS para elementos do LCP: Background images referenciadas no CSS são descobertas pelo navegador depois dos elementos <img> no HTML. Se você precisar usar uma background image como o elemento do LCP, faça o preload dela com a tag <link rel="preload"> para garantir sua 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 banda nos momentos iniciais. Use este checklist para garantir uma experiência fluida com web fonts. Para as melhores práticas de hospedagem de fontes, consulte nosso guia sobre como fazer self-host de Google Fonts.

• Use font-display: swap para um first paint mais rápido: Defina a propriedade font-display como swap nas suas declarações de @font-face. Isso garante que o navegador exiba uma fonte de fallback imediatamente enquanto carrega a web font em segundo plano. Quando a fonte estiver pronta, ele faz a troca de forma limpa. Leia mais sobre como garantir que o texto fique visível durante o carregamento da webfont.
• Use font-display: optional combinado com preloading para eliminar layout shifts causados por fontes: Combinar font-display: optional com o 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 a fonte de fallback. O preload instrui o navegador a buscar a web font antecipadamente, minimizando o tempo gasto em fontes de fallback e reduzindo layout shifts.
• Use descritores de font-face para igualar as dimensões da fonte de fallback às da web font: Isso garante um CLS mínimo quando a web font for trocada. Ao especificar métricas similares usando size-adjust, ascent-override, descent-override e line-gap-override na fonte de fallback, você impede que o conteúdo pule enquanto a fonte carrega.
• Crie subsets das fontes para incluir apenas os caracteres necessários: Reduza o tamanho do arquivo da fonte gerando subsets com apenas os caracteres usados no seu conteúdo. Ferramentas como Font Squirrel, pyftsubset ou glyphhanger ajudam a gerar subsets. Uma fonte completa com caracteres latinos frequentemente cai de mais de 100KB para menos de 20KB com o subsetting adequado.
• Limite o número de pesos e estilos de fonte: Evite carregar variações de fonte em excesso. Mantenha no máximo 2 fontes críticas (geralmente via preload) e 2 fontes de carregamento tardio (carregadas após o render inicial). Cada peso de fonte extra adiciona de 15 a 50KB ao tamanho do download.

Otimize 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 pintura (LCP e FCP). Para um guia completo, veja 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 no Chrome DevTools para encontrar código sem uso. Remover 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 usar defer ou carregar via 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 grandes bundles 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 baseado em imports dinâmicos.
• Minifique e recompile arquivos JavaScript: Sempre minifique e recompile seus arquivos JavaScript com uma ferramenta de minificação como o SWC, Terser ou esbuild. A minificação normalmente reduz o tamanho do arquivo JavaScript em 30% a 50%.
• Limite scripts de terceiros: Scripts de terceiros adicionam um overhead significativo de performance. Avalie sua necessidade e explore alternativas, se possível. Cada script de terceiros adiciona consultas de DNS, overhead de conexão e tempo de processamento na main thread. Audite os scripts de terceiros regularmente 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 eles bloqueiem a renderização. Use o atributo async ou defer em todas as tags de script de terceiros.
• Monitore a performance de scripts de terceiros: Use a API de Long Animation Frames (LoAF) ou o CoreDash para rastrear o impacto real dos scripts de terceiros no INP e no LCP. Defina performance budgets para o JavaScript de terceiros e revise-os regularmente.

Otimize Estilos

Estilos são render blocking por padrão. Otimizar os estilos resulta em métricas de pintura otimizadas. Siga este checklist para melhorar a performance de estilos da sua página. O CSS render blocking impacta diretamente o First Contentful Paint e o LCP element render delay. Para dicas sobre como limpar estilos sem uso, veja como remover CSS não utilizado.

• Minifique arquivos CSS: Remova caracteres desnecessários como espaços em branco, comentários e formatações dos arquivos CSS. Arquivos minificados são menores, resultando em tempos de carregamento mais rápidos. Ferramentas como cssnano, PostCSS ou a compressão nativa do seu pré-processador CSS podem automatizar isso.
• Remova CSS não utilizado: Identifique e elimine código CSS que não é usado nas suas páginas web. Isso reduz a quantidade de dados que o navegador precisa baixar e processar, melhorando a performance. Ferramentas como PurgeCSS ou a aba Coverage no Chrome DevTools ajudam a identificar o 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 pintura. Considere servir o CSS crítico apenas para novos visitantes e usar stylesheets externos cacheados para visitantes recorrentes. Essa técnica pode reduzir o FCP eliminando o round trip necessário para buscar um stylesheet externo.
• Distribua os tamanhos dos arquivos CSS de forma igual: Pode parecer eficiente combinar todo o CSS em um único arquivo, mas arquivos excessivamente grandes podem atrasar os downloads. 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.
• Faça o carregamento assíncrono de estilos offscreen: Para estilos aplicados a elementos fora do viewport inicial, considere usar o carregamento assíncrono via padrão media="print" onload="this.media='all'". Isso permite que o navegador busque esses estilos em paralelo com outros recursos sem bloquear o render inicial da página.

Otimize os Resource Hints

Os resource hints ajudam a priorizar os downloads de recursos críticos. Recursos com preload entram na fila de download e ficam disponíveis para o navegador muito antes. O uso eficaz de resource hints reduz bastante o LCP resource load delay. Para uma implementação avançada, leia sobre 103 Early Hints.

• Remova resource hints não críticos: Remova hints de preload de recursos que não são essenciais para o carregamento inicial da página. Isso evita downloads e conexões de rede desnecessárias que competem por recursos iniciais limitados de banda. Cada preload desnecessário consome banda que poderia ser usada em recursos críticos.
• Use preconnect para domínios críticos: Estabeleça conexões com domínios importantes (como CDNs ou provedores de fontes) desde cedo. Isso acelera o download de recursos críticos desses domínios completando os handshakes de DNS, TCP e TLS com antecedência. Use <link rel="preconnect" href="https://example.com"> em origens críticas de terceiros.
• Considere o DNS prefetch como alternativa ao preconnect: Semelhante ao preconnect, o DNS prefetch sugere possíveis conexões ao navegador. O preconnect prioriza estabelecer a conexão completa, mas o DNS prefetch apenas diz ao navegador para resolver o nome do domínio antecipadamente. Use <link rel="dns-prefetch"> quando o custo da conexão completa do preconnect não se justificar.
• Faça o preload do elemento do LCP: O LCP mede o tempo de carregamento do conteúdo principal. O preload do elemento do LCP instrui o navegador a priorizar o download desse recurso crítico, acelerando o tempo para os usuários verem o conteúdo principal. Isso é muito importante para imagens referenciadas no CSS ou carregadas via JavaScript.
• Faça o preload de fontes críticas: O preload de fontes críticas garante que o navegador as busque com antecedência, evitando atrasos na exibição de texto e melhorando os cumulative layout shifts causados pela troca de fonte. Use <link rel="preload" as="font" type="font/woff2" crossorigin> para as suas tipografias mais importantes.
• Prefira os 103 Early Hints para os resource hints: O código de status HTTP 103 Early Hints permite que o servidor envie resource hints antes da resposta completa estar pronta. Se o seu servidor não suportar o código 103, use os cabeçalhos de resposta Link. Se os cabeçalhos não estiverem disponíveis, adicione elementos <link> no <head> da página como um fallback. A entrega antecipada de hints resulta em descoberta mais rápida de recursos.
• Faça o preload das fontes antes de serem descobertas pelos arquivos CSS: Fontes referenciadas no CSS só são descobertas depois que o arquivo CSS é baixado e processado. Ao fazer o preload das fontes diretamente no <head> do HTML, você elimina a dependência do parse do CSS e permite carregar as fontes em paralelo, reduzindo o FCP e o risco de layout shift.

Otimize Ícones

Ícones podem adicionar um peso considerável à sua página se não forem otimizados. Ícones grandes em SVG inline inflam o seu HTML. Fontes de ícones geralmente incluem milhares de glifos não utilizados. Otimizar ícones impacta tanto o LCP (menor peso no HTML e CSS) quanto o CLS (reserva correta de dimensões).

• Evite ícones SVG inline no HTML: Colocar ícones SVG grandes inline pode aumentar o tamanho do seu HTML e atrasar o carregamento da página. Considere métodos alternativos. Sirva-os como arquivos separados ou use fontes de ícones (com cautela) para minimizar o HTML e permitir o cache dos ícones pelo navegador. Um sprite sheet SVG externo geralmente é o melhor equilíbrio entre performance e flexibilidade.
• Evite fontes de ícones grandes: Nunca use conjuntos grandes como o Font Awesome inteiros. Crie subsets para gerar fontes de ícones otimizadas ou use SVGs individuais. Isso reduz o tamanho geral da página e melhora a velocidade de carregamento. O conjunto completo do Font Awesome pode passar de 100KB, mas um subset com 20 ícones pode ter menos de 5KB.
• Reserve width e height para os ícones: Assim como nas imagens, especificar width e height nos ícones ajuda o navegador a reservar espaço e evita os layout shifts durante o carregamento. Use os atributos width e height nos elementos SVG ou defina dimensões explícitas no CSS.
• Tire a prioridade de conjuntos de ícones não críticos: Se os ícones não são críticos para a renderização inicial da página, carregue-os com menor prioridade. 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 os stylesheets dos ícones de forma assíncrona após o initial 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 pintura. Uma resposta lenta do servidor atrasa tudo que vem depois. Para estratégias detalhadas, explore nossos guias sobre como diagnosticar problemas de TTFB e como configurar o Cloudflare para performance.

• Use um provedor de hospedagem rápido e confiável: Um provedor rápido e com infraestrutura forte pode melhorar muito o tempo de resposta do servidor e a performance geral do site. Faça o benchmark dos provedores usando medições reais de TTFB, não alegações sintéticas de marketing.
• Otimize o código server-side e as consultas ao banco de dados: Registre frequentemente os tempos de execução do código e das consultas no banco para achar gargalos e melhorar a velocidade geral. Use ferramentas de query profiling e Application Performance Monitoring (APM) para identificar endpoints lentos.
• Implemente estratégias de cache: Use cache de navegador e cache no servidor para guardar dados acessados com frequência, reduzindo o resgate repetido de dados e melhorando os tempos de carregamento. O cache full-page pode reduzir o TTFB de segundos para menos de 100ms. Leia mais sobre como otimizar a duração do cache.
• Renderização client-side ou no edge para personalizações: Considere usar client-side ou edge rendering para pequenas personalizações. Exemplos incluem contagem no carrinho, status de login ou alterações menores no menu. Isso mantém a funcionalidade do cache full-page ativa e evita quebrar o cache da página inteira por causa de elementos dinâmicos pequenos.
• Otimize as configurações do servidor: Revise e ajuste as configurações do seu servidor web para priorizar performance. Isso inclui ajustes de keep-alive na conexão, contagem de processos worker, alocação de memória e valores de timeout. Servidores mal configurados desperdiçam recursos e aumentam os tempos de resposta.
• Use uma Content Delivery Network (CDN): Uma CDN distribui o conteúdo estático do seu site por vários edge nodes (servidores). Isso reduz a distância física que os usuários percorrem para acessar seu conteúdo, trazendo tempos de carregamento mais rápidos para visitantes globais. Além disso, as CDNs geralmente são melhor configuradas que seu próprio servidor. Veja nosso guia sobre como configurar o Cloudflare para um passo a passo prático.
• Reduza o processamento no servidor: Minimize a quantidade de trabalho que seu servidor faz a cada requisição. Pré-calcule operações custosas, use algoritmos eficientes e mova o processamento não essencial para background jobs. Analise o ciclo de vida das requisições na sua aplicação para achar e eliminar etapas de processamento desnecessárias.
• Use HTTP/3: O HTTP/3 é a versão mais recente do Hypertext Transfer Protocol. O HTTP/3 é mais rápido e mais eficiente que o HTTP/2 e muito mais rápido que o HTTP/1.1. Atualizar para o HTTP/3 pode melhorar o tempo de carregamento geral da página e potencialmente todas as três métricas do Core Web Vitals (LCP, INP, CLS). Leia mais sobre otimização da duração da conexão.
• Configure cabeçalhos Server-Timing: Estes cabeçalhos fornecem informações detalhadas sobre quanto tempo diferentes partes da sua página levam para processar no servidor. Com esses dados, você pode identificar gargalos e áreas para melhoria, com foco específico na melhoria do Largest Contentful Paint (LCP). Cabeçalhos Server-Timing ficam visíveis no painel Network do Chrome DevTools e podem ser capturados por ferramentas RUM como o CoreDash.
• Registre as consultas lentas no banco de dados e as otimize regularmente: Ative o log de consultas lentas no seu banco (MySQL, PostgreSQL, MongoDB) e revise-os semanalmente. Otimização de índices, reestruturação de consultas e adição de camadas de cache para consultas frequentes reduzem o TTFB drasticamente.
• Use compressão GZIP ou Brotli: O GZIP, ou o mais recente Brotli, oferece compressão on the fly para recursos de texto (HTML, CSS, JavaScript) antes da transmissão, reduzindo o tamanho do arquivo em cerca de 70%. O Brotli geralmente atinge de 15% a 20% mais compressão que o GZIP. Arquivos menores significam 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 geralmente é causada por long tasks no JavaScript. Elas 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 o padrão idle-until-urgent para scripts pesados: Essa abordagem prioriza tarefas críticas e adia a execução do JavaScript não essencial até que a main thread fique ociosa. Isso garante que tarefas críticas como renderização e interações do usuário não sejam bloqueadas por long tasks. Use requestIdleCallback para agendar trabalhos não urgentes. Leia mais sobre como otimizar o processing time.
• Quebre long tasks fazendo yield para a main thread: Tarefas complexas no JavaScript bloqueiam a main thread e atrasam a responsividade. Divida essas tarefas em partes menores. Faça o yield de volta à main thread entre elas. Isso permite que o navegador lide com as interações e mantenha uma experiência fluida. Use scheduler.yield() (onde suportado) ou setTimeout(0) para quebrar long tasks. Veja nosso guia sobre como melhorar o INP descartando o scroll em JavaScript.
• Forneça feedback imediato após o input: Os usuários esperam respostas imediatas ao interagir com o site. Forneça pistas visuais ou reconheça o input prontamente, mesmo durante o processamento de long tasks em segundo plano. Use transições CSS e a pseudo-classe :active para dar feedback visual instantâneo. Isso ajuda a manter o senso de interatividade e impede a sensação de site congelado.
• Use passive event listeners para scroll e touch: Adicione { passive: true } aos seus event listeners de scroll e touch. Listeners passivos dizem ao navegador que o handler nunca chamará preventDefault(), permitindo o scroll imediato, sem esperar pelo JavaScript. O impacto é enorme no mobile e melhora o INP diretamente nas interações próximas da rolagem.

Monitoramento do Core Web Vitals

Monitorar seu Core Web Vitals continuamente é essencial. Isso captura regressões desde cedo. Ajuda também a validar o impacto esperado de cada otimização. Use uma combinação de lab tools, field data e Real User Monitoring para ter uma visão completa.

• Verifique o Lighthouse regularmente: O Lighthouse é uma ferramenta de auditoria gratuita e de código aberto do Google. Ele identifica problemas de performance na sua página. O Lighthouse não mede o Core Web Vitals com usuários reais, mas é uma ótima ferramenta para testes periódicos. Ele compara seu site em condições reguladas e padronizadas. Execute o Lighthouse em pipelines de CI/CD para pegar regressões antes do deploy.
• Verifique os dados históricos do CrUX regularmente: O CrUX (Chrome User Experience Report) é um dataset público do Google. Ele fornece dados reais de performance. O CrUX é a fonte de dados que o Google usa para avaliar se você passa no Core Web Vitals. Use os dados históricos para localizar regressões de forma rápida. Você pode acessar os dados do CrUX via PageSpeed Insights, Dashboard do CrUX ou API do CrUX.
• Configure o RUM tracking: O RUM (Real User Monitoring) rastreia a experiência de usuários reais no seu site. Ferramentas de RUM coletam o tempo real de carregamento para visitantes de diversos locais e dispositivos. Isso fornece dados valiosos de performance no mundo real e complementa os dados simulados do Lighthouse e do CrUX. Recomendamos o CoreDash como sua ferramenta de RUM para dados detalhados de atribuição do Core Web Vitals.
• Defina performance budgets: Performance budgets impõem metas específicas. Por exemplo, limite o LCP a 2,5 segundos, o INP a 200ms e o CLS a 0,1 para diferentes métricas. Esses números agem como benchmarks e guiam as suas otimizações. Cheque sua performance contra esses budgets regularmente. Isso identifica as áreas com necessidade de atenção imediata e ajuda na priorização.
• Use segmentação: Use segmentação para rastrear os seus visitantes mais valiosos e tipos diferentes de página. Uma grande quantidade de tráfego pode mascarar problemas de performance nestes grupos vitais. Segmente por dispositivo, velocidade da conexão, geografia e template de página. Assim, você revela problemas ocultos.

Otimize o Critical Rendering Path

O critical rendering path é a sequência de passos que o navegador realiza para converter o HTML, CSS e JavaScript em pixels visíveis. Otimizar esse caminho melhora o First Contentful Paint e o LCP element render delay. Veja também como consertar um 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 de o navegador pintar a tela. Reduza a quantidade de recursos críticos adiando scripts não essenciais. Faça também o carregamento assíncrono para stylesheets não críticos.
• Otimize a ordem de carregamento dos recursos: Garanta que o CSS crítico e as fontes carreguem primeiro. Eles devem ser seguidos pelas imagens acima da dobra e, por último, os scripts com defer. Use o atributo fetchpriority e resource prioritization hints para comunicar a importância ao navegador.
• Reduza a profundidade da árvore do DOM: Árvores de DOM muito profundas 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 no total, se possível. Uma estrutura de DOM plana melhora a performance de pintura e o presentation delay do INP.
• Prefira classes e IDs em vez de tags e atributos: Em vez de p.important, use .important. Isso reduz a busca do navegador em todos os elementos daquele tipo. O recálculo de estilos será muito mais rápido.
• Evite seletores aninhados profundos: Quanto mais você aninha os seletores CSS, mais cálculos o navegador fará. Reestruture seu HTML para diminuir os aninhamentos. Use classes mais específicas perto do elemento. Limite a profundidade do seletor a um máximo de 3 níveis.
• Minimize seletores descendentes: Seletores como .container > .content forçam o navegador a checar cada elemento do container. Sempre que possível, use uma classe direta no elemento de conteúdo. Isso acelera o processamento do seletor.
• Consolide seletores com os mesmos estilos: Se vários elementos compartilham os mesmos estilos, agrupe-os em uma única classe. Use convenções como BEM (Block Element Modifier) para melhorar a manutenção e reduzir o CSS gerado.

Otimize o Consentimento de Cookies

Banners de consentimento de cookies são exigidos por regulamentações. No entanto, eles podem impactar os Core Web Vitals de forma agressiva se não forem bem implementados. Um banner mal carregado 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 usar server-side para o consentimento de cookies em páginas dinâmicas: Em páginas renderizadas dinamicamente no server-side, enviar o banner no HTML inicial é mais rápido. Você não precisará carregar uma solução separada baseada em JavaScript. Isso elimina a requisição de rede e o processamento extra de scripts.
• Carregue os scripts de consentimento de forma assíncrona em páginas em cache: Para páginas cacheadas, carregue o script de consentimento de forma assíncrona. Considere adicionar fetchpriority="high" ao script. Isso garante que o banner 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 no aviso de cookies podem assumir o lugar do elemento do LCP. O navegador considera o maior bloco de texto visível como candidato potencial ao LCP. Escreva textos mais curtos. Se precisar, quebre o texto em parágrafos para reduzir a área visível contínua.
• Faça o self-host dos scripts de consentimento de cookies: Faça cache e hospede localmente os scripts e stylesheets de consentimento sempre que possível. Isso elimina consultas DNS e os atrasos de conexão nas plataformas de terceiros. Você ganha controle total sobre o carregamento.

Otimize as Single Page Applications

As Single Page Applications (SPAs) feitas em React, Vue, Angular e outros frameworks enfrentam desafios únicos com o Core Web Vitals. O client-side rendering pode atrasar o FCP e o LCP. A hidratação bloqueia o INP.

• Sempre use server-side rendering ou prerendering: SPAs que dependem somente do client-side rendering forçam o navegador a baixar, processar e executar o JavaScript antes de qualquer conteúdo ficar visível. Use SSR (Next.js, Nuxt, SvelteKit) ou prerendering estático para servir um HTML inicial que o navegador possa pintar imediatamente.
• Prefira prerenders estáticos em vez da geração dinâmica: Os prerenders estáticos (feitos durante o build) são muito mais rápidos que os dinâmicos. Você pode servi-los direto da CDN sem nenhum processamento no servidor. Use essa geração estática nas páginas que não exigem dados atualizados a cada requisição.
• Carregue scripts de terceiros após a hidratação: Durante a hidratação, o framework já consome muito tempo da main thread. Ele precisa tornar a página interativa. Carregar scripts de terceiros ao mesmo tempo só piora o input delay. Atrase todo script não essencial até a hidratação terminar.

Evite um Tamanho Excessivo do DOM

Um DOM grande (mais de 1.500 elementos ou com profundidade maior que 32) aumenta o uso de memória. Ele deixa os cálculos de estilo mais lentos e causa reflows de layout caros. Isso afeta diretamente as métricas de pintura e o presentation delay do INP. Veja como consertar um DOM excessivamente grande.

• Reduza elementos desnecessários no DOM: Audite o seu HTML. Procure elementos de wrapper que não têm propósito de estilo ou estrutural. Substitua as estruturas de <div> aninhadas por HTML semântico. Use virtualização em listas longas usando bibliotecas como react-window ou virtual-scroller. Isso mantém o tamanho do DOM ativo pequeno.
• Use seletores de CSS e JavaScript eficientes: Seletores CSS complexos e buscas no DOM usando JavaScript (como querySelectorAll com padrões amplos) perdem velocidade de forma exponencial quando o DOM cresce. Use classes e seletores específicos. Limite o escopo das buscas para as subárvores do DOM sempre que puder.
• Use content-visibility: auto em conteúdos fora da tela: A propriedade CSS content-visibility: auto manda o navegador ignorar a renderização de elementos fora da tela. Ele só renderiza quando ocorre a rolagem da tela até eles. Isso pode cortar drasticamente o trabalho inicial de páginas mais longas.

Otimize 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. A busca de dados no client-side é 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 as funcionalidades do seu site e encontre oportunidades para reduzir a quantidade de requisições exigidas para renderizar o conteúdo inicial. Use técnicas de data batching (combinar várias requisições em uma) e GraphQL para reduzir round trips.
• Use APIs eficientes e otimizadas: O design e a implementação das próprias APIs também impactam a performance. Garanta que você usa APIs bem feitas e otimizadas para velocidade e eficiência. Implemente mecanismos de cache nas APIs. Isso reduz o tempo de resposta em dados acessados frequentemente.
• Faça o preload das requisições de API críticas: O processo é semelhante a fazer preload de recursos críticos como imagens. Usar o preload de API melhora muito a percepção de performance. Use <link rel="preload" as="fetch"> para instruir o navegador a baixar APIs com antecedência. Isso evita atrasos no render do conteúdo inicial. Veja nosso guia de priorização de recursos para mais técnicas.

Otimize os Widgets de Chat

Widgets de chat causam muitos layout shifts. Eles também atrapalham o LCP quando o carregamento deles ocorre no começo. Siga nosso passo a passo e leia sobre como implementar um widget de chat com um Core Web Vitals perfeito.

• Carregue os widgets de chat depois do conteúdo principal: Ninguém na história da internet quis o chat antes da página abrir de verdade. Adie a inicialização do widget. Faça isso usando requestIdleCallback ou após o usuário realizar um scroll na página.
• Evite layout shifts nos widgets de chat: Ocultar o chat com opacity: 0 é uma ótima estratégia quando ele causa layout shift. Espere ele ficar totalmente renderizado na página. Isso permite o layout atuar em segundo plano sem a página pular na frente do usuário. Use uma transição CSS para surgir com o widget na tela de modo agradável.
• Escolha provedores de widgets de chat leves: Pesquise bem. Alguns widgets de chat são muito mais leves e causam menos problemas no Core Web Vitals do que outros. Compare o tamanho do arquivo JavaScript, o número de requisições de rede e o impacto no INP de diferentes provedores antes de se comprometer.

Otimize a Performance do Service Worker

Service workers podem melhorar a performance das novas visitas ao guardar assets e até a página completa no cache. Isso diminui o TTFB dos visitantes de retorno. Um service worker mal feito pode afetar e atrasar a sua navegação. Leia mais sobre como otimizar a duração do cache.

• Faça cache de recursos críticos no service worker: Use uma estratégia cache-first para assets estáticos como CSS, JavaScript, fontes e imagens. Isso permite que visitantes recorrentes carreguem seu site quase instantaneamente pelo cache local. Faça o precache dos recursos mais importantes durante o evento de 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, 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 imediata.

Otimize Conteúdo em Vídeo

Os elementos de vídeo podem se tornar o LCP element se forem o maior conteúdo visível no viewport. Vídeos grandes e não otimizados competem por banda com os recursos críticos do site.

• Comprima e otimize os vídeos: Use codecs modernos como H.264, VP9 ou AV1. Ajuste a qualidade da forma correta. Reduza a resolução dos vídeos para corresponder ao seu tamanho máximo de exibição. Se o vídeo será mostrado a 400px de largura, ele não precisa ser codificado em 1920px. Use o two-pass encoding para ter a melhor relação de qualidade pelo menor arquivo final.
• Use lazy loading em vídeos: Aplique o atributo loading="lazy" nas tags <iframe> quando vídeos ficarem abaixo da dobra, ou atrase o carregamento deles usando a Intersection Observer API. Troque os background videos pelo uso prático de poster images. Traga o vídeo para a tela apenas quando a rolagem do usuário chegar nele.
• Hospede vídeos em uma CDN rápida: Arquivos de vídeo são grandes e se beneficiam muito da distribuição via CDN. Use uma CDN de vídeo dedicada ou serviço de hospedagem (como Cloudflare Stream, Mux ou Bunny.net) que forneça adaptive bitrate streaming, distribuição geográfica e entrega otimizada.
• Use poster images nos elementos de vídeo: Sempre defina um atributo poster nos elementos <video>. A poster image entrega ao navegador algo para pintar na tela na mesma hora enquanto os dados carregam. Isso se qualifica como elemento do LCP. Otimize a poster image exatamente como você faria com qualquer outra imagem do LCP.