Instalaste WP Rocket. Tu puntuación de Lighthouse subió de 35 a 52. Agregaste Autoptimize. De 52 a 58. Instalaste Perfmatters. Ahora estás ejecutando TRES plugins de rendimiento -- cada uno agregando su propio JavaScript -- para resolver problemas de rendimiento causados por otros plugins que agregan JavaScript. ¿Ves la ironía?

He estado exactamente en este lugar más veces de las que me gustaría admitir. Pasas un fin de semana completo ajustando configuraciones de WP Rocket, generando CSS crítico, diferiendo scripts, cargando imágenes de forma perezosa, habilitando precarga, configurando un CDN. Ejecutas Lighthouse nuevamente. 54. Quizás 58 en un buen día. Verificas la competencia -- están en 90+. Te preguntas qué estás haciendo mal.

Aquí está la cosa: no estás haciendo nada mal. Has alcanzado el techo de rendimiento de WordPress. Es real, está bien documentado, y ninguna combinación de plugins de almacenamiento en caché puede romperlo. El problema no es tu configuración. Es la arquitectura.

Este artículo desglosa exactamente por qué el almacenamiento en caché no puede arreglar el rendimiento de WordPress, qué está causando realmente tus puntuaciones bajas métrica por métrica, y cómo migramos un cliente real -- SleepDr -- de una puntuación de Lighthouse de 35 a 94 cambiando la arquitectura por completo.

Tabla de Contenidos

• La Paradoja del Plugin de Rendimiento
• CSS de Bloqueo de Representación: El Almacenamiento en Caché lo Sirve Más Rápido, No Más Pequeño
• Exceso de JavaScript: jQuery y el Impuesto del Constructor de Páginas
• Sobrecarga de Consultas de Base de Datos: El Problema de la Primera Solicitud
• Representación del Lado del Servidor: El Cuello de Botella Estructural de PHP
• Entendiendo tu Desglose de Puntuación de Lighthouse
• Caso de Estudio: Migración de SleepDr -- WordPress a Next.js
• La Arquitectura que Realmente Arregla el Rendimiento
• Cuándo Tiene Sentido la Migración (Y Cuándo No)
• Preguntas Frecuentes

La Paradoja del Plugin de Rendimiento

Déjame pintarte una imagen que veo cada mes. El dueño de un sitio se comunica porque su sitio de WordPress obtiene entre 35 y 55 en Lighthouse. Ya han instalado alguna combinación de estos plugins:

• WP Rocket ($59/año) -- almacenamiento en caché de páginas, minificación de CSS/JS, carga perezosa
• Autoptimize (gratis) -- agregación CSS/JS, CSS crítico
• Perfmatters ($24.95/año) -- administrador de scripts, limpieza de base de datos
• Asset CleanUp (gratis) -- carga condicional de activos
• Flying Scripts (gratis) -- retraso en la ejecución de JavaScript

Eso son cinco plugins cuyo único propósito es hacer que WordPress funcione como debería de forma predeterminada. Cada uno agrega su propia sobrecarga de ejecución de PHP. Cada uno escribe sus propias reglas en .htaccess. Algunos entran en conflicto entre sí de maneras sutiles que solo aparecen bajo carga real.

¿El mejor escenario? Pasas de 35 a quizás 65. He visto equipos gastar 40+ horas ajustando estos plugins y sus diversas interacciones. Eso es una semana de tiempo de desarrollador -- fácilmente $4,000-$8,000 en trabajo -- para ganar 20-30 puntos de Lighthouse y aún así no alcanzar umbrales de "buenos" Core Web Vitals.

Y aquí está lo que nadie habla: esas páginas en caché solo ayudan a los visitantes que regresan. ¿El primer golpe? Aún lento. ¿Un rastreo de Googlebot? Probablemente golpeando páginas sin caché. Tu tráfico más importante -- nuevos visitantes de búsqueda -- obtiene la peor experiencia.

CSS de Bloqueo de Representación: El Almacenamiento en Caché lo Sirve Más Rápido, No Más Pequeño

Este es el primer muro que golpearás, y es el que la mayoría de las personas malentiende.

Un tema típico de WordPress carga entre 200KB y 800KB de CSS en cada página. No estoy exagerando. Aquí está lo que contribuye:

