Lighthouse: Optimiza la velocidad del sitio web

Kayce Basques
Kayce Basques
Sofia Emelianova
Sofia Emelianova

Objetivo del instructivo

Este tutorial te enseña 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 tutorial:

Requisitos previos

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

No necesitas saber nada sobre el rendimiento de carga.

Introducción

Este es Tony. Tony es muy famoso en la sociedad de los gatos. Construyó un sitio web para que sus fans sepan cuál es su y alimentos. A sus fanáticos les encanta el sitio, pero Tony escucha quejas de que el el sitio web se carga lentamente. Tony te pidió que lo ayudes 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 un auditoría de Cloud. La auditoría tiene dos funciones importantes:

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

Configurar

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

  1. Haz un remix del proyecto del sitio web en Glitch. Se abrirá tu proyecto nuevo 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 de forma aleatoria. 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 > Obtén una vista previa en una ventana nueva. La demostración se abre en una pestaña nueva. Esta pestaña se denominará pestaña Demostración. Es posible que el sitio tarde un poco en cargarse.

    La pestaña de demostración.

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

    Herramientas para desarrolladores y la demostración.

Establece un modelo de referencia

El modelo de referencia es un registro del rendimiento del sitio antes de que mejoraras el rendimiento.

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

    El panel Lighthouse.

  2. Haz coincidir los parámetros de configuración del informe de Lighthouse con los de la captura de pantalla. Esta es una explicación de los opciones diferentes:

    • check_box Liberar espacio de almacenamiento. Si habilitas esta casilla de verificación, se borrará todo el almacenamiento asociado a la página antes de cada auditoría. Deja activado este parámetro de configuración si deseas auditar la experiencia de los visitantes nuevos en tu sitio. Inhabilita este parámetro de configuración cuando quieras disfrutar de la experiencia de visitas repetidas.
    • check_box Habilitar el muestreo de JS. Esta opción está desactivada de forma predeterminada. Cuando se activa, esta función agrega pilas de llamadas detalladas de JavaScript al seguimiento del rendimiento, pero puede ralentizar la generación de informes. El seguimiento está disponible en more_vert Menú Herramientas > Puedes ver el seguimiento ilimitado después de que se genere el informe de Lighthouse. Seguimiento de rendimiento sin muestreo de JS (izquierda) y con (derecha)
    • Limitación simulada (predeterminada) . Esta opción simula las condiciones típicas de la navegación en un dispositivo móvil. Se llama “simulación” porque Lighthouse en realidad no se limita durante el proceso de auditoría. Solo extrapola cuánto tiempo tardaría la página en cargarse en condiciones móviles. Por otro lado, la configuración de regulación de Herramientas para desarrolladores (avanzada), en realidad, limita la CPU y la red, con la compensación de un proceso de auditoría más largo.
    • Modo > Navigation (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 > Dispositivos móviles. La opción para dispositivos móviles cambia la cadena del usuario-agente y simula una llamada viewport. La opción de escritorio inhabilita más o menos los cambios en los dispositivos móviles.
    • Categorías > check_box Rendimiento. Una sola categoría habilitada hace que Lighthouse genere un informe solo con el conjunto de auditorías correspondiente. Si quieres ver los tipos de recomendaciones que ofrecen, puedes dejar habilitadas las otras categorías. Inhabilitar categorías irrelevantes acelera ligeramente 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 del informe

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

Un informe con un error.

Comprende tu informe

El número que aparece en la parte superior de tu informe es la puntuación de rendimiento general del sitio. Más adelante, a medida que hacer cambios en el código, este número debería aumentar. 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, First Contentful Paint indica cuándo se muestra el contenido en la pantalla por primera vez, lo que es un hito importante en la la percepción de la carga de la página, mientras que el Tiempo de interacción marca el punto en que la página parezca lo suficientemente listo para controlar las interacciones del usuario.

Capturas de pantalla

A continuación, hay una colección de capturas de pantalla que 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, que proporciona sugerencias específicas sobre cómo mejorar la carga de esta página en particular. rendimiento.

La sección Oportunidades

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

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 específica recomendaciones sobre cómo solucionarlo.

Diagnóstico

La sección Diagnóstico brinda más información acerca de los factores que contribuyen al rendimiento de la página. el tiempo de carga de los datos.

La sección Diagnóstico.

Auditorías aprobadas

La sección Auditorías aprobadas muestra qué hace el sitio correctamente. Haz clic para expandir sección.

La sección Auditorías aprobadas.

Paso 2: Experimenta

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

Habilita la compresión de texto

Según tu informe, habilitar la compresión de texto es una de las oportunidades principales para mejorar el el rendimiento de la página.

La compresión de texto es cuando se reduce o comprime el tamaño de un archivo de texto antes de enviarlo a través del en cada red. Es similar a comprimir una carpeta antes de enviarla por correo electrónico para reducir su tamaño.

Antes de habilitar la compresión, puedes comprobar de forma manual si el texto cuando se comprimen los recursos.

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

La columna Size en el panel Network muestra filas de solicitud grandes.

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

También puedes verificar la compresión mediante la inspección de los encabezados HTTP de un recurso:

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

    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 está comprimido, este encabezado se se suele establecer en gzip, deflate o br. Consulte las Directivas para obtener una explicación al respecto de salida.

Basta de explicaciones. Es hora de hacer algunos cambios. Habilita la compresión de texto agregando 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')).

    Editar server.js.

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

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

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

    En la columna Size, ahora se deberían 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 Tamaño, ahora se muestran dos valores diferentes para los recursos de texto.

  2. La sección Encabezados de respuesta de 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 la carga de la página rendimiento:

  1. Abre el panel Lighthouse y haz clic en Agrega 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 como antes 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 un progreso. Tu puntuación de rendimiento general debería haber aumentado, lo que significa que el sitio se está volviendo más rápido.

Compresión de texto en el mundo real

La mayoría de los servidores realmente tienen correcciones simples como esta para habilitar la compresión. Simplemente busca cómo para configurar el servidor que uses para comprimir texto.

Cambiar el tamaño de las imágenes

Según tu nuevo informe, el tamaño adecuado de las imágenes 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 los archivos de las imágenes. Si el usuario una pantalla de 500 píxeles de ancho, realmente no hay 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 el informe, haz clic en Tamaños adecuados de las imágenes para ver a qué imágenes se debe cambiar el tamaño. Al parecer, las 4 imágenes son más grandes de lo necesario.

    Detalles sobre las "imágenes del tamaño adecuado" oportunidad

  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 de rendimiento general. Sin embargo, hay algo que que la puntuación no se ve con claridad se refiere a la cantidad de datos de red que les ahorras a los usuarios. El total el tamaño de las fotos antiguas era de alrededor de 6.1 MB, mientras que ahora solo pesa unos 633 KB. Puedes comprobarlo en la barra de estado ubicada en la parte inferior del panel Red.

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

Cambio del tamaño de imágenes en el mundo real

Para una app pequeña, realizar un cambio de tamaño único como este puede ser suficiente. Sin embargo, para una app grande, esto obviamente no es escalable. A continuación, se incluyen 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 el tamaño más adecuado para el dispositivo en el que se ejecuta. 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 lo solicitas.
  • Como mínimo, optimiza cada imagen. Esto suele implicar grandes ahorros. La optimización se produce cuando ejecuta una imagen a través de un programa especial que reduce el tamaño del archivo de imagen. Ver esenciales Optimización de imágenes para obtener más sugerencias.

Elimina los recursos que bloquean el procesamiento

Según tu informe más reciente, la mayor oportunidad de eliminar los recursos que bloquean el procesamiento es ahora.

Un recurso que bloquea la representación es un archivo externo JavaScript o CSS que el navegador debe descargar. analizar y ejecutar antes de que pueda mostrar la página. El objetivo es ejecutar únicamente el CSS y JavaScript principales. necesario para mostrar la página correctamente.

Por lo tanto, la primera tarea consiste en encontrar el código que no necesita ejecutarse cuando se carga la página.

  1. Haz clic en Eliminar recursos de bloqueo de renderización para ver qué recursos están bloqueando: lodash.js y jquery.js.

    Más información sobre el parámetro de configuración “Reduce los recursos que bloquean el procesamiento” oportunidades.

  2. Según el sistema operativo que tengas, presiona las siguientes teclas para abrir el menú de comandos:

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

    Abriendo el menú Command desde el panel Lighthouse.

    Se abrirá la pestaña Cobertura en el panel lateral.

    La pestaña Cobertura.

  4. Haz clic en Actualizar Volver a cargar. En la pestaña Cobertura, se proporciona una descripción general de la cantidad del código de bundle.js, jquery.js y lodash.js que se ejecuta mientras se carga la página.

    El Informe de cobertura

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

  5. Haz clic en la fila jquery.js. Herramientas para desarrolladores abrirá el archivo en el panel Fuentes. Una línea de código se se ejecutará 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, indudablemente no es necesario en la carga de la página.

    Visualiza el archivo de jQuery en el panel Sources.

  6. Desplázate un poco por el código de jQuery. Algunas de las líneas que se “ejecutan” en realidad son solo comentarios. Ejecutar este código a través de un minificador que elimina los comentarios es otra forma de reducir el tamaño de este archivo.

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

¿Se necesitan los archivos jquery.js y lodash.js para cargar la página? La pestaña Request Blocking puede hacer lo siguiente: mostrarte 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 Mostrar bloqueo de solicitudes. Se abrirá la pestaña Request Blocking.

    La pestaña Bloqueo de solicitudes

  3. Haz clic en Agrega Add Pattern, escribe /libs/* en el cuadro de texto y presiona Intro para confirmar.

    Agregar un patrón para bloquear cualquier solicitud a 'libs' .

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

    El panel Network muestra que se bloquearon las solicitudes.

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

En general, la pestaña Request Blocking es útil para simular cómo se comporta tu página ante una recurso 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.

Optimización de 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 necesario para cargar una página. En general, puede acelerar la carga de la página al enviar solo el código crítico durante la carga de la página y, luego, la carga diferida todo lo demás.

  • Es poco probable que encuentres secuencias de comandos que puedas quitar directamente, pero a menudo descubrirás que muchas secuencias de comandos no necesitan solicitarse durante la carga de la página y, en su lugar, pueden solicitarse de forma asíncrona. Consulta Usa el modo asíncrono o aplazamiento.
  • Si usas un framework, verifica si tiene un modo de producción. Este modo puede usar una función como como eliminación de código no utilizado para eliminar código innecesario que bloquea la renderización crítica.

Realiza menos trabajo del subproceso principal

Tu informe más reciente muestra algunos ahorros potenciales menores en la sección Oportunidades, pero si te desplazas hasta la sección Diagnostics, parece que el mayor cuello de botella es demasiado subproceso principal actividad.

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 para cargar páginas y descubrir formas de diferir o quitar el trabajo innecesario.

  1. Abre Rendimiento > Configuración. Selecciona Capture Settings y configura Network como Slow 3G y CPU a 6x SLOdown.

    Configuración: Limitación de la CPU y la red en el panel Rendimiento

    Los dispositivos móviles generalmente tienen más limitaciones de hardware que las laptops o las computadoras de escritorio, por lo que estos parámetros de configuración te permiten experimentar la carga de la página como si estuvieras usando un dispositivo menos potente.

  2. Haz clic en Actualizar Volver a cargar. Herramientas para desarrolladores vuelve a cargar la página y muestra una visualización de todo lo que tuvo que hacer para cargarla. Esta visualización se denominará seguimiento.

    El registro de la carga de página que muestra el panel Rendimiento.

El seguimiento muestra la actividad en orden cronológico, de izquierda a derecha. Los gráficos de FPS, CPU y NET en la 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 amarillo que ves en la sección Descripción general significa que la CPU estuvo completamente ocupada con la actividad de secuencias de comandos. Esta es una pista de que podrías acelerar la carga de la página con menos trabajo de JavaScript.

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

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

    La sección Tiempos.

    Hay varias mediciones de User Timing de React. Parece que la app de Tony está usando el modo de desarrollo de React. Cambiar al modo de producción de React probablemente generará beneficios sencillos en el rendimiento.

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

  3. Explora la sección Main. 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 provocó que se ejecutara la función (anonymous), lo que provocó que se ejecutara __webpack__require__, lo que hizo que se ejecutara ./src/index.jsx, y así sucesivamente.

  4. Desplázate hacia la parte inferior de la sección Main. Cuando usas un framework, La mayor parte de la actividad superior es causada por el framework, que generalmente está fuera de que tú controlas. La actividad que genera la app suele aparecer en la parte inferior.

    La actividad de mineBitcoin.

    En esta app, parece que una función llamada App provoca 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. En esta pestaña, se desglosan las actividades que llevaron más tiempo. Si no aparece nada en la sección Bottom-Up, haz clic en la etiqueta para la sección Main.

    La pestaña Bottom-Up.

    La sección Bottom-Up solo muestra información para cualquier actividad o grupo de actividades que realices. seleccionado actualmente. Por ejemplo, si hiciste clic en una de las actividades de mineBitcoin, la La sección Bottom-Up solo mostrará la información de esa actividad.

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

Es hora de comprobar si se usa el modo de producción y se reduce la actividad de JavaScript que acelera 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.

Para reducir la actividad de JavaScript, quita la llamada a mineBitcoin:

  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 Cumulative Layout Shift.

Cómo hacer menos trabajo de subprocesos principales en el mundo real

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

Si prefieres un enfoque similar al de console.log(), la API de User Timing te permite marcar de forma arbitraria ciertas fases del ciclo de vida de la app para realizar un seguimiento de la duración fases.

Resumen

  • Cuando te propongas optimizar el rendimiento de carga de un sitio, empieza con durante una auditoría. La auditoría establece un punto de referencia y da sugerencias sobre cómo que puedes mejorar.
  • Realizar un cambio a la vez y auditar 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 carga, consulta todas las formas de obtener ayuda de la comunidad de Herramientas para desarrolladores:

  • Informa sobre los errores en este documento en el repositorio de developer.chrome.com.
  • Presenta informes de errores en Herramientas para desarrolladores en Errores de Chromium.
  • Habla sobre las funciones y los cambios en la Lista de distribución. No utilices 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 presentar solicitudes de errores, siempre usa los errores de Chromium.
  • Envíanos un tweet a @ChromeDevTools.