Presupuesto de rendimiento: LCP, INP y Save-Data

Precarga contra LCP: la página de ahora frente a la de después

El LCP —Largest Contentful Paint— mide cuándo aparece el elemento visible más grande de una página; es la métrica que resume cuánto tarda en cargar. La precarga tiene con el LCP una relación doble, y confundir sus dos caras es la raíz de casi todos los errores.

Para la página siguiente, la precarga es una bendición. Si su documento y sus recursos ya están en caché cuando el visitante navega, su LCP se desploma, porque no hay que esperar a la red. Ese es el beneficio que persigues, y es real.

Para la página actual, en cambio, la precarga es un competidor. Cada descarga anticipada disputa ancho de banda a los recursos que el visitante necesita ver ya. Por eso Astro emite la precarga con prioridad baja mediante <link rel="prefetch">, para que el navegador la posponga tras lo crítico.

En una conexión holgada, esa prioridad baja basta para que la precarga no dañe el LCP presente: el navegador la mete en los huecos ociosos del caño. En una conexión estrecha, donde todo compite por un tubo fino, precargar de más sí puede retrasar el LCP de la página que se está mirando. Has hipotecado el presente por un futuro que quizá no llegue.

Precarga e INP: cuando anticipar cuesta CPU

El INP —Interaction to Next Paint— mide la latencia entre que el visitante interactúa y la pantalla responde; es la métrica de cuánto responde una página. La precarga clásica, que solo descarga un documento, es casi pura red y apenas toca el hilo principal, así que su efecto sobre el INP de la página actual es mínimo.

La historia cambia con el prerenderizado. Cuando elevas la precarga a prerender —vía clientPrerender y la Speculation Rules API—, el navegador no solo trae el HTML: construye la página en segundo plano, ejecuta sus scripts, monta sus islas.

Eso ya no es solo red, es CPU, y esa CPU compite con la capacidad de la página actual de responder a las interacciones. El coste de red de un documento se paga en un caño que suele tener holgura; el coste de CPU de un prerender se paga en el único hilo por el que también pasan los eventos del visitante.

Prerenderizar una página pesada mientras el visitante intenta escribir en un campo puede encarecer su INP de forma perceptible. La regla que se deduce es limpia: cuanto más caro es el destino, más conservadora debe ser su anticipación. De ahí que eagerness: 'conservative' exista justo para las rutas intensivas en recursos.

Prioridad: en qué orden se gasta el presupuesto

Un presupuesto no solo tiene un techo, tiene un orden. Cuando los recursos escasean, lo primero que se financia debe ser lo de mayor retorno.

En precarga, eso significa reservar la anticipación temprana para el puñado de destinos que gobiernan de verdad el recorrido del visitante, y dejar el resto en espera o sin precargar.

Ese orden puede expresarse en la configuración, eligiendo una defaultStrategy tacaña como suelo común y subiendo a estrategias agresivas solo en los enlaces clave.

// astro.config.mjs — suelo conservador, lujo puntualexport default defineConfig({  prefetch: {    prefetchAll: true,    defaultStrategy: 'tap',  },});

O puede expresarse por código, cuando la decisión depende del contexto de red que solo se conoce en el cliente. La API programática, leída junto a navigator.connection, deja modular la apuesta enlace por enlace y momento a momento.

// Financiar primero lo critico; condicionar lo accesorio a que haya margenimport { prefetch } from 'astro:prefetch';const conexion = navigator.connection;const redHolgada = !conexion?.saveData && conexion?.effectiveType === '4g';prefetch('/checkout');                     // critico: siempreif (redHolgada) prefetch('/recomendados'); // accesorio: solo si sobra red

Financiar primero lo esencial y condicionar lo accesorio a que haya margen es la traducción literal de un presupuesto a código. No precargas todo lo que puedes, sino todo lo que el retorno y la red del visitante justifican, y en ese orden.

Save-Data y la red del visitante: diseño, no cortesía

Los navegadores exponen señales sobre la red y las preferencias del visitante: la cabecera Save-Data, el indicador navigator.connection.saveData para el modo de ahorro, y effectiveType para estimar la calidad de la conexión. Astro las respeta de fábrica, y su manera de hacerlo es más fina que un simple encendido y apagado.

Esas señales no son exclusivas del cliente: el servidor también recibe la cabecera Save-Data en la petición, lo que te permite adaptar incluso el HTML que emites —no solo la precarga— para quien pide ahorro.

---// El servidor tambien ve la senal de ahorro en la peticionconst ahorro = Astro.request.headers.get('Save-Data') === 'on';---

Con las estrategias declarativas, si Astro detecta ahorro de datos o conexión lenta, degrada cualquier estrategia a tap: no deja de precargar del todo, pero retrasa la apuesta hasta el instante casi seguro previo al clic, que es el más barato. Con la API programática, prefetch() directamente no precarga en esas condiciones, salvo que fuerces ignoreSlowConnection. Dos comportamientos, una misma filosofía: cuando el visitante señala que su red es escasa o cara, la anticipación se encoge sola.

Respetar esas señales no es una cortesía opcional, es parte del diseño de rendimiento. El visitante en modo de ahorro suele ser el que paga sus megabytes, el de la conexión intermitente en un tren, el del dispositivo modesto en un mercado emergente.

Precargar agresivamente sobre él invierte el sentido de la optimización: le quitas datos y batería para ahorrarle una espera que quizá ni valoraba. La velocidad que se construye ignorando al visitante más frágil no es velocidad, es privilegio disfrazado de ingeniería.