Next.js vs React + Inertia para landing pages: ¿cuál carga más rápido?
Dos de los stacks más populares para construir interfaces modernas en el ecosistema PHP/JavaScript son Next.js (React con SSR y SSG nativo) y React + Inertia.js (sobre Laravel). Ambos producen interfaces rápidas y componentes reutilizables. Pero no son iguales, y elegir el equivocado puede generarte fricción que se siente en el rendimiento, en el SEO o en el tiempo de desarrollo.
En Nebula usamos los dos. Acá explicamos las diferencias que importan para landing pages y sitios orientados a conversión.
El contexto: ¿qué es cada uno?
Next.js es un framework de React con Server-Side Rendering (SSR), Static Site Generation (SSG) y soporte nativo de API Routes. Es independiente del backend: el frontend se conecta a cualquier API. Desarrollado y mantenido por Vercel, tiene un ecosistema enorme y es uno de los estándares de la industria para sitios web de alto rendimiento.
React + Inertia.js es una combinación que permite construir SPAs modernas sin separar completamente el backend del frontend. Inertia actúa como el puente entre un backend Laravel y un frontend React, eliminando la necesidad de construir y mantener una API REST independiente. El servidor sigue siendo Laravel; el cliente sigue siendo React; Inertia hace que hablen entre sí sin duplicar lógica.
Performance para landing pages: los números reales
Para landing pages, las métricas que más importan son el tiempo hasta que el usuario ve contenido (LCP — Largest Contentful Paint) y la puntuación en Google PageSpeed Insights, que impacta directamente en el posicionamiento SEO.
Next.js con Static Site Generation (SSG) genera páginas HTML estáticas durante el build. El servidor — o mejor dicho, el CDN — responde instantáneamente con HTML completo. No hay que esperar a que el servidor procese nada en tiempo de request. Para landing pages simples bien optimizadas, los puntajes de Google PageSpeed están consistentemente entre 95 y 100.
Inertia.js con Laravel renderiza desde el servidor pero como una SPA: la primera carga incluye un HTML mínimo y luego React toma el control del lado del cliente. El JavaScript adicional de inicialización agrega latencia perceptible en la primera carga, especialmente en conexiones móviles lentas.
La comparación concreta
| Métrica | Next.js (SSG) | Inertia + Laravel |
|---|---|---|
| Tiempo de respuesta del servidor (TTFB) | Muy bajo desde CDN | Depende del servidor |
| LCP en condiciones normales | Excelente | Bueno |
| Puntaje Lighthouse típico | 90-100 | 75-90 |
| SEO sin configuración adicional | Excelente | Requiere configuración de SSR |
| Costo de hosting | Bajo (Vercel tiene tier gratuito) | Requiere servidor dedicado |
| Soporte de imágenes optimizadas | Nativo con next/image | Manual |
Para landing pages puras orientadas a SEO y velocidad de carga: Next.js gana con claridad.
Pero la performance no es el único criterio
Velocidad de desarrollo
Si el proyecto tiene un backend en Laravel con lógica de negocio compleja que el frontend necesita usar, Inertia.js elimina la necesidad de construir y mantener una API REST como capa intermedia. Eso puede ser una ventaja enorme en tiempo de desarrollo.
Next.js con un backend separado implica mantener dos proyectos, dos procesos de deployment y la sincronización de tipos entre frontend y backend si usás TypeScript en ambos. Para equipos pequeños, ese overhead se siente.
Para proyectos full stack con un solo equipo: Inertia + Laravel suele ganar en velocidad de desarrollo.
SEO
Next.js con SSG o SSR genera HTML completo en el servidor. Los crawlers de Google indexan el contenido sin necesitar ejecutar JavaScript. Es la solución con menos fricción para SEO.
Inertia.js puede lograr SSR con configuración adicional, pero es más complejo de configurar y mantener. Para una landing page donde el SEO es crítico, el costo de esa configuración no tiene mucho sentido cuando Next.js lo da gratis.
Equipo y separación de responsabilidades
Si el equipo de frontend y el de backend trabajan por separado, la separación limpia de Next.js más API REST es más adecuada. Cada equipo puede trabajar y deployar de forma independiente.
Si es un equipo pequeño que toca todo el stack, la integración de Inertia elimina complejidad operativa.
Cuándo usamos cada uno en Nebula
Usamos Next.js para:
Usamos Inertia + Laravel para:
Un caso real de la diferencia en práctica
Epic Bariloche — una landing de turismo de aventura en la Patagonia — la construimos con Next.js. El objetivo era posicionamiento en Google para búsquedas locales de turismo en Bariloche. En menos de 60 días desde el lanzamiento, el sitio apareció en primera página para más de 15 keywords relevantes.
Eso no habría sido tan inmediato con una SPA de Inertia sin configuración de SSR adicional.
MyOfficeTaxes — el SaaS de automatización fiscal — lo construimos con Inertia + Laravel. La lógica de negocio es compleja, los flujos entre backend y frontend son densos, y el SEO de la aplicación interna no importa. Inertia nos permitió movernos rápido sin duplicar validaciones y reglas de negocio en dos lugares.
La respuesta honesta
Si tu objetivo es una landing page que ranquee en Google y cargue rápido en mobile, Next.js es la respuesta sin mucha discusión.
Si tu objetivo es una aplicación compleja donde el backend y el frontend comparten mucha lógica y el equipo es pequeño, Inertia + Laravel probablemente te dé más velocidad de desarrollo con menos overhead.
Y si necesitás las dos cosas: una landing pública con Next.js y una aplicación interna con Inertia + Laravel pueden coexistir perfectamente.
¿Tenés dudas sobre qué stack usar en tu próximo proyecto?
Agendá un diagnóstico. Te explicamos qué tiene sentido para tu caso específico y por qué. Sin compromiso y sin intentar venderte el stack más caro.