El caso de SleepDr: de WordPress a Next.js — Recuperación de tráfico orgánico a través de optimización de Core Web Vitals

El trimestre pasado, asumimos un proyecto que ilustra perfectamente por qué WordPress no siempre es la herramienta correcta para el trabajo. SleepDr.com — un sitio de contenido sobre salud del sueño con 228 publicaciones de blog, un formulario de contacto y una puntuación móvil de Lighthouse de 35 — llegó a nosotros desesperado por velocidad. Su tráfico orgánico había estado disminuyendo durante meses. La actualización núcleo de Google de marzo de 2026, que introdujo puntuación holística de Core Web Vitals en todo el sitio, los golpeó duramente. Cada publicación de blog lenta estaba arrastrando a todo el dominio.

Los migramos a Next.js 15 + Payload CMS 3 + Supabase + Vercel. El resultado: Lighthouse móvil 94, escritorio 99. El tráfico orgánico se recuperó en 6 semanas. Esta es la historia completa de cómo llegamos allí — cada optimización, cada métrica, cada decisión — para que puedas aplicar el mismo pensamiento a tus propios proyectos.

Tabla de Contenidos

Caso de estudio de SleepDr: Migración de WordPress a Next.js (Lighthouse 35→94)

El Antes: Por qué WordPress estaba matando SleepDr

La configuración de WordPress de SleepDr era un ejemplo de manual de deuda técnica acumulada. Durante tres años, habían instalado 34 plugins. El tema cargaba jQuery más dos librerías JavaScript adicionales. Cada solicitud de página golpeaba una base de datos MySQL, generaba HTML sobre la marcha, y servía imágenes no optimizadas a través de un plan de hosting compartido que ya estaba luchando bajo la carga.

Aquí es cómo se veía la auditoría inicial de Lighthouse en móvil:

  • Puntuación general: 35 (rojo, fallando)
  • FCP: 4.2 segundos
  • LCP: 6.8 segundos — casi tres veces el umbral de "Bueno"
  • CLS: 0.28 — el diseño estaba saltando por todas partes debido a anuncios, imágenes sin dimensiones, y carga de fuentes web
  • TBT: 1.200ms — el hilo principal estaba bloqueado durante más de un segundo
  • TTFB: 2.1 segundos — el servidor en sí era lento antes de que algo se renderizara

El sitio no era solo lento. Era activamente hostil para usuarios en dispositivos móviles. Y dado que la simulación móvil de Lighthouse de Google imita un teléfono de gama media en una conexión 4G limitada, las puntuaciones reflejaban lo que los usuarios reales en condiciones menos que ideales estaban experimentando.

Después de que la actualización núcleo de Google de marzo de 2026 introdujo puntuación holística de CWV — agregando rendimiento en todo el dominio en lugar de por página — los 228 artículos de blog lentos de SleepDr estaban envenenando sus clasificaciones en todo el sitio. Los datos iniciales del lanzamiento mostraron caídas de tráfico del 20-35% para los sitios afectados. SleepDr vio aproximadamente una caída del 30%.

Algo tenía que cambiar.

La Pila de Migración: Por qué elegimos lo que elegimos

No elegimos esta pila porque esté de moda. La elegimos porque cada pieza resuelve un problema específico que SleepDr tenía.

  • Next.js 15 (App Router): Renderización híbrida. Generación estática para publicaciones de blog, renderización del lado del servidor cuando sea necesario. React Server Components para minimizar JavaScript del lado del cliente. Este es nuestro pan y mantequilla — hemos construido docenas de proyectos sobre él a través de nuestra práctica de desarrollo Next.js.
  • Payload CMS 3: CMS headless auto-hospedado que dio al equipo de contenidos de SleepDr la misma experiencia de edición a la que estaban acostumbrados con WordPress, menos el exceso de peso. Manejamos muchas implementaciones de CMS headless y Payload 3 se ha convertido en nuestro favorito para sitios con mucho contenido.
  • Supabase: Base de datos PostgreSQL con capacidades en tiempo real. Manejó los envíos de formularios de contacto, eventos de análisis, y cualquier dato dinámico.
  • Vercel: Despliegue en Edge. El sitio sirve desde el nodo más cercano al usuario. TTFB se vuelve casi insignificante.

