Comprender las métricas de rendimiento web cobra verdadero sentido cuando puedes vincularlas con el impacto real en el negocio. Mejorar un LCP o un TTFB no es solo un ejercicio técnico; es lo que permite conectar decisiones de arquitectura —como elegir server side rendering o static site generation— con resultados medibles. Y para llevar ese análisis a la práctica, la herramienta fundamental es Dev Tools, en particular una funcionalidad poco conocida pero muy poderosa: el coverage.
¿Qué es el coverage y por qué importa para optimizar tu sitio web?
El coverage es una herramienta integrada en Dev Tools que analiza qué porcentaje de tu código CSS y JavaScript se está utilizando realmente en una página [01:52]. Su propósito es detectar código muerto: funciones declaradas que nunca se ejecutan, hojas de estilo importadas que ningún elemento consume, reglas CSS que jamás se aplican.
Cada línea de código, cada byte adicional, suma peso a la transferencia. Ya sabemos que entre menos bytes transfiramos, mejor será el rendimiento [02:19]. Por eso identificar y eliminar ese código innecesario es una de las optimizaciones más directas que puedes hacer.
¿Cómo acceder al coverage en Dev Tools?
Para encontrarlo, abre Dev Tools con clic derecho e "Inspeccionar". Luego busca la sección more tools [01:32], donde aparece un listado extenso de herramientas disponibles. Cada una podría merecer una clase completa, pero el coverage destaca por su utilidad inmediata.
Al ejecutarlo, el coverage escanea todos los archivos cargados y marca en colores qué código fue usado y cuál no:
- Rojo: código que no se ejecutó ni se aplicó.
- Verde/Azul: código que sí fue utilizado durante la carga o la interacción.
¿Qué tipo de problemas puedes detectar con el coverage?
En el ejemplo analizado durante la práctica, el coverage reveló situaciones muy comunes [02:36]:
- Bootstrap importado al 100 % sin usar: toda la librería cargada sin que ningún estilo se aplicara en la landing.
- Animate.css completamente inactiva: una librería de animaciones CSS importada sin que ninguna animación se ejecutara.
- Reglas CSS propias sin utilizar: estilos como
.button-compare que nunca fueron activados.
Estos hallazgos permiten tomar decisiones concretas: eliminar librerías que no aportan nada reduce el peso de la página de forma significativa.
¿Qué precauciones debes tomar al interpretar el coverage?
Es importante analizar los resultados con criterio y detalle [03:33]. No todo lo que aparece en rojo es necesariamente código eliminable. Algunos estilos dependen de interacciones del usuario que aún no han ocurrido.
Por ejemplo, los estilos de hover aparecerán como no ejecutados si el usuario no ha pasado el cursor sobre esos elementos. Lo mismo aplica para estados como :focus, :active o media queries que responden a tamaños de pantalla específicos.
La clave está en distinguir entre:
- Código genuinamente muerto: librerías completas que no se usan.
- Código condicional: estilos que se activan solo ante ciertas interacciones o condiciones.
¿Por qué el coverage funciona con cualquier estrategia de renderizado?
Una ventaja importante es que esta herramienta es agnóstica a la arquitectura [04:15]. No importa si tu sitio usa static site generation, server side rendering o client side rendering; siempre puedes tener código que no se está utilizando.
El Dev Tools actúa sobre lo que el navegador recibe y ejecuta, así que cualquier proyecto se beneficia de este análisis. Es tu mejor aliado para depurar y encontrar oportunidades de mejora sin importar el framework o la estrategia elegida.
Después de identificar estas oportunidades, el siguiente paso lógico es automatizar esas optimizaciones. Hacerlo manualmente sería impráctico, y ahí es donde entran los empaquetadores (bundlers) [04:50], que los frameworks modernos ya incorporan para gestionar el código, eliminar lo innecesario y optimizar la entrega al navegador.
¿Has probado el coverage en alguno de tus proyectos? Comparte qué porcentaje de código muerto encontraste.