• Hoja de estilo del tema: 150-400KB (Los temas Divi, Avada y Elementor son los peores infractores)
• Hojas de estilo de plugins: 50-200KB (formularios de contacto, deslizadores, uso compartido social, plugins SEO)
• Google Fonts: 30-100KB (a menudo cargando 3-5 pesos de fuente que no usas)
• Bibliotecas de iconos: 50-80KB (cargando todo Font Awesome para 6 iconos)

Aquí está la estadística crítica: aproximadamente el 70% de este CSS no se usa en ninguna página determinada. Tu página de inicio no necesita los estilos del carrito de WooCommerce. Tu publicación de blog no necesita el CSS del formulario de contacto. Pero WordPress carga todo, en todas partes, todo de una vez.

¿Qué hace WP Rocket al respecto? Minifica el CSS (ahorra quizás 10-15%), combina archivos para reducir solicitudes HTTP, y genera CSS crítico para contenido superior al pliegue. Eso es genuinamente útil. Pero el navegador aún descarga todos los 400KB+. Aún analiza todo. El CSS no utilizado aún contribuye a retrasos de FCP.

WP Rocket no puede hacer tree-shake de tu CSS. No puede determinar qué estilos se necesitan por página y eliminar el resto. Eso requeriría entender la relación entre tu HTML y CSS en tiempo de compilación -- que es exactamente lo que hacen los marcos modernos.

Cómo Next.js + Tailwind Realmente Resuelve Esto

Con Next.js y Tailwind CSS, los estilos no utilizados se purgan en tiempo de compilación. No diferidos. No minificados. Eliminados completamente. El proceso de compilación escanea tus plantillas, identifica qué clases de utilidad se usan realmente, y genera un archivo CSS que contiene solo esos estilos.

¿El resultado? Carga útil CSS total: 15-40KB para un sitio completo. No por página -- para todo el sitio. Eso no es una mejora marginal. Es una diferencia de orden de magnitud.

/* WordPress: carga todo */
/* theme.min.css: 387KB */
/* elementor-frontend.min.css: 142KB */
/* woocommerce.min.css: 98KB */
/* contact-form-7.min.css: 12KB */
/* Total: 639KB CSS, ~70% no utilizado en cualquier página */

/* Next.js + Tailwind: construye solo lo que se usa */
/* globals.css: 22KB (sitio completo) */
/* CSS por página: 0KB adicional (está todo en el paquete purgado) */

Exceso de JavaScript: jQuery y el Impuesto del Constructor de Páginas

Aquí es donde TBT -- Total Blocking Time -- se destruye. Y TBT es el 30% de tu puntuación de rendimiento de Lighthouse. Literalmente no puedes estar por encima de 70 con mal TBT.

WordPress incluye jQuery en cada página. Eso es 87KB minificado y comprimido con gzip. Se ejecuta de forma síncrona en el hilo principal. Cada carga de página paga este impuesto, incluso si ninguna funcionalidad en la página requiere jQuery.

Pero jQuery es solo el aperitivo. Aquí está el presupuesto de JavaScript para un sitio típico de constructor de páginas de WordPress:

Fuente	Tamaño (minificado + gzip)	Tiempo del Hilo Principal
jQuery + jQuery Migrate	87KB + 10KB	150-300ms
Frontend de Elementor	180-350KB	200-500ms
WP Rocket (sí, en serio)	15-25KB	30-60ms
Plugin de deslizador	80-150KB	100-250ms
Analytics + rastreo	50-120KB	80-200ms
Otros plugins	50-200KB	100-300ms
Total	462KB - 855KB	660ms - 1,610ms

Eso es 660ms a 1.6 segundos de bloqueo de hilo principal solo por ejecución de JavaScript. Lighthouse quiere TBT por debajo de 200ms para una buena puntuación. Por debajo de 600ms para "necesita mejora". Ya estás fuera de rango antes de que tu contenido real se represente.

¿Qué pueden hacer los plugins de almacenamiento en caché? Pueden minificar (ahorra 5-10%), diferir ejecución (ayuda a FCP pero TBT se mantiene igual porque el trabajo aún sucede), y retrasar scripts hasta la interacción del usuario (lo cual rompe la funcionalidad y crea una experiencia desagradable cuando los usuarios hacen clic en algo y nada sucede durante 500ms).

