Medir la precarga: DevTools, Lighthouse y RUM

DevTools: ver la precarga con los propios ojos

El primer instrumento es la pestaña de red del navegador. Una petición de precarga se distingue de una normal en dos señales: su prioridad aparece como la más baja y su iniciador es la precarga, no un clic.

Cuando después navegas al destino, la petición del documento se sirve desde la caché de precarga —lo verás en la columna de tamaño— en lugar de golpear la red. Esa es la prueba visible de que la anticipación funcionó y de que has ahorrado un viaje completo de ida y vuelta.

Igual de valioso es detectar cuándo no funciona. Una precarga que se descarga pero no se reutiliza al navegar es gasto puro, y su causa más común son las cabeceras de caché.

Sin una Cache-Control, Expires o ETag adecuada, algunos navegadores descartan el documento precargado y vuelven a pedirlo: Firefox llega a abortar la precarga con un NS_BINDING_ABORTED, y Safari, que no soporta <link rel="prefetch"> y cae a fetch(), exige esas cabeceras para reutilizar nada.

En páginas estáticas o prerenderizadas, el ETag suele ponerlo tu plataforma de despliegue. En páginas dinámicas de servidor eres tú quien debe fijar las cabeceras según el contenido, y hacerlo es la diferencia entre precargar y reprecargar.

---// Ruta dinamica: cabeceras que permiten reutilizar el documento precargadoAstro.response.headers.set('Cache-Control', 'public, max-age=300');---

Si en DevTools ves la precarga descargarse y repetirse al navegar, casi siempre el culpable son las cabeceras. Arréglalas antes de medir nada más: medir un motor que gira en vacío solo produce números tristes.

Lighthouse: potente en su terreno, ciego fuera de él

Lighthouse es la herramienta de laboratorio por excelencia, y por eso mismo tiene un punto ciego para lo que aquí nos ocupa. Lighthouse carga una página en frío, aislada, y mide su rendimiento inicial.

Pero el beneficio de la precarga no está en la carga inicial de una página: está en la navegación a la siguiente, un evento que un análisis de una sola página en frío no llega a observar. Puedes tener una precarga perfectamente afinada y Lighthouse no reflejará ni un punto de mejora, porque mide justo lo que la precarga no toca.

Peor aún, Lighthouse puede penalizarte por precargar: si tu página descarga documentos anticipados que su auditoría considera bytes no usados durante esa carga inicial, lo verá como desperdicio, no como inversión.

Esto no significa que Lighthouse sea inútil —es excelente para el LCP, el INP de laboratorio, el peso de la página actual— sino que hay que leerlo sabiendo qué mide y qué no. Para juzgar la precarga, la carga aislada de una página es el instrumento equivocado.

RUM: la única medida que cuenta la verdad

La precarga optimiza la experiencia de personas reales navegando por rutas reales, y solo una medición de personas reales puede juzgarla. Eso es el RUM —Real User Monitoring—: instrumentar tu sitio para recoger métricas de campo de visitantes de carne y hueso. La librería web-vitals de Google es el camino idiomático.

<script>  import { onLCP, onINP, onCLS } from 'web-vitals';  const enviar = (m) => navigator.sendBeacon('/metricas', JSON.stringify(m));  onLCP(enviar);  onINP(enviar);  onCLS(enviar);</script>

Con datos de campo puedes por fin responder la pregunta que importa: ¿mis visitantes navegan más rápido con la precarga que sin ella? Comparas los tiempos de navegación agregados y miras el LCP de las páginas de destino.

Pero la medida más reveladora es la tasa de acierto: cuántas de tus precargas terminaron usándose frente a cuántas se descargaron en vano. Puedes aproximarla marcando lo que precargas y comprobando, en la página siguiente, si venías de un destino anticipado.

// Al precargar, deja una marca; al aterrizar, comprueba si acertasteimport { prefetch } from 'astro:prefetch';export function precargarYMarcar(url: string) {  sessionStorage.setItem('precargada', url);  prefetch(url);}// En la pagina de destinoconst previa = sessionStorage.getItem('precargada');const acierto = previa === location.pathname;navigator.sendBeacon('/metricas', JSON.stringify({ tipo: 'acierto', acierto }));

Una tasa alta significa que tu apuesta acierta y el gasto se justifica. Una tasa baja significa que estás quemando ancho de banda ajeno para acelerar navegaciones que no ocurren, y toca podar. Fuentes públicas como el informe de experiencia de Chrome agregan estas mismas métricas de campo si quieres un punto de comparación externo.

El equilibrio: velocidad percibida contra coste

Medir no es un fin, es el insumo de una decisión: ¿merece la pena lo que gasto por la velocidad que compro? La respuesta se afina con dos números que ahora sabes obtener —la mejora en los tiempos de navegación de campo y la tasa de acierto— leídos juntos.

El primero lo da la propia plataforma: la entrada de navegación del Performance API mide cuánto tardó de verdad cada carga, y agregada en campo revela si la precarga acortó las navegaciones reales.

// Duracion real de la navegacion, para comparar con y sin precargaconst [nav] = performance.getEntriesByType('navigation');navigator.sendBeacon('/metricas', JSON.stringify({  ruta: location.pathname,  duracion: Math.round(nav.duration),}));

Fija un umbral de acierto por debajo del cual una precarga no se justifica, y poda sin sentimentalismo lo que no lo alcance: enlaces de baja probabilidad, destinos caros, secciones que nadie recorre en cadena. Sube la agresividad solo donde el campo confirme que la gente de verdad encadena esas páginas. El objetivo no es la precarga máxima, sino la máxima velocidad percibida por byte arriesgado.