A maioria dos guias sobre Core Web Vitals dá 12 coisas para consertar. Isso é avassalador. Você não vai fazer os 12. Você vai fazer zero.
Aqui está o que realmente funciona. Conserte três coisas. Obtenha 80% do resultado. Siga em frente com sua vida.
O Que Você Vai Aprender
Este guia mostra como priorizar as correções de Core Web Vitals sem perder tempo. Você vai aprender quais métricas importam mais para seu tipo de site. Você vai aprender as três correções que fazem diferença. Você vai aprender como medir resultados em cerca de 15 minutos.
Isto não é teoria. Isto é o que funciona para pequenos negócios e agências que não têm um engenheiro de performance em tempo integral.
101: Por Que Core Web Vitals Realmente Importam
Core Web Vitals medem a velocidade de carregamento do seu site e como ele se sente estável. Google os utiliza como fator de classificação. Mais importante, sites lentos perdem clientes.
Existem três métricas:
Largest Contentful Paint (LCP) mede a velocidade de carregamento. Rastreia quanto tempo leva para o conteúdo principal aparecer. O bom é menos de 2,5 segundos. A maioria dos sites de pequenos negócios atinge 3,5 a 4,5 segundos.
Interaction to Next Paint (INP) mede a capacidade de resposta. Rastreia a rapidez com que seu site reage quando alguém clica ou toca. O bom é menos de 200 milissegundos. Sites com muito JavaScript frequentemente atingem 400 a 600 milissegundos.
Cumulative Layout Shift (CLS) mede a estabilidade visual. Rastreia quanto sua página salta enquanto carrega. O bom é menos de 0,1. Sites com anúncios ou imagens carregadas preguiçosamente frequentemente atingem 0,3 ou superior.
A maioria dos sites falha em pelo menos um desses. O site médio de pequeno negócio falha em dois.
A pesquisa de 2024 do HubSpot descobriu que 75% dos usuários nunca rolam além da primeira página de resultados de busca. Core Web Vitals são um desempate quando a qualidade do conteúdo é igual. Se seu concorrente tem o mesmo conteúdo mas carrega mais rápido, ele classifica mais alto.
O Problema Com o Conselho Atual
Procure por otimização de Core Web Vitals. Você vai encontrar guias abrangentes. Eles listam 12 a 15 táticas. Eles cobrem todos os casos extremos.
Eles estão corretos. Eles também são inúteis.
Um dono de taqueria não tem tempo para implementar 15 otimizações de performance. Uma agência gerenciando 30 sites de clientes não pode auditar cada arquivo JavaScript manualmente.
Os guias abrangentes perdem o ponto. Você precisa saber o que consertar primeiro. Você precisa saber o que realmente move seus números.
As ferramentas SEO tradicionais pioram isso. Elas dão você despejo de dados. Você obtém 100 problemas sem prioridade. Você obtém jargão técnico sem contexto. Você gasta horas tentando descobrir qual problema importa.
Lighthouse dá um score de performance. Não te diz se você deve consertar suas imagens ou seu JavaScript primeiro. PageSpeed Insights mostra o que está lento. Não te diz qual correção vai te levar de falha a aprovação.
201: As Três Correções Que Realmente Funcionam
Correção 1: Otimize Seu Elemento Largest Contentful Paint
LCP é quase sempre seu maior problema. Também é o mais fácil de consertar.
Seu elemento LCP é geralmente sua imagem hero ou seu cabeçalho principal. A maioria dos sites carrega isso lentamente porque a imagem é enorme e descompactada.
Site Audit pegou isso em nosso próprio site. Tínhamos uma imagem hero de 2,4 MB que estava sendo exibida em apenas 1200 pixels de largura. A imagem foi tirada em 4000 pixels. Esses pixels extras não fizeram nada exceto nos desacelerar.
Aqui está o que fazer:
Converta sua imagem hero para o formato WebP. Os arquivos WebP são 30% menores que JPEG com a mesma qualidade. Você pode usar ferramentas gratuitas como Squoosh ou CloudConvert. Navegadores modernos suportam WebP. Safari adicionou suporte em 2020. Edge adicionou suporte em 2018.
Aqui está o HTML:
<picture>
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Your hero image" width="1200" height="800">
</picture>O navegador carrega WebP se suportado. Ele volta para JPEG para navegadores mais antigos.
Redimensione a imagem para corresponder ao seu tamanho de exibição real. Se sua imagem hero é exibida em 1200 pixels de largura, não carregue uma imagem de 4000 pixels. Use 1200 pixels para desktop. Use 800 pixels para mobile. Sirva tamanhos diferentes baseado na largura da tela.
Aqui está o código:
<img
src="hero-1200.webp"
srcset="hero-800.webp 800w, hero-1200.webp 1200w"
sizes="(max-width: 768px) 800px, 1200px"
alt="Your hero image"
width="1200"
height="800"
>Adicione atributos width e height à sua tag de imagem. Isto diz ao navegador quanto espaço reservar. Previne layout shift enquanto a imagem carrega. Navegadores modernos usam estes para calcular proporção de aspecto automaticamente.
Use uma Content Delivery Network (CDN). CDNs servem suas imagens de servidores próximos aos seus visitantes. CloudFlare e BunnyCDN ambos têm camadas gratuitas. Uma CDN tipicamente reduz o tempo de carregamento de imagem em 40% a 60%.
Adicione fetchpriority=“high” à sua imagem LCP. Isto diz ao navegador para carregar esta imagem antes de outros recursos. É uma sugestão, não um comando. Navegadores respeitam quando conseguem.
<img
src="hero.webp"
alt="Your hero image"
width="1200"
height="800"
fetchpriority="high"
>Esta correção sozinha pode reduzir seu LCP de 4 segundos para 2 segundos. Essa é a diferença entre uma pontuação de aprovação e reprovação.
Erros comuns com otimização de LCP:
Não carregue preguiçosamente seu elemento LCP. Lazy loading diz ao navegador para esperar. Seu elemento LCP deve carregar imediatamente.
Não coloque seu elemento LCP abaixo da dobra. LCP mede o maior conteúdo visível. Se seu hero é minúsculo e seu conteúdo principal está mais abaixo, otimize o conteúdo que realmente aparece primeiro.
Não comprima imagens muito agressivamente. WebP em 80% de qualidade é aceitável. WebP em 40% de qualidade parece terrível. Usuários notam quedas de qualidade. Encontre o equilíbrio.
Correção 2: Adie JavaScript Não-Crítico
JavaScript bloqueia a renderização. O navegador tem que baixar, analisar e executar cada script antes de mostrar sua página. A maioria daquele JavaScript não faz nada no carregamento inicial.
O site médio de pequeno negócio carrega 8 a 12 arquivos JavaScript no carregamento da página. A maioria daqueles arquivos alimenta recursos abaixo da dobra. Eles não precisam carregar primeiro.
Aqui está o que fazer:
Adicione o atributo defer às suas tags de script. Isto diz ao navegador para baixar o script em segundo plano e executá-lo depois que a página carrega.
<!-- Antes: bloqueia renderização -->
<script src="analytics.js"></script>
<!-- Depois: carrega em segundo plano -->
<script src="analytics.js" defer></script>O atributo defer mantém a ordem de execução de script. Se o script B depende do script A, eles ainda executam em ordem. Eles apenas não bloqueiam a renderização.
Mova scripts de análise e rastreamento para o final de sua página. Google Analytics não precisa carregar antes de seu conteúdo aparecer. Nem Facebook Pixel. Nem seu widget de chat ao vivo.
Coloque esses scripts logo antes da tag de fechamento </body>. Eles carregam depois de tudo mais.
Remova JavaScript não utilizado completamente. A maioria dos sites WordPress carrega jQuery para recursos que não usam. Muitos temas carregam bibliotecas de animação que alimentam um botão.
Verifique quais scripts realmente disparam no carregamento da página. Abra Chrome DevTools. Vá para a aba Coverage. Atualize sua página. Chrome mostra quanto de cada arquivo JavaScript realmente executa.
Se um arquivo é 80% não utilizado, você provavelmente não precisa dele. Remova-o ou divida-o em arquivos menores.
Use async para scripts que não dependem um do outro. O atributo async baixa scripts em paralelo e os executa assim que terminam de baixar. Use async para scripts independentes como análise.
<script src="analytics.js" async></script>
<script src="chat-widget.js" async></script>Não use async para scripts que dependem um do outro. Se o script B precisa do script A para executar primeiro, use defer em vez disso.
Esta correção tipicamente melhora INP em 100 a 200 milissegundos. Também acelera LCP porque o navegador pode focar em conteúdo em vez de scripts.
Erros comuns com otimização de JavaScript:
Não adie JavaScript que adiciona funcionalidade crítica. Se sua navegação principal requer JavaScript para funcionar, não adie-a. Usuários verão um menu quebrado.
Não faça async em tudo cegamente. Async muda a ordem de execução. Se seus scripts dependem um do outro, async vai quebrar.
Não remova JavaScript sem testar. Remova um arquivo por vez. Verifique que tudo ainda funciona. Depois mova para o próximo arquivo.
Correção 3: Especifique Dimensões de Imagem e Elemento
Layout shift acontece quando elementos carregam sem tamanhos definidos. O navegador adivinha quanto espaço reservar. O navegador adivinha errado. Sua página salta.
Este é o problema Core Web Vitals mais irritante para usuários. O conteúdo salta enquanto leem. Eles clicam em um link. A página salta. Eles clicam na coisa errada.
Aqui está o que fazer:
Adicione atributos width e height explícitos a cada imagem. Navegadores modernos usam estes para calcular proporção de aspecto e reservar espaço.
<!-- Antes: sem dimensões, causa layout shift -->
<img src="product.jpg" alt="Product photo">
<!-- Depois: navegador reserva espaço correto -->
<img src="product.jpg" alt="Product photo" width="600" height="400">Você não precisa corresponder o tamanho de exibição exatamente. O navegador escala proporcionalmente. Você apenas precisa dar a ele a proporção de aspecto correta.
Defina dimensões para anúncios e embeds antes de carregarem. Se você executar Google Ads, reserve as dimensões exatas de pixel em seu CSS. Se você incorporar vídeos do YouTube, reserve espaço 16:9 antes do embed carregar.
.ad-container {
width: 300px;
height: 250px;
background: #f0f0f0;
}Carregue web fonts com font-display swap. Isto mostra fontes do sistema imediatamente e troca para sua fonte customizada quando pronta. Previne texto invisível e reflow de layout.
@font-face {
font-family: 'YourFont';
src: url('your-font.woff2') format('woff2');
font-display: swap;
}O texto aparece imediatamente em uma fonte de fallback. Quando sua fonte customizada carrega, ela é trocada. Isto é melhor que esperar a fonte carregar antes de mostrar qualquer texto.
Evite injetar conteúdo acima do conteúdo existente. Se você carregar preguiçosamente imagens ou anúncios, injete-os abaixo da dobra onde eles não vão empurrar conteúdo para baixo.
Use o atributo loading="lazy" para imagens abaixo da dobra. Isto adia o carregamento até o usuário rolar perto delas.
<img src="below-fold.jpg" alt="Image below fold" loading="lazy" width="800" height="600">Esta correção pode reduzir seu CLS de 0,3 para menos de 0,1. Essa é a diferença entre uma nota de falha e uma pontuação perfeita.
Erros comuns com layout shift:
Não injete banners promocionais no topo da página após carregamento. Usuários odeiam isto. Arruína sua experiência de leitura. Se você deve mostrar um banner, reserve espaço para ele em seu HTML inicial.
Não use animações CSS que mudem dimensões de elemento. Animações que crescem ou encolhem elementos causam layout shift. Use transforms em vez disso. Transforms não afetam layout.
Não carregue fonts sem fallbacks. Se sua font customizada falhar em carregar, usuários devem ver texto mesmo assim. Defina uma fallback font stack em seu CSS.
Como Saber O Que Consertar Em Seu Site
As três correções acima funcionam para a maioria dos sites. Mas seu site pode ser diferente.
Sites de e-commerce geralmente falham em LCP por causa deimagens de produtos. Você tem dezenas de fotos de alta resolução. Essas fotos geralmente são 3 a 5 MB cada uma. Comprimi-las reduz LCP pela metade.
Sites de SaaS geralmente falham em INP por causa dedashboards pesados em JavaScript. Você tem frameworks, gestão de estado e atualizações em tempo real. Adiar scripts não-críticos melhora a capacidade de resposta.
Sites de notícias geralmente falham em CLS por causa deanúncios e carregamento preguiçoso. Você injeta anúncios entre parágrafos. Você carrega preguiçosamente imagens em artigos. Ambos causam layout shift.
Você precisa saber qual métrica é seu ponto fraco. Você precisa saber qual correção vai mover seus números específicos.
301: Por Que Ferramentas Tradicionais Perdem o Ponto
PageSpeed Insights dá você scores. Lighthouse dá você oportunidades. Nenhuma delas te diz o que consertar primeiro.
Você recebe uma lista de 20 problemas. Cada problema tem uma economia de tempo potencial. O problema que poupa 2 segundos parece mais importante que o problema que poupa 0,5 segundos.
Essa matemática é enganosa.
A economia de 2 segundos pode exigir reescrever toda sua arquitetura JavaScript. A economia de 0,5 segundos pode exigir comprimir uma imagem. Uma leva 40 horas. Uma leva 5 minutos.
Ferramentas tradicionais não levam em conta dificuldade de implementação. Elas não te dizem quais correções te levam de falta a aprovação. Elas apenas despejam dados e deixam você descobrir.
Site Audit executa uma auditoria técnica em cerca de 15 minutos. Planos a partir de $50/tarefa. Verifica todas as três métricas de Core Web Vitals. Te diz exatamente quais elementos estão te desacelerando. Classifica as correções por impacto para você saber o que fazer primeiro.
Você recebe um relatório completo com projeções antes e depois. Você recebe os arquivos específicos e números de linha para mudar. Você recebe um arquivo JSON se quiser automatizar correções em múltiplos sites.
A maioria das auditorias custa $500 e leva três dias. Site Audit custa $50 e executa enquanto você toma um café.
Como Site Audit Realmente Funciona
Site Audit combina múltiplas ferramentas de teste em um relatório priorizado.
Executa Google PageSpeed Insights para métricas de laboratório. Puxa dados de Chrome UX Report para métricas de usuários reais. Executa Pa11y para testes de acessibilidade. Verifica compatibilidade de navegadores através de Chrome, Firefox, Safari e Edge.
Depois usa IA para sintetizar resultados em um plano de ação priorizado.
Você não recebe 100 problemas sem contexto. Você recebe 5 ações prioridades com estimativas de esforço e scores de impacto. Cada ação inclui o problema, o impacto em seu negócio, a correção e o resultado esperado.
Site Audit oferece dois escopos: 30 páginas ou 100 páginas. O escopo de 30 páginas é perfeito para sites pequenos. Você obtém auditorias principais, 5 ações prioridades e testes de navegador.
O escopo de 100 páginas adiciona análise de concorrentes. Site Audit compara seu site contra até 2 concorrentes lado a lado. Você vê exatamente onde está atrás. Você vê lacunas de palavras-chave, cobertura de schema e benchmarks de performance.
O escopo expandido também inclui análise de lacuna de conteúdo. Site Audit identifica tópicos pelos quais seus concorrentes se classificam e você não. Você obtém pesquisa alimentada por IA sobre o que escrever a seguir.
Números Reais De Sites Reais
Site Audit pegou 4 problemas legítimos em surmado.com.
Estávamos faltando schema LocalBusiness. Esses dados estruturados impulsionam melhora de busca local de 15% a 30%. Adicionamos. O tráfego local aumentou 18% em 30 dias.
Tínhamos 3 headers de segurança faltantes. Nosso score de segurança era 2 de 5. Adicionamos Content-Security-Policy, X-Content-Type-Options e Strict-Transport-Security. Nosso score saltou para 5 de 5.
Tínhamos gargalos de Speed Index de fonts não otimizadas. Trocamos para font-display swap. Speed Index caiu de 3,2 segundos para 2,1 segundos.
Lighthouse não pegou esses problemas. Lighthouse testa um navegador em condições ideais. Site Audit testa 4 navegadores com métricas de usuários reais. Site Audit também testa navegadores in-app de mídia social na versão Pro. Navegadores Instagram, Facebook e LinkedIn se comportam diferente que navegadores padrão.
30% a 50% do tráfego vem de mídia social. Se seu site quebra no navegador in-app do Instagram, você perde aquele tráfego.
A Comparação de Ferramentas Que Você Realmente Precisa
Aqui está como Site Audit se compara com outras opções:
PageSpeed Insights é gratuito e dá você scores de laboratório. Não prioriza correções. Não compara você a concorrentes. Não testa navegadores sociais. Dá você dados. Você descobre a estratégia.
Lighthouse é gratuito e integrado no Chrome DevTools. Requer expertise técnica. Você precisa saber como ler gráficos de waterfall. Você precisa entender recursos que bloqueiam renderização. Dá você oportunidades. Você descobre quais importam.
Semrush Site Audit custa $1.400 por ano. Rastreia todo seu site e encontra tudo errado. Você obtém 100+ problemas sem prioridade. Você obtém dashboards para monitorar tendências. Você gasta horas descobrindo o que consertar primeiro.
Screaming Frog custa $199 por ano. É um rastreador de desktop. Encontra links quebrados, conteúdo duplicado e problemas de metadados. Não testa performance. Não testa métricas de usuários reais. Não te diz impacto em negócio.
Site Audit começa em $50/tarefa. Você obtém um plano de ação priorizado em cerca de 15 minutos. Você obtém 5 a 10 coisas específicas para fazer com estimativas de esforço. Você obtém análise de concorrentes em Pro. Você obtém métricas de usuários reais do Chrome UX Report. Você obtém testes de navegador social em Pro.
Você obtém a auditoria que você escreveria depois de usar essas outras ferramentas.
Site Audit é a camada de estratégia. Outras ferramentas dão dados. Site Audit te diz o que fazer com isso.
Quando Otimização de Core Web Vitals Falha
Nem todo site se beneficia de otimização de Core Web Vitals. Você precisa saber quando importa e quando não importa.
Se seu site classifica na página 5 para suas palavras-chave alvo, Core Web Vitals não vão te salvar. Qualidade de conteúdo e backlinks importam mais. Conserte aqueles primeiro.
Se seus concorrentes também têm Core Web Vitals ruins, otimizar os seus dá uma vantagem. Se seus concorrentes têm scores perfeitos, combinar eles apenas nivela o campo.
Core Web Vitals são um desempate. Importam mais quando qualidade de conteúdo é igual e você está competindo por posições 1 a 5 na página 1.
Threads do Reddit de profissionais de SEO técnico confirmam isso. Sites com scores perfeitos de Core Web Vitals às vezes classificam abaixo de sites com scores falhando. Google considera centenas de fatores de classificação. Core Web Vitals são um fator.
Não desperdice 40 horas otimizando Core Web Vitals se seu conteúdo é fraco ou seu site não tem backlinks. Conserte os fundamentos primeiro.
API e Automação para Agências
Se você gerencia múltiplos sites de clientes, você precisa de automação.
Site Audit inclui suporte completo de API e webhook. Você pode disparar auditorias programaticamente. Você obtém saída JSON com dados estruturados. Você pode construir dashboards ou automatizar relatórios.
A API é baseada em REST com autenticação simples. Você envia uma requisição POST com uma URL. Site Audit executa assincronamente. Você obtém um webhook quando o relatório termina. Você pode consultar o endpoint de status se preferir.
A saída JSON inclui todas as métricas, ações prioridades e comparações de concorrentes. Você pode analisar isso em seus próprios sistemas. Você pode gerar relatórios customizados para clientes. Você pode rastrear progresso ao longo do tempo.
Site Audit também suporta modo clean-label em Portfolio. Seu nome de agência aparece em relatórios em vez de Surmado. Seus clientes veem sua marca.
A maioria das agências cobra $500 a $1.000 por auditorias de SEO. Scout entrega a mesma qualidade em ~15 minutos. Você mantém a margem. Seus clientes obtêm resultados rápidos e acionáveis.
Dicas Específicas de Framework
Suas correções dependem de sua pilha de tecnologia.
Sites WordPress: Use um plugin de cache como WP Rocket ou W3 Total Cache. Esses plugins tratam otimização de imagem, JavaScript deferral e integração de CDN automaticamente. A maioria da configuração leva 10 minutos.
Sites Shopify: Use o carregamento preguiçoso integrado para imagens de produtos. Adie apps de terceiros que adicionam JavaScript. A maioria das lojas Shopify carregam 8 a 12 scripts de terceiros. Audite quais você realmente usa.
Sites Next.js: Use o componente Image integrado. Trata dimensionamento responsivo, carregamento preguiçoso e conversão de formato automaticamente. Use imports dinâmicos para JavaScript do lado do cliente. Isto adia código que não precisa executar no servidor.
Sites React: Use React.lazy() para code splitting. Isto quebra seu JavaScript em chunks menores que carregam sob demanda. Use a API Intersection Observer para carregamento preguiçoso de conteúdo abaixo da dobra.
Sites estáticos: Faça pré-renderização tudo na hora da build. Use uma ferramenta de build como Eleventy ou Hugo. HTML estático carrega mais rápido que conteúdo renderizado em JavaScript. Use um CDN para servir seus arquivos estáticos globalmente.
Como Medir Resultados
Depois que você faz correções, você precisa verificar se funcionaram.
Use Google PageSpeed Insights. Entre sua URL. Verifique seus scores de Core Web Vitals. Compare-os com sua baseline antes das correções.
Execute o teste três vezes. Scores flutuam baseado em condições de rede e carga do servidor. Calcule a média dos resultados. Não entre em pânico se um teste mostrar scores piores. Olhe a tendência através de múltiplos testes.
Verifique mobile e desktop. Google classifica baseado em performance mobile. Scores desktop são geralmente mais altos mas importam menos para classificações.
Espere 28 dias por dados de usuários reais. Chrome UX Report agrega dados sobre uma janela móvel de 28 dias. Seus scores de laboratório melhoram imediatamente. Seus scores de campo melhoram gradualmente conforme usuários reais visitam seu site atualizado.
Se você quer monitoramento contínuo, planos Pro e Portfolio incluem monitoramento semanal. Você vê como seus scores mudam ao longo do tempo. Tarefas extras disponíveis por $25 quando você precisa de um look mais profundo.
Perguntas Comuns
Quanto tempo leva a otimização?
As três correções neste guia levam 1 a 3 horas no total para a maioria dos sites. Otimização de imagem leva 30 minutos. JavaScript deferral leva 30 minutos. Adicionar dimensões às imagens leva 1 a 2 horas dependendo de quantas imagens você tem.
Preciso de ajuda de desenvolvedor?
Para correções básicas, não. Comprimir imagens e adicionar dimensões podem ser feitos através de seu CMS. Para mudanças de JavaScript, você pode precisar de um desenvolvedor se seu site usa um tema customizado ou processo de build.
Isso vai quebrar meu site?
Não se você testar mudanças em um ambiente de staging primeiro. Faça uma mudança por vez. Teste que tudo ainda funciona. Depois mova para a próxima mudança. Não empurre 10 mudanças para produção ao mesmo tempo.
Quanto melhoria de tráfego posso esperar?
Depende de suas classificações atuais. Se você classifica em posições 4 a 7 na página 1, melhorar Core Web Vitals pode te mover para posições 2 a 4. Isso tipicamente aumenta tráfego em 20% a 40%. Se você classifica na página 2 ou 3, Core Web Vitals sozinho não vai te mover para página 1. Foque em conteúdo e backlinks primeiro.
Devo otimizar todas as páginas?
Não. Comece com suas páginas de maior tráfego. Otimize sua homepage, seus top 10 landing pages e seus top 10 páginas de produto ou serviço. Essas páginas impulsionam 80% do seu tráfego. Conserte-as primeiro.
E se eu usar um page builder?
A maioria dos page builders adiciona inchaço. Elementor, Divi e Visual Composer todos carregam JavaScript e CSS extras. Você ainda pode otimizar imagens e adicionar dimensões. Adiar JavaScript é mais difícil porque page builders frequentemente colocam scripts inline.
Considere trocar para um tema mais leve se performance é crítica. GeneratePress e Kadence são alternativas rápidas que funcionam com o editor de blocos.
O Que Fazer Esta Semana
Escolha a correção que corresponde sua pior métrica:
Se seu LCP está acima de 2,5 segundos, otimize sua imagem hero. Converta para WebP. Redimensione para dimensões de exibição. Adicione um CDN. Isto leva 30 minutos e geralmente reduz LCP em 40% a 50%.
Se seu INP está acima de 200 milissegundos, adie seu JavaScript. Adicione atributos defer a tags de script. Mova análise para o final. Remova scripts não utilizados. Isto leva 30 a 60 minutos e geralmente melhora INP em 100 a 200 milissegundos.
Se seu CLS está acima de 0,1, especifique dimensões para todas as imagens e conteúdo dinâmico. Defina tamanhos explícitos em HTML. Use font-display swap para fonts customizadas. Evite injetar conteúdo acima da dobra. Isto leva 1 a 2 horas e geralmente reduz CLS abaixo de 0,1.
Execute Site Audit para ver qual métrica precisa de atenção primeiro. Planos a partir de $50/tarefa. Conserte os top três problemas. Executa o teste novamente em uma semana.
Otimização de Core Web Vitals não é complicada. Você não precisa de uma grande agência. Você não precisa de um engenheiro em tempo integral. Você precisa consertar as três coisas certas.