Produits secs | Le guide pratique d'optimisation de la performance du projet Vue le plus complet

Préface

Grâce à la liaison de données bidirectionnelle et à la technologie DOM virtuelle, le framework Vue nous a aidés à gérer la partie la plus sale et la plus fatigante de la manipulation du DOM dans le développement frontal. Nous n'avons plus besoin de réfléchir à la façon de faire fonctionner le DOM et à exploiter le DOM le plus efficacement possible; mais toujours dans le projet Vue Il y a des problèmes tels que l'optimisation du premier écran du projet et l'optimisation de la configuration de la compilation Webpack, nous devons donc toujours faire attention à l'optimisation des performances du projet Vue pour faire en sorte que le projet ait des performances plus efficaces et une meilleure expérience utilisateur. Cet article est résumé par l'auteur à travers la pratique d'optimisation de projets réels.J'espère que les lecteurs auront une réflexion éclairante après avoir lu cet article, afin d'aider à optimiser leurs propres projets. Le contenu de cet article est divisé en trois parties:

Optimisation du niveau de code Vue;
Optimisation du niveau de configuration du webpack;
Optimisation de la technologie Web de base.

1. Optimisation au niveau du code

1.1, v-if et v-show distinguent les scénarios d'utilisation

v-if est un rendu conditionnel vrai, car il garantira que les écouteurs d'événements et les sous-composants du bloc conditionnel sont correctement détruits et reconstruits pendant le processus de commutation; il est également paresseux: si la condition est fausse au moment du rendu initial, rien n'est fait Do-Le bloc conditionnel ne sera pas rendu jusqu'à ce que la condition devienne vraie pour la première fois.

v-show est beaucoup plus simple, quelle que soit la condition initiale, l'élément sera toujours rendu et il est simplement commuté en fonction de la propriété d'affichage CSS.

Par conséquent, v-if convient aux scénarios qui changent rarement de conditions pendant l'exécution et n'ont pas besoin de changer fréquemment de conditions; v-show convient aux scénarios qui nécessitent des conditions de commutation très fréquentes.

1.2. Différenciation des scénarios d'utilisation entre calcul et surveillance

Calculé: il s'agit d'un attribut calculé, qui dépend d'autres valeurs d'attribut, et la valeur calculée est mise en cache. Ce n'est que lorsque la valeur d'attribut dont elle dépend change, la valeur calculée sera recalculée la prochaine fois que la valeur calculée est obtenue;

watch: Il s'agit plus de la fonction "d'observation", similaire au rappel de surveillance de certaines données, chaque fois que les données surveillées changent, le rappel sera exécuté pour les opérations suivantes;

Scénarios d'application:

Lorsque nous devons effectuer des calculs numériques et nous fier à d'autres données, nous devons utiliser calculées, car nous pouvons utiliser la fonction de cache de computed pour éviter le recalcul à chaque fois que nous obtenons une valeur;
Lorsque nous devons effectuer des opérations asynchrones ou coûteuses lorsque les données changent, nous devons utiliser watch. L'utilisation de l'option watch nous permet d'effectuer des opérations asynchrones (accès à une API), en limitant la fréquence à laquelle nous effectuons l'opération, et avant d'obtenir le résultat final, définissez l'état intermédiaire. Ce sont des choses que les propriétés calculées ne peuvent pas faire.

1.3, v-for traversal doit ajouter la clé à l'élément et éviter d'utiliser v-if en même temps

(1) Le parcours V-for doit ajouter la clé à l'élément

Lorsque les données de la liste sont parcourues et rendues, une valeur de clé unique doit être définie pour chaque élément, afin que le mécanisme interne de Vue.js puisse trouver avec précision les données de la liste. Lorsque l'état est mis à jour, la nouvelle valeur d'état est comparée à l'ancienne valeur d'état et le diff est localisé plus rapidement.

(2) v-for traversal évite d'utiliser v-if en même temps

v-for a une priorité plus élevée que v-if. Si vous devez parcourir le tableau entier à chaque fois, cela affectera la vitesse, en particulier lorsqu'une petite partie de celui-ci doit être rendue, elle doit être remplacée par la propriété calculée si nécessaire.

recommander:

