Solucionar 'Reduce Unused JavaScript' en Lighthouse

¿Qué es la advertencia de Lighthouse 'reduce unused JavaScript'?

Última revisión por Arjen Karel en Marzo de 2026

Lighthouse señala cada archivo JavaScript con más de 20 KiB de código no utilizado. Si ves esta advertencia, tu página está descargando y ejecutando JavaScript que no necesita para la carga actual de la página.

Esta advertencia afecta directamente a tu puntuación de rendimiento en Lighthouse. Pero lo que es más importante, el JavaScript no utilizado perjudica a tus usuarios reales. Según el Web Almanac 2025, la página móvil mediana envía 646 KB de JavaScript, y 251 KB del mismo quedan sin usarse en la página donde se cargan. En el percentil 90, ese número asciende a 931 KB de JavaScript desperdiciado.

Mientras tanto, el Tiempo Total de Bloqueo (Total Blocking Time) móvil aumentó un 58% interanual hasta alcanzar una mediana de 1.916 ms según el capítulo de Rendimiento del Web Almanac 2025. Las cargas de JavaScript están creciendo más rápido de lo que los dispositivos se vuelven más rápidos. En los sitios monitorizados por CoreDash, los orígenes que mantienen su JavaScript no utilizado por debajo de los 100 KB obtienen una puntuación "buena" en el INP el 93% del tiempo, en comparación con el 64% de los orígenes que superan los 400 KB.

¿Qué causa el JavaScript no utilizado?

El JavaScript no utilizado puede tener muchas causas. Las más comunes son:

• Demasiados plugins en tu CMS.
• Código muerto que ya no se utiliza en el sitio web actual.
• Scripts mal escritos con comprobaciones y ramificaciones innecesarias.
• Acceso sin restricciones al gestor de etiquetas (tag manager), donde los equipos de marketing añaden etiquetas y se olvidan de eliminarlas.
• Importaciones innecesarias: importar toda una biblioteca cuando solo utilizas una función.
• Código que se ejecuta en todas las páginas pero que solo es necesario en rutas específicas.
• Scripts que se cargan de inmediato y que podrían haberse cargado justo antes de su uso.

¿Cómo afecta el JavaScript no utilizado a los Core Web Vitals?

El JavaScript no utilizado afecta tu rendimiento de dos maneras:

• Contención de la red (Network contention). Cada archivo JavaScript tiene que ser descargado. Estas peticiones compiten por el ancho de banda con tu imagen LCP, tus fuentes y tu CSS. En una conexión móvil, este retraso puede empujar a tu Largest Contentful Paint muy por encima del umbral de 2,5 segundos.
• Bloqueo del hilo principal (Main thread blocking). El navegador tiene que analizar (parse), compilar y ejecutar todo ese JavaScript. Mientras lo hace, no puede responder a las entradas del usuario ni seguir renderizando la página. Esto afecta directamente tanto al LCP como al INP.

Ten en cuenta que una puntuación de Lighthouse no es una puntuación de Core Web Vitals. Los Core Web Vitals se miden con datos de campo de usuarios reales (CrUX). Lighthouse es una herramienta de diagnóstico que te ayuda a encontrar problemas, pero tu rendimiento real es lo que tus visitantes experimentan verdaderamente. Puedes verificar tu rendimiento de campo con Real User Monitoring.

Cómo encontrar el JavaScript no utilizado

Hay tres maneras de identificar el JavaScript no utilizado en tu página:

1. Leer la auditoría de Lighthouse

Lighthouse enumera cada archivo JavaScript que tiene más de 20 KiB de código no utilizado. Muestra los bytes totales, los bytes no utilizados y los ahorros potenciales. Este es tu punto de partida. Ten en cuenta que Lighthouse 13 (octubre de 2025) pasó a un formato de auditoría basado en información (insights), pero la comprobación de JavaScript no utilizado sigue ahí.

2. Usar la herramienta Coverage de Chrome

La herramienta Coverage te proporciona un desglose línea por línea del código utilizado frente al no utilizado para cada archivo JavaScript y CSS de la página.

Abre Chrome DevTools con Ctrl+Shift+I (o Cmd+Opción+I en Mac). Luego, usa Ctrl+Shift+P para abrir el menú de comandos y escribe coverage. Selecciona Show Coverage, y luego haz clic en el botón de recarga (reload) para comenzar a instrumentar. Tras la carga de la página, verás cada archivo con su porcentaje de bytes no utilizados.

Cambia al modo de cobertura "Per block" (en el menú desplegable de la parte superior del panel) para obtener resultados más granulares. La cobertura a nivel de bloque detecta ramas no utilizadas dentro de las funciones, no solo si se llamó a una función o no.

Haz clic en cualquier fila para abrir el archivo en el panel Sources. Las líneas azules son código utilizado. Las líneas rojas son no utilizadas. Esto te indica exactamente qué funciones y ramas no se ejecutaron nunca durante la carga de la página.

3. Analizar tus bundles

Si usas un empaquetador (bundler) como webpack, Rollup o Vite, usa un analizador de paquetes (bundle analyzer) para visualizar qué hay dentro de tus archivos JavaScript. Herramientas como webpack-bundle-analyzer y source-map-explorer muestran un mapa de árbol de cada módulo en tu paquete, lo que hace evidente cuando una biblioteca grande es importada para una característica pequeña.