La migración total tomó 7 semanas. La migración de contenido — los 228 posts con sus imágenes, metadatos y estructuras de URL — tomó aproximadamente 2 semanas de eso. Escribimos un script personalizado para extraer contenido de la API REST de WordPress, transformarlo, e insertarlo en Payload CMS.

Antes y Después: Los Números

Aquí está el desglose completo. Estas son puntuaciones de Lighthouse móvil, que es donde está la verdadera historia.

Métrica Antes (WordPress) Después (Next.js 15) Mejora
First Contentful Paint (FCP) 4.2s 1.1s -3.1s (74% más rápido)
Largest Contentful Paint (LCP) 6.8s 1.8s -5.0s (74% más rápido)
Cumulative Layout Shift (CLS) 0.28 0.01 -0.27 (reducción del 96%)
Total Blocking Time (TBT) 1.200ms 50ms -1.150ms (reducción del 96%)
Time to First Byte (TTFB) 2.1s 0.3s -1.8s (85% más rápido)
Puntuación móvil general 35 94 +59 puntos
Puntuación de escritorio general 61 99 +38 puntos

Quiero ser claro: estos no son números seleccionados arbitrariamente de una sola página. Ejecutamos Lighthouse en 20 páginas representativas y promediamos los resultados. La puntuación móvil osciló entre 91 y 97 en todas las páginas probadas. El escritorio fue de 97 a 100.

Ahora permíteme caminar a través de exactamente cómo logramos cada una de estas mejoras.

Caso de estudio de SleepDr: Migración de WordPress a Next.js (Lighthouse 35→94) - arquitectura

Optimización 1: Optimización de Imágenes (LCP -3s)

Las imágenes fueron el asesino de rendimiento más grande en el sitio antiguo. Las publicaciones de blog de SleepDr eran pesadas en fotografía de productos e infografías — a menudo subidas en resolución completa como PNG directamente de la máquina de un diseñador. Algunas imágenes eran de 3-4MB cada una.

Qué hicimos

Usamos next/image para cada imagen. Este componente hace mucho trabajo pesado:

import Image from 'next/image';

export function HeroImage({ src, alt }) {
  return (
    <Image
      src={src}
      alt={alt}
      width={1200}
      height={630}
      priority // Hero por encima del pliegue: precargarlo
      sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 1200px"
      quality={80}
    />
  );
}

Aquí está lo que next/image maneja automáticamente:

  • Conversión de formato: Sirve WebP (o AVIF donde sea compatible) en lugar de PNG/JPEG. Esto solo redujo los tamaños de imagen en un 60-80%.
  • srcset responsivo: Genera múltiples tamaños para que los usuarios móviles no descarguen imágenes de tamaño de escritorio.
  • Carga perezosa por defecto: Las imágenes por debajo del pliegue no se cargan hasta que el usuario se desplaza cerca de ellas.
  • Dimensiones explícitas: Los props width y height reservan espacio en el diseño, lo que corrige directamente CLS.

La idea clave: Carga prioritaria para elementos LCP

El prop priority en la imagen del héroe fue crítico. Sin él, Next.js carga la imagen de forma perezosa. Pero si la imagen del héroe es el elemento LCP — lo cual fue en la mayoría de las páginas de SleepDr — cargarla de forma perezosa en realidad perjudica tu puntuación de LCP. Quieres que comience a descargar inmediatamente.

Auditamos cada plantilla de página, identificamos el elemento LCP, y lo marcamos con priority. Las páginas de publicaciones de blog usaban la imagen destacada. La página de inicio usaba el banner del héroe. Simple, pero hizo una diferencia de 3 segundos en LCP.

CDN de imágenes

La optimización de imagen incorporada de Vercel sirve como CDN. Las imágenes se procesan y cachean en el edge en la primera solicitud. Los visitantes posteriores obtienen la versión almacenada en caché y optimizada en milisegundos. No se necesita suscripción a Cloudinary. No se necesita un plugin de WordPress tratando de hacer lo mismo pero peor.

Impacto neto: LCP bajó de 6.8s a aproximadamente 3.8s solo por optimización de imágenes. Las ganancias restantes de LCP vinieron de mejoras de TTFB y carga de fuentes.

Optimización 2: Optimización de Fuentes (FCP -1.5s)

El tema de WordPress de SleepDr cargaba tres Google Fonts a través de enlaces de hojas de estilo externas. Cada una era una solicitud de bloqueo de renderización a fonts.googleapis.com, seguida de otra solicitud a fonts.gstatic.com para los archivos de fuentes reales. Eso son seis viajes de ida y vuelta en la red antes de que el navegador pudiera pintar texto.

