Angular es el marco de desarrollo de aplicaciones web de una sola página más popular, aunque esto no significa que las aplicaciones angulares puedan contener solo una página. Con este marco, puede crear sitios que constan de docenas de páginas. La última versión de Angular, gracias a los esfuerzos del equipo de desarrollo y la comunidad entusiasta, está bien optimizada. Sin embargo, cuando se trata de una aplicación específica, uno no debe olvidarse de algunas cosas que afectan su rendimiento.
El material, cuya traducción publicamos hoy, revelará seis áreas de optimización de aplicaciones angulares.
1. Carga diferida y optimización del paquete principal
Si no se usa la carga diferida al preparar la versión de producción de la aplicación, lo más probable es que en la carpeta
dist vea los siguientes archivos.
polyfills.js scripts.js runtime.js styles.css main.js
El archivo
polyfills.js permite asegurarse de que una aplicación escrita con las últimas funciones de tecnología web sea compatible con varios navegadores.
El archivo
script.js contiene los scripts descritos en la sección de
scripts del archivo
angular.json . Aquí hay un ejemplo simple de tal sección.
"scripts": [ "myScript.js", ]
El archivo
runtime.js es el cargador de Webpack. Contiene las herramientas de Webpack necesarias para descargar otros archivos.
El archivo
styles.css contiene los estilos declarados en la sección de
styles del archivo
angular.json . Aquí hay un ejemplo de esta sección.
"styles": [ "src/styles.css", "src/my-custom.css" ],
El archivo
main.js almacena todo el código de la aplicación, incluidos los componentes (código TS, HTML y CSS), canalizaciones, directivas, servicios y módulos importados (incluidos los módulos de terceros).
A medida que la aplicación crece y se
main.j tamaño del archivo
main.j s
main.j . Esto puede convertirse en un problema, porque para formar una página, el navegador, además de resolver otras tareas en la visualización de datos, necesita descargar y analizar el archivo
main.js Si este archivo es lo suficientemente grande, su procesamiento será una tarea desalentadora no solo para dispositivos móviles, sino también para navegadores de escritorio.
La forma más fácil de resolver este problema es dividiendo la aplicación en varios módulos, que utilizan la técnica de carga diferida. Con este enfoque, Angular genera un archivo separado para cada módulo, que no se descargará hasta que sea necesario (generalmente al activar una ruta determinada).
Para demostrar la aplicación de la técnica de carga diferida, se crearon dos componentes:
app.component y
second.component . Ambos están en el módulo
app.module , la carga diferida no se aplica cuando se trabaja con ellos.
El componente
app.component extremadamente simple. Muestra dos botones, uno de los cuales es responsable de cambiar a
second.component , y el segundo vuelve a
app.component .
Aplicación componenteLa plantilla del
Second componente contiene un texto muy grande con un volumen de aproximadamente 1 MB.
Segundo componenteDado que la técnica de carga diferida no se aplica aquí, nuestra aplicación tendrá un gran archivo
main.js que contiene el código
app.component y
second.component .
Si abre las herramientas de desarrollador de Chrome y mira la pestaña Red, puede estimar el tamaño del archivo
main.js Es decir, es 1.3 Mb.
Análisis de tamaños de archivo con las Herramientas para desarrolladores de ChromeEl problema aquí es que la mayoría de las veces al trabajar con nuestro proyecto, el usuario estará en su página principal y no en otra página, por lo que no es una buena idea descargar todo el código como un solo archivo. El código del segundo componente se puede extraer en un módulo separado, que se cargará solo si el usuario accede a la página correspondiente. Esto se traduce en una reducción significativa en el archivo
main.js , que proporciona una primera carga muy rápida en la página principal del sitio.
Al utilizar la técnica de carga diferida, después de completar el proceso de compilación del proyecto, se
4.386205799sfghe4.js un archivo como
4.386205799sfghe4.js . Aquí es donde se almacenará el código que no se cargará cuando cargue el sitio por primera vez. Como resultado, si ahora abre el sitio y lo analiza, resulta que los tamaños de
main.js son de solo 266 Kb.
Reducción de main.jsUn archivo adicional grande de 1 MB se descarga solo después de ir a la página correspondiente.
Descargar archivo adicionalAplicamos carga diferida, pero no podemos decir que tal solución nos convenga por completo. El hecho es que este enfoque ralentiza la primera transición del usuario a la página, para cuyo resultado se necesita un archivo grande por separado. Afortunadamente, Angular proporciona un medio para resolver este problema. A saber, estamos hablando de la tecnología
PreloadingStrategy .
Al
main.js , podemos decirle al framework que, después de que el módulo principal (archivo
main.js ) se carga y procesa,
main.js en segundo plano otros módulos. Como resultado, cuando el usuario va a una página que anteriormente requería que se mostrara un archivo grande, resulta que el archivo ya se ha descargado. Aquí hay un código de muestra que precarga todos los módulos.
import { PreloadAllModules, RouterModule } from '@angular/router'; RouterModule.forRoot( [ { path: 'second', loadChildren: './second/second.module#SecondModule' } ], {preloadingStrategy: PreloadAllModules})
Al aplicar la carga diferida al optimizar las aplicaciones angulares, se recomienda esforzarse por dividir el proyecto en tantos módulos como sea posible. Además, debe prestar atención a precargarlos. Esto hará posible que el archivo
main.js sea pequeño, lo que significa una carga y visualización más rápida de la página principal del proyecto.
2. Análisis de paquetes con Webpack Bundle Analyzer
Si incluso después de dividir la lógica del proyecto en muchos módulos, resulta que
main.js sigue siendo demasiado grande (para aplicaciones pequeñas y medianas, el autor de este material sugiere considerar que el archivo tiene 1 MB de tamaño), puede continuar optimizando la aplicación utilizando Webpack Bundle Analyzer. Este paquete npm le permite visualizar los resultados de Webpack en una estructura de árbol que admite el zoom. Para utilizar Webpack Bundle Analyzer, instálelo en un proyecto Angular como una dependencia de desarrollo.
npm install --save-dev webpack-bundle-analyzer
Luego modificamos la sección del
script del archivo
package.json agregando el siguiente texto.
"bundle-report": "ng build --prod --stats-json && webpack-bundle-analyzer dist/stats.json"
Tenga en cuenta que la dirección del archivo
dist/stats.json puede ser diferente en su proyecto. Por ejemplo, si ha terminado de agrupar archivos en la carpeta
dist/browser , deberá volver a escribir la línea anterior de esta manera:
dist/browser/stats.json .
Ahora ejecute el analizador.
npm run bundle-report
Después de ejecutar este comando, se generará el ensamblaje de producción de la aplicación y se mostrarán estadísticas para cada paquete. Así es como se ve el resultado de visualizar estos datos.
Análisis de proyectos utilizando Webpack Bundle AnalyzerAhora puede analizar la composición de cada paquete. Esta es una herramienta muy útil que le permite identificar dependencias de las que puede prescindir.
3. Crear varios módulos pequeños para compartir
Los módulos que comparten diferentes partes de la aplicación contribuyen a la implementación del principio
DRY , pero a veces incluso dichos módulos, a medida que se desarrolla la aplicación, se vuelven cada vez más. Por ejemplo, si tenemos un cierto módulo
SharedModule que contiene muchos otros módulos, componentes, tuberías, la importación de dicho módulo en
app.module aumentará el tamaño del paquete
main.js , ya que tal movimiento no solo conducirá a la importación de lo que
main.js necesita, pero también todo lo que está en
SharedModule . Para evitar esta situación, puede crear otro módulo, algo así como
HomeSharedModule , diseñado para ser compartido por el módulo principal y sus componentes.
La presencia en el proyecto de varios módulos destinados a compartir es mejor que la presencia de un solo módulo de este tipo, que generalmente tiene tamaños grandes.
4. Uso de la técnica de carga diferida para imágenes que no son visibles en la página
Cuando carga por primera vez la página principal de la aplicación, puede resultar que contenga imágenes que no son visibles para el usuario (están fuera del área de visualización). Para verlos, debe desplazarse por la página. Pero estas imágenes invisibles se cargan cuando se carga la página. Si hay muchos de ellos, esto afectará la velocidad de carga de la página. Para hacer frente a este problema, puede aplicar la técnica de carga diferida a las imágenes, cargándolas solo cuando el usuario las alcance. Hay una herramienta JS útil,
Intersection Observer , que facilita la implementación de la carga de imágenes diferidas. Además, para reutilizar, sobre la base de esto, puede crear una directiva adecuada. Los detalles sobre esto se pueden encontrar
aquí .
5. Uso de desplazamiento virtual para listas largas
La séptima versión de Angular tiene la capacidad de usar
desplazamiento virtual . Esta tecnología carga elementos en el DOM y los descarga en función de cuánto de la lista es visible para el usuario. Esto acelera enormemente el trabajo de las aplicaciones que usan listas largas.
Solo los elementos visibles de la lista se muestran en la página.6. Uso de la estrategia FOUT para trabajar con fuentes en lugar de la estrategia FOIT
Muchos sitios usan fuentes personalizadas. Por lo general, se ven muy atractivos, pero su aplicación crea una carga adicional en el navegador, ya que tiene que descargar estas fuentes y prepararlas para el trabajo. Cuando utilice fuentes no estándar, digamos, descargadas de un servicio de terceros como Google Fonts, son posibles los siguientes dos escenarios:
- El navegador descarga la fuente, la procesa y solo luego muestra el texto. Hasta que la fuente esté lista para usarse, el texto escrito en esta fuente será invisible. Esto se llama FOIT (Flash de texto invisible).
- El navegador inicialmente muestra texto usando una fuente estándar, mientras carga una fuente externa. Cuando esta fuente está lista para usarse, la fuente estándar cambia a esta fuente en particular. Como resultado, resulta que el texto en la página se mostrará en una fuente estándar hasta que se cargue una fuente especial, después de lo cual el texto se mostrará de nuevo, pero con una nueva fuente. Esto se llama FOUT (Flash de texto sin estilo).
La mayoría de los navegadores usan fuentes no estándar que usan la estrategia FOIT; la estrategia FOUT se usa solo en Internet Explorer. Para usar FOUT en lugar de FOIT, puede usar el descriptor de
font-display de
@font-face para
@font-face , y decirle al navegador si queremos que el texto se muestre primero en una fuente estándar, y luego en la nuestra, o estaremos satisfechos con un cierto período de invisibilidad de texto . Si está interesado en el tema de las fuentes, eche un vistazo a
este material. En particular, aquí puede encontrar información sobre las características de las fuentes y recomendaciones sobre la elección de las estrategias FOIT o FOUT.
Resumen
Aquí observamos varias técnicas para optimizar las aplicaciones angulares. De hecho, hay muchos más. En particular, estamos hablando de la representación del servidor, el uso de trabajadores del servicio y las páginas AMP. La conveniencia de la optimización y la elección de sus métodos dependen de un proyecto específico, de sus características y objetivos.
Estimados lectores! ¿Qué enfoques utiliza para optimizar las aplicaciones angulares?
