Tabla de Contenidos

Tu panel de WordPress se abre con 228 entradas de blog, una puntuación Lighthouse móvil de 35 y un gráfico de tráfico que lleva tres meses descendiendo. SleepDr.com -- un sitio de contenido sobre salud del sueño -- vio caer sus visitas orgánicas un 41% tras la Actualización Principal de Google de marzo de 2026, que introdujo la puntuación de Core Web Vitals a nivel de todo el sitio. Cada publicación lenta era ahora una carga, arrastrando hacia abajo páginas que por sí solas cargaban bien. El cliente necesitaba velocidad en todo el dominio, no solo en la página de inicio. Migramos la biblioteca completa de contenido a Next.js 15, Payload CMS 3 y Vercel -- y elevamos su Lighthouse móvil a 94 en seis semanas. Aquí está el stack que elegimos, los tres cuellos de botella de rendimiento que eliminamos y la métrica que más importó.

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 lo logramos -- cada optimización, cada métrica, cada decisión -- para que puedas aplicar el mismo razonamiento a tus propios proyectos.

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

El Antes: Por Qué WordPress Estaba Destruyendo SleepDr

La configuración de WordPress de SleepDr era un ejemplo de libro de texto de deuda técnica acumulada. En tres años, habían instalado 34 plugins. El tema cargaba jQuery más dos bibliotecas JavaScript adicionales. Cada solicitud de página golpeaba una base de datos MySQL, generaba HTML al vuelo y servía imágenes sin optimizar a través de un plan de alojamiento compartido que ya estaba luchando bajo la carga.

Así era la auditoría inicial de Lighthouse en móvil:

  • Puntuación General: 35 (rojo, reprobado)
  • FCP: 4.2 segundos
  • LCP: 6.8 segundos -- casi tres veces el umbral "Bueno"
  • CLS: 0.28 -- el diseño saltaba por todas partes a causa de 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 se renderizara cualquier cosa

El sitio no era solo lento. Era activamente hostil para los 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 no ideales estaban experimentando.

Tras la Actualización Principal de Google de marzo de 2026, que introdujo la puntuación holística de CWV -- agregando el rendimiento en todo el dominio en lugar de por página -- las 228 entradas de blog lentas de SleepDr estaban envenenando sus rankings en todo el sitio. Los datos preliminares del lanzamiento mostraron caídas de tráfico del 20-35% para los sitios afectados. SleepDr experimentó aproximadamente un 30% de declive.

Algo tenía que cambiar.

El Stack de Migración: Por Qué Elegimos lo que Elegimos

No elegimos este stack porque esté de moda. Lo elegimos porque cada pieza resuelve un problema específico que tenía SleepDr.

  • Next.js 15 (App Router): Renderizado híbrido. Generación estática para entradas de blog, renderizado del lado del servidor donde se necesita. React Server Components para minimizar el JavaScript del lado del cliente. Este es nuestro pan de cada día -- hemos construido docenas de proyectos sobre él a través de nuestra práctica de desarrollo en Next.js.
  • Payload CMS 3: CMS headless autoalojado que le dio al equipo de contenido de SleepDr la misma experiencia de edición a la que estaban acostumbrados con WordPress, sin el bloat. Gestionamos muchas implementaciones de CMS headless y Payload 3 se ha convertido en nuestra opción preferida para sitios con mucho contenido.
  • Supabase: Base de datos PostgreSQL con capacidades en tiempo real. Gestionó los envíos del formulario de contacto, los eventos de analítica y cualquier dato dinámico.
  • Vercel: Despliegue en edge. El sitio se sirve desde el nodo más cercano al usuario. El TTFB se vuelve casi insignificante.

La migración completa tardó 7 semanas. La migración de contenido -- las 228 publicaciones con sus imágenes, metadatos y estructuras de URL -- ocupó unas 2 semanas de ese tiempo. Escribimos un script personalizado para extraer el contenido de la API REST de WordPress, transformarlo e introducirlo en Payload CMS.

Antes y Después: Los Números

Aquí está el desglose completo. Estas son las puntuaciones Lighthouse en 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 Escritorio General 61 99 +38 puntos

