Estudo de Caso: Migração de WordPress para Next.js — Aumentando Lighthouse de 35 para 94

No trimestre passado, assumimos um projeto que ilustra perfeitamente por que WordPress nem sempre é a ferramenta certa para o trabalho. SleepDr.com — um site de conteúdo sobre saúde do sono com 228 posts de blog, um formulário de contato e uma pontuação móvel do Lighthouse de 35 — chegou até nós desesperado por velocidade. Seu tráfego orgânico havia estado diminuindo por meses. A Atualização Principal de Março de 2026 do Google, que introduziu uma pontuação holística de Core Web Vitals em todo o site, os havia destruído. Cada post de blog lento estava prejudicando todo o domínio.

Migramos para Next.js 15 + Payload CMS 3 + Supabase + Vercel. O resultado: mobile Lighthouse 94, desktop 99. O tráfego orgânico se recuperou em 6 semanas. Esta é a história completa de como chegamos lá — cada otimização, cada métrica, cada decisão — para que você possa aplicar o mesmo raciocínio aos seus próprios projetos.

Índice

SleepDr Case Study: WordPress to Next.js Migration (Lighthouse 35→94)

O Antes: Por que o WordPress Estava Matando o SleepDr

A configuração do WordPress do SleepDr era um exemplo clássico de dívida técnica acumulada. Durante três anos, eles instalaram 34 plugins. O tema carregava jQuery mais duas bibliotecas JavaScript adicionais. Cada solicitação de página atingia um banco de dados MySQL, gerava HTML em tempo real e servia imagens não otimizadas através de um plano de hospedagem compartilhada que já estava lutando sob carga.

Aqui está como a auditoria inicial do Lighthouse parecia em dispositivos móveis:

  • Pontuação Geral: 35 (vermelho, reprovado)
  • FCP: 4.2 segundos
  • LCP: 6.8 segundos — quase três vezes o limite de "Bom"
  • CLS: 0.28 — o layout estava saltando por todos os lados devido a anúncios, imagens sem dimensões e carregamento de fontes web
  • TBT: 1.200ms — a thread principal estava travada por mais de um segundo
  • TTFB: 2.1 segundos — o próprio servidor era lento antes de qualquer coisa ser renderizada

O site não era apenas lento. Era ativamente hostil com usuários em dispositivos móveis. E como a simulação do Lighthouse móvel do Google imita um telefone de nível médio em uma conexão 4G limitada, as pontuações refletiam o que usuários reais em condições menos que ideais estavam experimentando.

Depois que a Atualização Principal de Março de 2026 do Google introduziu pontuação holística de CWV — agregando desempenho em todo o domínio em vez de por página — os 228 posts de blog lentos do SleepDr estavam envenenando seus rankings em todo o site. Os dados iniciais do lançamento mostraram quedas de tráfego de 20-35% para sites afetados. SleepDr viu um declínio de aproximadamente 30%.

Algo tinha que mudar.

A Stack de Migração: Por que Escolhemos o que Escolhemos

Não escolhemos essa stack porque é tendência. Escolhemos porque cada peça resolve um problema específico que SleepDr tinha.

  • Next.js 15 (App Router): Renderização híbrida. Geração estática para posts de blog, renderização no servidor quando necessário. React Server Components para minimizar JavaScript no lado do cliente. Este é nosso pão e manteiga — construímos dezenas de projetos nele através de nossa prática de desenvolvimento Next.js.
  • Payload CMS 3: CMS headless auto-hospedado que deu à equipe de conteúdo do SleepDr a mesma experiência de edição a que estavam acostumados com WordPress, sem a inchação. Tratamos muitas implementações de CMS headless e o Payload 3 se tornou nosso padrão para sites com muito conteúdo.
  • Supabase: Banco de dados PostgreSQL com capacidades em tempo real. Manipulou os envios de formulário de contato, eventos de análise e qualquer dado dinâmico.
  • Vercel: Implantação na borda. O site é servido a partir do nó mais próximo do usuário. TTFB fica quase negligenciável.

A migração total levou 7 semanas. A migração de conteúdo — todos os 228 posts com suas imagens, metadados e estruturas de URL — levou cerca de 2 semanas disso. Escrevemos um script personalizado para extrair conteúdo da API REST do WordPress, transformá-lo e enviá-lo para o Payload CMS.

Antes e Depois: Os Números