<ul> <li v-for="user in activeUsers" :key="user.id"> {
   
   { user.name }} </li></ul>computed: { activeUsers: function () { return this.users.filter(function (user) { return user.isActive }) }}
br

Non recommandé:

<ul> <li v-for="user in users" v-if="user.isActive" :key="user.id"> {
   
   { user.name }} </li></ul>
br

1.4, optimisation des performances de longue liste

Vue détournera les données via Object.defineProperty pour se rendre compte que la vue répond aux changements de données. Cependant, parfois, nos composants sont de purs affichages de données et il n'y aura pas de changements. Nous n'avons pas besoin de Vue pour détourner nos données. Dans le cas de l'affichage des données, cela peut réduire considérablement le temps d'initialisation du composant Comment empêcher Vue de détourner nos données? Vous pouvez figer un objet via la méthode Object.freeze. Une fois que l'objet est gelé, il ne peut plus être modifié.

export default { data: () => ({ users: {} }), async created() { const users = await axios.get("/api/users"); this.users = Object.freeze(users); }};
br

1.5. Destruction de l'événement

Lorsqu'un composant Vue est détruit, il nettoiera automatiquement sa connexion avec d'autres instances, dissociera toutes ses instructions et ses écouteurs d'événements, mais uniquement limité aux événements du composant lui-même. Si vous utilisez addEventListene et d'autres méthodes dans js, il ne sera pas automatiquement détruit. Nous devons supprimer manuellement les écouteurs de ces événements lorsque le composant est détruit pour éviter les fuites de mémoire, telles que:

created() { addEventListener('click', this.click, false)},beforeDestroy() { removeEventListener('click', this.click, false)}
br

1.6, chargement paresseux des ressources d'image

Pour les pages contenant trop d'images, afin d'accélérer la vitesse de chargement de la page, dans de nombreux cas, nous devons d'abord charger les images qui ne sont pas dans la zone visible de la page, puis les charger après avoir fait défiler la zone visible. Cela améliorera considérablement les performances de chargement de la page et améliorera également l'expérience utilisateur. Nous utilisons le plugin vue-lazyload de Vue dans le projet:

(1) Installez le plug-in

npm install vue-lazyload --save-dev
br

(2) Introduire et utiliser dans le fichier d'entrée man.js

import VueLazyload from 'vue-lazyload'
br

Ensuite, utilisez-le directement en vue

Vue.use(VueLazyload)
br

Ou ajoutez des options personnalisées

Vue.use(VueLazyload, {preLoad: 1.3,error: 'dist/error.png',loading: 'dist/loading.gif',attempt: 1})br

(3) Changez l'attribut src de la balise img directement en v-lazy dans le fichier vue pour changer le mode d'affichage de l'image en affichage de chargement paresseux:

<img v-lazy="/static/img/1.png">
br

Ce qui précède est une utilisation simple du plugin vue-lazyload. Si vous voulez voir plus d'options de paramètres du plugin, vous pouvez vérifier l'adresse github de vue-lazyload.

1.7, routage du chargement paresseux

Vue est une application d'une seule page, et il peut y avoir de nombreuses routes introduites. De cette façon, les fichiers fournis avec webpcak sont très volumineux. Lorsque vous entrez dans la page d'accueil, trop de ressources sont chargées et la page apparaîtra vide, ce qui est pas propice à l'expérience utilisateur. Si nous pouvons diviser les composants correspondant aux différentes routes en différents blocs de code, puis charger les composants correspondants lors de l'accès aux routes, ce sera plus efficace. Cela augmentera considérablement la vitesse d'affichage du premier écran, mais la vitesse des autres pages peut être réduite.

Chargement paresseux du routage:

const Foo = () => import('./Foo.vue')const router = new VueRouter({ routes: [ { path: '/foo', component: Foo } ]})
br

1.8. Introduction à la demande de plug-ins tiers

Nous devons souvent introduire des plug-ins tiers dans nos projets. Si nous introduisons directement l'intégralité du plug-in, la taille du projet sera trop importante. Nous pouvons utiliser babel-plugin-component pour introduire uniquement les composants requis dans réduire la taille du projet. Voici un exemple d'introduction de la bibliothèque de composants element-ui dans le projet:

