Webpack punând pachetele pe o dietă; Antrenament Lemoncode
Deschidem o serie de postări în care ne concentrăm asupra ușurării greutății pachetelor noastre, în această primă postare vă prezentăm un instrument care vă va ajuta să identificați ce pachete sunt de vină pentru „supraponderalitatea” aplicației dvs.
Ecosistemul javascript este incredibil, avem biblioteci pentru orice, este ca un bufet gratuit și, de asemenea, avem acum și instrumente de grupare, cum ar fi webpack, care împachetează „magic” totul pentru dvs.
Acest lucru sună grozav când începeți un proiect și începeți să utilizați bibliotecile ici și colo, gândindu-vă să vă salvați munca. Dintr-o dată a venit timpul să intrăm în producție și vă dați seama că pachetul meu micșorat cântărește 2 megabytes! . ok o poți pune în gzip și o vei descărca, dar dai o încărcare bună browserului clientului tău.
Contează că un pachet cântărește foarte mult? Răspunsul vă poate afecta afacerea, dacă aplicația dvs. web durează mai mult timp pentru încărcare, vor exista utilizatori care o vor ignora (mai bine să o folosiți pe cea din competiție, care este puțin mai rapidă și nu mă lasă uscat cu date și baterie), De asemenea, dacă nu vă controlați greutatea de la început, în câțiva ani veți avea un monstru de mai mulți megabytes că veți avea nevoie de un camion care să-l ducă dintr-un loc în altul.
Când facem o construcție la producție (amintiți-vă că în wepback puteți seta un semnal pentru a genera conținutul minimizat), putem vedea dimensiunea pachetelor din folderul dist.

Oh, Doamne, pachet de 2Mb!
Dacă ne uităm la acest rezultat generat (pe baza unui proiect real), vom constata că AHHHH. Avem doi megaocteți de furnizor js !, în vendor.js este locul unde aruncăm toate bibliotecile terță parte, se pare că există ceva de la terți care generează o digestie intensă.