Aqui está o detalhamento completo. Estas são pontuações Lighthouse móveis, que é onde a história real está.

Métrica Antes (WordPress) Depois (Next.js 15) Melhoria
First Contentful Paint (FCP) 4.2s 1.1s -3.1s (74% mais rápido)
Largest Contentful Paint (LCP) 6.8s 1.8s -5.0s (74% mais rápido)
Cumulative Layout Shift (CLS) 0.28 0.01 -0.27 (redução de 96%)
Total Blocking Time (TBT) 1.200ms 50ms -1.150ms (redução de 96%)
Time to First Byte (TTFB) 2.1s 0.3s -1.8s (85% mais rápido)
Pontuação Móvel Geral 35 94 +59 pontos
Pontuação Desktop Geral 61 99 +38 pontos

Quero deixar claro: estes não são números selecionados de uma única página. Executamos Lighthouse em 20 páginas representativas e calculamos a média dos resultados. A pontuação móvel variou de 91 a 97 em todas as páginas testadas. Desktop foi de 97 a 100.

Agora vou explicar exatamente como alcançamos cada uma dessas melhorias.

SleepDr Case Study: WordPress to Next.js Migration (Lighthouse 35→94) - architecture

Otimização 1: Otimização de Imagens (LCP -3s)

As imagens eram o maior assassino de desempenho único no site antigo. Os posts de blog do SleepDr eram pesados em fotografia de produtos e infográficos — frequentemente enviados como PNGs em resolução completa direto da máquina de um designer. Algumas imagens tinham 3-4MB cada.

O Que Fizemos

Usamos next/image para cada imagem única. Este componente faz muito trabalho pesado:

import Image from 'next/image';

export function HeroImage({ src, alt }) {
  return (
    <Image
      src={src}
      alt={alt}
      width={1200}
      height={630}
      priority // Hero acima da dobra: pré-carregue
      sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 1200px"
      quality={80}
    />
  );
}

Aqui está o que next/image manipula automaticamente:

  • Conversão de formato: Serve WebP (ou AVIF onde suportado) em vez de PNG/JPEG. Isso sozinho reduziu os tamanhos de imagem em 60-80%.
  • Srcset responsivo: Gera múltiplos tamanhos para que usuários móveis não baixem imagens em tamanho desktop.
  • Carregamento lento por padrão: Imagens abaixo da dobra não carregam até o usuário rolar perto delas.
  • Dimensões explícitas: As propriedades width e height reservam espaço no layout, o que corrige diretamente o CLS.

A Percepção Chave: Carregamento de Prioridade para Elementos LCP

A propriedade priority na imagem do herói foi crítica. Sem ela, Next.js carrega a imagem com atraso. Mas se a imagem do herói é o elemento LCP — o que era na maioria das páginas do SleepDr — carregá-la com atraso na verdade prejudica sua pontuação LCP. Você quer que ela comece a ser baixada imediatamente.

Auditamos cada template de página, identificamos o elemento LCP e o marcamos com priority. As páginas de posts de blog usavam a imagem destacada. A página inicial usava o banner do herói. Simples, mas fez uma diferença de 3 segundos no LCP.

CDN de Imagens

A otimização de imagem integrada do Vercel serve como o CDN. As imagens são processadas e armazenadas em cache na borda na primeira solicitação. Visitantes subsequentes obtêm a versão em cache e otimizada em milissegundos. Nenhuma assinatura do Cloudinary necessária. Nenhum plugin do WordPress tentando fazer a mesma coisa mas pior.

Impacto líquido: LCP caiu de 6.8s para aproximadamente 3.8s apenas com otimização de imagens. Os ganhos LCP restantes vieram de melhorias de TTFB e carregamento de fontes.

Otimização 2: Otimização de Fontes (FCP -1.5s)

O tema WordPress do SleepDr carregava três Google Fonts através de links de folha de estilo externa. Cada um era uma solicitação de bloqueio de renderização para fonts.googleapis.com, seguida por outra solicitação para fonts.gstatic.com pelos arquivos de fonte reais. São seis round trips de rede antes do navegador poder pintar texto.

O Que Fizemos

Auto-hospedamos fontes usando next/font:

import { Inter, Merriweather } from 'next/font/google';

const inter = Inter({
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-inter',
});

const merriweather = Merriweather({
  weight: ['400', '700'],
  subsets: ['latin'],
  display: 'swap',
  variable: '--font-merriweather',
});

