Desarrollador Next.js

Qué entregamos

Next.js 15 con App Router y React 19 Server Components en el frontend. WordPress 6.7+ como back end editorial, comunicándose por REST o GraphQL. Cloudflare Workers y Pages como runtime y cache en la edge. TypeScript en toda la stack. Tailwind CSS como sistema de diseño. Anthropic Claude y Model Context Protocol cuando las funciones de IA realmente compensan.

No es una lista de tecnologías sacada de una oferta de empleo, sino la stack que mantenemos en nuestra propia producción. Cada pieza tiene su justificación: el App Router permite decidir el renderizado por ruta, RSC recorta el JavaScript enviado al cliente, Workers elimina los arranques en frío y mantiene los datos al alcance de la regulación europea. Cuando una pieza deja de defenderse en la práctica, sale de la stack, y lo documentamos cada trimestre en el Tech Radar.

Cuándo Next.js es la elección correcta

Páginas personalizadas, flujos de sesión, experiencias con tests A/B, checkout transaccional, dashboards en tiempo real y espacios de trabajo autenticados se benefician del modelo streaming SSR + RSC. El modelo mental es: "renderizar cerca de los datos, hacer streaming de lo que está listo, hidratar lo que es interactivo". Para las páginas que encajan, Next.js entrega un UX que el SSR clásico o lo estático no pueden igualar.

Para las páginas que no encajan, lo decimos. Sitios de marketing con mucho contenido, blogs y documentación suelen ganar con Astro en estático + ISR a un coste menor. La decisión de framework es parte del scoping, no un valor por defecto. Si tras el discovery resulta que tu sitio no necesita Next.js, lo oirás junto con una recomendación más económica.

Arquitectura: WordPress como back end, Next.js como frontend

En una arquitectura headless, WordPress deja de renderizar páginas y se queda con lo que hace realmente bien: ser el sistema editorial. El equipo de contenido trabaja en su panel de siempre, con los mismos roles, flujos de trabajo y plugins editoriales. Next.js obtiene el contenido por REST o WPGraphQL y lo renderiza según la estrategia elegida para cada ruta: la home y las landings como estático con revalidación, el catálogo de producto como ISR con invalidación por webhooks, el checkout y el área de cliente como SSR con sesión completa.

Tres piezas deciden si esta arquitectura funciona en la práctica, y las tres forman parte de la implementación. Vista previa editorial: el redactor tiene que ver el borrador antes de publicar, así que configuramos el draft mode conectado a WordPress en lugar de explicarle al equipo que "eso ahora no se puede". Invalidación de cache: publicar en WordPress dispara un webhook que revalida exactamente las rutas afectadas por el cambio, en vez de vaciar toda la cache. Gestión de medios: las imágenes pasan por el pipeline de Next.js con AVIF automático y tamaños responsivos, suba lo que suba el redactor.

Rendimiento y Core Web Vitals

El rendimiento en Next.js no viene del framework, sino de las decisiones de arquitectura que el framework hace posibles. El streaming SSR envía el primer byte antes de que el servidor termine de renderizar el conjunto, lo que baja directamente el TTFB y el LCP. Los Server Components mantienen la lógica de obtención de datos en el servidor, así que el cliente recibe menos JavaScript y el INP deja de sufrir por hidratar todo a la vez. La cache en la edge de Cloudflare responde al usuario desde el punto de red más cercano en lugar de hacerlo desde un único servidor origin.

Cada proyecto arranca con un baseline: TTFB, LCP, INP y CLS medidos en usuarios reales antes del cambio, no en laboratorio. Tras la implementación, las mismas métricas se recogen por RUM y se comparan en la ventana de medición lado a lado. El resultado del proyecto es la diferencia en datos de campo, no una captura de Lighthouse. El protocolo público de medición Astro vs Next.js sobre WooCommerce, con la metodología disponible, está en la sección de referencia al final de la página.

WooCommerce headless sobre Next.js

Una tienda es la variante headless más exigente, porque combina contenido estático con transacción en vivo. Las fichas de producto y las categorías se renderizan como ISR: tan rápidas como lo estático, actualizadas por webhook cuando cambia el precio o el stock. El carrito, el checkout y la cuenta de cliente funcionan como SSR con sesión, conectados a la Store API de WooCommerce. Precios por cliente, escalados de descuento B2B y catálogos detrás de login, requisitos típicos de un mayorista, dejan de obligar a renunciar a la cache en toda la tienda, porque la decisión de renderizado se toma a nivel de ruta.

A esto se suma una capa por la que las tiendas preguntan cada vez más: estar preparadas para los agentes de compra de IA. HTML limpio renderizado en el servidor con schema Product y Offer correcto es la condición de entrada para que un agente vea siquiera el catálogo. Es la misma arquitectura que sirve páginas rápidas a las personas, así que no la pagas dos veces.

SEO, GEO y AEO en Next.js

El renderizado en servidor es el fundamento de visibilidad que un React de cliente nunca dará: los rastreadores de IA como GPTBot, ClaudeBot o PerplexityBot no ejecutan JavaScript, y Googlebot lo ejecuta con retraso y con presupuesto limitado. Next.js con SSR y RSC entrega el contenido completo en la primera respuesta HTML, así que lo que ve el usuario también lo ve el bot.

Sobre ese fundamento construimos la capa técnica: metadata API por ruta, canonical y hreflang via metadata.alternates, sitemap via generateSitemaps, datos estructurados como JSON-LD ajustados al tipo de página (Product, Article, FAQPage, HowTo), Open Graph con imágenes generadas por página. Para la visibilidad en buscadores generativos añadimos elementos GEO: secciones de respuesta directa, FAQ con datos estructurados, llms.txt y negociación de contenido para agentes. Cada proyecto pasa un checklist SEO de 30 puntos antes del cambio de DNS.

Seguridad y jurisdicción de la UE

Headless reduce la superficie de ataque de una forma que se puede explicar a la dirección en una frase: WordPress desaparece de la internet pública. La página de login, XML-RPC y los archivos de plugins dejan de ser alcanzables para los escáneres, porque el frontend lo sirve Next.js y el origin solo es accesible para él. A eso se suman cabeceras de seguridad configuradas de forma centralizada, validación de entradas en el servidor y secretos guardados fuera del repositorio.

Para las empresas sujetas al RGPD, NIS2 o DORA también cuenta la geografía de los datos: runtime en Cloudflare con procesamiento en la UE, contratos de encargo de tratamiento en inglés o polaco, documentación de los flujos de datos para el registro de actividades de tratamiento. Contrato B2B en jurisdicción europea, no los términos de una plataforma de fuera de ella.

Para quién es

• Tiendas WooCommerce con checkout personalizado o precios por usuario
• Dashboards SaaS y espacios de trabajo autenticados con WordPress como capa de contenido
• Marcas multi-región que necesitan ISR con invalidación por webhook
• Editoriales con feeds de datos en directo, comentarios o superficies de analítica en tiempo real
• Mayoristas B2B con catálogos detrás de login y tarifas negociadas por cliente

Modelo de colaboración

Contratos sénior B2B en jurisdicción de la UE. Cuatro fases: discovery con auditoría de contenido y baseline de rendimiento, scoping con decisiones de renderizado por ruta, construcción iterativa con demos semanales y ventana de medición lado a lado, y por último tuning y soporte con observability y revisiones trimestrales de la stack. Colaboración de alcance fijo o time-and-materials. Tarificación individual, calendario por etapas con puntos de decisión.