Quiero ser claro: estos no son números seleccionados a dedo 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 analizadas. En escritorio fue de 97 a 100.

Ahora déjame explicarte exactamente cómo logramos cada una de estas mejoras.

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

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

Las imágenes eran el mayor asesino del rendimiento en el sitio antiguo. Las entradas del blog de SleepDr estaban cargadas de fotografías de productos e infografías -- a menudo subidas como PNGs de resolución completa directamente desde la máquina de un diseñador. Algunas imágenes pesaban 3-4MB cada una.

Lo que Hicimos

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

import Image from 'next/image';

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

Esto es lo que next/image gestiona automáticamente:

  • Conversión de formato: Sirve WebP (o AVIF donde sea compatible) en lugar de PNG/JPEG. Esto por sí solo redujo el tamaño de las imágenes entre un 60-80%.
  • srcset responsive: Genera múltiples tamaños para que los usuarios móviles no descarguen imágenes de tamaño escritorio.
  • Carga diferida 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 el CLS.

La Clave: Carga Prioritaria para los Elementos LCP

El prop priority en la imagen hero fue fundamental. Sin él, Next.js carga la imagen de forma diferida. Pero si la imagen hero es el elemento LCP -- que lo era en la mayoría de las páginas de SleepDr -- cargarla de forma diferida en realidad perjudica tu puntuación LCP. Quieres que empiece a descargarse de inmediato.

Auditamos cada plantilla de página, identificamos el elemento LCP y lo marcamos con priority. Las páginas de entradas de blog usaban la imagen destacada. La página de inicio usaba el banner hero. Simple, pero marcó una diferencia de 3 segundos en el LCP.

CDN de Imágenes

La optimización de imágenes integrada de Vercel actúa como CDN. Las imágenes se procesan y almacenan en caché en el edge en la primera solicitud. Los visitantes posteriores obtienen la versión en caché y optimizada en milisegundos. Sin suscripción a Cloudinary. Sin plugin de WordPress intentando hacer lo mismo pero peor.

Impacto neto: el LCP bajó de 6.8s a aproximadamente 3.8s solo gracias a la optimización de imágenes. Las ganancias restantes en LCP provinieron de las mejoras en TTFB y la carga de fuentes.

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

El tema de WordPress de SleepDr cargaba tres Google Fonts mediante enlaces de hojas de estilo externas. Cada una era una solicitud bloqueante del renderizado a fonts.googleapis.com, seguida de otra solicitud a fonts.gstatic.com para los archivos de fuente reales. Eso son seis viajes de red de ida y vuelta antes de que el navegador pudiera pintar texto.

Lo que Hicimos

Fuentes autoalojadas 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 hace next/font de manera diferente:

  • Autoaloja los archivos de fuente: Sin solicitudes de red externas. Las fuentes se incluyen en el build y se sirven desde el mismo CDN.
  • Subsetting automático: Solo incluye los conjuntos de caracteres que realmente necesitas. El subconjunto Latin de Inter pesa unos 20KB en lugar del archivo completo de más de 100KB.
  • display: 'swap': El texto se renderiza inmediatamente con una fuente de reserva, luego cambia a la fuente web cuando se carga. Sin texto invisible. Sin parpadeo de contenido sin estilo que bloquee el FCP.
  • Inyección de variables CSS: La fuente se aplica mediante propiedades personalizadas de CSS, lo que significa cero cambio de diseño cuando se intercambia la fuente, porque emparejamos cuidadosamente las métricas de la fuente de reserva.

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

Impacto neto: el FCP mejoró aproximadamente 1.5 segundos al eliminar las solicitudes de fuentes que bloqueaban el renderizado.

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

Esta fue la mejora individual más dramática. Un TBT de 1,200ms significa que el hilo principal del navegador estuvo bloqueado durante más de un segundo completo -- el usuario no podía hacer clic, desplazarse ni interactuar con nada durante ese tiempo.

¿De Dónde Venía Todo Ese JavaScript?

El sitio WordPress cargaba:

  • jQuery (87KB minificado) -- usado por el tema y la mayoría de los plugins
  • 34 scripts de plugins -- formulario de contacto, analítica, compartir en redes sociales, consentimiento de cookies, dos bibliotecas de slider diferentes, un lightbox y más
  • JavaScript del tema -- otros 150KB de menús desplegables y bibliotecas de animación
  • Scripts en línea -- 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 lleva más de un segundo.