(1) Tout d'abord, installez babel-plugin-component:

npm install babel-plugin-component -D
br

(2) Ensuite, modifiez .babelrc en:

{ "presets": [["es2015", { "modules": false }]], "plugins": [ [ "component", { "libraryName": "element-ui", "styleLibraryName": "theme-chalk" } ] ]}
br

(3) Introduisez quelques composants dans main.js:

import Vue from 'vue';import { Button, Select } from 'element-ui'; Vue.use(Button) Vue.use(Select)
br

1.9. Optimiser les performances illimitées des listes

Si votre application possède une liste déroulante très longue ou infinie, vous devez utiliser la technologie de fenêtrage pour optimiser les performances. Il vous suffit de rendre une petite partie de la zone, ce qui réduit le temps de rendu des composants et de création de nœuds dom. Vous pouvez vous référer aux projets open source suivants vue-virtual-scroll-list et vue-virtual-scroller pour optimiser cette scène de liste infinie.

1.10, SSR de rendu côté serveur ou pré-rendu

Le rendu côté serveur signifie que le travail de Vue rendant l'ensemble des fragments html des balises côté client est terminé côté serveur, et les fragments html formés côté serveur sont directement renvoyés au côté client. Ce processus est appelé serveur - rendu côté.

(1) Avantages du rendu côté serveur:

Meilleur référencement: étant donné que le contenu de la page SPA est obtenu via Ajax et que l'outil d'exploration des moteurs de recherche n'attend pas la fin asynchrone d'Ajax pour analyser le contenu de la page, la page ne peut pas être explorée dans le SPA. La page est obtenue via Ajax Content et SSR renvoie directement la page rendue à partir du serveur (les données sont déjà contenues dans la page), de sorte que les outils d'analyse des moteurs de recherche peuvent explorer la page rendue;
Temps d'arrivée du contenu plus rapide (chargement plus rapide sur le premier écran): SPA attendra que tous les fichiers js compilés par Vue soient téléchargés avant de commencer à rendre la page. Le téléchargement de fichiers prend un certain temps, donc le rendu du premier écran nécessite un certain temps heure; SSR est directement rendu par le serveur et la page est directement renvoyée à l'affichage, sans attendre le téléchargement des fichiers js et le rendu, donc SSR a une heure d'arrivée du contenu plus rapide;

(2) Inconvénients du rendu côté serveur:

Plus de restrictions sur les conditions de développement: par exemple, le rendu côté serveur ne prend en charge que deux fonctions hook avant la création et la création, ce qui obligera certaines bibliothèques d'extensions externes à nécessiter un traitement spécial avant de pouvoir s'exécuter dans des applications de rendu côté serveur; et peut être déployée dans n'importe quel fichier statique Le SPA de l'application monopage entièrement statique sur le serveur est différent.L'application de rendu côté serveur doit se trouver dans l'environnement d'exécution du serveur Node.js;
Plus de charge du serveur: le rendu d'une application complète dans Node.js consomme évidemment plus de ressources processeur qu'un serveur qui ne fournit que des fichiers statiques. Par conséquent, si vous prévoyez de l'utiliser dans un environnement à fort trafic, préparez la charge de serveur correspondante. Et utilisez les stratégies de mise en cache à bon escient.

Si le référencement et le rendu du premier écran de votre projet sont les indicateurs clés pour évaluer le projet, alors votre projet a besoin d'un rendu côté serveur pour vous aider à obtenir les meilleures performances de chargement initial et le meilleur référencement. Pour une implémentation spécifique de Vue SSR, veuillez vous référer à l'auteur. Un autre article "Vue SSR Trampled Tour". Si votre projet Vue n'a besoin que d'améliorer le référencement de quelques pages marketing (telles que /, / about, / contact, etc.), vous devrez peut-être pré-rendre et simplement générer des fichiers HTML statiques pour des routes spécifiques au moment de la construction. . L'avantage est qu'il est plus facile de configurer le pré-rendu, et que vous pouvez utiliser votre front-end comme un site complètement statique. Plus précisément, vous pouvez utiliser prerender-spa-plugin pour ajouter facilement un pré-rendu.