O que next/font faz diferentemente:

  • Auto-hospeda os arquivos de fonte: Sem solicitações de rede externa. As fontes são incluídas na compilação e servidas do mesmo CDN.
  • Subsetting automático: Inclui apenas os conjuntos de caracteres que você realmente precisa. O subconjunto Latin de Inter é cerca de 20KB em vez do arquivo completo de 100KB+.
  • display: 'swap': O texto é renderizado imediatamente com uma fonte alternativa, depois troca para a fonte web quando carregada. Sem texto invisível. Sem flash de conteúdo não estilizado bloqueando FCP.
  • Injeção de variável CSS: A fonte é aplicada através de propriedades CSS personalizadas, o que significa zero mudança de layout quando a fonte troca porque combinamos cuidadosamente as métricas da fonte alternativa.

Também descartamos a terceira fonte completamente. O site antigo usava uma fonte decorativa para títulos que adicionava ruído visual sem melhorar a legibilidade. Duas fontes. É só isso.

Impacto líquido: FCP melhorou aproximadamente 1.5 segundos ao eliminar solicitações de fonte que bloqueiam renderização.

Otimização 3: Redução de JavaScript (TBT 1200ms → 50ms)

Esta foi a melhoria única mais dramática. Um TBT de 1.200ms significa que a thread principal do navegador estava bloqueada por mais de um segundo completo — o usuário não conseguia clicar, rolar ou interagir com nada durante esse tempo.

De Onde Vinha Todo esse JavaScript?

O site WordPress carregava:

  • jQuery (87KB minificado) — usado pelo tema e a maioria dos plugins
  • 34 scripts de plugin — formulário de contato, análise, compartilhamento social, consentimento de cookie, duas bibliotecas diferentes de slider, um lightbox, e mais
  • JavaScript do tema — outros 150KB de toggles de menu e bibliotecas de animação
  • Scripts inline — fragmentos aleatórios de vários plugins injetados na tag <head>

Total de JavaScript no carregamento da página: aproximadamente 1.8MB. Em uma conexão móvel limitada, fazer parsing e executar isso leva bem mais de um segundo.

O Que Fizemos

Zero jQuery. Next.js usa React. Não precisamos de jQuery.

Zero plugins. Cada recurso foi reconstruído como um componente propósito-específico:

  • Formulário de contato: componente React de 4KB + ação do servidor Supabase
  • Consentimento de cookie: componente de 2KB com estratégia next/script
  • Compartilhamento social: API Web Share nativa com links alternados — nenhuma biblioteca necessária
  • Análise: script Plausible leve (< 1KB)

Imports dinâmicos para qualquer coisa abaixo da dobra:

import dynamic from 'next/dynamic';

const NewsletterSignup = dynamic(
  () => import('@/components/NewsletterSignup'),
  { ssr: false } // Carrega apenas no cliente, apenas quando necessário
);

const RelatedPosts = dynamic(
  () => import('@/components/RelatedPosts')
);

React Server Components manipularam a maioria da renderização. Conteúdo de posts de blog, headers, footers, navegação — tudo renderizado no servidor com zero JavaScript no lado do cliente. Apenas elementos interativos (o toggle do menu móvel, formulário de contato, assinatura de newsletter) enviavam JS para o navegador.

Total de JavaScript no carregamento da página após migração: aproximadamente 85KB. Essa é uma redução de 95%.

Impacto líquido: TBT caiu de 1.200ms para 50ms. A thread principal está basicamente livre.

Otimização 4: Renderização no Servidor e Implantação na Borda (TTFB -85%)

TTFB mede quanto tempo leva para o servidor começar a enviar o primeiro byte da resposta. O site WordPress do SleepDr tinha um TTFB de 2.1 segundos em dispositivos móveis. Isso significa que antes de qualquer coisa acontecer — antes de imagens carregarem, antes de fontes serem baixadas, antes de JavaScript executar — o usuário estava olhando para uma tela em branco por mais de dois segundos esperando que o servidor respondesse.

Por Que o WordPress Era Tão Lento

Cada solicitação de página no WordPress:

  1. Atingia o servidor de hospedagem compartilhada (já lento)
  2. Carregava PHP
  3. Executava WordPress core
  4. Passava por 34 hooks de plugin
  5. Consultava MySQL múltiplas vezes
  6. Gerava HTML dinamicamente
  7. Enviava a resposta

