10
votes

Comment optimiser WebPack / ES6 sur le dessus?

J'ai optimisé la période de chargement de mon application et après quelques victoires rapides avec optimisation de mon code, j'ai remarqué qu'il semble y avoir une phase de prise de longue durée de 500 ms où toutes les déclarations requises semblent être résolues, ou quelque chose. < / p>

peut-il être optimisé et comment?

J'utilise WebPack, réagissez et couple des dizaines de packages NPM. Le fichier de résultats est de 2,8 m décompressé et d'environ 900k zippé. Il n'y a pas une énorme quantité de code de l'application elle-même, ses packages surtout NPM.

Je me demande si je peux simplement compiler cela différemment pour éviter tout le besoin et ce qui n'est pas en temps réel.

mise à jour: j'utilise la construction de la production avec le plug-in dédupe actuellement.

 WebPack / ES6 Holdhead


8 commentaires

Avez-vous essayé NPM dédupe ? Cela a-t-il montré des progrès?


Great, Astuce! J'ai vu une réduction globale de la durée de charge, mais je vois toujours que 500 ms webpack_require morceau.


Si vous ne faites pas beaucoup de chunking (on dirait que vous ne le faites pas), vous devriez probablement Go Chunks et améliorer le temps de départ par une paresseux en chargeant certaines d'entre elles. Je ne pense pas que quelque chose puisse être suggéré sans savoir plus sur votre construction. Vous pouvez parcourir le profil et analyser quels modules coûteux __ webpack_require __ appartiennent. Vérifiez également Ce .


Merci pour la suggestion. Je ferai probablement des fractionnements comme cela semble être le seul moyen de faire face à cela.


Lorsque vous regardez le profileur, assurez-vous de différencier votre propre temps et votre temps total. Le temps total passé dans __ webpack_require __ est élevé, car l'exécution du module compte contre la métrique de temps totale , mais moi-même devrait être beaucoup plus bas (temps passé dans la fonction mais pas pour les enfants ).


Par zippé, vous voulez dire gzippé ou minifiée? Vos tailles de fichiers sont-elles avec des cartes source ou non?


Les deux, sans cartes sources.


Êtes-vous sûr de vous montrer la chronologie du code Minify? __ webpack_require __ dans la timeline dit quelque chose de différent


3 Réponses :


2
votes

Une chose que vous pourriez faire est de jouer avec le DevTool Config et Changez votre façon de générer vos sources. Cela devrait accélérer un peu les choses au détriment de la facilité de débogage.

Webpack a un grand guide sur la façon d'optimiser les performances ici http://webpack.github.io/docs/build-performance.html .

essentiellement, il se résume à la quantité d'informations de débogage que vous ressentez vous avez besoin.

par réglage xxx

Vous conservez le code d'origine, ce qui est évidemment le plus facile à déboguer, mais cela vient au détriment de la taille des fichiers / de la taille des fichiers .

mis à jour: Selon le commentaire de Chris ci-dessous, voici Un autre guide


6 commentaires

Très bonne réponse! Ce guide pourrait bien compléter.


Chris! == Chris. J'avais l'impression que la question concerne les performances de l'exécution et non pas de temps, il s'agit donc de chunking et de chargement paresseux.


@Stus, je pourrais être très tort, mais les performances d'exécution impliquent la reconstruction / la compilation de l'application sur le changement de sauvegarde / du contenu. Où il se bloque sur les instructions pourraient être dues à WebPack essayant de sourire les modules?


Je crois que l'OP affiche le graphique de performance sur la page Chargement de la page, il s'agit donc d'environ app Performances d'exécution, pas Builder Runtime Performance.


Chris 2.0 ici. Je suis (légèrement) de meilleures performances sur une construction de production par rapport à un développement.


J'utilise déjà la production construite afin que le graphique provienne d'une construction de production.



2
votes

Je ne crois pas que votre timeline provient du code Minificateur (comparaison __ webpack_require __ code> dans les fichiers MAPED et f code> dans le code minificateur).

Je vais montrer que minifiez Et certains plugins peuvent réduire deux fois l'heure de fonctionnement de ce script. Dans WebPack Configs, je ne montrerai que la principale différence entre les configurations. p>


Développez le mode h2>

webpack.config.js code> p> xxx pré>

- 473 ms strong> p>

 Timeline en mode Développement P>

Mode de production H2>

webpack.config.js CODE> P>

plugins: [
    'transform-react-remove-prop-types',
    'transform-react-constant-elements',
    'transform-react-inline-elements'
],
cache: false,
debug: false,
plugins: [
    // Search for equal or similar files and deduplicate them in the output
    // https://webpack.github.io/docs/list-of-plugins.html#dedupeplugin
    new webpack.optimize.DedupePlugin(),

    // Minimize all JavaScript output of chunks
    // https://github.com/mishoo/UglifyJS2#compressor-options
    new webpack.optimize.UglifyJsPlugin({
        compress: {
            screw_ie8: true, 
            warnings: false,
        },
    }),

    // A plugin for a more aggressive chunk merging strategy
    // https://webpack.github.io/docs/list-of-   plugins.html#aggressivemergingplugin
    new webpack.optimize.AggressiveMergingPlugin(),
]


1 commentaires

Bonjour, True - Je l'ai remarqué aussi. Merci d'avoir montré combien de temps est enregistré en faisant une minécution! Je vais passer sur votre config et voir ce que je peux appliquer aussi.



3
votes

Comme certains commentaires ont déjà signalé, nous devons différencier le temps de construction et d'exécution. Guide référencé à partir de la pagePACK Documents concerne Performances de construction Strong>.

Tout en n'utilisant que DEVTools comme des cartes de source et un code minificateur a une incidence sur la vitesse d'exécution, je pense que le plus important est chunking / loading paresseux strong> (comme Stus a déjà signalé). P>

Vous devez choisir quelles parties de votre application ne sont pas nécessaires pour le rendu initial. Ces pièces doivent être déplacées dans un autre morceau et chargé de manière paresseuse via exiger.enture () code>. P>

Habituellement, votre routeur est un endroit typique pour charger des trucs asynchroniquement: P>

function loadPage(page) {
    return (location, cb) =>
        require("./path/to/pages/" + page + ".jsx")(
            module => cb(null, module.default)
        );
}


0 commentaires