Medición de la ruta de representación crítica

Ilya Grigorik

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 distintos métodos 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 usuarios reales (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 realiza una serie de pruebas en una página determinada y, a continuación, 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, que es útil para integrar Lighthouse con sistemas de integración continua.

Para comenzar, lee Auditorías de apps web con Lighthouse.

Cuando ejecutas Lighthouse como una extensión de Chrome, la CRP de tu página luce similar a 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: Esta es la marca de tiempo inicial de todo el proceso. El navegador está por 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 y EventEnd para permitirnos realizar un seguimiento del tiempo que llevó esta ejecución.
• 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 evento onload 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 eventos importantes relacionados con la ruta de acceso de renderización crítica:

• domInteractive marca el momento en que el DOM está listo.
• domContentLoaded suele marcar el momento en que el DOM y el CSSOM están listos.
  • Si no hay analizadores que bloqueen JavaScript, DOMContentLoaded se activará de inmediato después de domInteractive.
• 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>

Probar

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.

En resumen, ahora tenemos algunos elementos claves específicos por delante y una función básica para obtener esas 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.

Comentarios