La Ingeniería Detrás de Sudolabs: Por Qué Elegimos Next.js 16
¿Alguna vez has entrado a una web de agencia que tarda 5 segundos en cargar su propio logo? Nosotros también. Y nos molesta.
Cuando empezamos a diseñar la arquitectura de Sudolabs, teníamos una regla de oro innegociable: La web debe ser instantánea. No "rápida", instantánea.
En este artículo, no te voy a vender nuestros servicios. Quiero contarte, de ingeniero a ingeniero, cómo construimos este sitio, por qué tomamos decisiones arriesgadas (como usar Next.js 16 en canary) y qué aprendimos al estrellarnos un par de veces contra la pared.
El Problema: El "Bloat" del Frontend Moderno
El ecosistema de React ha engordado. SPA (Single Page Applications) que envían 500KB de JavaScript solo para renderizar un landing page estático es, honestamente, una irresponsabilidad técnica.
Nuestros requisitos eran claros:
- SEO Impecable: Necesitábamos HTML real, no una sopa de
divs vacíos esperando a JS. - Performance Core Web Vitals: LCP < 1.0s, TBT 0ms.
- DX (Developer Experience): Queríamos escribir Markdown, no pelear con CMSs legacy.
La Solución: Next.js 16 & Server Components
Decidimos apostar todo a la arquitectura de React Server Components (RSC).
¿Por qué RSC?
La magia de RSC no es solo "renderizar en el servidor" (eso ya lo hacíamos con PHP en 2010). La magia es no enviar el código del componente al cliente.
Mira este ejemplo de nuestro propio código para la sección de "Proyectos Destacados":
// src/components/home/featured-projects.tsx
// Este componente corre SOLO en el servidor.
// La librería 'fs' y 'path' nunca llegan al navegador del usuario.
import fs from 'fs/promises';
import path from 'path';
export async function FeaturedProjects() {
// Leemos el sistema de archivos directamente
const projectsDir = path.join(process.cwd(), 'src/content/projects');
const files = await fs.readdir(projectsDir);
// Procesamiento pesado de datos...
const projects = await processMetadata(files);
return (
<div className="grid gap-6">
{projects.map(p => (
// ProjectCard es un Client Component solo si necesita interactividad
<ProjectCard key={p.slug} project={p} />
))}
</div>
);
}El impacto real: Toda la lógica de formateo de fechas, lectura de archivos y procesamiento de texto se queda en el servidor. Al usuario solo le llega el HTML resultante y el mínimo JS necesario para la interactividad de la tarjeta (si la tiene).
El Reto de Tailwind CSS 4.0
Somos early adopters (a veces masoquistas). Decidimos probar la alpha de Tailwind 4.
Lo bueno: El motor de compilación en Rust es absurdamente rápido. El hot-reload es instantáneo.
Lo malo (Lecciones aprendidas):
Tuvimos problemas con la configuración de plugins antiguos. Algunos componentes de librerías de UI (como shadcn/ui en sus versiones antiguas) dependían de configuraciones de tailwind.config.js que cambiaron drásticamente.
Solución: Tuvimos que reescribir manualmente algunas utilidades y envolverlas en capas de compatibilidad CSS nativas.
MDX: Tratando el Contenido como Código
No queríamos un CMS externo. Queríamos que nuestros artículos vivieran en el repositorio, pasaran por Pull Requests y tuvieran control de versiones.
Implementamos un pipeline simple pero robusto usando next-mdx-remote.
// src/lib/mdx.ts
// Así es como tipamos nuestros metadatos para asegurar consistencia
export interface BlogMeta {
title: string;
category: 'Ingeniería' | 'Tutorial' | 'Reflexión';
difficulty: 'beginner' | 'intermediate' | 'advanced';
// ...
}
// Si un dev intenta crear un post sin 'difficulty', TypeScript grita en el build time.
// ¡Adiós a los errores en producción!Resultados Finales
Después de optimizar fuentes, imágenes (usando el formato AVIF por defecto en Next.js) y depurar bundles de terceros:
- Lighthouse Score: 100/100 en las 4 categorías.
- First Contentful Paint (FCP): 0.8s en 4G.
- JavaScript Bundle Size: Reducido en un 45% comparado con nuestra versión anterior en Gatsby.
Conclusión
No necesitas la última tecnología por moda. La necesitas si resuelve un problema real. Para nosotros, Next.js 16 resolvió el problema de entregar una experiencia rica e interactiva sin sacrificar la velocidad de carga en pleno 2026.
Si estás construyendo un sitio similar, mi consejo es: empieza por el servidor. Deja que el servidor haga el trabajo pesado. Tu usuario (y su batería de móvil) te lo agradecerá.
¿Te interesa saber cómo implementamos el modo oscuro sin parpadeos? Lo cubriremos en el próximo artículo de la serie.