JavaScript y rendimiento: cuánto pesa tu web y cómo aligerarla

Una de las pruebas que más nos gusta hacer con un cliente es sentarnos con un móvil Android de gama media, de los que lleva la mayoría de la gente, y abrir su web con la conexión del bar de enfrente. En el portátil de la oficina todo va fluido. En ese móvil, la página aparece, pero durante tres o cuatro segundos el menú no se abre, el botón de reservar no responde y el carrusel da tirones. La web parece cargada y, sin embargo, no está lista.

Casi siempre, detrás de esa sensación hay JavaScript. No porque sea malo, que es el lenguaje que da vida a las webs, sino porque se acumula. Un plugin para el slider, otro para el formulario, el chat, el píxel de publicidad, el mapa de calor que se instaló para una prueba hace un año. Cada pieza parecía pequeña. Juntas, el móvil tiene que procesar más código del que necesita la persona que solo quería ver el horario.

En esta guía vemos por qué el JavaScript pesa más de lo que dicen sus kilobytes, cómo medir el que carga tu web y un plan concreto para aligerarla.

01Por qué el JavaScript cuesta más que una imagen del mismo tamaño

Una imagen de 200 KB y un archivo JavaScript de 200 KB tardan lo mismo en descargarse. Lo que pasa después es muy distinto. La imagen se decodifica y se pinta, y eso el navegador lo hace en buena parte fuera del hilo principal. El JavaScript, en cambio, hay que analizarlo, compilarlo y ejecutarlo, y casi todo eso ocurre en el hilo principal: el mismo carril por el que el navegador atiende los toques, el scroll y el pintado de la página.

Mientras el hilo principal está ocupado ejecutando un script, la página no puede responder. Si alguien pulsa un botón en ese momento, su toque espera en la cola. Addy Osmani, del equipo de Chrome, lo resumió en su conocido artículo The Cost of JavaScript: el coste real del JavaScript está en el procesamiento, y se nota mucho más en móviles modestos que en el ordenador de quien desarrolla.

Esto se mide con dos conceptos que vale la pena conocer:

• →Tareas largas (*long tasks*). Cualquier bloque de trabajo que ocupa el hilo principal más de 50 milisegundos. Durante ese tiempo, la página no responde.
• →INP (*Interaction to Next Paint*). La métrica de Google que mide cuánto tarda la página en reaccionar visualmente a las interacciones. El objetivo es 200 ms o menos. Es la métrica de los Core Web Vitals que más depende del JavaScript.

El JavaScript también puede retrasar el LCP, el momento en que aparece el contenido principal, sobre todo cuando ese contenido lo pinta un script en vez de llegar ya en el HTML.

02Cómo medir cuánto JavaScript carga tu web

Antes de recortar, conviene saber qué hay. Este es el recorrido que hacemos en el estudio, de lo más general a lo más fino:

1. 01PageSpeed Insights. Introduce la URL y mira primero los datos de usuarios reales (los del informe CrUX de Chrome) y luego el diagnóstico. Busca los apartados «Reduce el JavaScript que no se usa», «Reduce el tiempo de ejecución de JavaScript» y «Minimiza el trabajo del hilo principal».
2. 02Pestaña Network de Chrome. Recarga con el filtro JS activado y la caché desactivada. Abajo verás el total transferido (comprimido) y el tamaño real descomprimido. Ordena por tamaño y por dominio para ver qué parte es tuya y qué parte de terceros.
3. 03Panel Coverage. Desde el menú de comandos de las herramientas de desarrollo, abre Coverage y recarga. Te muestra qué porcentaje de cada archivo se ha ejecutado de verdad en esa página. No es raro encontrar archivos con más de la mitad sin usar.
4. 04Panel Performance. Graba una carga con la CPU ralentizada cuatro veces (la opción de throttling) para simular un móvil. Las tareas largas aparecen marcadas con un triángulo rojo, y puedes ver qué script las provoca.
5. 05Analizador de bundles. Si la web se construye con herramientas como Vite, webpack o Next.js, un analizador visual (por ejemplo, @next/bundle-analyzer) muestra qué librerías ocupan más espacio dentro de tu propio código.

03De dónde sale tanto peso

Cuando auditamos webs, el JavaScript suele repartirse en cuatro grandes bloques. Saber cuál domina en tu caso orienta todo lo demás.

Los scripts de terceros merecen mención aparte porque suelen ser los que más pesan y los que menos controla el equipo técnico. Se añaden desde marketing, desde una agencia de publicidad o desde el propio proveedor del chat, a menudo a través del gestor de etiquetas, y rara vez se quitan. Además, muchos de ellos dependen del consentimiento de cookies, así que conviene revisarlos junto con la configuración del banner de cookies y del consentimiento.

04Un plan para aligerar tu web, en orden

El orden importa: empezar por lo que más pesa y menos cuesta quitar da resultados rápidos y deja para después lo que requiere cambiar código.

1. Haz inventario y quita lo que ya no usas

