El costo de JavaScript en 2018

Aunque lo mencionamos anteriormente, pensé que valía la pena profundizar un poco más en esta excelente publicación de Addy Osmani sobre los problemas de rendimiento de JavaScript .

En esa publicación, Addy aborda todos los aspectos del trabajo de rendimiento y cómo podemos solucionar algunos de los problemas más atroces, desde la configuración de un presupuesto hasta las mediciones del “tiempo de interacción” y la auditoría de sus paquetes de JavaScript.

Adopte los presupuestos de rendimiento y aprenda a vivir dentro de ellos. Para dispositivos móviles, busque un presupuesto JS de 170 KB minimizado/comprimido. Sin comprimir, esto sigue siendo ~0,7 MB de código. Los presupuestos son fundamentales para el éxito; sin embargo, no pueden arreglar mágicamente el rendimiento de forma aislada. La cultura, la estructura y el cumplimiento del equipo son importantes. Construir sin un presupuesto invita a regresiones en el desempeño y al fracaso.

¡Súper específico y súper práctico!

Sorprendentemente, Addy menciona que “la página web promedio hoy en día incluye alrededor de 350 KB de JavaScript minimizado y comprimido”, lo que parece muchísimo menos de lo que esperaba, si soy honesto. La estadística que más me asusta es que una página web promedio tarda unos quince segundos completos en volverse interactiva. Y colocar todo ese JS en un Web Worker o almacenarlo en caché con Service Workers ni siquiera compensará ese tiempo de interacción. Vaya.

Otro punto clave: no todos los bytes son iguales. Por ejemplo, 200 KB de JavaScript no equivalen a un archivo de imagen JPG de 200 KB:

Es necesario decodificar, rasterizar y pintar una imagen JPEG en la pantalla. Es necesario descargar un paquete de JavaScript y luego analizarlo, compilarlo y ejecutarlo, y hay una serie de otros pasos que un motor debe completar. Sólo tenga en cuenta que estos costos no son del todo equivalentes.