Lighthouse: Optimiza la velocidad del sitio web

Kayce vascos
Kayce Vascos
Sofía Emelianova
Sofía Emelianova

Objetivo del instructivo

En este instructivo, aprenderás a usar las Herramientas para desarrolladores de Chrome para encontrar maneras de hacer que tus sitios web se carguen más rápido.

Sigue leyendo o mira la versión en video de este instructivo:

Requisitos previos

Debes tener experiencia básica en desarrollo web, similar a la que se enseña en esta clase Introducción al desarrollo web.

No necesitas saber nada sobre el rendimiento de carga.

Introducción

Soy Tony. Tony es muy famoso en la sociedad de los gatos. Creó un sitio web para que sus fans puedan saber cuáles son sus comidas favoritas. A sus fans les encanta el sitio, pero Tony sigue escuchando quejas de que el sitio se carga lentamente. Antonio te pidió que lo ayudaras a acelerar el sitio.

El gato Tony.

Paso 1: Audita el sitio

Siempre que te propongas mejorar el rendimiento de carga de un sitio, comienza con una auditoría. La auditoría tiene dos funciones importantes:

  • Crea un modelo de referencia con el que podrás medir los cambios posteriores.
  • Allí encontrarás sugerencias prácticas sobre los cambios que tendrán el mayor impacto.

Configuración

Primero, debes configurar un nuevo entorno de trabajo para el sitio web de Tony, de modo que puedas hacerle cambios más adelante:

  1. Haz un remix del proyecto del sitio web en Glitch. El proyecto nuevo se abrirá en una pestaña. Esta pestaña se denominará pestaña Editor.

    La fuente original y la pestaña del editor después de hacer clic en Remix.

    El nombre del proyecto cambia de tony a algún nombre generado al azar. Ahora tienes tu propia copia editable del código. Más adelante, realizarás cambios en este código.

  2. En la parte inferior de la pestaña del editor, haz clic en Vista previa > Vista previa en una ventana nueva. La demostración se abrirá en una pestaña nueva. Esta pestaña se denominará pestaña de demostración. Es posible que el sitio demore un poco en cargarse.

    La pestaña de demostración

  3. Abre Herramientas para desarrolladores junto a la demostración.

    Herramientas para desarrolladores y la demostración.

Cómo establecer un modelo de referencia

El modelo de referencia es un registro del rendimiento del sitio antes de que realizaras mejoras.

  1. Abre el panel Lighthouse. Es posible que esté oculto detrás de Más paneles.

    El panel Lighthouse

  2. Haz que los parámetros de configuración de tu informe de Lighthouse coincidan con los de la captura de pantalla. A continuación, se explican las diferentes opciones:

    • Liberar espacio de almacenamiento. Si habilitas esta casilla de verificación, se borrará todo el almacenamiento asociado con la página antes de cada auditoría. Deja este parámetro de configuración activado si deseas auditar la experiencia de los visitantes nuevos en tu sitio. Inhabilita este parámetro de configuración cuando quieras la experiencia de volver a visitar la tienda.
    • Limitación simulada (predeterminada) . Esta opción simula las condiciones típicas de navegación en un dispositivo móvil. Se denomina "simulación" porque Lighthouse no limita el proceso durante el proceso de auditoría. En cambio, simplemente extrapola cuánto tiempo tardaría la página en cargarse en condiciones de dispositivos móviles. Por otro lado, el parámetro de configuración Limitación de DevOps (avanzado) limita la CPU y la red, con la compensación de un proceso de auditoría más largo.
    • Modo > Navegación (predeterminado). Este modo analiza la carga de una sola página, y eso es lo que necesitamos en este instructivo. Para obtener más información, consulta Los tres modos.
    • Dispositivo > Dispositivo móvil. La opción para dispositivos móviles cambia la string de usuario-agente y simula un viewport de dispositivo móvil. La opción de escritorio simplemente inhabilita los cambios en los dispositivos móviles.
    • Categorías > Rendimiento. Si habilitas una sola categoría, Lighthouse generará un informe solo con el conjunto de auditorías correspondiente. Puedes dejar habilitadas las otras categorías si deseas ver los tipos de recomendaciones que ofrecen. Inhabilitar categorías irrelevantes acelera un poco el proceso de auditoría.
  3. Haz clic en Analizar la carga de la página. Después de 10 a 30 segundos, el panel Lighthouse te muestra un informe del rendimiento del sitio.

    Un informe de Lighthouse sobre el rendimiento del sitio

