El frontend al arrancar
La etapa más larga de las que controlas: qué cuesta interpretar y ejecutar el paquete, qué hace de más un frontend al montarse, y cómo se recorta.
Qué cuesta sin descarga
La última fila es la que justifica el esfuerzo: en la web el coste de arranque se amortiza con la caché del navegador; aquí se repite cada vez que el usuario abre la aplicación.
Qué hace de más un frontend al montarse
Los cuatro habituales:
El primero y el tercero son los que más quitan y los dos tienen soluciones conocidas del mundo web: carga bajo demanda y virtualización de listas.
La carga diferida, aquí
Una técnica que en la web sirve para no descargar y aquí sirve para otra cosa: no interpretar ni ejecutar lo que no se usa todavía.
- Divide por pantalla, no por tamaño. Que la pantalla de ajustes y el editor pesado sean módulos aparte que se cargan al abrirlos.
- Y precarga en reposo: cuando la aplicación está lista y el usuario aún no ha hecho nada, cargar en segundo plano lo que probablemente use. Así el arranque es rápido y abrir la segunda pantalla también.
La precarga es lo que en la web no siempre compensa —consume datos— y aquí es gratis: los ficheros están en el disco y el único coste es un poco de procesador en un momento en que no hay nada que hacer.
Medir el reparto
Y sin medir no se sabe cuál de los cuatro es el problema:
- El perfilador de las herramientas del navegador —nivel 55.1, mejor en Windows— da el reparto exacto entre interpretar, ejecutar, calcular estilos y pintar.
- Las marcas de rendimiento del navegador permiten marcar puntos propios: «montaje empieza», «primera pintura», «datos listos».
- Y la traza del puente del nivel 55.1 dice cuánto de la espera es el core y cuánto es el frontend.
Con esos tres, el reparto queda claro en media hora, y sin ellos se optimiza a ciegas.