Ingeniería de rendimiento en Next.js

El trabajo de rendimiento tiene un modo de fallo característico: un equipo dedica un sprint a optimizar, la puntuación sube, y seis semanas después vuelve a estar donde estaba. Las correcciones no tenían nada de malo. Lo que faltaba era un mecanismo para conservarlas.

Cómo se desarrolla un encargo

Medir primero, desde el campo. Empezamos con datos del Chrome UX Report y vuestro RUM, segmentados por clase de dispositivo y plantilla de ruta. Un LCP p75 de 3,4 s en páginas de producto móviles es una afirmación accionable; «nuestra puntuación de Lighthouse es 62» no lo es.

Encontrar la causa, no el síntoma. Un LCP lento es una decisión de renderizado, una estrategia de fuentes, una cadena de imágenes o un tercero que bloquea. Un INP malo casi siempre es el tamaño y la forma del JavaScript que hidrata por encima del pliegue. Rastreamos cada métrica hasta la decisión concreta, a nivel de commit, que la produjo.

Corregir en el nivel arquitectónico. Mover un componente al otro lado de la frontera del servidor, eliminar una petición de datos en cliente que debería haber sido un render de servidor, sustituir una librería de fechas de 300 KB, dividir una ruta que envía el bundle completo del panel de administración a visitantes anónimos. Esos son los cambios que se sostienen.

Defender el resultado. Cada encargo termina con un presupuesto de rendimiento aplicado en CI. Un pull request que empuje el bundle de la ruta por encima de su techo hace fallar la comprobación. El presupuesto es el entregable; la puntuación es un efecto secundario.

Por qué la puntuación vuelve

Porque una puntuación es un resultado y nadie es dueño de un resultado. Un presupuesto es un número en un archivo, comprobado por una máquina, en cada pull request, y hace fallar el build de quien lo superó mientras todavía recuerda qué cambió.

Esa diferencia es toda la razón por la que el segundo encargo normalmente no llega. Optimizar sin presupuesto es un préstamo contra el trimestre siguiente: el mismo componente recibe un use client que no necesita, la misma librería se importa en el nivel superior, y la regresión vuelve un commit razonable detrás de otro, de gente que no tenía forma de saberlo.

Para que funcione, el presupuesto tiene que medir lo correcto. Un techo sobre el total de la salida del build no dice nada, porque el build contiene código que ninguna ruta carga. Lo que fijamos es un techo por ruta sobre el JavaScript comprimido que el HTML de esa ruta pide realmente, que es el número que paga un visitante.

Dónde se va el tiempo de verdad

A lo largo de los encargos que hacemos, las causas se agrupan:

Una frontera de cliente trazada demasiado arriba. Una directiva en un layout envía ese layout y todo lo que cuelga de él a cada visitante de cada ruta por debajo. Es la causa más común de un mal INP en una aplicación Next.js, y normalmente es una línea. Dónde va la frontera.

Una canalización de imágenes optimizada en todas partes menos en la que importa. La imagen del LCP cargada en diferido, sin dimensiones, o servida a través de una transformación que añade 300 ms antes del primer byte. Lo que cuesta, y la solución.

Una ruta que se volvió dinámica sin que nadie lo decidiera. Una sola llamada a cookies() en un componente compartido saca del renderizado estático a todas las rutas por debajo, y el CDN deja de responder. La página no se volvió lenta por el código que tiene; se volvió lenta porque dejó de estar cacheada.

Terceros cargados como si fueran gratis. Un gestor de etiquetas que arrastra otros cuatro scripts, un widget de chat que hidrata antes que el contenido, un banner de consentimiento que bloquea el renderizado que se suponía que debía condicionar. Eso no es código de aplicación, que es exactamente la razón por la que nadie lo perfila.

Tipografías que bloquean el texto para el que existen. Una fuente autoalojada sin font-display, o tres pesos cargados donde arriba del pliegue se usa uno.

Qué no hacemos

No optimizamos contra una puntuación de laboratorio que hayas elegido de antemano. Si tus datos de campo dicen que los visitantes están bien y una herramienta dice 62, la respuesta honesta es que la herramienta está midiendo un dispositivo y una red que tu audiencia no tiene, y te lo diremos en lugar de venderte un sprint.

Tampoco rodeamos una causa que no podemos arreglar haciendo otra cosa más rápida para compensar. Si el problema de LCP es un tercero que tu equipo de marketing necesita, el hallazgo lo dice, y la decisión sobre ese compromiso es tuya en lugar de quedar enterrada en un resumen.

Qué recibes

Un documento de hallazgos priorizado con cada problema rastreado hasta su causa y dimensionado por esfuerzo, las correcciones implementadas como pull requests revisables, la configuración del presupuesto en CI, y una comparación antes/después sobre datos de campo cuando el cambio lleve suficiente tiempo en producción como para mover la ventana de 28 días.

Y si el techo es la propia arquitectura - en algunas aplicaciones lo es - eso también está en los hallazgos, con el coste de la alternativa al lado. Esa conversación pertenece al principio de un encargo, no al final.