Para evaluar el rendimiento de una aplicación de página única, mide la carga inicial del documento, los cambios de ruta posteriores y las interacciones entre ellos. Son experiencias relacionadas, pero sus límites son distintos. Responder pronto a un clic no demuestra que el destino haya cargado, y una buena puntuación de entrada no describe todas las rutas que el visitante abre después.
Define qué mide realmente el informe
Una navegación completa crea un documento nuevo. Un cambio de ruta típico de una SPA modifica el documento actual. Cambiar la dirección mediante la API History no define, por sí solo, una medición de rendimiento nueva en todos los navegadores y sistemas de informes.
Distingue la recopilación basada en documentos de la que admite expresamente navegaciones suaves. La compatibilidad varía entre navegadores, herramientas de recopilación y tipos de informe. Cuando existan mediciones de navegación suave, conserva esa identificación y no las mezcles silenciosamente con cargas convencionales. Un temporizador de ruta propio también resulta útil, pero no se convierte automáticamente en LCP, INP o CLS.
La guía de Google sobre medición en SPA explica por qué importa el modelo de navegación. Comprueba la definición del conjunto de datos de tu herramienta antes de comparar resultados. Si falta la medición de una ruta, falta cobertura; no significa que la ruta sea instantánea.
Diagnostica la ruta de entrada por separado
Abre directamente un destino importante en una sesión nueva. Observa cómo el navegador descubre el contenido principal, descarga sus recursos y ejecuta el código necesario para mostrarlo. El contenido renderizado en el servidor o generado previamente puede facilitar un descubrimiento temprano, aunque la hidratación siga añadiendo trabajo de interacción.
Separa la espera de red de la ejecución y el renderizado. Una ruta puede descargar poco y detenerse mientras ejecuta JavaScript. A la inversa, reducir la ejecución no resuelve una petición de API que empieza después de dependencias evitables. Utiliza la guía de LCP para investigar el camino del contenido visible, sin atribuir el resultado únicamente al framework.
Define cuándo una ruta resulta útil
En una ficha de producto, la condición podría ser que estén disponibles su identidad, el precio actual y la acción principal. En un artículo, podría bastar con que el encabezado y el texto principal estén incorporados al documento. Elige una definición relacionada con la tarea del visitante y aplícala de forma coherente. Que desaparezca un indicador de carga no basta si la siguiente acción sigue bloqueada.
Registra el inicio en el evento del enrutador que representa la intención de navegar. Registra el final cuando se cumpla la condición elegida. Distingue cancelaciones, errores y redirecciones de transiciones completadas. Si una navegación sustituye a otra anterior, no atribuyas a la nueva ruta la finalización tardía de la anterior.
Añade una señal de tiempo de la aplicación
Este ejemplo crea un temporizador para una transición completada. Llama a beginRouteTiming() cuando comience la navegación y ejecuta la función devuelta cuando se cumpla la condición de disponibilidad. Usa un nombre de ruta normalizado, como article, en vez de una URL que contenga información personal.
function beginRouteTiming(routeName) {
const id = crypto.randomUUID();
const start = `route:${id}:start`;
const end = `route:${id}:end`;
const name = `route:${id}:ready`;
performance.mark(start);
return function finishRouteTiming() {
performance.mark(end);
const result = performance.measure(name, {
start,
end,
detail: { route: routeName }
});
performance.clearMarks(start);
performance.clearMarks(end);
performance.clearMeasures(name);
return result.duration;
};
}La duración devuelta se expresa en milisegundos. El ayudante mide el intervalo entre señales de la aplicación; no verifica que los píxeles se hayan mostrado ni que se cumpla un umbral de Core Web Vitals. Conéctalo al enrutador y al ciclo de renderizado reales. Añade limpieza al cancelar y registro de errores durante esa integración. Los nombres únicos separan mediciones satisfactorias simultáneas y la limpieza evita conservar sus entradas en la línea temporal.
Una confirmación de renderizado del framework o una llamada a requestAnimationFrame no demuestra que todo el contenido útil haya aparecido. Contrasta las señales con una traza del navegador y con el comportamiento visible antes de decidir qué representa la métrica.
Separa la respuesta a la interacción de la carga del destino
INP evalúa la respuesta a las interacciones hasta el siguiente pintado. Un clic puede mostrar enseguida un estado de carga mientras el destino continúa sin estar disponible. La interacción puede responder bien y la ruta seguir siendo lenta. Conserva ambas observaciones en lugar de llamar INP a toda la duración de la ruta.
Investiga manejadores costosos, renderizado síncrono y cálculos de disposición repetidos. Pospón el trabajo que no contribuya a la respuesta inmediata y muestra un progreso fiel a lo que ocurre. Si el hilo principal está ocupado después del clic, revisa la traza antes de cambiar ajustes de red. La guía de INP ayuda a delimitar el problema.
Carga lo necesario sin desestabilizar la vista
Dividir el código por rutas puede reducir el trabajo inicial innecesario, pero una secuencia adicional de peticiones dependientes puede retrasar el destino. Inicia conjuntamente las tareas independientes de código y datos cuando la arquitectura lo permita. Precarga de forma selectiva: el trabajo especulativo puede competir con la ruta que el visitante está utilizando.
Reserva espacio para imágenes y paneles asíncronos. Mantén estable la navegación y evita insertar contenido tardío por encima de lo que se está leyendo. Una transición puede producir movimientos molestos aunque un desplazamiento concreto quede excluido de CLS por una interacción reciente. Evalúa tanto la experiencia visible como la métrica.
Compara recorridos y conjuntos de datos equivalentes
Prueba la entrada directa, la navegación interna, las rutas repetidas, los botones de retroceso y avance y una transición con datos lentos. Incluye peticiones fallidas y transiciones abandonadas. Mantén comparables el estado de caché y las condiciones del dispositivo. De lo contrario, una ruta ya preparada puede aparentar una mejora que solo proviene del trabajo anterior.
Los límites de una buena experiencia son LCP igual o inferior a 2.5 s, INP igual o inferior a 200 ms y CLS igual o inferior a 0.1, en el percentil 75 y separando móvil y escritorio. Se aplican a las mediciones definidas de Core Web Vitals, no a temporizadores arbitrarios de la aplicación. Comprueba si el informe representa una URL, un origen, cargas de documentos o navegaciones suaves identificadas.
Asocia el contexto de ruta a la interacción o transición que lo produjo, no a la URL que casualmente esté activa cuando se envía la telemetría. Revisa la diferencia entre datos de campo y laboratorio antes de extrapolar una traza local satisfactoria a todos los visitantes. Un informe útil permite identificar recorridos lentos y comprobar las correcciones.
