Inflación de JavaScript en 2024

Artículo original ↗ Discusión en Hacker News ↗

Los sitios web modernos envían rutinariamente varios megabytes de JavaScript, incluso para páginas relativamente simples, con ejemplos que van desde ~1–3 MB en el extremo más ligero hasta 10–60 MB en servicios como Gmail, Figma y Jira. Quienes comentan sostienen que esta inflación proviene de frameworks pesados, mala división de código, rastreo de terceros e incentivos organizativos, y señalan que la compresión y la caché no resuelven los costos de CPU, memoria y batería, especialmente en dispositivos de gama baja o conexiones lentas. Algunos ven los bundles grandes como aceptables para aplicaciones web ricas si la navegación es rápida tras la carga inicial, mientras que otros señalan sitios ligeros y enfoques sin dependencias como prueba de que son posibles diseños mucho más eficientes.

Comparaciones de tamaño de titulares y sorpresas

  • Quienes comentan destacan enormes cargas útiles de JS: Gmail y Figma ~20 MB, YouTube ~12 MB de JS + 2.5 MB de CSS, Jira ~58 MB, y algunas páginas de aterrizaje con varios MB “solo para mostrar texto e imágenes”.
  • Los sitios porno (p. ej., Pornhub) se citan repetidamente como comparativamente ligeros (≈1–1.4 MB) a pesar de estar centrados en contenido multimedia.
  • Varios desarrolladores informan que sus propias apps complejas están en 1–4 MB y se muestran perplejos de que empresas mucho más grandes envíen 10–50 MB.

Compresión, análisis y limitaciones de dispositivos

  • Se debate entre mirar tamaños comprimidos o sin comprimir: la compresión reduce la transferencia, pero no el costo de análisis/ejecución.
  • Se enfatiza que los dispositivos Android antiguos y de gama baja son los que más sufren con bundles grandes y trabajo pesado del DOM.
  • Algunos argumentan que el tamaño por sí solo es una proxy tosca; el perfilado muestra que el renderizado del DOM, el layout, la reactividad ineficiente y las cascadas suelen dominar.

Fuentes de la inflación: SPAs, frameworks y rastreo

  • Muchos culpan a los frameworks SPA y a arquitecturas sobrediseñadas por convertir sitios simples en aplicaciones.
  • Otros dicen que muchos bytes son analíticas, gestores de etiquetas, A/B testing y widgets de soporte al cliente gestionados por marketing, a veces inyectados sin supervisión del equipo de desarrollo.
  • Los scripts de rastreo de terceros pueden ser ellos mismos de varios MB y a menudo cargan desde CDNs externos.

Experiencia de usuario: rápida para algunos, inutilizable para otros

  • Informes mixtos: algunos encuentran YouTube, GitHub, Discord, etc. “ágiles”; otros ven retrasos y bloqueos notables, especialmente en hardware antiguo o intermedio o en móvil.
  • Personas con conexiones limitadas (rural, itinerancia, 2 Mbps o topes bajos de datos como 15 GB/mes) describen muchos sitios modernos como prácticamente inutilizables sin bloqueadores.
  • La UX sin conexión o con mala conectividad de apps como Spotify y Gmail es muy criticada.

Debate: ¿los bundles grandes son realmente un problema?

  • Un lado: “Menos JS = mejor” es una heurística útil; 10–50 MB para interfaces básicas es un desperdicio claro y perjudica a los usuarios medios.
  • El otro lado: el costo es aceptable en conexiones “normales”; es mejor optimizar la UX global (caché, navegación rápida dentro de la app) que perseguir métricas de tamaño de bundle.
  • Algunos sostienen que deberíamos arreglar el caché/PWA y los problemas de plataforma en lugar de obsesionarnos con los kilobytes.

Críticas metodológicas y matices

  • Varios comentarios señalan problemas de medición en el artículo:
    • Mirar solo cargas en frío y tamaños sin comprimir.
    • Tener la caché desactivada exagera las descargas repetidas (p. ej., sandboxes de la documentación de React).
    • Algunas páginas “de aspecto estático” en realidad son puertas de entrada a webapps multiherramienta (p. ej., Outlook, Translate).
  • Otros responden que, incluso con estas salvedades, las diferencias de orden de magnitud y la lentitud en el mundo real muestran un problema genuino de inflación.

Alternativas, herramientas y prácticas

  • Mitigaciones sugeridas: división de código, carga diferida, listas virtuales, evitar nodos DOM innecesarios y herramientas de análisis de bundles (p. ej., analizadores de Webpack/Rollup).
  • Algunos abogan por enfoques sin dependencias o con pocas dependencias, navegación estilo HTMX/PJAX, o marcos más nuevos “resumibles” (p. ej., Qwik).
  • Tema recurrente fuerte: los incentivos organizativos (marketing, rapidez de desarrollo) favorecen acumular JS; el rendimiento tiene pocos defensores.