2. Optimisation au niveau du Webpack

2.1, Webpack compresse les images

Dans le projet vue, sauf que la taille limite peut être définie dans le chargeur d'url dans webpack.base.conf.js pour traiter les images, les images plus petites que la limite sont converties au format base64 et le reste n'est pas exploité. Par conséquent, pour certaines ressources image plus importantes, le chargement sera très lent lors de la demande de ressources. Nous pouvons utiliser image-webpack-loader pour compresser les images:

(1) Tout d'abord, installez image-webpack-loader:

npm install image-webpack-loader --save-dev
br

(2) Ensuite, configurez dans webpack.base.conf.js:

{ test: /\.(png|jpe?g|gif|svg)(\?.*)?$/, use:[ { loader: 'url-loader', options: { limit: 10000, name: utils.assetsPath('img/[name].[hash:7].[ext]') } }, { loader: 'image-webpack-loader', options: { bypassOnDebug: true, } } ]}
br

2.2, réduisez le code redondant de ES6 à ES5

Le plugin Babel injectera des fonctions auxiliaires lors de la conversion du code ES6 en code ES5, comme le code ES6 suivant:

class HelloWebpack extends Component{...}
br

Lorsque ce code est converti en code ES5 qui peut fonctionner normalement, les deux fonctions auxiliaires suivantes sont nécessaires:

babel-runtime/helpers/createClass // 用于实现 class 语法babel-runtime/helpers/inherits // 用于实现 extends 语法
br

Par défaut, Babel incorporera ces codes de fonction d'assistance dépendants dans chaque fichier de sortie. Si plusieurs fichiers de code source reposent sur ces fonctions d'assistance, les codes de ces fonctions d'assistance apparaîtront plusieurs fois, ce qui entraînera une redondance du code. Afin d'éviter que le code de ces fonctions d'assistance ne réapparaisse, vous pouvez les importer via require ('babel-runtime / helpers / createClass') lorsque vous vous y fiez, afin qu'elles ne puissent apparaître qu'une seule fois. Le plug-in babel-plugin-transform-runtime est utilisé pour réaliser cette fonction, en remplaçant les fonctions auxiliaires associées par des instructions d'importation, réduisant ainsi la taille du fichier du code compilé par babel.

(1) Tout d'abord, installez babel-plugin-transform-runtime:

npm install babel-plugin-transform-runtime --save-dev
br

(2) Ensuite, modifiez le fichier de configuration .babelrc pour:

"plugins": [ "transform-runtime"]
br

Si vous souhaitez voir plus de détails sur le plug-in, vous pouvez consulter l'introduction détaillée de babel-plugin-transform-runtime.

2.3, extraire le code public

Si les bibliothèques tierces et les modules publics de chaque page ne sont pas extraits dans le projet, le projet aura les problèmes suivants:

Les mêmes ressources sont chargées à plusieurs reprises, gaspillant le trafic des utilisateurs et les coûts de serveur.
Les ressources qui doivent être chargées pour chaque page sont trop volumineuses, ce qui entraîne un chargement lent du premier écran de la page Web, ce qui affecte l'expérience utilisateur.

Nous devons donc extraire le code commun de plusieurs pages dans des fichiers séparés pour optimiser les problèmes ci-dessus. Webpack a intégré CommonsChunkPlugin, un plug-in dédié à l'extraction des parties communes de plusieurs Chunks. La configuration de CommonsChunkPlugin dans le projet est la suivante:

// 所有在 package.json 里面依赖的包，都会被打包进 vendor.js 这个文件中。new webpack.optimize.CommonsChunkPlugin({ name: 'vendor', minChunks: function(module, count) { return ( module.resource && /\.js$/.test(module.resource) && module.resource.indexOf( path.join(__dirname, '../node_modules') ) === 0 ); }}),// 抽取出代码模块的映射关系new webpack.optimize.CommonsChunkPlugin({ name: 'manifest', chunks: ['vendor']})
br

Si vous souhaitez voir plus de détails sur le plug-in, vous pouvez voir l'introduction détaillée de CommonsChunkPlugin.

2.4, précompilation des modèles

