Optimización de rendimiento Next.js: la guía completa

Q: ¿Qué es una buena puntuación Lighthouse para una web Next.js?

Todo lo que supere 90 se considera bueno; por encima de 95, muy bueno. Nuestros proyectos logran regularmente 95–100. Una puntuación por debajo de 70 indica problemas de rendimiento estructurales que pueden resolverse con una optimización dirigida.

Q: ¿Por qué mi sitio Next.js es lento aunque uso Next.js?

Next.js no es garantía de rendimiento: implementaciones incorrectas pueden anular las ventajas. Causas frecuentes: falta de flags priority en imágenes, demasiados client components en lugar de server components, scripts externos que bloquean el renderizado, consultas a base de datos deficientes en SSR.

Q: ¿Cuánto dura una auditoría de rendimiento?

Una auditoría de rendimiento básica con recomendaciones de mejora dura entre 2 y 4 horas. Una auditoría completa con implementación de las mejoras requiere entre 1 y 5 días según el tamaño del proyecto.

Q: ¿Realmente mejora el rendimiento la tasa de conversión?

Sí, lo demuestran numerosos estudios. Google y Amazon han mostrado que 100 ms más de tiempo de carga equivalen a un 1 % menos de conversiones. Una página que carga 1 segundo más rápido convierte normalmente entre un 2 y un 5 % mejor.

Q: ¿Cuánto cuesta una optimización de rendimiento Next.js?

Una auditoría de rendimiento cuesta entre 490 y 990 €. La implementación de las mejoras identificadas depende del alcance: entre 1.000 y 5.000 € para proyectos típicos. A menudo, sin embargo, el 20 % de las medidas son responsables del 80 % de la mejora de rendimiento.

Wito AI

Guía de rendimiento11 min de lectura

Guía de rendimiento

Rendimiento Next.js Consigue Lighthouse 95+

Técnicas concretas para un rendimiento máximo en Next.js: LCP por debajo de 1 segundo, CLS cercano a cero, INP por debajo de 50 ms. Con estos métodos nuestros proyectos alcanzan de forma constante puntuaciones Lighthouse superiores a 95.

Comprender Core Web Vitals

Los Core Web Vitals de Google son las métricas de rendimiento decisivas para el SEO y la experiencia de usuario: LCP (Largest Contentful Paint): ¿cuánto tarda en cargarse el elemento visible más grande de la página? Objetivo: por debajo de 2,5 segundos, idealmente por debajo de 1 segundo. INP (Interaction to Next Paint): ¿con qué rapidez reacciona la página a las interacciones del usuario? Objetivo: por debajo de 200 ms, idealmente por debajo de 50 ms. CLS (Cumulative Layout Shift): ¿cuánto se desplazan los elementos durante la carga? Objetivo: por debajo de 0,1, idealmente 0,02 o menos. Next.js ofrece de serie mejores condiciones para las tres métricas que WordPress o las SPA clásicas, pero implementaciones incorrectas pueden anular estas ventajas.

Google utiliza los Core Web Vitals como factor de ranking. Las páginas con buenos vitales posicionan en promedio entre un 15 y un 25 % mejor que páginas comparables con vitales deficientes.

Optimización de imágenes con next/image

Las imágenes son el asesino más común del LCP. Next.js `` resuelve la mayoría de los problemas automáticamente: Conversión automática a WebP/AVIF: Next.js entrega las imágenes en el mejor formato que admite el navegador. AVIF es entre un 40 y un 60 % más pequeño que JPEG con la misma calidad. Lazy loading: las imágenes por debajo del viewport se cargan solo cuando el usuario hace scroll. Establece `loading="lazy"` correctamente. Flag priority para imágenes LCP: la imagen principal (a menudo la imagen hero) debe tener `priority` para que se cargue pronto. La falta de esta flag es una causa habitual de LCP deficiente. Dimensiones fijas: define siempre `width` y `height` para evitar CLS por imágenes que cargan tarde. Placeholder borroso: `placeholder="blur"` muestra un placeholder difuminado durante la carga y evita saltos visuales.

Error frecuente: la imagen hero sin la flag priority. Añade priority a todas las imágenes above-the-fold: suele mejorar el LCP entre 0,5 y 1,5 segundos.

Elegir la estrategia de renderizado adecuada

Next.js ofrece varios modos de renderizado; la elección incorrecta cuesta rendimiento: Static Generation (SSG): las páginas se renderizan en tiempo de build y se entregan como archivos HTML estáticos. El tiempo de carga más rápido posible. Adecuado para páginas que cambian poco (landings, posts de blog). Incremental Static Regeneration (ISR): las páginas estáticas se actualizan en segundo plano. Ideal para páginas que cambian ocasionalmente (páginas de producto, noticias). El parámetro `revalidate` controla la frecuencia de actualización. Server-Side Rendering (SSR): las páginas se renderizan en cada petición. Necesario para contenido personalizado, pero más lento. Cuidado: usar SSR para todo es un error de rendimiento habitual. React Server Components (RSC): con el App Router, los componentes pueden renderizarse en el servidor, sin enviar JavaScript al cliente. Reduce el tamaño del bundle y mejora el INP.

¿Problemas de rendimiento en tu proyecto Next.js?

Optimizar fuentes y scripts externos

next/font para Google Fonts Nunca incrustes Google Fonts directamente vía CDN. `next/font/google` carga las fuentes localmente y elimina la petición de red a los servidores de Google: ahorra entre 200 y 500 ms y mejora la privacidad. next/script para scripts externos Analítica, widgets de chat, herramientas de testing A/B: incrústalos siempre con `