Next.js: Cero jQuery, División Inteligente de Código

Next.js no carga jQuery. Punto. No hay equivalente. React maneja la manipulación del DOM, y ya está en el paquete para interactividad. Pero aquí está la verdadera victoria: división automática de código.

Cada página solo carga el JavaScript que necesita. Una página "About" estática podría enviar 30KB de JS total. Tu página de formulario de reserva interactivo carga la biblioteca de formularios solo en esa página. Las importaciones dinámicas significan que los componentes pesados se cargan bajo demanda.

// Solo carga el calendario de reserva cuando este componente se representa
import dynamic from 'next/dynamic'

const BookingCalendar = dynamic(() => import('../components/BookingCalendar'), {
  loading: () => <div className="h-96 animate-pulse bg-gray-100 rounded" />,
  ssr: false // No incluyas ni siquiera en el paquete del servidor
})

export default function BookingPage() {
  return (
    <main>
      <h1>Programa tu Consulta</h1>
      <BookingCalendar />
    </main>
  )
}

Esa bandera ssr: false significa que el JavaScript del calendario ni siquiera existe en la carga inicial de página. Los usuarios ven un marcador de posición al instante, luego el componente interactivo se hidrata. TBT se mantiene minimal.

Sobrecarga de Consultas de Base de Datos: El Problema de la Primera Solicitud

Cada carga de página de WordPress desencadena consultas de base de datos. No unas pocas. Muchas.

Instalé Query Monitor en el sitio de un cliente el año pasado -- una configuración bastante estándar de WordPress + WooCommerce + Yoast. Aquí está lo que una única carga de página de inicio generó:

• Núcleo de WordPress: 8-12 consultas (opciones, sesión del usuario, reglas de reescritura)
• Yoast SEO: 15+ consultas (datos meta, configuración de esquema, migas de pan)
• WooCommerce: 20+ consultas (datos del producto, carrito, sesión)
• Opciones del tema: 10-15 consultas (configuración del personalizador, datos de widgets)
• Representación de menú: 5-8 consultas (elementos de menú anidados, meta)
• Widgets de la barra lateral: 5-10 consultas por widget

Total: 63-80 consultas de base de datos para una sola carga de página. En alojamiento compartido con una base de datos MySQL que también sirve a otros 200 sitios? Puedes ver a dónde va esto.

El almacenamiento en caché de páginas de WP Rocket elimina esto -- para páginas en caché. Pero los cachés expiran. Las nuevas páginas no se almacenan en caché hasta la primera visita. Las páginas del carrito de WooCommerce no se pueden almacenar en caché (son dinámicas por usuario). Los usuarios administradores omiten el caché. Y Googlebot a menudo golpea páginas que han caído fuera del caché.

Cada solicitud sin caché paga la penalización completa de la base de datos.

Next.js ISR: HTML Pre-Representado, Cero Consultas de BD en Tiempo de Solicitud

Con Next.js usando Incremental Static Regeneration (ISR), las páginas se pre-representan en HTML estático en tiempo de compilación. Cuando un usuario solicita una página, el servidor devuelve un archivo HTML pre-construido. Sin ejecución de PHP. Sin consultas de base de datos. Sin computación.

// Esto se ejecuta en tiempo de compilación, NO en tiempo de solicitud
export async function getStaticProps() {
  const posts = await fetchFromWordPressAPI('/wp-json/wp/v2/posts')
  
  return {
    props: { posts },
    revalidate: 3600 // Reconstruye esta página cada hora
  }
}

El revalidate: 3600 significa que la página se reconstruye en segundo plano cada hora. Los usuarios siempre obtienen HTML estático instantáneo. El contenido se mantiene fresco. Las consultas de base de datos suceden una vez durante la regeneración, no en cada solicitud de visitante.

Cuando hacemos desarrollo de CMS sin cabeza, WordPress se convierte en el backend de contenido -- los editores aún usan la interfaz de administración familiar -- pero el frontend está completamente desacoplado. La base de datos solo se golpea durante compilaciones o revalidación, no durante solicitudes de usuarios.

