Fecha de publicación: 31 de marzo de 2014
La base de toda estrategia de rendimiento sólida es una buena medición e instrumentación. No se puede optimizar lo que no se puede medir. En esta guía, se explican diferentes enfoques para medir el rendimiento de CRP.
- El método Lighthouse realiza una serie de pruebas automatizadas en una página y, a continuación, genera un informe sobre el rendimiento de CRP en la página. Este enfoque proporciona una descripción general rápida y básica de alto nivel del rendimiento de CRP de una página en particular cargada en tu navegador, lo que te permite probar, iterar y mejorar su rendimiento rápidamente.
- El método Navigation Timing API captura métricas de supervisión de usuario real (RUM). Como su nombre insinúa, estas métricas se capturan de las interacciones de los usuarios reales con tu sitio y proporcionan una vista precisa del rendimiento de CRP en el mundo real, tal como lo experimentan los usuarios de varios dispositivos y diferentes condiciones de red.
En general, es buena idea usar Lighthouse para identificar oportunidades obvias de optimización de CRP y, luego, instrumentar tu código con la API de Navigation Timing para supervisar el rendimiento de tu app en el mundo real.
Cómo realizar auditorías de una página con Lighthouse
Lighthouse es una herramienta de auditoría de apps web que ejecuta una serie de pruebas en una página determinada y, luego, muestra los resultados de la página en un informe consolidado. Puedes ejecutar Lighthouse como una extensión de Chrome o un módulo de NPM, lo que es útil para integrar Lighthouse en sistemas de integración continua.
Para comenzar, lee Auditorías de apps web con Lighthouse.
Cuando ejecutas Lighthouse como una extensión de Chrome, los resultados de CRP de tu página se ven como en la siguiente captura de pantalla.
Consulta Cadenas de solicitudes críticas para obtener más información sobre los resultados de esta auditoría.
Instrumenta tu código con la API de Navigation Timing
La combinación de Navigation Timing API y otros eventos del navegador emitidos mientras se carga la página te permite capturar y grabar el rendimiento real de CRP de cualquier página.
Cada una de las etiquetas del diagrama anterior corresponde a una marca de tiempo de alta resolución que el navegador rastrea para cada una de las páginas que carga. De hecho, en este caso específico solo mostraremos una fracción de todas las marcas de tiempo diferentes; por ahora, omitiremos todas las marcas de tiempo relacionadas con la red, pero regresaremos a ellas en una de las próximas lecciones.
¿Qué significan estas marcas de tiempo?
domLoading
: Es la marca de tiempo de inicio de todo el proceso. El navegador está a punto de comenzar a analizar los primeros bytes recibidos del documento HTML.domInteractive
: Marca el punto en el que el navegador termina de analizar todo el HTML y se completa la construcción del DOM.domContentLoaded
: Marca el punto en el que el DOM está listo y no hay hojas de estilo que bloqueen la ejecución de JavaScript, lo que significa que ahora (posiblemente) podemos construir el árbol de renderización.- Muchos frameworks de JavaScript esperan este evento antes de comenzar a ejecutar su propia lógica. Por este motivo, el navegador captura las marcas de tiempo
EventStart
yEventEnd
para permitirnos realizar un seguimiento del tiempo que llevó esta ejecución.
- Muchos frameworks de JavaScript esperan este evento antes de comenzar a ejecutar su propia lógica. Por este motivo, el navegador captura las marcas de tiempo
domComplete
: Como su nombre lo indica, se completó la totalidad del procesamiento y se terminaron de descargar todos los recursos de la página (imágenes, etc.); en otras palabras, el indicador de carga dejó de girar.loadEvent
: Como paso final en cada carga de página, el navegador activa un eventoonload
que puede activar lógica de aplicación adicional.
La especificación HTML dicta condiciones específicas para cada evento: cuándo se debe activar, qué condiciones debe cumplir y otras consideraciones importantes. Para nuestros fines, nos enfocaremos en algunos elementos claves relacionados con la ruta de acceso de renderización crítica:
domInteractive
marca cuándo el DOM está listo.domContentLoaded
generalmente marca cuándo tanto el DOM como el CSSOM están listos.- Si no hay analizadores que bloqueen JavaScript,
DOMContentLoaded
se activará de inmediato después dedomInteractive
.
- Si no hay analizadores que bloqueen JavaScript,
domComplete
marca el momento en que la página y todos sus recursos secundarios están listos.
<!DOCTYPE html>
<html>
<head>
<title>Critical Path: Measure</title>
<meta name="viewport" content="width=device-width,initial-scale=1" />
<link href="style.css" rel="stylesheet" />
<script>
function measureCRP() {
var t = window.performance.timing,
interactive = t.domInteractive - t.domLoading,
dcl = t.domContentLoadedEventStart - t.domLoading,
complete = t.domComplete - t.domLoading;
var stats = document.createElement('p');
stats.textContent =
'interactive: ' +
interactive +
'ms, ' +
'dcl: ' +
dcl +
'ms, complete: ' +
complete +
'ms';
document.body.appendChild(stats);
}
</script>
</head>
<body onload="measureCRP()">
<p>Hello <span>web performance</span> students!</p>
<div><img src="awesome-photo.jpg" /></div>
</body>
</html>
El ejemplo anterior puede parecer intimidante a primera vista, pero en realidad es bastante sencillo. La Navigation Timing API captura todas las marcas de tiempo relevantes y nuestro código espera a que se active el evento onload
(recuerda que el evento onload
se activa después de domInteractive
, domContentLoaded
y domComplete
) y calcula la diferencia entre las diversas marcas de tiempo.
Dicho esto, ahora tenemos algunos hitos específicos de los que hacer un seguimiento y una función básica para obtener estas mediciones. Ten en cuenta que, en lugar de imprimir estas métricas en la página, también puedes modificar el código para enviarlas a un servidor de estadísticas (Google Analytics lo hace automáticamente), lo que es una excelente manera de hacer un seguimiento del rendimiento de tus páginas y de identificar las páginas candidatas que pueden beneficiarse de un trabajo de optimización.
¿Qué sucede con DevTools?
Si bien estos documentos a veces usan el panel Network de Chrome DevTools para ilustrar conceptos de CRP, DevTools no es ideal para realizar mediciones de CRP porque no cuenta con un mecanismo incorporado para aislar recursos críticos. Ejecuta una auditoría de Lighthouse para identificar estos recursos.