Mesmo com WP Super Cache instalado, a taxa de cache hit era inconsistente e o servidor em si era fraco.

O Que Fizemos

Geração estática para todos os 228 posts de blog. No momento da compilação, Next.js pré-renderiza cada post de blog em HTML estático. O resultado é um conjunto de arquivos .html sentados na Edge Network do Vercel — distribuído por mais de 80 locais globais.

Quando um usuário solicita um post de blog, ele recebe um arquivo HTML pré-construído do nó de borda mais próximo. Nenhuma consulta ao banco de dados. Nenhum processamento no servidor. Apenas uma leitura de arquivo de um CDN.

// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await payload.find({
    collection: 'posts',
    limit: 300,
  });

  return posts.docs.map((post) => ({
    slug: post.slug,
  }));
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await payload.find({
    collection: 'posts',
    where: { slug: { equals: params.slug } },
    limit: 1,
  });

  return <ArticleLayout post={post.docs[0]} />;
}

Para a página do formulário de contato, usamos renderização no servidor já que precisava de comportamento dinâmico. Mas até SSR nas Edge Functions do Vercel executa em menos de 100ms porque o compute acontece na borda, não em um data center centralizado.

Impacto líquido: TTFB caiu de 2.1s para 0.3s — uma melhoria de 85%. Em visitas repetidas com cache, é mais próximo de 50ms.

Otimização 5: Gerenciamento de Scripts de Terceiros

Scripts de terceiros são os assassinos silenciosos do desempenho web. O site WordPress do SleepDr carregava Google Analytics (GA4), Google Tag Manager, um Facebook pixel, um script de gravação do Hotjar e um gerenciador de consentimento de cookie — todos bloqueando renderização na tag <head>.

O Que Fizemos

Next.js fornece o componente next/script com estratégias de carregamento. Usamos intencionalmente:

import Script from 'next/script';

{/* Análise: carregue após a página ficar interativa */}
<Script
  src="https://plausible.io/js/script.js"
  strategy="afterInteractive"
  data-domain="sleepdr.com"
/>

{/* Consentimento de cookie: carregue quando navegador está ocioso */}
<Script
  src="/scripts/cookie-consent.js"
  strategy="lazyOnload"
/>

A estratégia afterInteractive carrega o script após a hidratação do Next.js ser completa. O usuário já pode ver e interagir com a página. A estratégia lazyOnload aguarda até que o navegador esteja completamente ocioso — ótimo para scripts não-críticos.

Também substituímos Google Analytics com Plausible (< 1KB, focado em privacidade, sem necessidade de consentimento de cookie na maioria das jurisdições). Removemos Hotjar completamente — SleepDr não estava realmente analisando as gravações. Removemos o Facebook pixel já que eles pararam de executar anúncios do Facebook seis meses antes.

Matar scripts de terceiros desnecessários é a vitória de desempenho mais fácil no desenvolvimento web. Eu continuo dizendo isso. A maioria dos sites carrega scripts para serviços que ninguém na equipe está usando ativamente.

Otimização 6: Otimização de CSS (800KB → 35KB)

O tema WordPress do SleepDr enviava aproximadamente 800KB de CSS. Isso incluía a folha de estilo do tema, folhas de estilo de plugins, um sistema de grid Bootstrap completo (não utilizado) e Font Awesome (para cerca de 12 ícones).

O Que Fizemos

Tailwind CSS com purga automática. Tailwind faz scan dos seus arquivos de template no momento da compilação e gera CSS apenas para as classes de utilidade que você realmente usa. Nosso pacote de CSS de produção: 35KB (gzipped: ~8KB).

// tailwind.config.ts
export default {
  content: [
    './app/**/*.{ts,tsx}',
    './components/**/*.{ts,tsx}',
  ],
  theme: {
    extend: {
      fontFamily: {
        sans: ['var(--font-inter)'],
        serif: ['var(--font-merriweather)'],
      },
    },
  },
};

Para os 12 ícones, usamos SVGs inline. Nenhuma biblioteca de ícones. Cada SVG é cerca de 500 bytes. Peso total de ícones: ~6KB versus Font Awesome's 70KB+.

O resultado é zero solicitações de CSS de bloqueio de renderização. A saída do Tailwind é inline no payload HTML inicial pelo Next.js, para que o navegador possa começar a renderizar imediatamente.

Impacto líquido: CSS reduzido em 96%, contribuindo para melhorias tanto de FCP quanto de TBT.