Representación del Lado del Servidor: El Cuello de Botella Estructural de PHP

Hablemos de TTFB -- Time to First Byte. Esto es cuánto tiempo tarda el servidor en comenzar a enviar una respuesta después de una solicitud.

WordPress genera cada página ejecutando PHP. Incluso una publicación de blog simple requiere:

1. Apache/Nginx recibe solicitud
2. Spawn del proceso PHP (o se reutiliza del grupo)
3. Bootstrap de WordPress carga (~50 archivos)
4. Plugins activos cargan (cada uno: lecturas de archivo, consultas de base de datos, registro de hooks)
5. Funciones del tema cargan
6. Jerarquía de plantillas se resuelve
7. Consultas de base de datos se ejecutan
8. Plantilla se representa en HTML
9. Respuesta enviada

En alojamiento compartido (donde vive la mayoría de sitios de WordPress -- SiteGround, Bluehost, GoDaddy), este proceso toma 2-4 segundos solo para TTFB. Antes de que se cargue ningún CSS, JavaScript o imagen. Tu usuario está mirando una pantalla en blanco durante 2+ segundos.

El alojamiento administrado de WordPress (Kinsta, WP Engine, Flywheel) reduce esto a 0.8-1.5s TTFB. Mejor. Aún no es excelente.

¿Next.js en Vercel's Edge Network? 50-200ms TTFB. Eso no es porque Vercel tiene servidores mágicos. Es porque no hay nada que calcular. El HTML ya existe. El nodo de borde más cercano al usuario lo sirve directamente. Sin PHP. Sin base de datos. Sin representación de plantilla.

La brecha de rendimiento entre 2+ segundos TTFB y 100ms TTFB no es algo que puedas cerrar con un plugin de almacenamiento en caché.

Entendiendo tu Desglose de Puntuación de Lighthouse

Antes de ver el caso de estudio, entendamos qué mide realmente Lighthouse y por qué WordPress lucha con cada métrica:

Métrica	Peso	Qué Mide	Problema de WordPress	Solución Next.js
TBT	30%	Bloqueo de hilo principal por JS	jQuery + plugin JS = 600ms+	División de código = <50ms
LCP	25%	Elemento visible más grande pintado	TTFB lento + CSS de bloqueo de representación	HTML pre-representado + CSS purgado
CLS	25%	Cambios de diseño visual	Imágenes cargadas perezosamente sin dimensiones, anuncios dinámicos	next/image con dimensionamiento explícito
Speed Index	10%	Integridad visual en el tiempo	CSS pesado bloquea la representación	CSS minimal, HTML instantáneo
FCP	10%	Primer contenido pintado	Recursos de bloqueo de representación	CSS crítico alineado, nada bloquea

TBT solo en 30% de peso significa que si estás golpeando 1,200ms+ de tiempo de bloqueo (común en WordPress), estás perdiendo casi un tercio de tu puntuación justo ahí. Ninguna cantidad de optimización de imagen o almacenamiento en caché puede compensar.

Caso de Estudio: Migración de SleepDr -- WordPress a Next.js

SleepDr vino a nosotros con un problema que he visto docenas de veces. Son una práctica de salud del sueño con un sitio de WordPress construido en un tema premium, ejecutando WooCommerce para programación de citas, Yoast para SEO, Elementor para construcción de páginas, y -- lo adivinaste -- WP Rocket, Autoptimize, Y Perfmatters para rendimiento.

Tres plugins de rendimiento. Puntuación de Lighthouse: 35.

Aquí están los números antes y después:

Métrica	WordPress (Antes)	Next.js (Después)	Cambio
FCP	4.2s	1.1s	-74%
LCP	6.8s	1.8s	-74%
CLS	0.28	0.01	-96%
TBT	1,200ms	50ms	-96%
TTFB	2.1s	0.3s	-86%
Puntuación de Lighthouse	35	94	+169%

Ninguna combinación de plugins de almacenamiento en caché podría lograr estos resultados. La arquitectura tenía que cambiar. Déjame recorrer cada métrica.

FCP: 4.2s → 1.1s (-74%)

