En fait, c'est un vaste sujet, mais je ne vais pas l'aborder ici car c'est trop laborieux - pour comprendre tous les détails, il ne suffit pas de connaître Angular.
Pour résumer les points clés, je dirai deux points :
La pré-compilation des modèles n'est pas difficile (il s'agit ici de mettre en cache des modèles statiques dans $templateCache, afin que les modèles soient directement chargés en mémoire lors du chargement de l'application), mais c'est sérieux pour Angular Pour un framework qui repose sur la liaison de données , la charge de travail de compilation de modèles ne vaut pas la peine d'être mentionnée. À moins que votre projet soit extrêmement volumineux et qu'il y ait trop de modèles à gérer - mais ce qui est plus grave en ce moment est la perte de temps de pré-compilation des modèles lors du développement local - la modularisation d'applications géantes est donc la bonne voie ; le point. Des instructions comme ng-repeat seront notre objectif de "réduire la charge sur le navigateur", c'est-à-dire d'étendre ces instructions et de remplir le DOM avant que le navigateur ne se charge. Les instructions comme ng-if ne peuvent pas être prétraitées, car elles s'appuient souvent sur elles ; "liaison de données".
Laissez-moi vous donner un exemple. Par exemple, il y a une section sur la page contrôlée par ng-if Elle est jugée en fonction du fait que l'utilisateur actuel dispose d'autorisations. Cependant, le statut de l'utilisateur doit attendre l'utilisateur. pour vous connecter (ou d'autres conditions prédéfinies). Obtenir - Comment prétraiter ng-if en dehors du navigateur ? Cela impliquera des opérations DOM et affectera également les performances du navigateur. Voulez-vous dire un prétraitement ou non ? Si toutes ces balises nécessitent un compromis pour décider de prétraiter ou non, alors le coût est trop élevé, il est donc préférable de ne pas utiliser Angular. Angular ne peut pas être complètement statique (d'ailleurs, le Object.observe() d'ESNext sera la clé de la solution), alors que le semi-statique est possible, mais souvent pas en raison des performances du navigateur.
En fait, il faut croire que les performances des navigateurs modernes sont très fortes. Le rendu côté client n'est pas le "goulot d'étranglement des performances" que beaucoup de gens imaginent. De nombreuses tentatives de rendu côté serveur (pour Angular) sont principalement destinées. recherche. Optimisation du moteur plutôt que amélioration des performances. Laissez-moi vous donner quelques mots-clés à rechercher. C'est une bonne occasion d'apprendre (utilisez un moteur de recherche anglais, il n'y a pas de résultats utiles en chinois) :
rendu côté serveur
rendu dom côté serveur
nœud
angulaire
pré-rendu
pré-compiler
phantomjs/casperjs
bibliothèques js isomorphes
Vous pouvez diviser et combiner ces mots-clés pour explorer le contenu connexe. De nombreux outils/pratiques/tutoriels/discussions vous attendent.
Pour résumer. Pour les applications JS basées principalement sur la « liaison de données » (comme Angular), parce que la prise en charge actuelle du langage et de l'environnement n'est pas en place (comme ce qui précède Object.observe(), etc.), il est impossible de réaliser une intégration complète au niveau Niveau DOM. Précompilé ou statique. Il est possible de prétraiter des parties du DOM d'autres manières avant d'entrer dans le navigateur, mais cela n'aura pas un impact énorme sur l'amélioration globale des performances de l'application ou/et sur l'amélioration des performances du navigateur, ni sur le coût de mise en œuvre de ces prétraitements. en lui-même n'est pas petit ; à moins que vous ne fassiez une demande avec des performances extrêmement strictes (comme Taobao ?), c'est toujours une décision.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
En fait, c'est un vaste sujet, mais je ne vais pas l'aborder ici car c'est trop laborieux - pour comprendre tous les détails, il ne suffit pas de connaître Angular.
Pour résumer les points clés, je dirai deux points :
La pré-compilation des modèles n'est pas difficile (il s'agit ici de mettre en cache des modèles statiques dans
$templateCache, afin que les modèles soient directement chargés en mémoire lors du chargement de l'application), mais c'est sérieux pour Angular Pour un framework qui repose sur la liaison de données , la charge de travail de compilation de modèles ne vaut pas la peine d'être mentionnée. À moins que votre projet soit extrêmement volumineux et qu'il y ait trop de modèles à gérer - mais ce qui est plus grave en ce moment est la perte de temps de pré-compilation des modèles lors du développement local - la modularisation d'applications géantes est donc la bonne voie ; le point. Des instructions commeng-repeatseront notre objectif de "réduire la charge sur le navigateur", c'est-à-dire d'étendre ces instructions et de remplir le DOM avant que le navigateur ne se charge. Les instructions commeng-ifne peuvent pas être prétraitées, car elles s'appuient souvent sur elles ; "liaison de données".Laissez-moi vous donner un exemple. Par exemple, il y a une section sur la page contrôlée par
ng-ifElle est jugée en fonction du fait que l'utilisateur actuel dispose d'autorisations. Cependant, le statut de l'utilisateur doit attendre l'utilisateur. pour vous connecter (ou d'autres conditions prédéfinies). Obtenir - Comment prétraiterng-ifen dehors du navigateur ? Cela impliquera des opérations DOM et affectera également les performances du navigateur. Voulez-vous dire un prétraitement ou non ? Si toutes ces balises nécessitent un compromis pour décider de prétraiter ou non, alors le coût est trop élevé, il est donc préférable de ne pas utiliser Angular. Angular ne peut pas être complètement statique (d'ailleurs, leObject.observe()d'ESNext sera la clé de la solution), alors que le semi-statique est possible, mais souvent pas en raison des performances du navigateur.En fait, il faut croire que les performances des navigateurs modernes sont très fortes. Le rendu côté client n'est pas le "goulot d'étranglement des performances" que beaucoup de gens imaginent. De nombreuses tentatives de rendu côté serveur (pour Angular) sont principalement destinées. recherche. Optimisation du moteur plutôt que amélioration des performances. Laissez-moi vous donner quelques mots-clés à rechercher. C'est une bonne occasion d'apprendre (utilisez un moteur de recherche anglais, il n'y a pas de résultats utiles en chinois) :
Vous pouvez diviser et combiner ces mots-clés pour explorer le contenu connexe. De nombreux outils/pratiques/tutoriels/discussions vous attendent.
Pour résumer. Pour les applications JS basées principalement sur la « liaison de données » (comme Angular), parce que la prise en charge actuelle du langage et de l'environnement n'est pas en place (comme ce qui précède
Object.observe(), etc.), il est impossible de réaliser une intégration complète au niveau Niveau DOM. Précompilé ou statique. Il est possible de prétraiter des parties du DOM d'autres manières avant d'entrer dans le navigateur, mais cela n'aura pas un impact énorme sur l'amélioration globale des performances de l'application ou/et sur l'amélioration des performances du navigateur, ni sur le coût de mise en œuvre de ces prétraitements. en lui-même n'est pas petit ; à moins que vous ne fassiez une demande avec des performances extrêmement strictes (comme Taobao ?), c'est toujours une décision.Du point de vue de l'optimisation des moteurs de recherche, cela a également du sens. Les outils prêts à l'emploi adaptés à AngularJS incluent
prerender.io
serveur-angularjs
L'île Midway de Taobao devrait être un point de départ similaire