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.
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:
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.
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.
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.
Abre Herramientas para desarrolladores junto a 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.
Abre el panel Lighthouse. Es posible que esté oculto detrás de
Más paneles.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 > Los tres modos. 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
- 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.
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.
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.
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.
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....
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.
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.
Haz clic en una oportunidad para obtener más información al respecto.
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.
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.
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 Usar filas de solicitud grandes.
Configuración >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:
Haz clic en bundle.js y abre la pestaña Encabezados.
Busca un encabezado
content-encoding
en la sección Encabezados de respuesta. No deberías ver uno, lo que significa quebundle.js
no estaba comprimido. Cuando un recurso se comprime, este encabezado suele establecerse engzip
,deflate
obr
. 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:
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')); ...
Asegúrate de colocar
app.use(compression())
antes deapp.use(express.static('build'))
.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:
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 de269 KB
parabundle.js
es el tamaño del archivo que se envió a través de la red y el valor inferior de1.4 MB
es el tamaño del archivo sin comprimir.La sección Encabezados de respuesta para
bundle.js
ahora debe incluir un encabezadocontent-encoding: gzip
.
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:
Abre el panel Lighthouse y haz clic en Realizar una auditoría... en la barra de acciones de la parte superior.
Deja los parámetros de configuración anteriores y haz clic en Analizar la carga de la página.
¡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.
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.
En la pestaña del editor, abre
src/model.js
.Reemplaza
const dir = 'big'
porconst dir = 'small'
. Este directorio contiene copias de las mismas imágenes a las que se les cambió el tamaño.Vuelve a auditar la página para ver cómo este cambio afecta el rendimiento de carga.
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.
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.
Haz clic en Eliminar los recursos que bloquean la renderización para ver los recursos que están bloqueando:
lodash.js
yjquery.js
.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.
Comienza a escribir
Coverage
y selecciona Show Coverage.La pestaña Cobertura se abrirá en el panel lateral.
Haz clic en Volver a cargar. La pestaña Cobertura proporciona una descripción general de cuánto código de
bundle.js
,jquery.js
ylodash.js
se ejecuta mientras se carga la página.En esta captura de pantalla, se indica que no se usan alrededor del 74% y el 30% de los archivos jQuery y Lodash, respectivamente.
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.
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.
- Haz clic en la pestaña Red y vuelve a abrir el Menú de comandos.
Comienza a escribir
blocking
y, luego, selecciona Show Request Blocking. Se abrirá la pestaña Bloqueo de solicitudes.Haz clic en Add Pattern (Agregar patrón), escribe
/libs/*
en el cuadro de texto y presiona Intro para confirmar.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.
Haz clic en 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:
- En la pestaña del editor, abre
template.html
. 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>
Espera a que el sitio se vuelva a compilar y a implementar.
Vuelve a auditar la página desde el panel de Lighthouse. Tu puntuación general debería haber mejorado nuevamente.
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.
Abre Rendimiento > Configuración de captura y establece la Red en 3G lenta y la CPU en Retraso de 6 veces.
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.
Haz clic en 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.
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.
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:
Haz clic en la sección Tiempos para expandirla.
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.
Vuelve a hacer clic en Tiempos para contraer esa sección.
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.
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.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.
En esta app, parece que una función llamada
App
causa muchas llamadas a una funciónmineBitcoin
. Parece que Tony está usando los dispositivos de sus fans para minar criptomonedas...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 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:
- En la pestaña del editor, abre
webpack.config.js
. - Cambia
"mode":"development"
por"mode":"production"
. - Espera a que se implemente la compilación nueva.
Vuelve a auditar la página.
Quita la llamada a mineBitcoin
para reducir la actividad de JavaScript:
- En la pestaña del editor, abre
src/App.jsx
. - Marca como comentario la llamada a
this.mineBitcoin(1500)
enconstructor
. - Espera a que se implemente la compilación nueva.
- Vuelve a auditar la página.
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.