Lo que Hicimos

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

Cero plugins. Cada funcionalidad se reconstruyó como un componente específico:

  • Formulario de contacto: componente React de 4KB + acción de servidor de Supabase
  • Consentimiento de cookies: componente de 2KB con estrategia next/script
  • Compartir en redes sociales: API nativa Web Share con enlaces de respaldo -- sin biblioteca necesaria
  • Analítica: script ligero de Plausible (< 1KB)

Importaciones dinámicas para todo lo que está por debajo del pliegue:

import dynamic from 'next/dynamic';

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

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

Los React Server Components gestionaron la mayor parte del renderizado. El contenido de las entradas de blog, encabezados, pies de página, navegación -- todo renderizado en el servidor con cero JavaScript del lado del cliente. Solo los elementos interactivos (el botón de menú móvil, el formulario de contacto, el registro al boletín) enviaron JS al navegador.

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

Impacto neto: el TBT bajó de 1,200ms a 50ms. El hilo principal está básicamente libre.

Optimización 4: Renderizado del Lado del Servidor y Despliegue en Edge (TTFB -85%)

El TTFB mide cuánto tiempo tarda el servidor en comenzar a enviar el primer byte de la respuesta. El sitio WordPress de SleepDr tenía un TTFB de 2.1 segundos en móvil. Eso significa que antes de que cualquier cosa pudiera suceder -- antes de que cargaran las imágenes, antes de que se descargaran las fuentes, antes de que se ejecutara JavaScript -- el usuario miraba 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 alojamiento compartido (ya lento)
  2. Cargaba PHP
  3. Ejecutaba el núcleo de WordPress
  4. Pasaba por los hooks de 34 plugins
  5. Consultaba MySQL varias veces
  6. Generaba HTML dinámicamente
  7. Enviaba la respuesta

Incluso con WP Super Cache instalado, la tasa de aciertos de caché era inconsistente y el servidor en sí tenía poca potencia.

Lo que Hicimos

Generación estática para las 228 entradas de blog. En el momento de la compilación, Next.js pre-renderiza cada entrada de blog a HTML estático. El resultado es un conjunto de archivos .html que residen en la Edge Network de Vercel -- distribuidos en más de 80 ubicaciones globales.

Cuando un usuario solicita una entrada de blog, recibe un archivo HTML pre-construido desde el nodo edge más cercano. Sin consulta a la 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 renderizado del lado del servidor ya que necesitaba comportamiento dinámico. Pero incluso el SSR en las Edge Functions de Vercel se ejecuta en menos de 100ms porque el cómputo ocurre en el edge, no en un centro de datos centralizado.

Impacto neto: el TTFB bajó de 2.1s a 0.3s -- una mejora del 85%. En visitas repetidas con caché, se acerca a los 50ms.

Optimización 5: Gestión de Scripts de Terceros

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

Lo que Hicimos

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

import Script from 'next/script';

{/* Analítica: cargar 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: cargar cuando el navegador esté inactivo */}
<Script
  src="/scripts/cookie-consent.js"
  strategy="lazyOnload"
/>

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

También reemplazamos Google Analytics por Plausible (< 1KB, centrado en la privacidad, sin necesidad de consentimiento de cookies en la mayoría de jurisdicciones). Eliminamos Hotjar por completo -- SleepDr no estaba revisando realmente las grabaciones. Eliminamos el píxel de Facebook ya que habían dejado de ejecutar anuncios en Facebook seis meses antes.

Eliminar scripts de terceros innecesarios es la mejora de rendimiento más fácil en el desarrollo web. Lo sigo repitiendo. La mayoría de los sitios cargan scripts para servicios que nadie en el equipo está usando activamente.

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

El tema WordPress de SleepDr incluía aproximadamente 800KB de CSS. Eso incluía la hoja de estilos del tema, hojas de estilos de plugins, un sistema de rejilla Bootstrap completo (sin usar) y Font Awesome (para unos 12 iconos).

Lo que Hicimos

