Joan León Esta es una guía paso a paso de cómo utilizo Chrome DevTools (DevTools en adelante) para detectar problemas de Web Performance en una web, así como validar algunas hipótesis para solventar algunos de los problemas encontrados.
Disclaimer
Antes de entrar en materia, quiero aclarar que: esto no es una guía de cómo funcionan las DevTools, es una aplicación muy completa, solo me voy a centrar en los pasos que suelo hacer en el análisis preliminar de rendimiento de una web. Hay muchas otras herramientas (hablaré de ellas en futuros artículos), pero hoy os quiero hablar de las DevTools, esa herramienta que tenemos incluida en Google Chrome. Y centrándome en algunas de las herramientas que tenemos disponibles para el análisis del rendimiento o que, aunque inicialmente no son herramientas de análisis de rendimiento, nos ayudan a detectar problemas que pueden degradar el rendimiento, lo que acaba en una degradación de la UX de nuestra web o producto.
Dame una URL…
Casi siempre que me dan una URL, he de confesar que lo primero que hago es abrir las DevTools. Me apasiona analizar el rendimiento de una web. Así que empecemos por conocer la web que analizaremos en esta guía.
Recientemente, vi un post de Aleyda Solis, “Top Black Friday Organic Search Traffic Winners & Trends in 2025”, en el que recoge las webs con mayor tráfico orgánico durante el Black Friday 2025, un artículo muy completo e interesante. En él, tenemos webs de USA y algunos países de Europa, y los tipos de webs analizadas son retailers, medios de noticias, sitios de reviews/tecnología, plataformas sociales, comparadores de precios y agregadores de ofertas.
Me he decantado por una de las webs de España, al estar en el mismo país no tengo que emular geolocalización y es un test más realista. Y de la lista, me ha llamado la atención la web de Zara, así que empecemos a analizar https://www.zara.com/es/en/-pT9796937300.html?v1=501611224.
El navegador
Como ya indica el título, vamos a usar las DevTools de Google Chrome, quiero destacar que para este tipo de análisis uso la versión Canary, una versión de desarrollo en la que tenemos las últimas novedades en funcionalidades (algunas en versión beta). Además, como no es mi navegador habitual, no tengo extensiones instaladas, ya que interfieren en la experiencia y pueden alterar ligeramente las métricas.
También tenemos la opción de crear un perfil de usuario en Chrome donde no tengamos extensiones instaladas y usarlo para este tipo de análisis. O abrir un perfil de invitado temporal.
DevTools
Antes de la versión 129 de Chrome, lo primero que hacía era abrir las DevTools e ir a la pestaña network. Una vez allí ordeno la columna Size, con eso podemos ver de un vistazo cuáles son los recursos más pesados.
Aquí ya tenemos información interesante. Vamos a fijarnos en los recursos con un peso superior a 200kB, para ello añado larger-than:200k en el campo de filtro.
Aquí ya podemos ver algunos datos interesantes:
Primero, podemos ver que hay una petición fetch a categories con 218kB de peso, pero justo debajo vemos 1827kB, ese es el peso del archivo sin comprimir. El servidor sirve una versión comprimida con Brotli, lo podemos ver en la cabecera content-encoding: br. Lo que me llama la atención de este recurso, más allá de sus 1.8MB, es que tiene una caché de 72 segundos.
No conozco el producto, pero por mi experiencia, diría que las categorías de un eCommerce no tienen una rotación o cambios que requieran que el cliente consulte ese listado cada 72 segundos.
Segundo, tenemos una imagen en formato WebP de 254kB. El formato de la imagen es considerado “moderno” (tiene 15 años), eso está bien, en mi opinión, siendo un eCommerce de moda donde la calidad de las imágenes es crítica, sugeriría el uso de AVIF o JPEG-XL con fallback. En cuanto al peso, un WebP de más de 200kB me ha hecho sospechar, así que he seleccionado la fila y la pestaña preview para validar la resolución.
Como podemos ver, la resolución de la imagen es de 1440 x 2160 px, y es la imagen que podemos ver en el viewport, la cual no se está renderizando a esa resolución. Con eso podemos validar que se está descargando una imagen de una resolución mayor de lo que necesitamos.
Hay otra herramienta en las DevTools que me gusta mostrar para validar esto, y es la preview que tenemos en la pestaña Elements al hacer hover en un recurso de una imagen.
Aquí podemos ver que la imagen que hemos descargado de 1440x2160px se está renderizando a 372 × 558 px, aunque tengamos en cuenta el uso de las densidades según el dispositivo, sigue siendo una resolución demasiado grande. Así que, para optimizar esa petición, que además según podemos ver es https://static.zara.net/assets/public/.../T9796937300-p.jpg?ts=1764580554499&w=1440&f=auto, con un parámetro w=1440 que define la resolución, podríamos adaptar el valor de una manera sencilla (asumiendo que no hay complejidad).
Por último, el recurso con mayor peso es un JavaScript de 1MB comprimido, siendo de 4MB descomprimido. Además el nombre recom-chat.js sugiere que es un chat, el cual no vemos en el viewport.
Recursos tipo chatbot o recaptcha, los cuales solo necesitamos en un flujo que envía datos por parte del usuario mediante un formulario, no deberíamos descargarlos hasta que sea necesario.
Nuevo inicio
Volvamos un momento al inicio, donde he dicho “Antes de la versión 129 de Chrome, lo primero que hacía era abrir las DevTools e ir a la pestaña network”, y eso se debe a que en esa versión tuvimos un cambio muy interesante en las DevTools, Live metrics observations, un cambio en la home de la pestaña Performance, donde muestra información en tiempo real sobre Core Web Vitals, tanto en tu equipo local como basadas en datos de campo del Informe Chrome UX Report.
Ahora, lo primero que hago es acceder a esta pestaña, ya que tenemos información de visitas reales de la web como las Core Web Vitals y el porcentaje de mobile y desktop, así como el percentil 75 de la velocidad de red de las visitas.
Analicemos qué vemos en esta pantalla:
Local and field metrics
- Las Core Web Vitals del percentil 75 de las visitas reales registradas en CrUX:
- Un Largest Contentful Paint (LCP) de 7.15 s
- Un Cumulative Layout Shift (CLS) de 0.11
- Un Interaction to Next Paint (INP) de 779 ms
- También vemos las Core Web Vitals de la lectura de local (en mi dispositivo y con mi conexión):
- Un Largest Contentful Paint (LCP) de 4.05 s
- Un Cumulative Layout Shift (CLS) de 0.08
- En cuanto a la métrica Interaction to Next Paint (INP) en local, no está disponible. Eso es porque no he hecho ninguna interacción, ya que simplemente he hecho una carga. En un rato analizamos esto.
Field metrics
- Tenemos un dropdown con la URL (1) y el dispositivo, Auto (Mobile) en este caso.
(1) Podréis ver que he cambiado de URL, eso es porque en la anterior no tenemos información de visitas en CrUX, por no tener el volumen mínimo de datos. Es algo muy habitual en sites donde los productos son temporales, como en un eCommerce.
Environment settings
- Aquí tenemos una información muy interesante e importante:
- Device: 55% mobile, 45% desktop, el 55% de las visitas registradas en CrUX ha sido con móvil, he de decir que es algo que me ha sorprendido, ya que en muchos sites entre el 80 y 90% de visitas son desde dispositivos móviles.
- Network: 75th percentile is similar to Slow 4G throttling, esta otra información nos muestra que el percentil 75 de las visitas tiene una conexión similar a Slow 4G
Con esta información, podremos configurar nuestro entorno de las DevTools lo más similar a las visitas de la web.
Environment settings
Con la configuración recomendada, ya tenemos unos datos más cercanos a los datos de campo, algo que nos ayuda a tener una visión más cercana a la experiencia de las visitas de la web que estamos analizando.
Core Web Vitals
Siguiendo las recomendaciones de Google, y coincidiendo con las métricas de Experience de Google Search Console, empecemos por analizar las Core Web Vitals.
Largest Contentful Paint (LCP)
En el recuadro de LCP podemos ver que, tras la configuración del entorno, los valores de local y el percentil 75 de datos de campo son similares. Y salta a la vista que hay mucho margen de mejora en esta métrica.
Justo debajo, tenemos una información muy valiosa:
LCP element img.media-image__image.media__wrapper--media, es el elemento que genera la métrica LCP. Al hacer hover sobre este selector, vemos cómo en el viewport se resalta el elemento al que hace referencia.
Al hacer click sobre el selector, nos lleva a la pestaña Elements con el elemento DOM seleccionado. De un vistazo veo que no tenemos un fetchpriority='high', lo que me hace sospechar que no se está priorizando la carga de la imagen que afecta al LCP de la página.
<img
class="media-image__image media__wrapper--media"
data-qa-qualifier="media-image"
alt="Mid-knit ecru jumper set with a roll neck and long sleeves, paired with dark socks and high heels."
src="https://static.zara.net/assets/public/06b4/86e0/c99d4e959492/ec7ecb3e3a0a/05802109715-p/05802109715-p.jpg?ts=1764087684969&w=744&f=auto"
/>
Pero eso lo validaremos en un rato, ya que hay varias maneras de priorizar la carga de recursos.
Cumulative Layout Shift (CLS)
En la información del CLS, la diferencia entre los datos de campo y local, IMHO, es la métrica más complicada de emular, ya que depende de la resolución del dispositivo. Aun así, veamos la información tan útil que tenemos disponible en las DevTools.
Si hacemos click en Worst cluster 1 shift, nos muestra Layout shifts con una lista de los elementos que se han visto afectados por un desplazamiento.
Al igual que con el selector de LCP, al hacer hover sobre los elementos de la lista, vemos cómo el elemento se muestra resaltado en el viewport, de igual manera si hacemos click, nos selecciona el elemento del DOM en la pestaña Elements.
En este caso, la causa de este desplazamiento es provocada por el elemento que tenemos por encima, el banner de aplicación nativa, que al aparecer desplaza el contenido.
Interaction to Next Paint (INP)
Ya hemos comentado, y visto en las capturas que hemos visto hasta ahora, que no tenemos una métrica de INP en local hasta que hacemos una interacción en la página, así que voy a hacer un click en el icono de menú hamburguesa.
Aquí también vemos una gran diferencia entre el valor del INP en local y el percentil 75 de los datos de campo, podríamos probar entre las diferentes opciones de CPU throttling o hacer el debugging con un dispositivo conectado vía USB, pero eso ya es otro artículo, creo que ya tenemos un escenario que nos permite buscar puntos de mejora.
En la parte inferior vemos un listado con las interacciones, aquí se mostrarán todas las interacciones que vayamos haciendo en la página, y la que tenga un mayor valor será la que tenga un label INP (con el color correspondiente al umbral en el que esté ese valor)
Si desplegamos una de esas interacciones, veremos información de las subpartes del valor de INP. En este caso vemos unos valores (en ms) de Input delay: 41, Processing duration: 216 y Presentation delay: 55. Claramente el problema está en el paso de procesado, el cual tiene un valor de 216 ms.
Si hacemos click en Local duration (ms), gracias a la Long Animation Frames API, Chrome nos muestra en la consola un listado de los scripts que se han ejecutado durante la interacción. Este listado es un resultado de la instrumentación de Chrome para INP (Interaction to Next Paint) y muestra qué código JavaScript contribuyó al tiempo de procesamiento de la interacción seleccionada. Cada fila corresponde a un event listener o callback que se ejecutó como consecuencia directa o indirecta del input (click, tap, pointer, etc.).
Esto nos ayuda a detectar qué scripts y funciones están provocando que la experiencia no sea buena.
Panel Performance
Vamos a echar un vistazo a la parte más completa para analizar el rendimiento de una web, la pestaña de Performance cuando hacemos una carga o interacción.
Otro disclaimer: a esta pestaña de las DevTools le podríamos dedicar varios artículos (o un libro), así que veremos algunas de las cosas que creo que os pueden ayudar a detectar puntos de mejora.
Grabar y cargar página
Si hacemos una carga de página desde la pestaña de Performance, con el icono de “Record and reload” o ⌘ ⇧ E (en Mac), veremos algo como esto.
El equipo de Chrome DevTools no para de actualizar las DevTools con funcionalidades que nos hacen el trabajo de depuración más fácil, así que desde aquí les quiero dar las gracias y felicitar por el trabajo tan fantástico que están haciendo.
Una de esas funcionalidades que nos facilitan el análisis y depuración es el sidebar lateral Insights, donde ya tenemos una cantidad de consejos y tips que nos ayudarán a mejorar la experiencia, como:
Use efficient cache lifetimes
Donde tenemos un listado de recursos con un cache lifetime muy bajo. Optimizarlo ayudará a las visitas recurrentes, ya que contarán con una versión de esos recursos en la caché del navegador.
Insights LCP request discovery
Aquí podemos validar lo que antes habíamos visto al analizar el código HTML del elemento que afecta al LCP de la página.
Más cosas a destacar
En la parte superior, podemos ver que el gráfico muestra muchas áreas en amarillo, que indica ejecución de JavaScript. También lo podemos ver en la parte inferior, el Summary, donde nos informa que el navegador ha ejecutado JavaScript durante 7 segundos.
En la fila de Network he resaltado la carga del HTML, que en esta ocasión ha sido muy alta. Aquí puedo ver los recursos que toman más tiempo en descargar, o incluso el número de recursos que se están descargando en paralelo, como podemos ver en la siguiente captura, donde tenemos muchos recursos JavaScript y CSS, Render blocking (corner rojo) descargándose en paralelo.
Por cierto, en el sidebar de Insights, veremos un Render blocking requests, que si seleccionamos, nos resalta en el área de Network los recursos que son Render blocking.
Por último, he destacado una de las tareas largas que podemos ver, que esta tarda más de un segundo, ahí es uno de los puntos donde deberíamos profundizar para mejorar la experiencia.
Grabar interacción
Otra opción que tenemos en el panel de Performance es grabar interacciones. Lo podemos hacer con el botón Grabar o ⌘ E, esto inicia la grabación del Performance Profiler hasta que lo detengamos con el botón Stop.
En este caso, he grabado la acción de abrir el menú, seguro que es una de las acciones más utilizadas por las visitas de esta web.
Y como podemos ver, genera un INP de 279 ms, y si seleccionamos INP breakdown nos muestra las subpartes: Input delay: 24, Processing duration: 191 y Presentation delay: 62, y de forma gráfica en los flame charts. Claramente es un candidato a mejorar.
Interacciones con side effects
Al analizar esa interacción he visto algo interesante. Al abrir el menú, se muestran unas imágenes y vídeos, los cuales se descargan en ese momento, lo podemos ver en la fila de Network.
Uno de ellos me ha llamado mucho la atención, ya que ha tardado 6 segundos en descargar. Vamos a investigar (spoiler: he encontrado otra cosa interesante)
Volvemos a la pestaña Network, esta vez con el filtro de media, para listar solo los recursos de vídeo.
Por cierto, ahora los tiempos de descarga son más rápidos por no tener throttling, ya que lo que me interesa mirar en este momento es el peso de los recursos.
Y ahí tenemos un par de vídeos con pesos de 3.3MB y 29MB, vamos a centrarnos en este último. Abriendo el vídeo en una nueva pestaña, veo que es un vídeo de una secuencia de 5 segundos de productos sobre un fondo blanco. Eso me hace sospechar que seguro que se puede optimizar mejor, luego vemos cómo lo he hecho para validar esa hipótesis. Pero antes os quiero mostrar algo más interesante.
Al probar de abrir un par de veces el menú, veo que hay otra llamada al vídeo, pero en esta ocasión en lugar de utilizar el parámetro w=400, lo hace con w=398 por lo que es otra URL y descarga la misma versión del vídeo, pero 2 píxeles más pequeño.
Layers
Otra cosa que me gusta validar es si se está optimizando el renderizado de los componentes que están fuera del viewport. Para ello, utilizo la pestaña Layers, que aunque desactualizada, sigue siendo muy útil para esta validación.
Aquí podemos ver qué está renderizando el navegador, y que no veamos las imágenes de los productos por debajo del viewport es algo que está bien para la optimización. Hagamos scroll hasta el footer.
Ahora sí que podemos ver renderizadas las imágenes, ya que hemos hecho scroll, vertical y horizontal, haciendo que los componentes se muestren en el viewport y rendericen los recursos necesarios.
#WebPerfTipAquí podríamos hacer algo para mejorar el rendimiento, lo que mejora el INP de la página. Se podría hacer uso de la propiedadcontent-visibilitypara liberar memoria y elementos a los que aplicar estilos en las operaciones de Recalculate style. En este post “content-visibility: the new CSS property that boosts your rendering performance” encontrarás información sobre esta propiedad, y en esta Pull Request un ejemplo de implementación y un vídeo de la pestaña Layers donde se puede ver el funcionamiento.
WebPerf Snippets
Una de las herramientas que me gustan para analizar el rendimiento de una web, es mediante la ejecución de scripts desde la consola. Con el tiempo, he ido creando y adaptando algunos scripts que me ayudan a detectar puntos de mejora. A eso le podemos añadir que, en la pestaña Sources de las DevTools, tenemos una subpestaña Snippets, donde podemos crear y editar scripts que podemos ejecutar. Esto nos ayuda a no tener que hacer copy&paste de fuentes externas, lo tenemos todo integrado en el navegador.
Os voy a mostrar algunos de ellos. Los podréis encontrar en WebPerf Snippets, es un proyecto que empezó como un repositorio en GitHub para recopilarlos y compartir con la comunidad, y he acabado creando un site para facilitar la consulta, búsqueda y documentación.
Largest Contentful Paint Sub-Parts (LCP)
Se trata de un script que muestra en consola una tabla con las Sub-Parts del LCP de la página.
Esta información ahora la tenemos integrada en los Performance Insights, pero antes no lo teníamos, así que este script me ha ayudado durante bastante tiempo.
CSS Media Queries Analysis
Este snippet analiza todas las reglas @media en tus hojas de estilo CSS para identificar cuánto CSS específico de escritorio estás enviando innecesariamente a usuarios móviles.
Incluye dos funciones complementarias:
analyzeCSSMediaQueries(): Identifica y cuantifica el CSS que solo se usa en viewports grandes (por defecto >768px). Te muestra exactamente cuántos bytes podrían ahorrarse los usuarios móviles.
analyzeCSSPerformanceImpact(): Calcula el impacto real en rendimiento de ese CSS innecesario en diferentes tipos de dispositivos (gama alta, media y baja). Te muestra:
- Tiempo de bloqueo del render
- Impacto en Core Web Vitals (FCP, LCP, INP, TBT)
- Overhead de memoria
- Estimación de impacto en conversiones
Los resultados te darán números específicos y una estrategia de implementación para optimizar.
Content Visibility
Relacionado con lo que hemos visto en la pestaña Layers, este otro snippet nos ayuda a detectar mejoras potenciales con el uso de la propiedad CSS content-visibility.
Al ejecutar el script, se ejecuta detectContentVisibility() que nos informa de si en la web se está haciendo uso de la propiedad content-visibility. Esta propiedad CSS es una potente optimización de renderizado que permite a los navegadores omitir el trabajo de diseño y pintura del contenido fuera de pantalla, lo que mejora significativamente el rendimiento inicial de carga de la página.
También vemos el mensage To find optimization opportunities, run: analyzeContentVisibilityOpportunities(), que nos sugiere ejecutar la función que nos mostrará una lista potenciales de elementos en el DOM a los que podríamos aplicar la propiedad CSS, mostrando el selector, height, distanceFromViewport, childElements, incluso estimatedSavings, con una estimación del ahorro de tiempo de renderizado.
Y un ejemplo de implementación de la solución:
/* Optimize offscreen content */
.your-selector {
content-visibility: auto;
contain-intrinsic-size: auto 500px; /* Use actual height */
}
Dejo que eches un vistazo al resto de Snippets, ya que me ayudan a detectar mejoras de rendimiento.
La IA para agilizar la Performance Review
Como habrás podido apreciar, todos los pasos son muy artesanales, realmente creo que es lo que me gusta de este proceso. Pero la IA nos puede ayudar a agilizar procesos, interpretación de la información (sobre todo del Performance Profiler), así como generar los reportes para mantener un mismo estilo y lógica en la priorización a la hora de implementar las mejoras.
El equipo de las DevTools, hace tiempo que trabaja en ofrecernos herramientas de IA para eso, como el AI assistance, incluso tenemos el reciente Chrome DevTools MCP, pero eso lo veremos en otro artículo.
Bonus: Optimización de vídeo
Siempre que veo un vídeo como recurso en una web, no puedo evitar probar de conseguir una versión más optimizada. Así que en este caso he probado de forma rápida una optimización con HandBrake, un software de escritorio, multiplataforma y gratuito que nos permite convertir vídeo entre diferentes formatos.
En este caso con un simple click con el botón derecho, para mostrar el menú contextual, y abrirlo con HandBrake.
El siguiente paso para este ejemplo, es elegir Web -> Creator 720p60 (High quality video for publishing via online services such as Vimeo and YouTube. H.264 video (up to 720p60) and high bit rate AAC stereo audio in an MP4 container.) uno de los presets que tenemos disponibles y hacer click en el botón de “Start Encoding”.
Y la magia nos consigue convertir un vídeo de 29 MB en uno de 1 MB.
Este proceso es muy manual claro, pero me sirve para validar que podemos conseguir una versión del vídeo más optimizada. El siguiente paso es automatizar la conversión en el paso de creación de contenidos o un proceso en servidor que ejecute FFmpeg. O mejor aún, utilizar un servicio de CDN Media, como Cloudinary que nos permitirá optimizar los vídeos bajo demanda, adaptándolos a los dispositivos (esto también es material de otro artículo).
Conclusión
Como habréis podido ver, el proceso que yo uso para detectar puntos de mejora en rendimiento con las DevTools es muy artesanal. Y debemos tener en cuenta que:
- Cada web es un mundo.
- Las DevTools están en continuo desarrollo con mejoras, a las que nos tenemos que adaptar. Seguro que en un tiempo este artículo quedará desfasado.
- No he podido recoger en un artículo todo lo que hago en una Performance Review.
- Tampoco era objetivo de este artículo, que fuera un mega-manual de las DevTools.
Espero que te haya sido de utilidad, y no dudes en compartir tus procesos o trucos, eso nos convierte en una de las mejores comunidades.