Maneja los errores de los informes

Si alguna vez recibes un error en tu informe de Lighthouse, intenta ejecutar la pestaña de demostración desde una ventana de incógnito sin otras pestañas abiertas. Esto garantiza que ejecutes Chrome desde un estado limpio. En particular, las extensiones de Chrome pueden interferir en el proceso de auditoría.

Un informe con un error.

Comprende tu informe

La cifra que aparece en la parte superior de tu informe corresponde a la puntuación del rendimiento general del sitio. Más adelante, a medida que realices cambios en el código, deberías ver que este número aumenta. Una puntuación más alta significa un mejor rendimiento.

Es la puntuación de rendimiento general.

Métricas

Desplázate hacia abajo hasta la sección Métricas y haz clic en Expandir vista. Para leer la documentación sobre una métrica, haz clic en Más información....

La sección Métricas

En esta sección, se proporcionan mediciones cuantitativas del rendimiento del sitio. Cada métrica proporciona estadísticas sobre un aspecto diferente del rendimiento. Por ejemplo, el First Contentful Paint indica la primera vez que el contenido se pinta en la pantalla, lo que constituye un hito importante en la percepción que tiene el usuario de la carga de la página, mientras que Time To Interactive indica el punto en el que la página parece estar lo suficientemente lista para controlar las interacciones del usuario.

Capturas de pantalla

A continuación, incluimos una colección de capturas de pantalla que te muestran cómo se veía la página mientras se cargaba.

Capturas de pantalla del aspecto de la página mientras se cargaba.

Oportunidades

A continuación, se encuentra la sección Oportunidades, en la que se proporcionan sugerencias específicas sobre cómo mejorar el rendimiento de carga de esta página en particular.

La sección Oportunidades

Haz clic en una oportunidad para obtener más información al respecto.

Más información sobre la oportunidad de compresión de texto.

Haz clic en Más información... para ver la documentación sobre por qué una oportunidad es importante y recomendaciones específicas sobre cómo corregirla.

Diagnóstico

En la sección Diagnóstico, se proporciona más información sobre los factores que contribuyen al tiempo de carga de la página.

La sección Diagnóstico

Auditorías aprobadas

En la sección Auditorías aprobadas, se muestra lo que el sitio está haciendo correctamente. Haz clic para expandir la sección.

La sección de auditorías aprobadas

Paso 2: Experimenta

La sección Oportunidades de tu informe de Lighthouse te brinda sugerencias para mejorar el rendimiento de la página. En esta sección, implementarás los cambios recomendados en la base de código y auditarás el sitio después de cada cambio para medir cómo afecta su velocidad.

Habilita la compresión de texto

En tu informe, se indica que habilitar la compresión de texto es una de las principales oportunidades para mejorar el rendimiento de la página.

La compresión de texto se produce cuando se reduce o comprime el tamaño de un archivo de texto antes de enviarlo a través de la red. Es así como puedes comprimir una carpeta antes de enviarla por correo electrónico para reducir su tamaño.

Antes de habilitar la compresión, a continuación, se describen algunas maneras en las que puedes verificar de forma manual si los recursos de texto están comprimidos.

Abre el panel Red y marca Configuración > Usar filas de solicitud grandes.

La columna Tamaño en el panel Red que muestra filas de solicitud grandes.

Cada celda de Size muestra dos valores. El valor superior es el tamaño del recurso descargado. El valor inferior es el tamaño del recurso sin comprimir. Si los dos valores son iguales, el recurso no se comprime cuando se envía a través de la red. En este ejemplo, los valores inferior y superior de bundle.js son 1.4 MB.

Para comprobar la compresión, también puedes inspeccionar los encabezados HTTP de un recurso:

  1. Haz clic en bundle.js y abre la pestaña Encabezados.

    La pestaña Encabezados.

  2. Busca un encabezado content-encoding en la sección Encabezados de respuesta. No deberías ver uno, lo que significa que bundle.js no estaba comprimido. Cuando un recurso se comprime, este encabezado suele establecerse en gzip, deflate o br. Consulta las Directivas para obtener una explicación de estos valores.