Lista todos los scripts de terceros y pregunta por cada uno quién lo pidió, para qué se usa hoy y quién mira sus datos. Es habitual encontrar un mapa de calor de una prueba que terminó, el píxel de una red social donde ya no se invierte o dos herramientas de analítica que miden lo mismo. Cada uno que se va es trabajo que el móvil se ahorra.

2. Carga cada cosa en su momento

• →Los scripts propios, con defer, para que no bloqueen la lectura del HTML.
• →Los terceros independientes, con async o cargados tras el evento load.
• →Lo que solo se usa en una página (el mapa de contacto, el configurador), solo en esa página.
• →Lo que depende de una acción (abrir el chat, reproducir un vídeo), cuando ocurra esa acción.

3. Usa fachadas para los incrustados pesados

Un vídeo de YouTube incrustado carga bastante JavaScript aunque nadie le dé al play. Una fachada es una imagen con un botón de reproducción que solo carga el reproductor real al pulsarla. Lo mismo sirve para mapas, chats o widgets de reservas: se muestra un botón con buen aspecto y el componente completo llega cuando la persona lo pide.

<!-- Fachada: imagen y botón; el reproductor se carga al pulsar -->
<button class="video-facade" data-video-id="abc123" aria-label="Reproducir vídeo: así trabajamos">
  <img src="/img/video-portada.avif" alt="" width="1280" height="720" loading="lazy">
</button>
<script type="module">
  document.querySelectorAll('.video-facade').forEach((btn) => {
    btn.addEventListener('click', () => {
      const iframe = document.createElement('iframe');
      iframe.src = `https://www.youtube-nocookie.com/embed/${btn.dataset.videoId}?autoplay=1`;
      iframe.allow = 'autoplay; encrypted-media';
      iframe.title = btn.getAttribute('aria-label');
      btn.replaceWith(iframe);
    }, { once: true });
  });
</script>

4. Sustituye librerías por lo que ya trae el navegador

Muchas librerías nacieron para cubrir carencias que los navegadores ya resolvieron. fetch sustituye a los asistentes de peticiones, Intl.DateTimeFormat formatea fechas en cualquier idioma, <dialog> resuelve ventanas modales, y CSS moderno hace animaciones, acordeones con <details> y efectos que antes pedían scripts (lo contamos en la guía de CSS moderno). Cada sustitución es código que deja de viajar.

5. Divide el código y trocea las tareas

Con code splitting, el código se divide en trozos y cada página carga solo los suyos. Con la importación dinámica (import()), un componente pesado se descarga cuando se va a mostrar. Y cuando hay trabajo largo que hacer, partirlo en tareas más pequeñas y ceder el hilo principal entre ellas permite que la página siga respondiendo mientras tanto.

6. Revisa la arquitectura si el problema es de fondo

Si la web pinta todo su contenido con JavaScript en el navegador, el recorte tiene un límite. En ese caso la mejora de verdad viene de renderizar en el servidor y enviar HTML ya montado, dejando el JavaScript solo para lo interactivo. Es un cambio mayor, y lo explicamos en la guía sobre SSR, SSG, ISR y renderizado en cliente.

05Un presupuesto de rendimiento para que no vuelva a crecer

Aligerar una web una vez es relativamente fácil. Lo difícil es que siga ligera dentro de un año, después de diez campañas y tres herramientas nuevas. Para eso sirve un presupuesto de rendimiento: unos límites acordados que el equipo se compromete a respetar.

En nuestros proyectos de webs corporativas y de servicios solemos trabajar con referencias de este tipo, que ajustamos a cada caso:

• →JavaScript de la primera carga: por debajo de unos 150-200 KB comprimidos.
• →Scripts de terceros: una lista cerrada, con un responsable para cada uno.
• →Tareas largas durante la carga en un móvil simulado: las mínimas posibles, y ninguna por encima de 200 ms.
• →Core Web Vitals en verde en datos de campo: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1.

Lo importante es que el presupuesto se vigile: Lighthouse CI puede ejecutarse en cada despliegue y avisar si un cambio se sale de los límites, y una revisión trimestral de etiquetas y plugins mantiene a raya el resto. Cuando alguien propone añadir una herramienta nueva, la pregunta pasa a ser natural: qué aporta y qué quitamos a cambio.

Clave: la web más rápida es la que solo envía al móvil el código que esa persona necesita en ese momento.

06Ligera por diseño, no por parche

La mejor forma de tener poco JavaScript es decidirlo desde el principio. Cuando diseñamos una web, cada animación, cada carrusel y cada widget se discute con su coste encima de la mesa: a veces compensa con creces, a veces una solución en CSS consigue el mismo efecto, y a veces lo más elegante es una imagen bien elegida. El resultado son webs que se sienten ágiles en cualquier móvil, y esa sensación de rapidez forma parte de cómo se percibe una marca.

En SIMA trabajamos así en nuestros proyectos de desarrollo web, y en el mantenimiento web vigilamos que el peso no vuelva a crecer con el tiempo. Si quieres que midamos cuánto JavaScript carga tu web y te propongamos un plan para aligerarla, escríbenos.