Lors de l'utilisation d'un modèle DOM ou d'un modèle de chaîne en JavaScript, le modèle sera compilé dans une fonction de rendu au moment de l'exécution. Normalement, ce processus est assez rapide, mais il vaut mieux éviter cette utilisation pour les applications sensibles aux performances.

Le moyen le plus simple d'utiliser des modèles précompilés consiste à utiliser des paramètres de construction liés aux composants à fichier unique qui gèrent automatiquement la précompilation, de sorte que le code généré contient déjà la fonction de rendu compilée au lieu de la chaîne de modèle d'origine.

Si vous utilisez webpack et que vous souhaitez séparer les fichiers JavaScript et modèles, vous pouvez utiliser vue-template-loader, qui peut également convertir les fichiers modèles en fonctions de rendu JavaScript pendant le processus de construction.

2.5, extraire le CSS du composant

Lors de l'utilisation d'un composant mono-fichier, le CSS du composant sera injecté dynamiquement via JavaScript sous la forme de balises de style. Cela a une petite surcharge d'exécution. Si vous utilisez le rendu côté serveur, cela provoquera une période de "scintillement du contenu non stylé (fouc)". L'extraction du CSS de tous les composants dans le même fichier peut éviter ce problème et permettra également au CSS d'être mieux compressé et mis en cache.

Consultez la documentation respective de cet outil de construction pour en savoir plus:

webpack + vue-loader (Le modèle webpack de vue-cli a été préconfiguré)
Browserify + vueify
Rollup + rollup-plugin-vue

2.6, optimiser SourceMap

Une fois le projet empaqueté, nous emballerons les multiples codes de fichier en cours de développement dans un seul fichier, et après la compression, la suppression des espaces supplémentaires et la compilation avec babel, le code compilé sera enfin utilisé dans l'environnement en ligne, puis il y aura un gros différence entre le code traité et le code source. Lorsqu'il y a un bogue, nous ne pouvons localiser que l'emplacement du code compressé, et ne pouvons pas localiser le code dans l'environnement de développement, ce qui n'est pas facile pour le développement. Le problème, donc sourceMap est apparu, il est de résoudre le problème du mauvais code de débogage.

Les valeurs facultatives de SourceMap sont les suivantes (plus il y a de signes +, plus la vitesse est rapide, plus il y a de signes, plus la vitesse est lente et o signifie vitesse moyenne)

Environnement de développement recommandé: cheap-module-eval-source-map

Recommandation d'environnement de production: cheap-module-source-map

Les raisons sont les suivantes:

bon marché: les informations de colonne dans le code source n'ont aucun effet. Par conséquent, le fichier packagé ne souhaite pas contenir d'informations relatives aux colonnes. Seules les informations de ligne peuvent établir une relation de dépendance avant et après l'empaquetage. Par conséquent, qu'il s'agisse d'un environnement de développement ou d'un environnement de production, nous voulons ajouter le type basique de cheap pour ignorer les informations de colonne avant et après l'empaquetage;
module: Qu'il s'agisse d'un environnement de développement ou d'un environnement formel, nous espérons tous localiser l'emplacement spécifique du code source du bogue. Par exemple, si un fichier Vue signale une erreur, nous espérons localiser le fichier Vue spécifique, donc nous avons également besoin d'une configuration de module;
soure-map: source-map générera un fichier de sourcemap séparé pour chaque module packagé, nous devons donc ajouter des attributs source-map;
eval-source-map: la vitesse du code d'empaquetage eval est très rapide, car il ne génère pas de fichier de carte, mais vous pouvez utiliser eval-source-map en combinaison avec eval. Le fichier de carte sera stocké dans le fichier js empaqueté sous la forme de DataURL. N'utilisez pas eval-source-map dans un environnement formel, car cela augmentera la taille du fichier, mais dans un environnement de développement, vous pouvez l'essayer car ils sont empaquetés rapidement.

2.7 Analyse de sortie des résultats de construction

Le code produit par Webpack est très lisible et le fichier est très volumineux, ce qui nous donne un mal de tête. Afin d'analyser les résultats de sortie de manière plus simple et intuitive, de nombreux outils d'analyse visuelle sont apparus dans la communauté. Ces outils affichent les résultats de manière plus intuitive de manière graphique, ce qui nous permet de comprendre rapidement le problème. Ensuite, expliquez l'outil d'analyse que nous avons utilisé dans le projet Vue: webpack-bundle-analyzer.