Qué hicimos

Fuentes auto-hospedadas 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',
});

Lo que next/font hace diferente:

  • Auto-hospeda los archivos de fuente: Sin solicitudes de red externas. Las fuentes se agrupan con la compilación y se sirven desde el mismo CDN.
  • Subsetting automático: Solo incluye los conjuntos de caracteres que realmente necesitas. El subset Latin de Inter es aproximadamente 20KB en lugar del archivo completo de 100KB+.
  • display: 'swap': El texto se renderiza inmediatamente con una fuente alternativa, luego cambia a la fuente web cuando se carga. Sin texto invisible. Sin cambio de contenido sin estilo que bloquee FCP.
  • Inyección de variable CSS: La fuente se aplica a través de propiedades CSS personalizadas, lo que significa cero cambio de diseño cuando la fuente cambia porque coincidimos cuidadosamente con las métricas de fuente alternativa.

También eliminamos la tercera fuente completamente. El sitio antiguo usaba una fuente decorativa para encabezados que añadía ruido visual sin mejorar la legibilidad. Dos fuentes. Eso es todo.

Impacto neto: FCP mejoró aproximadamente 1.5 segundos al eliminar solicitudes de fuentes de bloqueo de renderización.

Optimización 3: Reducción de JavaScript (TBT 1200ms → 50ms)

Esta fue la mejora de una sola cosa más dramática. Un TBT de 1.200ms significa que el hilo principal del navegador estaba bloqueado durante más de un segundo completo — el usuario no podía hacer clic, desplazarse, o interactuar con nada durante ese tiempo.

¿De dónde venía todo ese JavaScript?

El sitio de WordPress cargaba:

  • jQuery (87KB minificado) — usado por el tema y la mayoría de plugins
  • 34 scripts de plugin — formulario de contacto, análisis, compartir en redes sociales, consentimiento de cookies, dos bibliotecas de sliders diferentes, un lightbox, y más
  • JavaScript del tema — otros 150KB de toggle de menú y librerías de animación
  • Scripts inline — fragmentos aleatorios de varios plugins inyectados en el <head>

JavaScript total en la carga de página: aproximadamente 1.8MB. En una conexión móvil limitada, analizar y ejecutar eso toma bien más de un segundo.

Qué hicimos

Cero jQuery. Next.js usa React. No necesitamos jQuery.

Cero plugins. Cada característica fue reconstruida como un componente de propósito específico:

  • Formulario de contacto: componente React de 4KB + acción de servidor Supabase
  • Consentimiento de cookies: componente de 2KB con estrategia next/script
  • Compartir en redes sociales: API nativa de Web Share con enlaces de reserva — no se necesita biblioteca
  • Análisis: script ligero de Plausible (< 1KB)

Importaciones dinámicas para cualquier cosa por debajo del pliegue:

import dynamic from 'next/dynamic';

const NewsletterSignup = dynamic(
  () => import('@/components/NewsletterSignup'),
  { ssr: false } // Solo se carga en cliente, solo cuando sea necesario
);

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

React Server Components manejó la mayoría de la renderización. Contenido de publicaciones de blog, encabezados, pies de página, navegación — todo renderizado del lado del servidor con cero JavaScript del lado del cliente. Solo elementos interactivos (el toggle del menú móvil, formulario de contacto, signup del boletín) enviaban JS al navegador.

JavaScript total en la carga de página después de la migración: aproximadamente 85KB. Eso es una reducción del 95%.

Impacto neto: TBT bajó de 1.200ms a 50ms. El hilo principal es básicamente libre.

Optimización 4: Renderización del lado del servidor y despliegue en Edge (TTFB -85%)

TTFB mide cuánto tiempo tarda el servidor en comenzar a enviar el primer byte de la respuesta. El sitio de WordPress de SleepDr tenía un TTFB de 2.1 segundos en móvil. Eso significa que antes de cualquier cosa pueda suceder — antes de que carguen imágenes, antes de que descarguen fuentes, antes de que JavaScript se ejecute — el usuario estaba mirando una pantalla en blanco durante más de dos segundos esperando que el servidor respondiera.

Por qué WordPress era tan lento