Lo que causó la puntuación de WordPress: El sitio de WordPress tenía 2.1s TTFB (alojamiento compartido), seguido de 580KB de CSS de bloqueo de representación de Elementor, el tema, WooCommerce, y seis hojas de estilo de plugins. El navegador no podía pintar nada hasta que descargara y analizara todo ese CSS. FCP literalmente no podía comenzar hasta 4+ segundos después del clic.

La solución de Next.js: HTML pre-representado servido desde el borde de Vercel (0.3s TTFB). CSS crítico alineado en el <head> -- aproximadamente 4KB. El navegador pinta contenido casi inmediatamente después de recibir el HTML. CSS total para todo el sitio: 28KB, cargado asincrónicamente después del primer paint.

LCP: 6.8s → 1.8s (-74%)

Lo que causó la puntuación de WordPress: El elemento de contenido más grande era una imagen de héroe. En WordPress, se cargaba a través de la carga perezosa de Elementor (que entraba en conflicto con la carga perezosa de WP Rocket -- sí, se estaban peleando entre sí). La imagen era un PNG de 2.4MB servido sin conversión de formato next-gen. LCP no podía completarse hasta que esta imagen masiva terminara de descargar sobre una conexión TTFB lenta.

La solución de Next.js: next/image con conversión automática de WebP/AVIF, srcset responsivo, y carga prioritaria para imágenes superior al pliegue. La imagen de héroe fue de 2.4MB PNG a 85KB AVIF. Se priorizó en la secuencia de carga -- sin carga perezosa para contenido superior al pliegue. Combinado con el TTFB rápido, LCP se completó en 1.8s.

CLS: 0.28 → 0.01 (-96%)

Lo que causó la puntuación de WordPress: Tres culpables. Primero, imágenes sin atributos de ancho/alto explícitos (Elementor las dimensionaba dinámicamente vía CSS, causando reflujo). Segundo, un banner de consentimiento de cookies que se inyectaba en el DOM después de la carga de página, empujando contenido hacia abajo. Tercero, fuentes web cargadas con font-display: swap causando un reflujo de texto visible. Un CLS de 0.28 es terrible -- Google considera cualquier cosa por encima de 0.1 "pobre".

La solución de Next.js: next/image obliga ancho y alto, reservando espacio antes de que las imágenes se carguen. El banner de cookies se posicionaba como una superposición fija en lugar de contenido en línea. Las fuentes se alojaban automáticamente con font-display: optional y se precargaban. El resultado: 0.01 CLS. Efectivamente cero cambio de diseño.

TBT: 1,200ms → 50ms (-96%)

Lo que causó la puntuación de WordPress: jQuery (87KB + 150ms ejecución). Frontend JS de Elementor (280KB + 400ms). Fragmentos de carrito de WooCommerce (35KB + 80ms). JavaScript de tres plugins de rendimiento (combinado 45KB + 90ms). Analytics y rastreo (60KB + 120ms). Varios scripts de plugins (100KB + 200ms). Total: más de un segundo de bloqueo de hilo principal.

La solución de Next.js: Cero jQuery. Cero JS del constructor de páginas. Importaciones dinámicas para el widget de reserva de cita. Analytics cargado vía next/script con strategy="lazyOnload". JavaScript total en la página de inicio: 62KB. TBT: 50ms. Eso es una reducción del 96%.

TTFB: 2.1s → 0.3s (-86%)

Lo que causó la puntuación de WordPress: SleepDr estaba en alojamiento compartido de SiteGround. Cada solicitud sin caché desencadenaba bootstrap de WordPress, carga de plugins, 60+ consultas de base de datos, y representación de plantilla PHP. Incluso con el caché de página de WP Rocket, la invalidación de caché sucedía frecuentemente debido a dinámicas del carrito de WooCommerce. TTFB promedio para usuarios reales: 2.1 segundos.

La solución de Next.js: Páginas estáticas desplegadas a la red global de borde de Vercel. ISR maneja actualizaciones de contenido -- las páginas se regeneran en segundo plano cada 30 minutos. Las solicitudes de usuarios siempre golpean HTML pre-construido en el nodo de borde más cercano. TTFB bajó a 0.3s promedio, con algunas regiones viendo sub-100ms.

La Arquitectura que Realmente Arregla el Rendimiento