Nous configurons webpack.prod.conf.js dans le projet:

if (config.build.bundleAnalyzerReport) { var BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin; webpackConfig.plugins.push(new BundleAnalyzerPlugin());}
br

Après avoir exécuté $ npm run build --report, le rapport d'analyse est généré comme suit:

2.8, Optimisation de la compilation du projet Vue

Si votre projet Vue est compilé avec Webpack et vous oblige à prendre une tasse de café, vous devez peut-être optimiser la configuration Webpack du projet pour améliorer l'efficacité de la construction de Webpack. Pour plus de détails sur l'optimisation de la construction Webpack du projet Vue, veuillez vous référer à un autre article de l'auteur "Vue Project Webpack Optimization Practice"

3. Optimisation de la technologie Web de base

3.1, compression gzip ouverte

gzip est l'abréviation de GNUzip, et a été utilisé pour la première fois pour la compression de fichiers dans les systèmes UNIX. Le codage gzip sur le protocole HTTP est une technologie utilisée pour améliorer les performances des applications Web. Le serveur Web et le client (navigateur) doivent prendre en charge gzip ensemble. Les navigateurs courants actuels, Chrome, Firefox, IE, etc. prennent tous en charge ce protocole. Les serveurs courants tels que Apache, Nginx et IIS le prennent également en charge. L'efficacité de la compression gzip est très élevée, atteignant généralement un taux de compression de 70%. C'est-à-dire que si votre page Web a 30 Ko, elle deviendra environ 9 Ko après la compression. .

Prenons l'exemple de l'express côté serveur. Il est très simple d'ouvrir gzip. Les étapes pertinentes sont les suivantes:

installation:

npm install compression --save
br

Ajouter une logique de code:

var compression = require('compression');var app = express();app.use(compression())
br

Redémarrez le service et observez l'en-tête de réponse dans le panneau réseau. Si vous voyez les champs suivants dans le cercle rouge, cela signifie que gzip a été ouvert avec succès:

3.2, cache du navigateur

Afin d'améliorer la vitesse de chargement des pages pour les utilisateurs, il est nécessaire de mettre en cache les ressources statiques. Selon qu'il est nécessaire de relancer les requêtes vers le serveur ou non, les règles de mise en cache HTTP sont divisées en deux catégories (mise en cache obligatoire, Si vous ne le comprenez pas très clairement, vous pouvez vous référer à l'article de l'auteur sur la mise en cache HTTP "Compréhension approfondie des mécanismes et principes de la mise en cache HTTP", qui ne sera pas répété ici.

3.3 Utilisation du CDN

Les navigateurs doivent se connecter au serveur lors du téléchargement de CSS, js et images à partir du serveur. La plupart des serveurs ont une bande passante limitée. Si la limite est dépassée, la page Web ne pourra pas répondre pendant une demi-journée. CDN peut charger des fichiers via différents noms de domaine, ce qui augmente considérablement le nombre de connexions simultanées pour le téléchargement de fichiers, et CDN a une meilleure disponibilité, un délai réseau plus faible et un taux de perte de paquets.

3.4. Utilisez les performances de Chrome pour trouver les goulots d'étranglement des performances

Le panneau des performances de Chrome peut enregistrer les détails et l'heure d'exécution de js sur une période donnée. Les étapes pour analyser les performances de la page à l'aide des outils de développement Chrome sont les suivantes.

Ouvrez les outils de développement Chrome et passez au panneau Performances
Cliquez sur Enregistrer pour démarrer l'enregistrement
Actualiser la page ou développer un nœud
Cliquez sur Arrêter pour arrêter l'enregistrement

FIN

3.4. Utilisez les performances de Chrome pour trouver les goulots d'étranglement des performances

Ouvrez les outils de développement Chrome et passez au panneau Performances
Cliquez sur Enregistrer pour démarrer l'enregistrement
Actualiser la page ou développer un nœud
Cliquez sur Arrêter pour arrêter l'enregistrement

FIN