Cada solicitud de página en WordPress:

  1. Golpeaba el servidor de hosting compartido (ya era lento)
  2. Cargaba PHP
  3. Ejecutaba el núcleo de WordPress
  4. Pasaba a través de 34 hooks de plugin
  5. Consultaba MySQL múltiples veces
  6. Generaba HTML dinámicamente
  7. Enviaba la respuesta

Incluso con WP Super Cache instalado, la tasa de acierto de caché era inconsistente y el servidor en sí era insuficiente.

Qué hicimos

Generación estática para los 228 artículos de blog. En tiempo de compilación, Next.js pre-renderiza cada artículo de blog a HTML estático. El resultado es un conjunto de archivos .html sentados en la Red Edge de Vercel — distribuidos a través de 80+ ubicaciones globales.

Cuando un usuario solicita un artículo de blog, se sirve un archivo HTML pre-construido desde el nodo edge más cercano. Sin consulta a base de datos. Sin procesamiento del lado del servidor. Solo una lectura de archivo desde un 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 la página del formulario de contacto, usamos renderización del lado del servidor ya que necesitaba comportamiento dinámico. Pero incluso SSR en Edge Functions de Vercel corre en menos de 100ms porque el cálculo sucede en el edge, no en un centro de datos centralizado.

Impacto neto: TTFB bajó de 2.1s a 0.3s — una mejora del 85%. En visitas repetidas con caching, es más cercano a 50ms.

Optimización 5: Gestión de scripts de terceros

Los scripts de terceros son los asesinos silenciosos del rendimiento web. El sitio de WordPress de SleepDr cargaba Google Analytics (GA4), Google Tag Manager, un pixel de Facebook, un script de grabación de Hotjar, y un gestor de consentimiento de cookies — todos de bloqueo de renderización en el <head>.

Qué hicimos

Next.js proporciona el componente next/script con estrategias de carga. Las usamos intencionalmente:

import Script from 'next/script';

{/* Analytics: cargarse después de que la página sea interactiva */}
<Script
  src="https://plausible.io/js/script.js"
  strategy="afterInteractive"
  data-domain="sleepdr.com"
/>

{/* Consentimiento de cookies: cargarse cuando el navegador esté inactivo */}
<Script
  src="/scripts/cookie-consent.js"
  strategy="lazyOnload"
/>

La estrategia afterInteractive carga el script después de que completa la hidratación de Next.js. El usuario ya puede ver e interactuar con la página. La estrategia lazyOnload espera hasta que el navegador esté completamente inactivo — excelente para scripts no críticos.

También reemplazamos Google Analytics con Plausible (< 1KB, enfocado en privacidad, no se requiere consentimiento de cookies en la mayoría de jurisdicciones). Eliminamos Hotjar completamente — SleepDr no estaba revisando las grabaciones. Removimos el pixel de Facebook ya que habían dejado de ejecutar anuncios de Facebook hace seis meses.

Matar scripts de terceros innecesarios es la victoria de rendimiento más fácil en desarrollo web. Sigo diciendo esto. La mayoría de sitios cargan scripts para servicios que nadie en el equipo está usando activamente.

Optimización 6: Optimización de CSS (800KB → 35KB)

El tema de WordPress de SleepDr envió aproximadamente 800KB de CSS. Eso incluía la hoja de estilo del tema, hojas de estilo de plugin, un sistema de cuadrícula completo de Bootstrap (sin usar), y Font Awesome (para aproximadamente 12 iconos).

Qué hicimos