O Checklist Passo a Passo

Se você está enfrentando problemas de desempenho similares, aqui está a ordem exata em que eu abordaria as coisas. Isso é priorizado pela razão impacto-para-esforço.

Fase 1: Vitórias Rápidas (Semana 1)

  • Execute Lighthouse em suas 10 páginas de maior tráfego (modo móvel)
  • Identifique elementos LCP em cada template de página
  • Adicione width e height explícitos a todas as imagens e iframes
  • Adicione loading="lazy" a imagens abaixo da dobra
  • Adicione fetchpriority="high" a imagens LCP
  • Faça auditoria de scripts de terceiros — remova qualquer coisa não utilizada
  • Mova scripts de terceiros restantes para async ou defer

Fase 2: Fonte e CSS (Semana 2)

  • Auto-hospede fontes web (elimine solicitações externas de fontes)
  • Adicione font-display: swap a todas as declarações @font-face
  • Subconjunto de fontes apenas para conjuntos de caracteres necessários
  • Faça auditoria de CSS — remova folhas de estilo não utilizadas
  • Substitua fontes de ícone por SVGs inline

Fase 3: JavaScript (Semana 3)

  • Analise de pacote para identificar maiores dependências JS
  • Remova jQuery se possível
  • Importe dinamicamente componentes não-críticos
  • Adie JavaScript não-essencial
  • Implemente divisão de código por rota

Fase 4: Infraestrutura (Semana 4+)

  • Avalie opções de CDN / implantação na borda
  • Implemente geração estática para páginas de conteúdo
  • Configure headers de cache apropriados
  • Considere migração completa para um framework moderno se WordPress for o gargalo

Se você está considerando esse último ponto — uma migração completa — entre em contato conosco. Fizemos esse tipo exato de projeto muitas vezes. Nossa página de preços tem detalhes sobre o que migrações headless tipicamente custam.

O que os Core Web Vitals de 2026 Significam para Seu Site

A Atualização Principal de Março de 2026 do Google mudou o jogo. CWV não é mais avaliado por página — é agregado em todo seu domínio, ponderado por tráfego. Isso significa:

  • Uma única página modelo lenta usada por 200 posts de blog prejudicará o ranking de todo seu site
  • Páginas de alto tráfego carregam mais peso na pontuação agregada
  • Você não pode apenas otimizar sua página inicial e achar que terminou

Os dados iniciais do lançamento mostram que sites com CWV fraco experimentaram quedas de tráfego orgânico de 20-35%. Alguns viram perdas de mais de 50%. Os sites que se recuperaram mais rápido foram aqueles que abordaram o desempenho a nível de infraestrutura — não otimizando páginas individuais, mas corrigindo a arquitetura subjacente.

Este é exatamente o por que a migração do SleepDr foi tão eficaz. Não otimizamos 228 páginas WordPress individuais. Reconstruímos todo o sistema de entrega para que toda página seja rápida por padrão.

Para sites que não estão prontos para uma migração completa, frameworks como Astro oferecem outro caminho compelling — especialmente para sites ricos em conteúdo onde você quer JavaScript praticamente zero por padrão.

Abordagem Custo Típico Timeline Ganho Lighthouse Esperado
Otimização de plugin WordPress (WP Rocket, ShortPixel) $100-500/yr 1-2 semanas +10-20 pontos
Substituição de tema WordPress $2.000-5.000 2-4 semanas +15-25 pontos
Migração de CMS headless (Next.js/Astro) $15.000-50.000 4-10 semanas +30-60 pontos
Reconstrução completa de plataforma $30.000-100.000+ 8-20 semanas +40-65 pontos

O projeto do SleepDr ficou na faixa de $20.000-25.000 para a migração completa, incluindo transferência de conteúdo de todos os 228 posts, setup do CMS, componentes personalizados e otimização de desempenho. A hospedagem no Vercel custa $20/mês no plano Pro. Isso é aproximadamente $740/ano em hospedagem versus os $300/ano que eles estavam pagando por hospedagem compartilhada que não conseguia manter TTFB abaixo de 2 segundos.

O ROI? Seu tráfego orgânico se recuperou dentro de 6 semanas e superou níveis pré-declínio em 10 semanas. Para um negócio que depende de busca orgânica, a migração se pagou no primeiro trimestre.

FAQ

