Posez la question, vous pouvez définir les paramètres de construction sans compression pour voir à quoi ressemble le code à l'intérieur.

Votre tag dit vue, parlons-en à partir de la démo vue à laquelle j'ai été exposé. Tout d'abord, un projet vue doit utiliser vue, et deuxièmement, le js de la page du projet, c'est-à-dire comment instancier vue et écrire le business.

S'il s'agit du modèle de développement jquery traditionnel, une page doit contenir au moins deux js, ​​un pour jquery et un pour le business des pages.

Retournez à l'application, au fournisseur et au manifeste, et publiez la configuration du webpack de l'échafaudage de vue précédent

new webpack.optimize.CommonsChunkPlugin({
      name: 'vendor',
      minChunks: function (module, count) {
        // any required modules inside node_modules are extracted to vendor
        return (
          module.resource &&
          /\.js$/.test(module.resource) &&
          module.resource.indexOf(
            path.join(__dirname, '../node_modules')
          ) === 0
        )
      }
    }),
    // extract webpack runtime and module manifest to its own file in order to
    // prevent vendor hash from being updated whenever app bundle is updated
    new webpack.optimize.CommonsChunkPlugin({
      name: 'manifest',
      chunks: ['vendor']
    })

app.js est l'entrée js, le fournisseur est le bloc de code extrait en extrayant le plug-in du module public (la partie code modulaire du webpack lui-même), et le manifeste est basé sur le fournisseur, et il doit être extrait fréquemment Parties modifiées, telles que le contenu sur le chargement asynchrone des modules js.

On peut également voir sur la capture d'écran que la taille du fichier du fournisseur est la plus grande car elle contient le code de l'ensemble du framework vue et le code modulaire du webpack.

Quant au manifeste, il comprend principalement certaines méthodes d'implémentation de chargement asynchrone (introduction dynamique de js en créant des scripts), et le contenu inclut le nom de fichier et le chemin du js asynchrone.

J'ai déjà vérifié certaines informations. La raison principale est que les modifications js changeront le nom du fichier js lors du chargement asynchrone, qui change relativement fréquemment, les codes tels que les bibliothèques vue ne doivent être compilés et empaquetés qu'une seule fois. n'est emballé que dans un fournisseur, les modifications fréquentes apportées à js entraîneront une recompilation du fournisseur, ce qui est un peu inutile, de sorte que les parties qui suivront les modifications à plusieurs reprises sont extraites sous forme de fichiers manifestes.

Ceci est ma compréhension personnelle, veuillez me corriger si vous avez des questions

La plupart de ce que @Dont a dit est vrai, mais il y a quelques points qui, à mon avis, doivent être modifiés : 1. CommonsChunkPlugin extrait les parties communes au lieu de "changer fréquemment de pièces" 2. Après observation, le webpack devrait être Le le dernier morceau produit par CommonsChunkPlugin injecte la définition de webpackJsonp, ainsi que les définitions liées au chargement asynchrone, et cela impliquera le md5 de toutes les entrées et morceaux , il "changera fréquemment", et le fournisseur par défaut de vue-cli est L'emballage de toutes les dépendances sous node_module sera très volumineux. Dans un environnement de production, les fichiers trop volumineux doivent être mis en cache pour accélérer le chargement. Cependant, les "changements fréquents" ne sont pas propices à la mise en cache, donc pour effectuer l'entrée (ici, vous pouvez le faire). être considéré comme app.js ) les modifications sont isolées en dehors du fournisseur. vue-cli crée un morceau de manifeste supplémentaire après le fournisseur, de sorte que l'entrée n'affectera pas le fournisseur tant qu'elle n'introduit pas de nouveaux packages dans node_modules. est en fait lié à la compilation. Le nombre de fois n'a pas d'importance, tous les fichiers seront à nouveau compilés à chaque fois qu'ils seront empaquetés. Les points clés sont les fichiers volumineux, la mise en cache et le fractionnement des codes modifiés.. Les instructions suivantes ne sont interprétées qu'en fonction de la configuration par défaut du bucket de la famille vue-cli. S'il y a des erreurs, veuillez le signaler :

.vue ou).
.js ?), il n'existe pas de page de ce type. Impossible d'exécuter. vendor.js : dans la configuration par défaut du bucket de la famille vue-cli, ce morceau consiste à empaqueter toutes les dépendances requises (importation) à partir de node_modules/, donc ceci contient toutes les dépendances requises (importation) sous le fichier node_modules/ js manifest.js : Le dernier morceau est injecté avec la définition de webpackJsonp et la définition liée au chargement asynchrone (webpack appelle CommonsChunkPlugin pour traiter le cœur de la gestion des modules. Parce que c'est le noyau, il doit être chargé en premier, sinon une erreur sera signalée).

Simplification : en raison de la stratégie d'emballage par défaut du fournisseur, ce morceau est très volumineux. Selon la configuration par défaut, il n'y a fondamentalement rien à rationaliser. Si vous souhaitez le rationaliser, vous devez essentiellement modifier la stratégie d'emballage de chaque morceau en fonction. le projet réel (essayez de réduire la taille du package pour accélérer la première étape) chargement de l'écran)

Optimisation : une seule page équivaut fondamentalement à une rationalisation. S'il y a plusieurs pages, je pense qu'il est préférable de personnaliser la stratégie d'emballage du fournisseur. Après tout, toutes les pages n'utiliseront pas la totalité des dépendances tierces. la taille du vendeur peut considérablement améliorer la vitesse de chargement.