Aprovar no PageSpeed Insights mobile com score ≥ 90 em 2026 não é truque de configuração — é disciplina técnica em LCP (Largest Contentful Paint, ≤ 2,5s), INP (Interaction to Next Paint, ≤ 200ms) e CLS (Cumulative Layout Shift, ≤ 0,1). Esses são os três Core Web Vitals que o PageSpeed Insights e o CrUX (Chrome User Experience Report) medem como sinais de ranqueamento desde 2021. Em mobile, o ambiente é mais hostil — rede 4G simulada, CPU throttled — e o que passa em desktop frequentemente reprova em mobile.
A Huios é agência de desenvolvimento; otimizamos performance pra clientes em Next.js, WordPress e ecommerce. Conflito de interesse declarado: vendemos serviço de otimização técnica. Honestidade técnica acima do interesse comercial.
Este post é checklist técnico. Para a discussão de quando vale construir do zero em vez de otimizar, leia criar site com IA ou landing page no WordPress.
O que o PageSpeed mobile mede em 2026
PageSpeed Insights combina dois tipos de dado:
- Lab data (Lighthouse) — simulação controlada da página em rede 4G slow + CPU throttled 4×. Score 0-100.
- Field data (CrUX) — dados reais de usuários Chrome nos últimos 28 dias. Esse é o que o Google usa pra ranqueamento.
A confusão comum: o score 0-100 que aparece no topo é lab data (simulação). O que ranqueia é o field data (real users). Aprovar no lab é necessário mas não suficiente — você pode ter score 95 no Lighthouse e ainda ter Core Web Vitals ruins em CrUX se o usuário real estiver em conexão pior.
Os 3 Core Web Vitals que importam:
| Métrica | O que mede | Bom | Precisa melhorar | Ruim |
|---|---|---|---|---|
| LCP | Tempo até o maior elemento visível carregar | ≤ 2,5s | 2,5–4s | > 4s |
| INP | Latência da interação mais lenta do usuário (clique, scroll, input) | ≤ 200ms | 200–500ms | > 500ms |
| CLS | Quanto o layout se mexe durante carregamento | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Detalhes oficiais em web.dev/articles/vitals. INP substituiu FID em março de 2024 como métrica de interatividade.
Por que mobile reprova mais que desktop
Quatro razões técnicas:
- Rede simulada 4G slow (1.6 Mbps down, 750 Kbps up, 150ms latência) — JavaScript pesado e imagem grande dobram em tempo de transferência.
- CPU throttled 4× — em desktop um JavaScript leva 200ms; mesmo código em mobile simulado leva 800ms. INP sofre.
- Viewport pequeno — uma imagem hero de 1920px que serve bem em desktop é 4× maior que o necessário em mobile (480px de viewport visível).
- Cache cold — o teste sempre roda como visita nova. Recursos em cache não ajudam no score.
Os 5 erros que custam 20–40 pontos no mobile
Em 80+ auditorias Huios entre 2024 e 2026, esses cinco aparecem em pelo menos 70% dos sites com score < 70:
1. Imagem do hero não otimizada
Sintoma: LCP > 4s só por causa da imagem.
Fix por stack:
- Next.js 16:
next/imagecompriority={true}no hero,sizescorreto,fetchPriority="high". Formato AVIF ou WebP. Largura real ≤ 1080px pra mobile. - WordPress: plugin
ImagifyouShortPixelpra converter pra WebP/AVIF + lazy load nativo do WP 5.5+ (mas remover lazy do hero, que precisa carregar imediato). Smush também serve. - Wix: menos controle — usar Wix Performance Optimization e remover sliders pesados. Score 90+ em Wix é raro mesmo otimizando.
2. JavaScript de terceiros bloqueante
Sintoma: INP > 500ms, score Lighthouse "Reduce unused JavaScript" listando 1MB+ de scripts.
Fix:
- Auditar via Chrome DevTools Coverage — quantos % do JS é realmente usado?
- Carregar Google Analytics, Meta Pixel, Hotjar etc com
<Script strategy="lazyOnload">(Next.js) ouasync/defere WP-Rocket no WordPress. - Considerar tracking server-side via Stape ou GTM Server-side — tira ~300KB de JS do client.
3. Fonte web sem preload
Sintoma: FOIT (Flash of Invisible Text) ou FOUT (Flash of Unstyled Text), CLS alto.
Fix:
- Next.js 16: usar
next/fontcomdisplay: 'swap'. Isso já faz preload + self-host automático. - WordPress: Local Fonts plugin pra self-hostar Google Fonts + adicionar
<link rel="preload">no<head>. - Limitar a 2 famílias × 3 weights máximo. Cada peso adicional = ~30KB.
4. Layout shift de banner/cookie consent
Sintoma: CLS > 0,1.
Fix:
- Reservar altura fixa pra banner antes de renderizar (use
min-height). - Cookie consent (LGPD) deve aparecer com
position: fixedsobre o conteúdo, NÃO empurrar conteúdo. Bibliotecas como Cookiebot e OneTrust configuradas em modo "no layout shift". - Imagens com
widtheheightexplícitos no HTML — evita o reflow quando a imagem carrega.
5. Render bloqueante de CSS
Sintoma: FCP > 1,8s e Lighthouse listando "Eliminate render-blocking resources".
Fix:
- Next.js 16: já faz CSS-in-JS otimizado por padrão; verificar se módulos CSS estão importados no nível certo.
- WordPress: WP-Rocket ou LiteSpeed Cache com "Optimize CSS Delivery" + "Remove Unused CSS" ativos.
- Critical CSS inline (Lighthouse aponta quando vale).
Checklist técnico por stack
Next.js 16 + Vercel
Checklist mínimo pra score ≥ 90 mobile:
-
next/imageem todas imagens comwidth/heightexplícitos - Hero image com
priorityefetchPriority="high" -
next/fontcomdisplay: 'swap' - Server Components default (
'use client'só onde precisa) -
<Script>comstrategy="lazyOnload"em GA/Pixel/Hotjar - Sem importação direta de bibliotecas grandes em components client (use dynamic import)
- Vercel Speed Insights ativo pra medir CrUX em produção
- CSS modules ou Tailwind (CSS-in-JS pesado tipo Styled Components custa CLS)
Em projetos Huios em Next.js 16 com esse checklist seguido desde o primeiro commit, score Lighthouse mobile mediano em maio/2026 é 96 (lab) / 92 (field/CrUX) medido em 12 sites em produção.
WordPress
Checklist pra score ≥ 85 mobile (90+ exige Next.js ou similar):
- Hospedagem decente (WP Engine, Kinsta ou Cloudways — não shared hosting barato)
- WP-Rocket ou LiteSpeed Cache ativo
- Plugin de imagem (Imagify, ShortPixel) convertendo pra WebP/AVIF
- CDN ativo (Cloudflare gratuito ou Bunny.net pago)
- Tema leve (GeneratePress, Astra, Kadence — não Avada/Divi)
- Limitar plugins ativos a < 25 (cada plugin novo custa ~5-10 pontos)
- Remover Google Fonts não usadas (Local Fonts plugin)
- Desativar Gutenberg block library se usa só blocos básicos
Em 11 sites WordPress otimizados pela Huios em 2025, score mediano pós-otimização foi 88 mobile (lab) / 75 (CrUX) — comparativamente, sites em Next.js no mesmo nicho atingem 94 mobile (lab) / 90 (CrUX) com menos esforço.
Wix / Squarespace / Webflow
Checklist mais limitado — você não controla a stack:
- Limitar slider de imagem (tipicamente custa 15-25 pontos sozinho)
- Remover apps/plugins não essenciais
- Imagem hero ≤ 200KB (re-comprimir antes de subir)
- Remover analytics duplicados
- Configurar Wix Velocity ou Webflow CMS só onde necessário
Realidade de Wix em 2026: mesmo com tudo otimizado, score mobile dificilmente passa de 75-80 em campos com imagem rica. É decisão de plataforma, não de configuração.
Como medir o que importa (CrUX, não Lighthouse)
Lighthouse é simulação. CrUX é o que o Google usa pra ranquear. Para medir CrUX real:
- PageSpeed Insights — mostra CrUX field data se o site tem tráfego suficiente (~10k pageviews/mês). Olha "Real User Experience" no topo.
- CrUX Dashboard — relatório histórico no Looker Studio.
- Vercel Speed Insights ou SpeedCurve — se você precisa de CrUX em tempo real e segmentado.
- GSC Core Web Vitals report — em Google Search Console, veja "Experience" → "Core Web Vitals".
Como Annie Sullivan, líder do CrUX, descreveu em 2024: "Lab data is great for catching issues. Field data is what matters for ranking."
Mito comum: "score 100 é melhor que 90"
Não, do ponto de vista de SEO. Acima de 90 mobile, o ganho marginal de SEO é zero. Otimizar de 92 para 100 frequentemente custa 10-20h de engineering — e em 90% dos casos, não move ranking. A regra Huios: parar em 90+ field data (CrUX) consistente.
A excepção: ecommerce de alto ticket onde cada 100ms de LCP adicional reduz conversão em ~1% (estudo Google/Deloitte 2020). Aí vale otimizar até o último décimo.
Erros que NÃO valem corrigir (ROI negativo)
Lighthouse aponta dezenas de "issues". Nem todos importam:
- "Serve images in next-gen formats" quando você já está em WebP — o aviso pra AVIF é marginal (≤ 1 ponto).
- "Reduce JavaScript execution time" abaixo de 200ms — abaixo disso, não há ganho perceptível.
- "Use HTTP/2" se você está em Vercel/Cloudflare — já está em HTTP/3 por padrão.
- "Eliminate render-blocking resources" quando o resource bloqueante é o CSS principal (não dá pra eliminar, só otimizar).
A regra: se o issue não está em vermelho/laranja no Lighthouse, frequentemente não vale o esforço de corrigir.
Perguntas frequentes
O que é considerado um bom score no PageSpeed mobile?
Score Lighthouse mobile ≥ 90 é a meta para a maioria dos sites em 2026. Score ≥ 95 é difícil de manter e marginal em ROI. Acima de 90, o foco deve ser CrUX field data (Real User Metrics) — esse é o que o Google usa pra ranqueamento.
Por que meu site é rápido no desktop mas reprova no mobile?
Mobile usa rede 4G simulada e CPU throttled 4×. JavaScript que leva 200ms no desktop leva 800ms no mobile simulado. Imagens grandes (otimizadas pra desktop 1920px) custam o dobro pra transferir em mobile. Lighthouse mobile é teste mais hostil por design.
Posso ter score 90+ no mobile usando WordPress?
Sim, mas exige stack disciplinada: hospedagem decente (WP Engine, Kinsta, Cloudways), WP-Rocket ou LiteSpeed Cache, plugin de imagem WebP/AVIF, CDN, tema leve (GeneratePress, Astra), < 25 plugins ativos. Em projetos Huios, score mediano pós-otimização em WordPress é 88. Para 90+ consistente, Next.js entrega com menos esforço.
LCP, INP e CLS — quais são os limites em 2026?
Core Web Vitals oficiais: LCP ≤ 2,5s, INP ≤ 200ms, CLS ≤ 0,1. INP substituiu FID em março de 2024. Esses são os 3 que entram em ranking. Outras métricas (FCP, TBT, Speed Index) compõem o score Lighthouse mas não rankeiam diretamente.
Quanto tempo demora pra otimizar um site existente?
Em 80+ otimizações Huios entre 2024 e 2026, site existente típico (WordPress de PME) leva 12-25h de trabalho técnico pra subir de score 50-65 pra 85+ mobile. Sites em Next.js com problemas pontuais geralmente são resolvidos em 4-8h. Sites em Wix com score < 60 — frequentemente o melhor caminho é migrar plataforma, não otimizar.
CrUX vs Lighthouse — qual importa pra Google?
Field data CrUX é o que Google usa para ranqueamento. Lighthouse (lab data) é simulação útil pra detectar issues técnicos. Você pode ter Lighthouse 95 e CrUX ruim se usuários reais estão em conexão pior. A regra: otimize Lighthouse pra atingir CrUX bom, não o contrário.
Vale a pena ter score 100 no PageSpeed?
Não para SEO. Acima de 90 mobile, o ganho marginal em ranking é zero. Custo de subir de 92 pra 100 é tipicamente 10-20h de engineering — em 90% dos casos não move métrica de negócio. Excepção: ecommerce de alto ticket onde 100ms a mais de LCP reduz conversão.
Glossário de performance web
Vocabulário técnico recorrente em auditorias de performance, Core Web Vitals e otimização de carregamento.
- TTFB (Time To First Byte): tempo até o primeiro byte da resposta chegar do servidor ao browser.
- FCP (First Contentful Paint): momento em que o primeiro pixel de conteúdo aparece na tela.
- LCP (Largest Contentful Paint): carregamento do maior elemento visível acima da dobra (geralmente imagem hero).
- INP (Interaction to Next Paint): latência da interação mais lenta — substituiu FID em março de 2024.
- CLS (Cumulative Layout Shift): soma de deslocamentos visuais durante carregamento.
- TBT (Total Blocking Time): tempo total em que main thread ficou bloqueado por tasks longas (>50ms).
- Speed Index: velocidade visual média de carregamento da viewport.
- Critical Rendering Path: sequência de etapas que browser executa pra renderizar primeira pintura.
- Render-blocking resource: CSS ou JavaScript que pausa renderização até carregar.
- Throttling: simulação proposital de rede e CPU mais lentas em testes (Lighthouse usa 4G slow + CPU 4×).
- Viewport: área visível da página no dispositivo do usuário.
- Hydration: processo em que JavaScript "ativa" HTML pré-renderizado pelo servidor.
- Tree shaking: técnica de bundle que remove código não utilizado durante build.
- Code splitting: dividir aplicação em chunks carregados sob demanda.
- Lazy loading: adiar carregamento de recurso até momento necessário (rolagem, interação).
- Prefetch, preconnect, preload: dicas de browser pra adiantar conexões e recursos críticos.
- Service worker: script proxy que intercepta requisições e habilita cache offline.
- Edge function: computação executada perto do usuário em rede global (Vercel, Cloudflare).
- Static Site Generation (SSG): gerar HTML em build time pra servir já pronto.
- Incremental Static Regeneration (ISR): regenerar páginas estáticas em background sob critério.
- Server-Side Rendering (SSR): gerar HTML por requisição no servidor.
- Client-Side Rendering (CSR): browser baixa shell vazio e renderiza tudo via JavaScript.
- Above-the-fold: porção visível sem rolagem — área crítica pra LCP.
- Web font: fonte tipográfica baixada da web (Google Fonts, self-hosted).
- Font swap: estratégia de exibir fallback enquanto web font carrega (display: swap).
Próximos passos
Se você está construindo do zero e quer Next.js com performance correta desde o primeiro commit, criar site com IA cobre quais ferramentas geram código que passa em PageSpeed (v0, Lovable) e quais não (Wix, Durable).
Pra quem está em WordPress decidindo se vale otimizar ou migrar, landing page no WordPress tem o decision tree dos 4 caminhos. E se a landing page é parte de uma estratégia de conversão, landing page de alta conversão cobre os 11 elementos técnicos onde Core Web Vitals é só o passo inicial.
Fontes e dados: "80+ auditorias Huios" e "11 sites WordPress otimizados em 2025" são dados internos consolidados do nosso time técnico (não publicados externamente). Limites de Core Web Vitals e definições de LCP/INP/CLS conforme web.dev/articles/vitals (Google). Estudo "100ms de LCP a mais reduz conversão em ~1%" do Google/Deloitte Milliseconds Make Millions, 2020.
Publicado em 30 de abril de 2026 · Por Equipe Huios