Quanto tempo leva para melhorias de Core Web Vitals afetarem as classificações do Google? Em nossa experiência com SleepDr e projetos similares, Search Console começa a mostrar dados CWV atualizados dentro de 28 dias após o deploy. As melhorias de ranking normalmente seguem 2-3 meses depois. O Google precisa re-rastrear suas páginas, coletar dados de campo frescos de usuários reais do Chrome (dados CrUX), e considerar isso em seus algoritmos de ranking. Não espere resultados da noite para o dia — mas espere melhoria mensurável dentro de um trimestre.

Uma pontuação Lighthouse de 94 é realmente alcançável para um site de produção real? Sim, mas requer escolhas de arquitetura intencionais desde o início. Pontuações de laboratório acima de 90 em dispositivos móveis são alcançáveis com frameworks modernos como Next.js ou Astro quando você controla seus scripts de terceiros, otimiza imagens apropriadamente e implanta em uma rede de borda. A chave é que cada componente deve ser ciente de desempenho. Um único embed ruim ou widget de terceiros não otimizado pode derrubá-lo de volta para os 70s.

Preciso me afastar do WordPress para obter bons Core Web Vitals scores? Não necessariamente. Sites WordPress podem ter bom desempenho com o tema certo, cache agressivo (WP Rocket + Cloudflare), hospedagem otimizada (Kinsta, WP Engine) e plugins mínimos. Realistically, a maioria dos sites WordPress que auditamos pontua entre 30-60 em dispositivos móveis por causa de inchação de plugin acumulada e overhead de tema. Se você estiver abaixo de 50, otimização de plugin sozinha provavelmente não vai levá-lo acima de 75. Uma abordagem headless — onde WordPress serve como uma API de conteúdo enquanto um framework frontend manipula renderização — é frequentemente o meio-termo que vale explorar.

Qual é a diferença entre pontuações do Lighthouse e dados reais de Core Web Vitals? Lighthouse é uma ferramenta de laboratório — ela simula um telefone de nível médio em 4G limitada e oferece pontuações sintéticas. Core Web Vitals em Search Console são dados de campo — medições reais de usuários reais do Chrome visitando seu site ao longo de uma janela móvel de 28 dias. Google usa dados de campo para sinais de ranking, não pontuações de laboratório. Lighthouse é útil para diagnosticar problemas e testar correções, mas seu objetivo é status CWV verde em Search Console no percentil 75.

Qual é a otimização single mais impactante para LCP? Otimização de imagem. Em aproximadamente 60% dos sites que auditamos, o elemento LCP é uma imagem. Dimensioná-la apropriadamente, servi-la em formato WebP/AVIF, adicionar fetchpriority="high" e garantir que não carregue com atraso normalmente reduzirá o LCP em 2-4 segundos. No SleepDr, otimização de imagem sozinha representou aproximadamente 3 segundos de melhoria do LCP.

Como a pontuação holística de CWV de 2026 do Google funciona? Desde a Atualização Principal de Março de 2026, Google agrega dados de Core Web Vitals em todo seu domínio em vez de avaliar páginas individualmente. Páginas de alto tráfego carregam mais peso no cálculo. Isso significa que um template de arquivo de blog lento usado em centenas de páginas prejudicará os rankings de sua página inicial também. A correção é arquitetural — você precisa que todo template de página passe nos limites de CWV, não apenas suas principais páginas de destino.

Quanto custa uma migração de WordPress para Next.js tipicamente? Para um site de conteúdo similar ao SleepDr (200+ páginas, layout de blog padrão, formulários de contato, sem e-commerce), espere $15.000-30.000 de uma agência experiente. Migrações de e-commerce ficam mais altas — $30.000-75.000+ dependendo da complexidade. Hospedagem contínua no Vercel Pro é $20/mês. O ROI depende de quanto tráfego orgânico vale para seu negócio, mas para sites que experimentaram quedas de tráfego de CWV fraco, a migração normalmente se paga dentro de 3-6 meses.

Devo me focar em pontuações Lighthouse móvel ou desktop? Móvel. Sempre móvel first. Google usa indexação mobile-first e pontuação Lighthouse móvel é significativamente mais severa que desktop porque simula um dispositivo constrangido e rede. Se sua pontuação móvel é 94, sua pontuação desktop quase certamente será 95+. A pontuação desktop de 99 do SleepDr não requereu trabalho adicional além do que fizemos para otimização móvel.