La migración de SleepDr usó lo que llamamos el patrón de WordPress sin cabeza. WordPress se mantiene como el CMS -- el equipo de SleepDr aún inicia sesión en wp-admin, escribe contenido en Gutenberg, administra sus tipos de cita en WooCommerce. Nada cambió para ellos en el lado de la administración de contenido.

Pero el frontend es completamente Next.js. El proceso de compilación extrae contenido de WordPress vía la API REST, genera páginas estáticas, e implementa en Vercel. Los editores de contenido publican en WordPress, un webhook desencadena una revalidación, y la página actualizada está en vivo en menos de 30 segundos.

Para equipos considerando un enfoque similar, Astro es otra opción que vale la pena evaluar -- especialmente para sitios ricos en contenido con interactividad minimal. Astro envía cero JavaScript de forma predeterminada, lo que puede impulsar las puntuaciones de Lighthouse aún más alto.

La idea clave: no optimizamos WordPress. Reemplazamos la parte que era lenta (la representación de PHP y entrega de frontend) mientras mantenemos la parte que funciona bien (administración de contenido).

Cuándo Tiene Sentido la Migración (Y Cuándo No)

No voy a decirte que cada sitio de WordPress debería migrar a Next.js. Eso es deshonesto. Aquí está mi evaluación honesta:

La migración tiene sentido cuando:

• Tus puntuaciones de Lighthouse están atoradas por debajo de 60 a pesar de esfuerzos de optimización
• El rendimiento impacta directamente en ingresos (e-commerce, gen de leads, sitios de marketing SaaS)
• Estás pagando $200+/mes por alojamiento administrado de WordPress tratando de obtener velocidad aceptable
• Tu equipo de desarrollo es cómodo con React/JavaScript
• Las clasificaciones de SEO están sufriendo por fallos de Core Web Vitals

La migración no tiene sentido cuando:

• Eres un blog personal o pequeño sitio de folleto (la inversión no valdrá la pena)
• Tu equipo de contenido depende fuertemente de plugins específicos de WordPress sin equivalente de API
• Estás feliz en 60-70 Lighthouse y tus Core Web Vitals pasan
• Tu presupuesto está por debajo de $15,000 para la migración

Para sitios donde la migración tiene sentido, la inversión típica oscila entre $15,000-$50,000+ dependiendo de la complejidad, número de plantillas, y funcionalidad personalizada. Hemos detallado nuestro enfoque y estructuras típicas de proyectos en nuestra página de precios.

El cálculo de ROI es directo: si el rendimiento pobre te cuesta X en conversiones perdidas por mes, y la migración cuesta Y, sabes tu período de recuperación. Para SleepDr, la velocidad de página mejorada contribuyó a un aumento del 34% en reservas de citas dentro del primer trimestre.

Preguntas Frecuentes

¿Realmente WP Rocket no puede arreglar mi puntuación de WordPress Lighthouse? WP Rocket es genuinamente uno de los mejores plugins de almacenamiento en caché de WordPress disponibles. Hace todo lo que una capa de almacenamiento en caché puede hacer -- almacenamiento en caché de páginas, minificación, carga perezosa, integración de CDN, generación de CSS crítico. Pero opera dentro de las restricciones arquitectónicas de WordPress. Si tu puntuación está por debajo de 50, WP Rocket típicamente puede llevarte a 55-65. Llegar por encima de 80 consistentemente requiere remover el CSS de bloqueo de representación, la dependencia de jQuery, y la sobrecarga de representación de PHP que WP Rocket simplemente no puede eliminar. Optimiza entrega. No puede reestructurar la arquitectura.

¿Qué puntuación de Lighthouse puede WordPress alcanzar realmente con plugins de almacenamiento en caché? Con una configuración bien optimizada -- tema ligero, plugins mínimos, WP Rocket completamente configurado, alojamiento administrado como Kinsta o WP Engine -- puedes alcanzar realisticamente 65-75 en Lighthouse móvil. Las puntuaciones de escritorio serán más altas (80-90) porque el dispositivo de prueba tiene más poder de procesamiento. Llegar por encima de 80 en móvil consistentemente requiere configuración de WordPress extremadamente mínima (casi sin plugins, tema personalizado) o un cambio de arquitectura. Los sitios con constructores de páginas como Elementor o Divi típicamente cumplen con 50-65.