Tailwind CSS con purga automática. Tailwind analiza tus archivos de plantilla en el momento de la compilación y genera CSS solo para las clases de utilidad que realmente usas. Nuestro bundle de CSS en producción: 35KB (gzipeado: ~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 en línea. Sin biblioteca de iconos. Cada SVG pesa unos 500 bytes. Peso total de iconos: ~6KB frente a los 70KB+ de Font Awesome.

El resultado es cero solicitudes de CSS que bloqueen el renderizado. La salida de Tailwind se incluye en línea en el payload HTML inicial por Next.js, para que el navegador pueda comenzar a renderizar de inmediato.

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

La Lista de Verificación Paso a Paso

Si te enfrentas a problemas de rendimiento similares, aquí está el orden exacto en que yo abordaría las cosas. Está priorizado por la relación impacto-esfuerzo.

Fase 1: Victorias Rápidas (Semana 1)

  • Ejecutar Lighthouse en tus 10 páginas con más tráfico (modo móvil)
  • Identificar los elementos LCP en cada plantilla de página
  • Añadir width y height explícitos a todas las imágenes e iframes
  • Añadir loading="lazy" a las imágenes por debajo del pliegue
  • Añadir fetchpriority="high" a las imágenes LCP
  • Auditar scripts de terceros -- eliminar todo lo que no se use
  • Mover los scripts de terceros restantes a async o defer

Fase 2: Fuentes y CSS (Semana 2)

  • Autoalojar fuentes web (eliminar solicitudes de fuentes externas)
  • Añadir font-display: swap a todas las declaraciones @font-face
  • Hacer subsetting de fuentes a solo los conjuntos de caracteres necesarios
  • Auditar CSS -- eliminar hojas de estilos no utilizadas
  • Reemplazar fuentes de iconos con SVGs en línea

Fase 3: JavaScript (Semana 3)

  • Analizar el bundle para identificar las dependencias JS más grandes
  • Eliminar jQuery si es posible
  • Importar dinámicamente los componentes no críticos
  • Diferir el JavaScript no esencial
  • Implementar code splitting por ruta

Fase 4: Infraestructura (Semana 4+)

  • Evaluar opciones de CDN / despliegue en edge
  • Implementar generación estática para páginas de contenido
  • Configurar cabeceras de caché adecuadas
  • Considerar la 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 -- contáctanos. Hemos realizado exactamente este tipo de proyecto muchas veces. Nuestra página de precios tiene detalles sobre lo que suelen costar las migraciones headless.

Qué Significan los Core Web Vitals de 2026 para Tu Sitio

La Actualización Principal de Google de marzo de 2026 cambió las reglas del juego. Los CWV ya no se evalúan por página -- se agregan en todo tu dominio, ponderados por tráfico. Esto significa:

  • Una sola plantilla de página lenta utilizada por 200 entradas de blog hundirá los rankings de todo tu sitio
  • Las páginas con mucho tráfico tienen más peso en la puntuación agregada
  • No puedes optimizar solo tu página de inicio y darlo por hecho

Los datos preliminares del lanzamiento muestran que los sitios con CWV deficientes experimentaron caídas de tráfico orgánico del 20-35%. Algunos vieron pérdidas de más del 50%. Los sitios que se recuperaron más rápido fueron los que abordaron el rendimiento a nivel de infraestructura -- no modificando páginas individuales, sino corrigiendo 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 con mucho contenido donde quieres casi cero JavaScript por defecto.

Enfoque Coste Típico Plazo Ganancia Esperada en Lighthouse
Optimización con plugins 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 a 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 se situó en el rango de $20,000-25,000 para la migración completa, incluyendo la transferencia de contenido de las 228 publicaciones, la configuración del CMS, los componentes personalizados y la optimización del rendimiento. El alojamiento en Vercel cuesta $20/mes en el plan Pro. Eso es aproximadamente $740/año en alojamiento frente a los $300/año que pagaban por un alojamiento compartido que no podía mantener el TTFB por debajo de 2 segundos.

¿El retorno de la inversión? Su tráfico orgánico se recuperó en 6 semanas y superó los niveles previos 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.

FAQ

¿Cuánto tiempo tardan las mejoras en Core Web Vitals en afectar los rankings de Google?

En nuestra experiencia con SleepDr y proyectos similares, Search Console comienza a mostrar datos de CWV actualizados dentro de los 28 días posteriores al despliegue. Las mejoras en el ranking típicamente siguen 2-3 meses después. Google necesita volver a rastrear tus páginas, recopilar datos de campo frescos de usuarios reales de Chrome (datos de CrUX) y tener eso en cuenta en sus algoritmos de ranking. No esperes resultados inmediatos -- pero sí espera mejoras medibles dentro de un trimestre.

¿Es realmente alcanzable una puntuación Lighthouse de 94 para un sitio en producción real?

Sí, pero requiere decisiones arquitectónicas intencionales desde el principio. 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 las imágenes correctamente y despliegas en una red edge. La clave es que cada componente debe ser consciente del rendimiento. Un mal embed o un widget de terceros sin optimizar puede hacerte retroceder a los 70.

¿Necesito migrarme de WordPress para obtener buenas puntuaciones en Core Web Vitals?

No necesariamente. Los sitios WordPress pueden puntuar bien con el tema adecuado, caché agresivo (WP Rocket + Cloudflare), alojamiento optimizado (Kinsta, WP Engine) y plugins mínimos. En la práctica, sin embargo, la mayoría de los sitios WordPress que auditamos puntúan entre 30-60 en móvil debido al bloat acumulado de plugins y la sobrecarga del tema. Si estás por debajo de 50, la optimización de plugins por sí sola probablemente no te llevará por encima de 75. Un enfoque headless -- donde WordPress actúa como API de contenido mientras un framework frontend gestiona el renderizado -- es a menudo el punto medio que vale la pena explorar.

¿Cuál es la diferencia entre las puntuaciones de Lighthouse y los 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. Los Core Web Vitals en Search Console son datos de campo -- mediciones reales de usuarios reales de Chrome que visitan tu sitio durante una ventana continua de 28 días. Google usa datos de campo para las señales de ranking, no puntuaciones de laboratorio. Lighthouse es útil para diagnosticar problemas y probar soluciones, pero tu objetivo es el estado verde de CWV en Search Console en el percentil 75.

¿Cuál es la optimización individual más impactante para el LCP?

La 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ñadir fetchpriority="high" y asegurarse de que no cargue de forma diferida típicamente reducirá el LCP entre 2-4 segundos. En SleepDr, la optimización de imágenes por sí sola supuso aproximadamente 3 segundos de mejora en el LCP.

¿Cómo funciona la puntuación holística de CWV de Google en 2026?

Desde la Actualización Principal de marzo de 2026, Google agrega los datos de Core Web Vitals en todo tu dominio en lugar de evaluar las páginas individualmente. Las páginas con mucho tráfico tienen más peso en el cálculo. Esto significa que una plantilla de blog lenta usada en cientos de páginas también arrastrará hacia abajo los rankings de tu página de inicio. La solución es arquitectónica -- necesitas que cada plantilla de página supere los umbrales de CWV, no solo tus páginas de destino clave.

¿Cuánto cuesta típicamente una migración de WordPress a Next.js?

Para un sitio de contenido similar a SleepDr (más de 200 páginas, diseño de blog estándar, formularios de contacto, sin e-commerce), espera entre $15,000-30,000 de una agencia con experiencia. Las migraciones de e-commerce son más costosas -- $30,000-75,000+ según la complejidad. El alojamiento continuo en Vercel Pro es de $20/mes. El retorno de la inversión depende de cuánto vale el tráfico orgánico para tu negocio, pero para sitios que experimentaron caídas de tráfico por CWV deficientes, la migración típicamente se paga sola en 3-6 meses.

¿Debo enfocarme en las puntuaciones Lighthouse móvil o 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 exigente que la de escritorio porque simula un dispositivo y red con restricciones. Si tu puntuación móvil es 94, tu puntuación de escritorio casi con certeza será 95+. La puntuación de escritorio de SleepDr de 99 no requirió ningún trabajo adicional más allá de lo que hicimos para la optimización móvil.

Conclusión clave:

La optimización de imágenes en Next.js reduce el LCP al eliminar los activos sin comprimir y de tamaño excesivo.