No utilizado no siempre significa innecesario

Ten en cuenta que "no utilizado" en una página no significa "innecesario". Un script que hace funcionar tu formulario de pago aparece como un 100% no utilizado en tu página de inicio. Eso no quiere decir que debas borrarlo. Significa que no debes cargarlo en la página de inicio.

Esto es lo que resuelve la división del código (code splitting): cada ruta carga solo el JavaScript que realmente necesita. Si ves grandes cantidades de JavaScript "no utilizado" y tu sitio es una aplicación de una sola página (SPA), la solución es casi siempre una mejor división del código a nivel de ruta, no la eliminación de código.

Cómo arreglar 'reduce unused JavaScript'

Para corregir la advertencia 'reduce unused JavaScript', primero debes rastrear de dónde proviene el desperdicio. Lighthouse te indica qué scripts tienen una gran cantidad de bytes no utilizados. A continuación te presentamos 7 formas de reducirlo:

1. Eliminar los plugins innecesarios. Si usas un CMS como WordPress, la victoria más fácil es eliminar los plugins que no necesitas o sustituir plugins triviales con unas pocas líneas de código. Tu plugin de análisis, los botones para compartir en redes sociales y el widget de chat suelen ser los culpables habituales.
2. Eliminar el código muerto. El código muerto (dead code) es código que el sitio web actual ya no usa. Programa una auditoría de código muerto al menos dos veces al año. Herramientas como Knip pueden automatizar la detección de exportaciones y dependencias no utilizadas en proyectos de JavaScript.
3. Aplicar "tree shake" a tus bundles. El tree shaking elimina las exportaciones no utilizadas en el momento de la compilación. Para que funcione, necesitas usar la sintaxis de módulos ES (import/export), no CommonJS (require). Añade "sideEffects": false a tu package.json para que tu empaquetador pueda eliminar agresivamente el código no utilizado. Importa solo lo que necesites:

   // Malo: importa toda la biblioteca (70+ KB)
   import _ from 'lodash';
   const result = _.debounce(fn, 300);
   
   // Bueno: importa solo debounce (~1 KB con tree shaking)
   import { debounce } from 'lodash-es';
   const result = debounce(fn, 300);

4. Hacer "code split" a tus rutas. Carga únicamente el JavaScript que cada página necesita realmente. Utiliza import() dinámico para dividir tus paquetes por ruta o por característica:

   // En lugar de importar todo desde el principio:
   import { validateForm } from './formValidation.js';
   
   // Cárgalo únicamente cuando el usuario interactúe con el formulario:
   document.querySelector('form').addEventListener('focus', async () => {
     const { validateForm } = await import('./formValidation.js');
     validateForm();
   }, { once: true });

   En React, utiliza React.lazy() con <Suspense> para la división a nivel de componentes. En el App Router de Next.js, los React Server Components no envían ningún JavaScript al cliente por defecto. En Vue, usa defineAsyncComponent() o importaciones dinámicas en Vue Router.

5. Limpiar tu gestor de etiquetas y restringir el acceso. El gestor de etiquetas (tag manager) es una fuente común de código no utilizado, especialmente cuando los equipos de marketing añaden etiquetas sin quitar las antiguas. Audita tu contenedor del gestor de etiquetas regularmente. Cada etiqueta que se dispara al cargar la página añade JavaScript que compite por los recursos.
6. Eliminar importaciones innecesarias. En los proyectos de React, Vue y Next.js, comprueba tus sentencias de importación. ¿Estás importando toda una biblioteca de componentes cuando solo empleas dos componentes? ¿Estás incorporando moment.js (330 KB) cuando la API nativa Intl o una alternativa de 2 KB como dayjs serían suficientes?
7. Aplazar la carga de scripts no críticos. A veces requieres un script (para enviar un formulario, por ejemplo) pero no lo precisas durante la carga de la página. Cárgalo cuando el usuario lo necesite de verdad. Un script que se carga en la interacción en lugar de al cargar la página ya no figura como "JavaScript no utilizado" en la auditoría de Lighthouse. Consulta también async vs defer para comprender la diferencia entre estas dos estrategias de carga.

Cuando no puedes solucionarlo por completo

En ocasiones no te será posible suprimir todo el JavaScript no utilizado. Los scripts de terceros, las herramientas de pruebas A/B y las redes publicitarias a menudo envían paquetes voluminosos sobre los que no ejerces ningún control. Llegado el caso, minimiza su impacto:

• Autohospeda (Self-host) los scripts de terceros en tu dominio principal siempre que sea posible. Esto evita el coste aparejado de una nueva búsqueda de DNS y conexión TCP por cada dominio externo.
• Prioriza los recursos críticos. Haz un preload de tu imagen LCP y de las fuentes críticas a fin de que no queden bloqueadas detrás de las descargas de JavaScript en la cola de red.
• Aplaza tanto JavaScript como te sea posible. Traslada los scripts no críticos fuera de la ruta crítica de renderizado valiendote de defer, async o mediante carga demorada.
• Aplica fetchpriority="low" en los recursos de scripts prescindibles para indicarle al navegador que tienen la posibilidad de esperar.
• Supervisa tus datos de campo. Utiliza herramientas de Real User Monitoring en aras de constatar que tus alteraciones realmente lograron mejorar la experiencia frente a los usuarios reales, y no se ciñeron en exclusiva al puntaje de Lighthouse.