Poprzednie badania:

Jak mówi wiki webpack, możliwe jest użycie narzędzia analitycznego w celu optymalizacji wydajności kompilacji:

z: https://github.com/webpack/docs/wiki/build-performance#hints-from-build-stats

Wskazówki ze statystyk budowy

Istnieje narzędzie do analizy, które wizualizuje kompilację, a także zapewnia wskazówki, jak można zoptymalizować rozmiar kompilacji i wydajność kompilacji .

Możesz wygenerować wymagany plik JSON, uruchamiając pakiet webpack --profile --json> stats.json

Wygenerowałem plik statystyk ( dostępny tutaj ), przesłałem go do narzędzia analizy webpacka
i pod zakładką Wskazówki poleciłem użyć prefetchPlugin:

z: http://webpack.github.io/analyse/#hints

Długie łańcuchy budowy modułów

Użyj pobierania wstępnego, aby zwiększyć wydajność kompilacji. Pobierz wstępnie moduł ze środka łańcucha .

Przekopałem sieć na lewą stronę, aby znaleźć jedyną dokumentację dostępną na prefechPlugin:

od: https://webpack.js.org/plugins/prefetch-plugin/

PrefetchPlugin

new webpack.PrefetchPlugin([context], request)

Żądanie normalnego modułu, które jest rozwiązywane i budowane jeszcze przed wystąpieniem żądania. Może to zwiększyć wydajność. Spróbuj najpierw profilować kompilację, aby określić sprytne punkty pobierania wstępnego .

Moje pytania:

• Jak poprawnie używać prefetchPlugin?
• Jaki jest właściwy przepływ pracy, aby używać go z narzędziem Analiza?
• Skąd mam wiedzieć, czy prefetchPlugin działa? jak mogę to zmierzyć?
• Co to znaczy pobrać wstępnie moduł ze środka łańcucha ?

Naprawdę docenię kilka przykładów

Proszę, pomóż mi uczynić to pytanie cennym źródłem informacji dla następnego programisty, który chce używać prefechPlugin i narzędzi analitycznych. Dziękuję Ci.

Tak, dokumentacja wtyczki pobierania z wyprzedzeniem prawie nie istnieje. Po zastanowieniu się, jest dość prosty w użyciu i nie ma dużej elastyczności. Zasadniczo pobiera dwa argumenty, kontekst (opcjonalnie) i ścieżkę modułu (względem kontekstu). Kontekst, w Twoim przypadku będzie /absolute/path/to/your/project/node_modules/react-transform-har/przy założeniu, że w zrzucie tylda odnosi się node_moduleszgodnie WebPACK w rozdzielczości node_module .

Rzeczywisty moduł pobierania wstępnego powinien być idealnie głęboki nie więcej niż trzy zależności modułu. Więc w twoim przypadku isFunction.jsjest to moduł z długim łańcuchem kompilacji i idealnie powinien być wstępnie pobrany nagetNative.js

Podejrzewam jednak, że w twojej konfiguracji jest coś dziwnego, ponieważ zależności łańcucha budowania odnoszą się do zależności modułów, które powinny być automatycznie optymalizowane przez webpack. Nie jestem pewien, jak to osiągnąłeś, ale w naszym przypadku nie widzimy żadnych ostrzeżeń dotyczących długich łańcuchów kompilacji w node_modules. Większość naszych długich łańcuchów budowy wynika z głęboko zagnieżdżonych komponentów reakcyjnych, które wymagają SCSS. to znaczy:

Niezależnie od tego, będziesz chciał dodać nową wtyczkę do każdego ostrzeżenia, na przykład:

plugins: [
    new webpack.PrefetchPlugin('/web/', 'app/modules/HeaderNav.jsx'),
    new webpack.PrefetchPlugin('/web/', 'app/pages/FrontPage.jsx')
];

Drugi argument musi być łańcuchem wskazującym na względną lokalizację modułu. Mam nadzieję, że to ma sens.

Prawdopodobnie środek twojego łańcucha react-transform-hmr/index.jszaczyna się mniej więcej w połowie. Możesz spróbować PrefetchPlugin('react-transform-hmr/index')ponownie uruchomić swój profil, aby sprawdzić, czy pomoże to przyspieszyć całkowity czas tworzenia.