Codare Base64; Vrăjitorie CSS; Optimizarea performanței web
Scris de Harry Roberts pe vrăjitorie CSS.
Acesta este primul dintr-un post în două părți. Citiți partea 2.
Recomandările de performanță de câțiva ani în urmă au afirmat pur și simplu că ar trebui „să reducem numărul de cereri pe care le facem”. În timp ce acesta este, în general, un sfat perfect solid, nu este lipsit de avertismente. De fapt, putem face paginile să se încarce mult mai repede prin distribuirea elegantă a activelor noastre pe câteva cereri mai bine luate în considerare, mai degrabă decât mai puține.
Una dintre „cele mai bune practici” susținute, născută din acest sfat, a fost adoptarea codificării Base64: actul de a prelua un activ extern (de exemplu, o imagine) și de a-l încorpora direct în resursa text care l-ar folosi (de exemplu, o foaie de stil). Rezultatul este că reducem numărul de solicitări HTTP și că ambele materiale (de exemplu, foaia de stil și imaginea) ajung în același timp. Sună ca un vis, corect?
Din păcate, activele de codificare Base64 sunt foarte mult un anti-model 1. În acest articol, sper să vă împărtășesc câteva informații despre optimizarea căilor critice, Gzip și, bineînțeles, Base64.
Să ne uităm la un cod
Motivul pentru care am fost motivat să scriu acest articol este pentru că tocmai am făcut un audit de performanță pentru un client și am dat peste problemele pe care urmează să le subliniez. Aceasta este o foaie de stil reală de la un client real: lucrurile sunt anonimizate, dar acesta este un proiect complet real.
Am rulat un profil rapid de rețea peste pagină și am descoperit o singură foaie de stil (ceea ce este cam bun într-un fel, deoarece cu siguranță nu vrem să vedem 12 solicitări de foaie de stil), dar foaia de stil a intrat în mare 925K după ce a fost decomprimat și extins. Cantitatea reală de octeți care vin peste fir a fost substanțial mai mică, dar totuși foarte mare la 232K.
De îndată ce începem să vedem foi de stil de acea dimensiune, ar trebui să începem să intrăm în panică. Eram relativ sigur - fără să trebuiască măcar să mă uit - că va exista ceva Base64 aici. Asta nu înseamnă că m-am așteptat să fie singurul factor (pluginurile, lipsa arhitecturii, moștenirea etc. sunt susceptibile să joace un rol), dar foile de stil atât de mari sunt de obicei indicative pentru Base64. Încă:
- Base64 sau nu, 925K de CSS este terifiant.
- Reducerea acestuia se reduce doar la 759K.
- Gzipping ne duce la doar 232K. Exact același cod comprimat cu 693K.
- 232K peste fir este încă terifiant.
Este nevoie de un efect de uimire de 88 ms chiar pentru a analiza o foaie de stil de acea dimensiune. Obținerea acestuia prin rețea este doar începutul problemelor noastre:
Am pregătit fișierul 2, l-am salvat pe mașina mea, l-am rulat prin CSSO, apoi am rulat acea ieșire minimizată prin Gzip pe setarea sa obișnuită. Așa am ajuns la aceste numere și am rămas uitându-mă la asta:
Următorul lucru de făcut a fost să vedem cât de mulți dintre acești octeți provin din activele codificate Base64. Pentru a rezolva acest lucru, am eliminat pur și simplu (și destul de grosolan) toate liniile/declarațiile care conțineau date: șiruri (: g/data:/d 3 pentru utilizatorii Vim care citesc acest lucru). Majoritatea acestei codificări Base64 a fost pentru imagini/sprite și câteva fonturi. Am salvat apoi acest fișier ca no-base64.css și am rulat aceeași minificare și Gzipping peste asta:
În CSS-ul nostru necomprimat, am reușit să pierdem un întreg 217K din Base64. Acest lucru ne lasă încă cu o cantitate alarmantă de CSS (708K este destul de dificil), dar am reușit să scăpăm de un bun 23,45% din codul nostru.
Unde lucrurile devin cu adevărat surprinzătoare acum, este după ce am Gzipped ce a mai rămas. Am reușit să trecem de la 708K până la doar 68K peste fir! Asta este o economie de 90,39%. Wow.
Salvează Gzip ...
Gzip este incredibil! Este probabil cel mai bun instrument unic pentru protejarea utilizatorilor de dezvoltatori. Am reușit să economisim 90% peste fir doar prin comprimarea CSS-ului nostru. De la 708K până la 68K gratuit.
... Uneori
Cu toate acestea, Gzip lucrează versiunea codificată non-Base64. Dacă ne uităm la CSS original (CSS cu codare Base64), vom constata că am făcut doar o economie de 74,91%.
| da | 925K | 232K | 74,91% |
| Nu | 708K | 68K | 90,39% |
Diferența dintre cele două opțiuni este de 164K (70,68%). Putem trimite cu 164K CSS mai puțin prin cablu doar mutând acele active în alt loc mai potrivit.
Base64 se comprimă teribil. Data viitoare când cineva încearcă să meargă, da, dar Gzip ... scuză-te, spune-le despre asta (dacă încearcă să justifice Base64, adică).
Deci, de ce este atât de rău Base64?
Bine, deci suntem destul de clari acum că Base64 crește dimensiunea fișierelor într-un mod în care Gzip nu ne poate ajuta cu adevărat, dar aceasta este doar o mică parte a problemei. De ce ne este atât de frică de această creștere a dimensiunii fișierelor? O singură imagine ar putea cântări mult peste 232K, deci nu este mai bine să începem de acolo?
Întrebare bună și mă bucur că ai menționat imagini ...
Trebuie să vorbim despre imagini
Pentru a înțelege cât de rău este Base64, trebuie mai întâi să înțelegem cât de bune sunt imaginile. Opinie controversată: imaginile nu sunt la fel de rele pentru performanță pe cât crezi.
Da, imaginile sunt o problemă. De fapt, acestea contribuie numărul unu la umflarea paginii. Începând cu 2 decembrie 2016, imaginile reprezintă aproximativ 1623K (sau 65,46%) din media paginii web. Asta face ca foaia noastră de stil de 232K să pară o picătură în ocean prin comparație. Cu toate acestea, există diferențe fundamentale între modul în care browserele tratează imaginile și foile de stil: