¿Por qué su sitio Next.js es lento y cómo solucionarlo?
¿Un sitio Next.js lento perjudica su posicionamiento y conversiones? Descubra las verdaderas causas de unos Core Web Vitals deficientes y cómo Belk Digital los soluciona rápidamente.
Introducción
Su puntuación de Lighthouse indica 45. Su cliente pregunta por qué la página de inicio tarda cuatro segundos en ser interactiva. Y en alguna reunión de retrospectiva, alguien hace la pregunta obvia: ¿no construimos esto en Next.js para que fuera rápido por defecto?
Es una pregunta justa, y la respuesta sincera es no. Next.js le proporciona las herramientas para construir un sitio realmente rápido, pero no lo construye por usted. Con la configuración por defecto, una aplicación Next.js puede enviar los mismos paquetes sobredimensionados, imágenes no optimizadas y sobrecarga de hidratación que cualquier otro framework de JavaScript, y a veces peor, porque los equipos asumen que la velocidad viene integrada.
Esta guía desglosa por qué se ralentizan realmente los sitios Next.js, cómo confirmar si el suyo es uno de ellos y la secuencia de solución que utilizamos en Belk Digital para recuperar el control de los sitios donde el rendimiento es crítico. Explore nuestros servicios especializados en rendimiento de Next.js o solicite una auditoría de Core Web Vitals para evaluar su aplicación.
La paradoja de la velocidad de Next.js: Por qué moderno no significa automáticamente rápido
Next.js se diseñó para resolver los problemas de rendimiento que afectaban a las primeras aplicaciones de React: pantallas en blanco, paquetes de cliente gigantescos y un SEO débil debido al renderizado exclusivo en el cliente. El renderizado en el servidor (SSR), la generación estática (SSG), la división automática de código y el modelo de transmisión (streaming) del App Router existen específicamente para que las páginas se carguen más rápido.
Nada de eso sucede automáticamente cuando un proyecto escala más allá de una demostración. Añada suficientes componentes de cliente, scripts de terceros e imágenes sin optimizar, y un sitio Next.js regresará exactamente a los problemas que debía evitar. El framework proporciona la capacidad; la calidad de la implementación decide el resultado.
Next.js ofrece SSR, SSG, ISR y transmisión mediante App Router, pero ninguno ofrece velocidad automáticamente sin una arquitectura deliberada.
Escalar una aplicación con excesivos componentes de cliente y scripts de terceros provoca una regresión hacia problemas de rendimiento monolíticos de React.
La calidad de la implementación, el manejo de activos y las estrategias de obtención de datos determinan el rendimiento final.
Cómo saber si su sitio Next.js es realmente lento
Antes de solucionar nada, confirme qué está realmente fallando. "Parece lento" y "mediblemente lento" son dos problemas diferentes que requieren herramientas distintas.
Google mide la velocidad del sitio y la experiencia del usuario a través de tres Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS). LCP mide cuánto tarda en renderizarse el elemento visible más grande (habitualmente una imagen principal o un encabezado). INP mide la capacidad de respuesta de la página ante cada clic, toque y pulsación de tecla durante la visita. CLS mide cuánto se desplaza inesperadamente el contenido mientras se carga la página.
| Métrica | Bueno | Necesita mejora | Deficiente |
|---|---|---|---|
| Largest Contentful Paint (LCP) | ≤ 2,5s | 2,5s – 4,0s | > 4,0s |
| Interaction to Next Paint (INP) | ≤ 200ms | 200ms – 500ms | > 500ms |
| Cumulative Layout Shift (CLS) | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Google evalúa estos umbrales en el percentil 75 de sesiones de visitantes reales durante una ventana móvil de 28 días, utilizando datos de campo de Chrome UX Report (CrUX), no una simple prueba en un entorno de desarrollo. Una página puede parecer rápida en Lighthouse y seguir fallando en el mundo real si una parte significativa de los visitantes en teléfonos antiguos o conexiones lentas tiene una experiencia deficiente.
Las herramientas imprescindibles:
- [Google PageSpeed Insights](https://pagespeed.web.dev/): Combina datos de campo (CrUX) con datos de laboratorio (Lighthouse) tanto para móvil como para escritorio.
- [Informe de Core Web Vitals de Search Console](https://support.google.com/webmasters/answer/9205520): Muestra el estado real de aprobado/suspenso agrupado por URL.
- Panel de rendimiento de Chrome DevTools: Para identificar cuellos de botella específicos durante el desarrollo.
- WebPageTest: Análisis de cascada más profundo, útil para diagnosticar TTFB y recursos que bloquean el renderizado.
- Vercel Analytics o herramientas RUM: Para la monitorización continua de usuarios reales en lugar de capturas puntuales.
Los datos de laboratorio le indican qué falla en una prueba controlada. Los datos de campo le muestran lo que experimentan sus visitantes reales. Los equipos que solo comprueban Lighthouse habitualmente ignoran a los usuarios de dispositivos móviles y conexiones lentas que fallan en el mundo real; utilice ambos.
Diferencie los datos de diagnóstico de laboratorio (Lighthouse) de los datos de campo de usuarios reales de CrUX a 28 días.
Supervise LCP (≤2,5s), INP (≤200ms) y CLS (≤0,1) en el percentil 75 de las sesiones reales.
Combine PageSpeed Insights, DevTools, Search Console y RUM para una visibilidad completa.
Las seis causas fundamentales de un sitio Next.js lento
Una vez que el diagnóstico confirma un problema real, la solución depende de cuál de las seis causas fundamentales lo está impulsando. La mayoría de los sitios Next.js lentos presentan varias al mismo tiempo:
1. La estrategia de renderizado incorrecta para el contenido
Next.js admite varias estrategias de renderizado, y elegir la equivocada para una página determinada es uno de los errores más comunes y costosos que observamos.
| Estrategia | Qué hace | Ideal para | Compromiso / Desventaja |
|---|---|---|---|
| Server-Side Rendering (SSR) | Renderiza la página en cada solicitud | Contenido altamente personalizado o de cambio rápido | Mayor TTFB; el servidor trabaja en cada visita |
| Static Site Generation (SSG) | Renderiza páginas en tiempo de compilación | Páginas de marketing, blogs, documentación | Entrega más rápida; las actualizaciones requieren compilación |
| Incremental Static Regeneration (ISR) | Sirve páginas estáticas y las regenera a intervalos definidos | Catálogos de productos, contenido actualizado periódicamente | Velocidad casi estática con contenido más fresco |
Un panel de control renderizado con SSR en cada solicitud siempre será más lento de lo necesario si los datos subyacentes solo cambian una vez por hora. Cambie ese panel a ISR y el TTFB disminuirá drásticamente sin perder la frescura del contenido. Lea nuestra guía de arquitectura CMS headless para obtener patrones profundos de renderizado.
2. Sobrecarga de hidratación en el lado del cliente
La hidratación es el proceso mediante el cual React vincula la interactividad al HTML estático que el servidor ya envió. Hasta que termina la hidratación, los botones parecen interactivos pero no lo son. En páginas cargadas de JavaScript con docenas de componentes de cliente, este retraso se vuelve evidente y perjudica desproporcionadamente al INP.
Los React Server Components, introducidos con el App Router, reducen este problema al mantener las partes no interactivas de una página exclusivamente en el servidor. Una página repleta de componentes de cliente que realmente no necesitan interactividad está pagando un peaje de hidratación innecesario.
3. Paquetes de JavaScript sobredimensionados
Cada importación innecesaria, biblioteca no utilizada y dependencia duplicada añade un peso que el navegador debe descargar, analizar y ejecutar antes de que la página sea utilizable. Entre los culpables habituales: importar una biblioteca entera de iconos para solo tres iconos, incluir una biblioteca de fechas pesada cuando el formato nativo Intl sería suficiente y enviar código exclusivo de administración a todos los visitantes.
La división de código y las importaciones dinámicas (`next/dynamic`) permiten que un componente pesado (un modal, un gráfico, un editor de texto enriquecido) se cargue solo cuando realmente se necesita, en lugar de hacerlo durante la carga inicial de la página. `@next/bundle-analyzer` facilita ver exactamente qué está engordando el paquete antes de decidir qué recortar.
4. Imágenes y fuentes no optimizadas
Las imágenes siguen siendo el activo individual más grande en la mayoría de las páginas web, y Next.js incluye el componente `next/image` diseñado específicamente para solucionarlo: redimensionamiento automático, carga perezosa y conversión a formatos modernos como WebP o AVIF. La clave está en que solo ayuda cuando se usa correctamente. La falta de la propiedad `priority` en imágenes principales visibles, la ausencia de dimensiones explícitas (`width` y `height`) que provocan cambios de diseño y las imágenes servidas desde fuentes externas no optimizadas anulan el propósito de la herramienta. Para técnicas avanzadas de imágenes, consulte nuestra guía sobre 7 técnicas prácticas para mejorar el LCP en Next.js.
Las fuentes causan un problema relacionado. Sin una estrategia de carga definida, las fuentes personalizadas crean un destello de texto no diseñado o invisible mientras se cargan, perjudicando tanto al CLS como a la velocidad percibida. `next/font` aloja y precarga automáticamente los archivos de fuentes, eliminando la solicitud que bloquea el renderizado hacia proveedores externos.
5. Tiempo de respuesta inicial (TTFB) lento y falta de almacenamiento en caché
El TTFB mide cuánto tarda el servidor en responder antes de que el navegador pueda comenzar a renderizar. Un TTFB lento empeora todas las métricas posteriores: un LCP deficiente de cinco segundos suele ser síntoma de una respuesta del servidor de dos segundos, no de un problema del front-end.
Las causas comunes incluyen solicitudes SSR no cacheadas, funciones serverless con inicios en frío, falta de caché en el borde de CDN y consultas a bases de datos que se ejecutan de forma síncrona en cada carga. Las cabeceras `Cache-Control` adecuadas, el almacenamiento en caché en la red CDN (como la red Edge de Vercel o Cloudflare) y el traslado del trabajo pesado fuera de la ruta de la solicitud mediante ISR o tareas en segundo plano solucionan la mayoría de estos casos.
6. Scripts de terceros y consultas a la base de datos no optimizadas
Los píxeles de analítica, widgets de chat, etiquetas publicitarias y herramientas de marketing añaden su propio JavaScript, y cada uno compite con el código propio del sitio por el hilo principal. Una página puede tener un código perfectamente optimizado y fallar en INP porque un script de terceros no optimizado bloquea la interacción durante medio segundo.
En el backend, los problemas de consultas N+1 y la falta de índices en la base de datos ralentizan las rutas SSR y API aunque el front-end esté bien construido. Si una página realiza diez consultas a la base de datos para renderizar una lista, ninguna optimización front-end lo resolverá: la corrección debe realizarse en el ORM o a nivel de consulta.
Ajuste la estrategia de renderizado (SSG, ISR, SSR) a la frecuencia real de actualización de datos para reducir el TTFB.
Aproveche los React Server Components en el App Router para reducir la sobrecarga de hidratación y mejorar el INP.
Elimine paquetes JS sobredimensionados mediante importaciones dinámicas, aloje fuentes con next/font y priorice imágenes LCP.
App Router vs. Pages Router: ¿Realmente importa para la velocidad?
Migrar al App Router por sí solo no garantiza un sitio más rápido, aunque esa suposición sea habitual. Las verdaderas ventajas de rendimiento del App Router (React Server Components, transmisión y almacenamiento en caché más granular) solo se manifiestan cuando se utilizan deliberadamente. Un proyecto que migra de router pero marca cada componente como "use client" por costumbre conserva exactamente la misma sobrecarga de hidratación que tenía antes, solo que envuelta en una sintaxis más nueva.
El router importa menos que las decisiones arquitectónicas que se toman dentro de él.
Los beneficios del App Router requieren elecciones arquitectónicas deliberadas (Server Components, streaming, caché en el borde).
Envolver todo con "use client" mantiene la sobrecarga de hidratación del antiguo Pages Router.
Cómo solucionamos un sitio Next.js lento: Nuestro proceso de auditoría y optimización
En Belk Digital, seguimos un marco sistemático de remediación de 7 pasos para recuperar el control de sitios lentos:
- Establecer la línea base del estado actual: Ejecutar PageSpeed Insights y el informe de Core Web Vitals de Search Console para establecer cifras reales de datos de campo antes de tocar código.
- Identificar el cuello de botella dominante: TTFB, tamaño del paquete, hidratación, imágenes o una combinación. Solucionar lo equivocado primero desperdicia un sprint entero.
- Corregir primero el tiempo de respuesta del servidor: Las correcciones en la estrategia de renderizado y en el almacenamiento en caché suelen generar la mayor mejora individual, ya que todo lo demás depende de ello.
- Optimizar imágenes y fuentes: Normalmente son las victorias más rápidas con menor riesgo de romper otros elementos de la página.
- Reducir y dividir el paquete de JavaScript: Auditar dependencias, convertir componentes de cliente innecesarios en componentes de servidor y añadir importaciones dinámicas para UI pesada no crítica.
- Auditar scripts de terceros: Diferir, cargar de forma perezosa o eliminar scripts que no aporten un valor equivalente al peso que añaden.
- Reevaluar y configurar una monitorización continua: Una solución puntual se degrada a medida que se lanzan nuevas funciones; RUM detecta regresiones antes de que los usuarios las reporten.
Establezca líneas base reales con datos de campo CrUX antes de refactorizar el código.
Aborde primero el TTFB y la estrategia de renderizado para lograr el máximo impacto en el rendimiento posterior.
Implemente una monitorización RUM continua para evitar regresiones de rendimiento al lanzar nuevas funciones.
Cuándo solucionarlo usted mismo frente a cuándo recurrir a un experto en rendimiento de Next.js
Los equipos con capacidad de ingeniería interna generalmente pueden encargarse de la optimización de imágenes, la carga de fuentes y el recorte básico de paquetes sin ayuda externa; son soluciones bien documentadas y de bajo riesgo. Los cambios en la estrategia de renderizado, las migraciones al App Router y la optimización de consultas a bases de datos conllevan más riesgo, ya que afectan a la arquitectura en lugar de a componentes aislados, y una decisión equivocada puede introducir nuevos errores mientras se busca ganar velocidad.
Si un sitio ha sido lento durante meses a pesar de los intentos internos por solucionarlo, o si la corrección requiere rediseñar cómo fluyen los datos a través de la aplicación, una auditoría externa suele ser el camino más rápido y económico. Para obtener orientación sobre precios y evaluación para tomar esa decisión, consulte nuestra guía sobre cómo elegir el socio digital adecuado.
Las correcciones aisladas (imágenes, fuentes, recorte de paquetes) son de bajo riesgo para equipos internos.
Los cambios arquitectónicos (estrategias de renderizado, optimización de consultas) se benefician de auditorías expertas.
Belk Digital ofrece auditorías de rendimiento de alcance fijo para desbloquear a los equipos de ingeniería.
Por qué la velocidad del sitio es un problema de negocio, no solo técnico
La velocidad del sitio no se limita a la pestaña de DevTools. Los Core Web Vitals son una señal confirmada de posicionamiento en Google, y las páginas lentas e inestables tienden a registrar tasas de rebote más altas y menor participación que las páginas que superan las tres métricas cómodamente. Google ha documentado casos de estudio de minoristas que mejoraron sus puntuaciones de Core Web Vitals junto con aumentos medibles en ingresos publicitarios, duración de sesiones y tráfico orgánico, aunque los resultados varían según el sitio y no deben tomarse como una fórmula garantizada.
El punto clave es que el trabajo de rendimiento se combina directamente con las labores de SEO, UX y conversión detalladas en nuestro artículo sobre cómo afecta el rendimiento del sitio web a los ingresos. Tratar la velocidad como un proyecto técnico de una sola vez, en lugar de como una disciplina continua, es la razón principal por la que un sitio optimizado vuelve a ralentizarse seis meses después.
Los Core Web Vitals actúan como una señal de posicionamiento en Google y como impulsores de conversión.
Las mejoras de rendimiento se combinan directamente con la visibilidad SEO y la participación del usuario.
La disciplina continua de rendimiento evita regresiones tras el lanzamiento de nuevas características.
Conclusión
Un sitio web Next.js lento es casi siempre un problema de implementación, no una limitación del framework. Al auditar sus datos de campo en Search Console, seleccionar la estrategia de renderizado adecuada para cada tipo de página, aprovechar los React Server Components y configurar una monitorización continua, puede construir una aplicación web rápida y escalable que ofrezca una experiencia de usuario excepcional y un excelente rendimiento de Core Web Vitals.
¿Listo para resolver sus cuellos de botella de rendimiento? Explore los servicios de rendimiento de Next.js de Belk Digital o contacte con nuestro equipo de ingeniería para programar una auditoría de Core Web Vitals.
Preguntas Frecuentes
¿Listo para Transformar su Presencia Digital?
Let's discuss how we can help you achieve your digital goals and create an exceptional online presence.