¿Cuánto cuesta migrar de WordPress a Next.js? Los costos varían significativamente basado en la complejidad del sitio. Un sitio de folleto simple (5-15 páginas, blog, formulario de contacto) corre $15,000-$25,000. Un sitio de complejidad media con tipos de publicación personalizados, múltiples plantillas, e integraciones corre $25,000-$40,000. E-commerce o aplicaciones web complejas con cuentas de usuario, datos dinámicos, e integraciones de terceros comienzan en $40,000+. Estas son tasas del mercado de 2025 para agencias con experiencia comprobada en sin cabeza. Puedes comunicarte con nosotros para una estimación específica basada en tu sitio.

¿Significa WordPress sin cabeza que mi equipo de contenido tiene que aprender nuevas herramientas? No. Ese es el punto completo del enfoque sin cabeza. Tu equipo de contenido continúa usando wp-admin, Gutenberg, ACF, o lo que sea que estén acostumbrados. El único cambio visible es que pueden necesitar esperar 30-60 segundos para que las actualizaciones de contenido aparezcan en el sitio en vivo (debido a revalidación de ISR) en lugar de ver cambios al instante. Algunos equipos encuentran esto apenas perceptible. La experiencia editorial se mantiene prácticamente idéntica.

¿Cuál es la diferencia entre TBT y FCP, y por qué ambos importan? FCP (First Contentful Paint) mide cuándo el usuario ve algo -- cualquier contenido. TBT (Total Blocking Time) mide cuánto tiempo el hilo principal está bloqueado por ejecución de JavaScript entre FCP y Time to Interactive. Puedes tener un FCP decente pero terrible TBT, significando que los usuarios ven contenido rápidamente pero no pueden interactuar con él. Esto es común en sitios de WordPress donde HTML se representa desde caché pero luego 800KB+ de JavaScript se ejecuta. Ambas métricas importan porque juntas representan el 40% de tu puntuación de Lighthouse (TBT en 30%, FCP en 10%).

¿Migrar a Next.js dañará mis clasificaciones de SEO temporalmente? Si se hace correctamente, no. La clave es mantener estructuras de URL, implementar redirecciones 301 adecuadas para cualquier URL que cambie, preservar todos los metadatos, y asegurar que el mapa del sitio XML sea correcto. Típicamente vemos un período de estabilización de 1-2 semanas donde las clasificaciones fluctúan ligeramente, seguido de mejoras mientras Google reconoce los Core Web Vitals mejores. SleepDr no vio caídas de clasificación durante la migración y ganó posiciones dentro de 6 semanas. El riesgo proviene de migraciones descuidadas -- redirecciones rotas, páginas faltantes, estructuras de URL cambiadas sin redirecciones.

¿Puedo usar Astro en lugar de Next.js para la migración? Absolutamente. Astro es una excelente opción para sitios ricos en contenido con interactividad limitada. Astro envía cero JavaScript de forma predeterminada e hidrata solo componentes interactivos -- lo que ellos llaman "arquitectura de islas". Para un sitio como un blog, sitio de documentación, o sitio de marketing donde el contenido es primario, Astro puede lograr puntuaciones de Lighthouse aún mejores que Next.js. Recomendamos Next.js cuando necesitas interactividad significativa del lado del cliente (dashboards, sistemas de reserva, e-commerce) y Astro cuando el contenido es primario.

¿Vale la pena la mejora en la puntuación de Lighthouse la inversión? Eso depende completamente de lo que tu sitio hace. Para un blog personal, probablemente no. Para un negocio donde el tráfico de búsqueda orgánica genera ingresos, las matemáticas son convincentes. Google ha confirmado Core Web Vitals como factor de clasificación. Estudios de 2024-2025 muestran que cada mejora de 100ms en LCP se correlaciona con un aumento del 1.1% en la tasa de conversión para sitios de e-commerce. Si tu sitio genera $50,000/mes en ingresos y una mejora de conversión del 10-15% agrega $5,000-$7,500/mes, una migración de $30,000 se paga a sí misma en 4-6 meses. Ejecuta tus propios números -- la respuesta siempre es específica para tu negocio.