¿Un inicio más rápido del frontend?

¡Hola a todos! :blush:

Esta tarde he estado trabajando en la optimización de la carga inicial del frontend, que a veces puede ser un poco lenta en móvil cuando la red es mala, creo.

:wrench: Mejoras realizadas:

:white_check_mark: Carga dinámica de librerías pesadas :

  • HLS.js (streaming de cámara)
  • Leaflet (mapa del mundo)
  • ApexChart (gráficos)

:backhand_index_pointing_right: Estas librerías ahora solo se cargan cuando son necesarias, aligerando el bundle principal.

:white_check_mark: Optimización del código dividido :

Algunas rutas no estaban correctamente separadas, lo que pesaba innecesariamente la carga al poner el código de estas rutas en el bundle JS principal.

:bar_chart: Resultado:

El bundle JS principal pasa de 2,94 MB a 694 KB, reduciendo significativamente el tiempo de carga inicial.

Por supuesto, nada es mágico, el tamaño retirado del bundle principal se añade al bundle de cada ruta, pero la idea es que ahora solo se carga lo necesario.

Mi objetivo es tener la carga del panel de control lo más rápida posible, porque cuando llego a Gladys en mi teléfono, a menudo es solo para apagar una lámpara, y si la carga se ralentiza solo porque el frontend está cargando cosas innecesarias, es una pena :smiley:

:mobile_phone: ¡Prueben y den sus opiniones!

He generado un build de Gladys Plus con estas mejoras:

:link: https://dynamically-import-librairie.gladys-plus.pages.dev

¡Tengo ganas de conocer sus impresiones! :blush:

Hola @pierre-gilles, excelente noticia si aceleramos el tiempo de carga, eso hará que la UX sea aún mejor.
Por cierto, para los grandes neófitos como yo en desarrollo, ¿qué es un bundle JS principal? :confused:

Gladys es una PWA (Progressive Web App), es una aplicación web que se asemeja más a una aplicación que a un sitio web.

El “bundle JS principal”, en resumen, es el archivo JavaScript que contiene el código “principal” de la aplicación y que se ejecuta cuando la lanzas.

Luego, cada página de la interfaz tiene su propio bundle JS (= su código).

Hasta ahora, la división entre el código del bundle principal y el de los bundles de cada página no era perfecta. Esto hacía que tu navegador perdiera tiempo interpretando código “demasiado pronto”, en un momento en el que no lo necesitabas.

La desventaja de esta optimización es que cuando cambias de página, puede ser un poco menos instantáneo la primera vez que cargas esa página. Por otro lado, ¡el cargado inicial es más rápido!

En el caso de Gladys, este corte tiene sentido, porque la mayoría de las aperturas de la app en móvil sirven para mostrar el tablero de control, controlar rápidamente un dispositivo y luego cerrar Gladys.