Suficiente con las explicaciones. Es hora de hacer algunos cambios. Para habilitar la compresión de texto, agrega un par de líneas de código:

  1. En la pestaña del editor, abre server.js y agrega las siguientes dos líneas (destacadas):

    ...
    const fs = require('fs');
    const compression = require('compression');
    
    app.use(compression());
    app.use(express.static('build'));
    ...
    
  2. Asegúrate de colocar app.use(compression()) antes de app.use(express.static('build')).

    Editando server.js.

  3. Espera a que Glitch implemente la compilación nueva del sitio. Un emoji feliz en la esquina inferior izquierda indica que la implementación se realizó correctamente.

Usa los flujos de trabajo que aprendiste antes para verificar de forma manual que la compresión funcione:

  1. Regresa a la pestaña de demostración y vuelve a cargar la página.

    La columna Size ahora debería mostrar dos valores diferentes para los recursos de texto, como bundle.js. El valor superior de 269 KB para bundle.js es el tamaño del archivo que se envió a través de la red y el valor inferior de 1.4 MB es el tamaño del archivo sin comprimir.

    En la columna Size, ahora se muestran dos valores diferentes para los recursos de texto.

  2. La sección Encabezados de respuesta para bundle.js ahora debe incluir un encabezado content-encoding: gzip.

    La sección Encabezados de respuesta ahora contiene un encabezado de codificación de contenido.

Vuelve a ejecutar el informe de Lighthouse en la página para medir el impacto que tiene la compresión de texto en el rendimiento de carga de la página:

  1. Abre el panel Lighthouse y haz clic en en Agregar. Realizar una auditoría... en la barra de acciones de la parte superior.

    El botón Realizar una auditoría

  2. Deja los parámetros de configuración anteriores y haz clic en Analizar la carga de la página.

    Un informe de Lighthouse después de habilitar la compresión de texto

¡Muy bien! Eso parece progreso. Tu puntuación de rendimiento general debería haber aumentado, lo que significa que el sitio es cada vez más rápido.

Compresión de texto en el mundo real

La mayoría de los servidores cuentan con correcciones sencillas como esta para habilitar la compresión. Solo haz una búsqueda sobre cómo configurar cualquier servidor que uses para comprimir texto.

Cómo cambiar el tamaño de las imágenes

Su nuevo informe indica que ajustar el tamaño de las imágenes correctamente es otra gran oportunidad.

Cambiar el tamaño de las imágenes ayuda a acelerar el tiempo de carga, ya que reduce el tamaño de las imágenes. Si el usuario ve las imágenes en la pantalla de un dispositivo móvil que tiene 500 píxeles de ancho, no tiene sentido enviar una imagen de 1,500 píxeles de ancho. Lo ideal sería enviar una imagen de 500 píxeles de ancho como máximo.

  1. En tu informe, haz clic en Tamaño correcto de las imágenes para ver a qué imágenes se debe cambiar el tamaño. Parece que las 4 imágenes son más grandes de lo necesario.

    Detalles sobre la oportunidad de utilizar imágenes de un tamaño adecuado

  2. En la pestaña del editor, abre src/model.js.

  3. Reemplaza const dir = 'big' por const dir = 'small'. Este directorio contiene copias de las mismas imágenes a las que se les cambió el tamaño.

  4. Vuelve a auditar la página para ver cómo este cambio afecta el rendimiento de carga.

    Un informe de Lighthouse después de cambiar el tamaño de las imágenes

Parece que el cambio solo tiene un efecto leve en la puntuación del rendimiento general. Sin embargo, algo que la puntuación no muestra con claridad es la cantidad de datos de red que se ahorran a los usuarios. El tamaño total de las fotos antiguas era de alrededor de 6.1 MB, mientras que ahora solo pesan unos 633 KB. Puedes verificar esto en la barra de estado en la parte inferior del panel Red.

Cantidad de datos transferidos antes y después de cambiar el tamaño de las imágenes.

