¿Por qué mi sitio de Next.js es lento?

Primero encuentre la causa

La lentitud son varios problemas distintos, y cada uno tiene una corrección diferente. Antes de cambiar el código, averigüe qué páginas son lentas, para quién y en qué medición.

• Abra el informe de Core Web Vitals en Search Console y anote qué grupos de páginas son deficientes, en móvil y en computadora por separado.
• Ejecute PageSpeed Insights en una dirección de ejemplo de cada grupo para ver la causa principal que informa la prueba de laboratorio.
• Abra el panel de rendimiento del navegador con una conexión limitada y grabe una carga de página y algunos toques.
• Revise el tiempo de respuesta del servidor para la página: un primer byte lento apunta al renderizado o a los datos, no al navegador.
• Mida la compilación de producción, nunca el servidor de desarrollo, que es más lento por diseño.

Renderizar en cada solicitud

Next.js puede generar una página una vez y servirla desde una caché, o renderizarla en el servidor para cada visitante. Las páginas de productos, servicios y artículos rara vez necesitan un renderizado nuevo cada vez. Las páginas que leen cookies, encabezados o datos sin caché se renderizan en cada solicitud, a menudo por accidente. Haga que las páginas de contenido sean estáticas o almacénelas en caché con un intervalo de revalidación razonable, y reserve el renderizado por solicitud para las páginas que realmente cambian según el visitante.

La salida de la compilación indica cómo se renderiza cada ruta. Léala después de cada cambio importante: una página que el mes pasado era estática y ahora es dinámica suele haber adquirido una lectura de cookies o una solicitud sin caché en algún lugar de su layout, y esa sola línea puede volver más lentas todas las páginas que dependen de él.

Imágenes

Las fotos grandes son la causa más común de una primera visualización lenta. Use el componente de imagen del framework con el ancho y el alto reales, los tamaños adecuados para cada pantalla y prioridad solo para la imagen principal visible. Reserve espacio para cada imagen para que el diseño no se desplace.

Revise también los archivos de origen. Una foto de producto subida con la resolución de la cámara todavía tiene que descargarse y redimensionarse antes de poder servirse, y un servidor remoto de imágenes sin caché hace que cada visitante espere por eso. Suba las imágenes con un tamaño cercano al más grande con el que se muestran, y deje que el framework genere las versiones más pequeñas.

Debajo de la primera pantalla, deje que las imágenes se carguen de forma diferida, algo que el componente de imagen hace de forma predeterminada. Marcar todas las imágenes como prioritarias anula el propósito, porque entonces el navegador las descarga todas antes que la que importa.

Demasiado JavaScript

Marcar páginas o layouts completos como componentes de cliente envía su código a cada visitante. Mantenga los componentes en el servidor a menos que necesiten estado o manejadores de eventos, lleve la interactividad solo a las partes pequeñas que la necesitan y revise el tamaño de cada biblioteca que agregue. Una tarea larga en el navegador es lo que hace que los toques se sientan lentos.

Un analizador de bundles muestra qué bibliotecas componen el código que envía cada página. Las sorpresas comunes son una biblioteca de fechas o de gráficas cargada en todas las páginas para un solo widget, un conjunto de íconos importado completo en lugar de ícono por ícono y una biblioteca de animación usada para un solo desvanecimiento. Cargue las piezas pesadas solo en las páginas que las usan, o solo cuando se abren.

Datos lentos y solicitudes que bloquean

Una página espera a su solicitud de datos más lenta. Haga las solicitudes en paralelo en lugar de una tras otra, almacene en caché los resultados que no cambian según el visitante y transmita las secciones más lentas después del contenido principal para que los visitantes vean la página antes.

Scripts de terceros

Los widgets de chat, los administradores de etiquetas, los mapas de calor y los píxeles publicitarios suelen costar más que el propio código del sitio. Cárguelos después de que la página sea interactiva, elimine los que nadie usa y haga pruebas con ellos desactivados para ver su costo real.

Fuentes

Las fuentes web cargadas desde un servidor de terceros agregan una conexión antes de que el texto pueda mostrarse, y un cambio de fuente tardío puede desplazar el diseño. Las herramientas de fuentes del framework descargan las fuentes durante la compilación y las sirven desde su propio dominio, con métricas de respaldo que limitan el desplazamiento del diseño. Use una o dos familias, solo con los pesos que necesita el diseño.

Alojamiento y caché

Dónde se ejecuta el sitio importa tanto como cómo está escrito. Las páginas estáticas y en caché deben servirse desde una red cercana a los visitantes. El renderizado en servidor y la obtención de datos deben ejecutarse cerca de la base de datos o la API a la que llaman, porque una página que hace varias solicitudes a través de un océano espera cada viaje de ida y vuelta.

Revise los encabezados de caché de las páginas y los recursos. Las imágenes, los scripts y los estilos con nombres que incluyen un hash de su contenido pueden almacenarse en caché por mucho tiempo; las páginas deben almacenarse en caché durante el tiempo que su contenido lo permita.

Código que se ejecuta antes de cada solicitud

El código que se ejecuta antes del enrutamiento, como el middleware o lo que las versiones más recientes de Next.js llaman proxy, se ejecuta en cada solicitud que coincide, incluidas las solicitudes de páginas que de otro modo se servirían directamente desde una caché. Manténgalo pequeño, limítelo a las rutas que lo necesitan y evite consultas lentas dentro de él. Las cadenas largas de redirecciones definidas ahí agregan un viaje de ida y vuelta cada una.

Un orden típico de reparación

• Haga que las páginas de contenido sean estáticas o estén en caché, lo que a menudo corrige el tiempo de respuesta del servidor en todo el sitio.
• Corrija la imagen principal en las plantillas más lentas: tamaño, formato y prioridad de carga.
• Elimine o retrase los scripts de terceros.
• Reduzca el JavaScript del lado del cliente en las páginas con INP deficiente.
• Reserve espacio para imágenes, contenidos incrustados y banners para bajar el CLS.
• Vuelva a medir después de cada paso, para saber qué cambio ayudó.

Cómo lo abordamos

Construimos con Next.js y React, y probamos la velocidad en teléfonos antes del lanzamiento. En un sitio existente, primero medimos, corregimos la causa más grande y volvemos a medir. Consulte desarrollo de sitios web de comercio electrónico o mantenimiento y soporte de sitios web, y Core Web Vitals explicadas para conocer las mediciones en sí.

Si la lentitud viene de una construcción antigua que costaría más reparar que reemplazar, un rediseño o una migración conserva sus URL y traslada el sitio a una estructura más rápida. Nuestra propia tienda es el caso de estudio de Vanta Labs, y hay desarrolladores disponibles las 24 horas, los 7 días de la semana.