Como aprovar no PageSpeed mobile em 2026: checklist técnico para Next.js e WordPress

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:

1. Lab data (Lighthouse) — simulação controlada da página em rede 4G slow + CPU throttled 4×. Score 0-100.
2. 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:

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:

1. 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.
2. CPU throttled 4× — em desktop um JavaScript leva 200ms; mesmo código em mobile simulado leva 800ms. INP sofre.
3. 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).
4. 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/image com priority={true} no hero, sizes correto, fetchPriority="high". Formato AVIF ou WebP. Largura real ≤ 1080px pra mobile.
• WordPress: plugin Imagify ou ShortPixel pra 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) ou async/defer e 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/font com display: '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: fixed sobre o conteúdo, NÃO empurrar conteúdo. Bibliotecas como Cookiebot e OneTrust configuradas em modo "no layout shift".
• Imagens com width e height explí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/image em todas imagens com width/height explícitos
• Hero image com priority e fetchPriority="high"
• next/font com display: 'swap'
• Server Components default ('use client' só onde precisa)
• <Script> com strategy="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:

1. PageSpeed Insights — mostra CrUX field data se o site tem tráfego suficiente (~10k pageviews/mês). Olha "Real User Experience" no topo.
2. CrUX Dashboard — relatório histórico no Looker Studio.
3. Vercel Speed Insights ou SpeedCurve — se você precisa de CrUX em tempo real e segmentado.
4. 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.