Cómo cambiar el tamaño de las imágenes en el mundo real

Para una app pequeña, hacer un cambio de tamaño único como este puede ser suficiente. Sin embargo, para una app grande, esto no es escalable. Estas son algunas estrategias para administrar imágenes en apps grandes:

  • Cambia el tamaño de las imágenes durante el proceso de compilación.
  • Crea varios tamaños de cada imagen durante el proceso de compilación y, luego, usa srcset en tu código. Durante el tiempo de ejecución, el navegador se encarga de elegir qué tamaño es mejor para el dispositivo en el que se está ejecutando. Consulta Imágenes de tamaño relativo.
  • Usa una CDN de imágenes que te permita cambiar el tamaño de una imagen de forma dinámica cuando la solicites.
  • Como mínimo, optimiza cada imagen. A menudo, esto puede generar grandes ahorros. La optimización ocurre cuando ejecutas una imagen a través de un programa especial que reduce el tamaño del archivo de imagen. Consulta Optimización esencial de imágenes para obtener más sugerencias.

Elimina los recursos que bloquean el procesamiento

Según tu informe más reciente, la eliminación de los recursos que bloquean la renderización ahora es la mayor oportunidad.

Un recurso que bloquea el procesamiento es un archivo JavaScript o CSS externo que el navegador debe descargar, analizar y ejecutar para poder mostrar la página. El objetivo es ejecutar solo el código CSS y JavaScript principal que se necesita para mostrar la página correctamente.

La primera tarea, entonces, es encontrar código que no necesite ejecutarse cuando se cargue la página.

  1. Haz clic en Eliminar los recursos que bloquean la renderización para ver los recursos que están bloqueando: lodash.js y jquery.js.

    Más información sobre la oportunidad "reducir los recursos que bloquean la renderización".

  2. Según el sistema operativo, presiona lo siguiente para abrir el menú de comandos:

    • En Mac, Comando + Mayúsculas + P.
    • En Windows, Linux o ChromeOS, Control + Mayúsculas + P.
  3. Comienza a escribir Coverage y selecciona Show Coverage.

    Abriendo el menú de comandos desde el panel de Lighthouse.

    La pestaña Cobertura se abrirá en el panel lateral.

    La pestaña Cobertura

  4. Haz clic en Vuelve a cargar la página. Volver a cargar. La pestaña Cobertura proporciona una descripción general de cuánto código de bundle.js, jquery.js y lodash.js se ejecuta mientras se carga la página.

    El Informe de cobertura

    En esta captura de pantalla, se indica que no se usan alrededor del 74% y el 30% de los archivos jQuery y Lodash, respectivamente.

  5. Haz clic en la fila jquery.js. Herramientas para desarrolladores abrirá el archivo en el panel Fuentes. Se ejecutó una línea de código si tiene una barra verde a su lado. Una barra roja junto a una línea de código significa que no se ejecutó y, definitivamente, no se necesita cuando se carga la página.

    Visualización del archivo jQuery en el panel Sources.

  6. Desplázate un poco por el código de jQuery. Algunas de las líneas que se "ejecutan" son en realidad solo comentarios. Otra forma de reducir el tamaño de este archivo es ejecutar este código a través de un reductor que quita los comentarios.

En resumen, cuando trabajas con tu propio código, la pestaña Cobertura puede ayudarte a analizarlo, línea por línea y a enviar solo el código necesario para cargar la página.