Tailwind CSS con purga automática. Tailwind escanea tus archivos de plantilla en tiempo de compilación y genera CSS solo para las clases de utilidad que realmente usas. Nuestro bundle de CSS de producción: 35KB (comprimido: ~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 los 12 iconos, usamos SVGs inline. Sin biblioteca de iconos. Cada SVG es aproximadamente 500 bytes. Peso total de iconos: ~6KB versus Font Awesome de 70KB+.

El resultado es cero solicitudes de CSS de bloqueo de renderización. La salida de Tailwind se inserta en la carga de HTML inicial por Next.js, por lo que el navegador puede comenzar a renderizar inmediatamente.

Impacto neto: CSS reducido en un 96%, contribuyendo a mejoras de FCP y TBT.

Lista de verificación paso a paso

Si estás enfrentando problemas de rendimiento similares, aquí está el orden exacto en que abordaría las cosas. Esto se prioriza por relación impacto-esfuerzo.

Fase 1: Victorias rápidas (Semana 1)

  • Ejecuta Lighthouse en tus 10 páginas de mayor tráfico (modo móvil)
  • Identifica elementos LCP en cada plantilla de página
  • Añade width y height explícitos a todas las imágenes e iframes
  • Añade loading="lazy" a imágenes por debajo del pliegue
  • Añade fetchpriority="high" a imágenes LCP
  • Audita scripts de terceros — elimina cualquier cosa sin usar
  • Mueve scripts de terceros restantes a async o defer

Fase 2: Fuentes y CSS (Semana 2)

  • Auto-hospeda fuentes web (elimina solicitudes de fuentes externas)
  • Añade font-display: swap a todas las declaraciones @font-face
  • Subset fuentes a solo conjuntos de caracteres necesarios
  • Audita CSS — elimina hojas de estilo sin usar
  • Reemplaza fuentes de iconos con SVGs inline

Fase 3: JavaScript (Semana 3)

  • Analiza el bundle para identificar dependencias JS más grandes
  • Elimina jQuery si es posible
  • Importación dinámica de componentes no críticos
  • Aplaza JavaScript no esencial
  • Implementa code splitting por ruta

Fase 4: Infraestructura (Semana 4+)

  • Evalúa opciones de CDN / despliegue en edge
  • Implementa generación estática para páginas de contenido
  • Configura encabezados de caché apropiados
  • Considera migración completa a un framework moderno si WordPress es el cuello de botella

Si estás considerando ese último punto — una migración completa — comunícate con nosotros. Hemos hecho este tipo exacto de proyecto muchas veces. Nuestra página de precios tiene detalles sobre lo que típicamente cuestan las migraciones headless.

Qué significan los Core Web Vitals de 2026 para tu sitio

La actualización núcleo de Google de marzo de 2026 cambió las reglas. CWV ya no se evalúa por página — se agrega en todo tu dominio, ponderado por tráfico. Esto significa:

  • Una sola página de plantilla lenta usada por 200 artículos de blog hundiría la clasificación de tu sitio completo
  • Las páginas de alto tráfico llevan más peso en la puntuación agregada
  • No puedes solo optimizar tu página de inicio y considerarlo hecho

Los datos iniciales del lanzamiento muestran que sitios con CWV deficiente experimentaron caídas de tráfico orgánico del 20-35%. Algunos vieron pérdidas superiores al 50%. Los sitios que se recuperaron más rápido fueron aquellos que abordaron el rendimiento a nivel de infraestructura — no optimizando páginas individuales, sino arreglando la arquitectura subyacente.

Esto es exactamente por qué la migración de SleepDr fue tan efectiva. No optimizamos 228 páginas individuales de WordPress. Reconstruimos todo el sistema de entrega para que cada página sea rápida por defecto.

Para sitios que no están listos para una migración completa, frameworks como Astro ofrecen otro camino convincente — especialmente para sitios ricos en contenido donde quieres cero JavaScript por defecto.

Enfoque Costo típico Línea de tiempo Ganancia esperada de Lighthouse
Optimización de plugin de WordPress (WP Rocket, ShortPixel) $100-500/año 1-2 semanas +10-20 puntos
Reemplazo de tema de WordPress $2.000-5.000 2-4 semanas +15-25 puntos
Migración de CMS headless (Next.js/Astro) $15.000-50.000 4-10 semanas +30-60 puntos
Reconstrucción completa de plataforma $30.000-100.000+ 8-20 semanas +40-65 puntos

El proyecto de SleepDr cayó en el rango de $20.000-25.000 para la migración completa, incluyendo transferencia de contenido de los 228 posts, configuración de CMS, componentes personalizados, y optimización de rendimiento. El hosting en Vercel corre $20/mes en el plan Pro. Eso es aproximadamente $740/año en hosting versus los $300/año que estaban pagando por hosting compartido que no podía mantener TTFB por debajo de 2 segundos.

¿El ROI? Su tráfico orgánico se recuperó en 6 semanas y superó los niveles anteriores al declive en la semana 10. Para un negocio que depende de la búsqueda orgánica, la migración se pagó sola dentro del primer trimestre.

Preguntas frecuentes

¿Cuánto tiempo tarda para que mejoras de Core Web Vitals afecten las clasificaciones de Google? En nuestra experiencia con SleepDr y proyectos similares, Search Console comienza a mostrar datos de CWV actualizados dentro de 28 días del despliegue. Las mejoras de clasificación típicamente siguen 2-3 meses después. Google necesita re-rastrear tus páginas, recopilar datos de campo frescos de usuarios reales de Chrome (datos de CrUX), e incorporar eso en sus algoritmos de clasificación. No esperes resultados de un día para otro — pero sí espera mejora medible dentro de un trimestre.

¿Es una puntuación de Lighthouse de 94 realmente alcanzable para un sitio real en producción? Sí, pero requiere decisiones de arquitectura intencionales desde el inicio. Las puntuaciones de laboratorio por encima de 90 en móvil son alcanzables con frameworks modernos como Next.js o Astro cuando controlas tus scripts de terceros, optimizas imágenes correctamente, y despliegas en una red edge. La clave es que cada componente debe ser consciente del rendimiento. Un embed malo o un widget de terceros no optimizado puede devolverte a los 70s.

¿Necesito migrar lejos de WordPress para obtener buenas puntuaciones de Core Web Vitals? No necesariamente. Los sitios de WordPress pueden puntuar bien con el tema correcto, caching agresivo (WP Rocket + Cloudflare), hosting optimizado (Kinsta, WP Engine), y plugins mínimos. Realísticamente sin embargo, la mayoría de sitios de WordPress que auditamos puntúan entre 30-60 en móvil debido a acumulación de plugin bloat y overhead de tema. Si estás por debajo de 50, la optimización de plugin sola probablemente no te llevará por encima de 75. Un enfoque headless — donde WordPress sirve como una API de contenido mientras un framework de frontend maneja la renderización — a menudo es el término medio que vale la pena explorar.

¿Cuál es la diferencia entre puntuaciones de Lighthouse y datos reales de Core Web Vitals? Lighthouse es una herramienta de laboratorio — simula un teléfono de gama media en 4G limitado y te da puntuaciones sintéticas. Core Web Vitals en Search Console son datos de campo — mediciones reales de usuarios reales de Chrome visitando tu sitio durante una ventana rodante de 28 días. Google usa datos de campo para señales de clasificación, no puntuaciones de laboratorio. Lighthouse es útil para diagnosticar problemas y probar correcciones, pero tu objetivo es estado de CWV verde en Search Console en el percentil 75.

¿Cuál es la optimización de una sola cosa más impactante para LCP? Optimización de imágenes. En aproximadamente el 60% de los sitios que auditamos, el elemento LCP es una imagen. Dimensionarla correctamente, servirla en formato WebP/AVIF, añadirle fetchpriority="high", y asegurar que no se cargue de forma perezosa típicamente cortará LCP en 2-4 segundos. En SleepDr, la optimización de imágenes sola representó aproximadamente 3 segundos de mejora de LCP.

¿Cómo funciona la puntuación holística de CWV de Google de 2026? Desde la actualización núcleo de Google de marzo de 2026, Google agrega datos de Core Web Vitals en todo tu dominio en lugar de evaluar páginas individualmente. Las páginas de alto tráfico llevan más peso en el cálculo. Esto significa que una plantilla lenta de archivo de blog usada en cientos de páginas hundiría tus clasificaciones de página de inicio también. La corrección es arquitectónica — necesitas que cada plantilla de página pase umbrales de CWV, no solo tus páginas de destino clave.

¿Cuánto típicamente cuesta una migración de WordPress a Next.js? Para un sitio de contenido similar a SleepDr (200+ páginas, diseño de blog estándar, formularios de contacto, sin e-commerce), espera $15.000-30.000 de una agencia experimentada. Las migraciones de e-commerce corren más alto — $30.000-75.000+ dependiendo de complejidad. El hosting continuo en Vercel Pro es $20/mes. El ROI depende de cuánto valga el tráfico orgánico para tu negocio, pero para sitios que experimentaron caídas de tráfico por CWV deficiente, la migración típicamente se paga sola dentro de 3-6 meses.

¿Debo enfocarme en puntuaciones de Lighthouse móvil o de escritorio? Móvil. Siempre móvil primero. Google usa indexación mobile-first, y la puntuación móvil de Lighthouse es significativamente más punitivva que la de escritorio porque simula un dispositivo y red restringidos. Si tu puntuación móvil es 94, tu puntuación de escritorio será casi con certeza 95+. La puntuación de escritorio de SleepDr de 99 no requirió trabajo adicional más allá de lo que hicimos para optimización móvil.