¿Los archivos jquery.js y lodash.js son necesarios para cargar la página? En la pestaña Bloqueo de solicitudes, puedes ver lo que sucede cuando los recursos no están disponibles.

  1. Haz clic en la pestaña Red y vuelve a abrir el Menú de comandos.
  2. Comienza a escribir blocking y, luego, selecciona Show Request Blocking. Se abrirá la pestaña Bloqueo de solicitudes.

    La pestaña Solicitar bloqueo

  3. Haz clic en en Agregar. Add Pattern (Agregar patrón), escribe /libs/* en el cuadro de texto y presiona Intro para confirmar.

    Se agregó un patrón para bloquear cualquier solicitud al directorio "libs".

  4. Vuelve a cargar la página. Las solicitudes jQuery y Lodash están en rojo, lo que significa que estaban bloqueadas. La página aún se carga y es interactiva, por lo que parece que estos recursos ya no son necesarios.

    En el panel Network, se muestra que se bloquearon las solicitudes.

  5. Haz clic en Quitar. Quitar todos los patrones para borrar el patrón de bloqueo /libs/*.

En general, la pestaña Bloqueo de solicitudes es útil para simular el comportamiento de tu página cuando un recurso determinado no está disponible.

Ahora, quita del código las referencias a estos archivos y vuelve a auditar la página:

  1. En la pestaña del editor, abre template.html.
  2. Borra las etiquetas <script> correspondientes:

    <head>
        ...
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <script src="/libs/lodash.js"></script>
        <script src="/libs/jquery.js"></script>
        <title>Tony's Favorite Foods</title>
    </head>
    
  3. Espera a que el sitio se vuelva a compilar y a implementar.

  4. Vuelve a auditar la página desde el panel de Lighthouse. Tu puntuación general debería haber mejorado nuevamente.

    Un informe de Lighthouse después de quitar los recursos que bloquean la renderización

Cómo optimizar la ruta de acceso de representación crítica en el mundo real

La Ruta de acceso de representación crítica hace referencia al código que necesitas para cargar una página. En general, para acelerar la carga de la página, solo debes enviar el código crítico durante la carga de la página y, luego, realizar una carga diferida de todo lo demás.

  • Es poco probable que encuentres secuencias de comandos que puedas quitar directamente. Sin embargo, a menudo notarás que no es necesario solicitar muchas secuencias de comandos durante la carga de la página, sino que pueden solicitarse de forma asíncrona. Consulta Cómo usar las funciones asíncronas o aplazadas.
  • Si usas un framework, verifica si tiene un modo de producción. Este modo puede usar una función como la eliminación de código no utilizado para eliminar el código innecesario que bloquea la renderización crítica.

Menos trabajo en el subproceso principal

En tu informe más reciente, se muestran algunos ahorros potenciales menores en la sección Oportunidades. Sin embargo, si te desplazas hacia abajo hasta la sección Diagnóstico, parece que el mayor cuello de botella es demasiada actividad en el subproceso principal.

El subproceso principal es donde el navegador realiza la mayor parte del trabajo necesario para mostrar una página, como analizar y ejecutar HTML, CSS y JavaScript.

El objetivo es usar el panel Performance para analizar qué trabajo realiza el subproceso principal mientras se carga la página y encontrar formas de diferir o quitar el trabajo innecesario.

  1. Abre Rendimiento > Configuración. Configuración de captura y establece la Red en 3G lenta y la CPU en Retraso de 6 veces.

    Cómo configurar la limitación de la CPU y la red en el panel Rendimiento

    Los dispositivos móviles generalmente tienen más restricciones de hardware que las computadoras portátiles o de escritorio, por lo que esta configuración te permite experimentar la carga de la página como si utilizaras un dispositivo menos potente.

  2. Haz clic en Vuelve a cargar la página. Volver a cargar. Herramientas para desarrolladores vuelve a cargar la página y produce una visualización de todo lo que se debió hacer para cargarla. Esta visualización se denominará trace.

    Es el seguimiento del panel Rendimiento de la carga de página.

El seguimiento muestra la actividad en orden cronológico, de izquierda a derecha. Los gráficos de FPS, CPU y NET en la parte superior te brindan una descripción general de los fotogramas por segundo, la actividad de CPU y la actividad de red.

La sección Descripción general del seguimiento.

El muro de color amarillo que ve en la sección Descripción general indica que la CPU estuvo completamente ocupada con actividad de secuencias de comandos. Esta es una pista de que podrías acelerar la carga de la página si realizas menos trabajo de JavaScript.

Investiga el seguimiento para encontrar maneras de reducir el trabajo de JavaScript:

  1. Haz clic en la sección Tiempos para expandirla.

    La sección Tiempos.

    Hay muchas mediciones de Tiempo de usuario de React. Parece que la app de Tony usa el modo de desarrollo de React. Cambiar al modo de producción de React probablemente te permita mejorar el rendimiento fácilmente.

  2. Vuelve a hacer clic en Tiempos para contraer esa sección.

  3. Explora la sección Principal. En esta sección, se muestra un registro cronológico de la actividad del subproceso principal, de izquierda a derecha. El eje Y (de arriba abajo) muestra por qué ocurrieron los eventos.

    La sección principal

    En este ejemplo, el evento Evaluate Script hizo que se ejecutara la función (anonymous), lo que hizo que se ejecutara __webpack__require__, lo que hizo que se ejecutara ./src/index.jsx, etcétera.

  4. Desplázate hacia la parte inferior de la sección Principal. Cuando usas un framework, la mayor parte de la actividad superior se debe al framework, que, por lo general, está fuera de tu control. La actividad causada por tu app suele estar en la parte inferior.

    La actividad de mineBitcoin

    En esta app, parece que una función llamada App causa muchas llamadas a una función mineBitcoin. Parece que Tony está usando los dispositivos de sus fans para minar criptomonedas...

  5. Abre la pestaña Bottom-Up en la parte inferior. Esta pestaña desglosa las actividades que más tiempo ocuparon. Si no ves nada en la sección Bottom-Up, haz clic en la etiqueta de la sección Main.

    La pestaña Bottom-Up.

    La sección De abajo hacia arriba solo muestra información de cualquier actividad o grupo de actividades que hayas seleccionado. Por ejemplo, si hiciste clic en una de las actividades mineBitcoin, la sección Bottom-Up solo mostrará información para esa actividad específica.

    La columna Tiempo propio muestra cuánto tiempo se dedicó directamente a cada actividad. En este caso, se dedicó alrededor del 82% del tiempo del subproceso principal a la función mineBitcoin.

Es momento de comprobar si el uso del modo de producción y la reducción de la actividad de JavaScript aceleran la carga de la página. Comienza con el modo de producción:

  1. En la pestaña del editor, abre webpack.config.js.
  2. Cambia "mode":"development" por "mode":"production".
  3. Espera a que se implemente la compilación nueva.
  4. Vuelve a auditar la página.

    Un informe de Lighthouse después de configurar webpack para usar el modo de producción

Quita la llamada a mineBitcoin para reducir la actividad de JavaScript:

  1. En la pestaña del editor, abre src/App.jsx.
  2. Marca como comentario la llamada a this.mineBitcoin(1500) en constructor.
  3. Espera a que se implemente la compilación nueva.
  4. Vuelve a auditar la página.

Un informe de Lighthouse después de quitar el trabajo innecesario de JavaScript

Como siempre, aún hay cosas por hacer, por ejemplo, reducir las métricas Largest Contentful Paint y Cambio de diseño acumulado.

Cómo reducir el trabajo de subproceso principal en el mundo real

En general, el panel Rendimiento es la forma más común de comprender qué actividad realiza tu sitio mientras se carga, además de encontrar maneras de quitar la actividad innecesaria.

Si prefieres un enfoque similar a console.log(), la API de User Timing te permite marcar de manera arbitraria ciertas fases del ciclo de vida de tu app para realizar un seguimiento del tiempo que toma cada una de esas fases.

Resumen

  • Siempre que te propongas optimizar el rendimiento de carga de un sitio, comienza con una auditoría. La auditoría establece un modelo de referencia y te brinda sugerencias sobre cómo mejorar.
  • Realiza un cambio a la vez y audita la página después de cada cambio para ver cómo ese cambio aislado afecta el rendimiento.

Próximos pasos

Ejecuta auditorías en tu propio sitio. Si necesitas ayuda para interpretar tu informe o encontrar formas de mejorar el rendimiento de la carga, consulta todas las formas de obtener ayuda de la comunidad de Herramientas para desarrolladores:

  • Informa errores en este documento en el repositorio developer.chrome.com.
  • Presenta informes de errores de las Herramientas para desarrolladores en Errores de Chromium.
  • Comenta las funciones y los cambios en la Lista de distribución. No uses la lista de distribución para preguntas de asistencia. En su lugar, usa Stack Overflow.
  • Obtén ayuda general para usar las Herramientas para desarrolladores en Stack Overflow. Para enviar solicitudes de errores, usa siempre Errores de Chromium.
  • Envíanos un tweet a @ChromeDevTools.