Am folosit web-ul pentru o zi cu un buget de 50 MB

Acest articol face parte dintr-o serie în care încerc să folosesc web-ul sub diferite constrângeri, reprezentând un anumit demografic al utilizatorului. Sper să ridic profilul dificultăților cu care se confruntă oamenii reali, care pot fi evitate dacă proiectăm și dezvoltăm într-un mod care să fie simpatic cu nevoile lor.

Ultima dată, am navigat pe web timp de o zi folosind Internet Explorer 8. De data aceasta, am navigat pe web o zi cu un buget de 50 MB.

De ce 50 MB?

Mulți dintre noi sunt destul de norocoși să avem planuri de telefonie mobilă care permit transfer de mai mulți gigaocteți de date pe lună. În caz contrar, de obicei ne putem conecta la rețele WiFi de acasă sau publice care au conexiuni rapide în bandă largă și au date efectiv nelimitate.

Dar există părți ale lumii în care datele mobile sunt prohibitiv de scumpe și unde există puțină infrastructură de bandă largă sau deloc.

Oamenii cumpără adesea pachete de date de doar zeci de megaocteți odată, făcând un gigaoctet o cantitate relativ mare și, prin urmare, costisitoare de date de cumpărat.
— Dan Howdle, analist de telecomunicații pentru consumatori la Cable.co.uk

Cât de scump vorbim?

Costul datelor mobile

Un studiu realizat de cable.co.uk din 2018 a constatat că Zimbabwe a fost cea mai scumpă țară din lume pentru date mobile, unde 1 GB a costat în medie 75,20 USD, variind de la 12,50 USD la 138,46 USD. Gama enormă de preț se datorează faptului că cantitățile mai mici de date sunt foarte scumpe, devenind proporțional mai ieftine cu cât planul de date este mai mare. Puteți citi metodologia de studiu pentru mai multe informații.

Zimbabwe nu este deloc unic. Guineea Ecuatorială, Sfânta Elena și Insulele Falkland sunt următoarele, cu 1 GB de date care costă 65,83 USD, 55,47 USD și, respectiv, 47,39 USD. Aceste țări au, în general, o combinație de infrastructură tehnică slabă și adoptare scăzută, ceea ce înseamnă că datele sunt atât costisitoare de furnizat, cât și nu au economia de scară pentru a reduce costurile.

Datele sunt scumpe și în anumite părți ale Europei. Un gigabyte de date în Grecia vă va costa 32,71 USD înapoi; în Elveția, 20,22 USD. Pentru comparație, aceeași cantitate de date costă 6,66 USD în Marea Britanie sau 12,37 USD în SUA. La celălalt capăt al scalei, India este cel mai ieftin loc din lume pentru date, la un cost mediu de 0,26 USD. Urmează Kârgâzstan, Kazahstan și Ucraina la 0,27 USD, 0,49 USD și, respectiv, 0,51 USD per GB.

Viteza rețelelor mobile, de asemenea, variază considerabil între țări. Poate surprinzător, utilizatorii experimentează viteze mai mari într-o rețea mobilă decât WiFi în cel puțin 30 de țări din întreaga lume, inclusiv Australia și Franța. Coreea de Sud are cea mai mare viteză de descărcare mobilă, cu o medie de 52,4 Mbps, dar Irakul are cea mai lentă, cu o medie de 1,6 Mbps de descărcare și 0,7 Mbps de încărcare. SUA ocupă locul 40 în lume pentru viteze de descărcare pe mobil, la aproximativ 34 Mbps, și riscă să rămână și mai în urmă pe măsură ce lumea se îndreaptă către 5G.

În ceea ce privește tipul de conexiune la rețeaua mobilă, 84,7% dintre conexiunile utilizatorilor din Marea Britanie sunt pe 4G, comparativ cu 93% în SUA și 97,5% în Coreea de Sud. Aceasta se compară cu mai puțin de 50% în Uzbekistan și mai puțin de 60% în Algeria, Ecuador, Nepal și Irak.

Costul datelor în bandă largă

Între timp, un studiu al costului de bandă largă în 2018 arată că o conexiune de bandă largă în Niger costă 263 USD „pe megabit pe lună”. Această măsurătoare este puțin greu de înțeles, așa că iată un exemplu: dacă costul mediu al pachetelor de bandă largă într-o țară este de 22 USD și viteza medie de descărcare oferită de pachete este de 10 Mbps, atunci costul „pe megabit pe lună” ar fi fi 2,20 USD.

Este o măsură interesantă și una care recunoaște că viteza de bandă largă este un factor la fel de important ca și limita de date. Un cost de 263 USD sugerează o combinație de bandă largă extrem de lentă și extrem de scumpă. Pentru referință, valoarea este de 1,19 USD în Marea Britanie și 1,26 USD în SUA.

Ceea ce este probabil mai ușor de înțeles este costul mediu al unui pachet de bandă largă. Rețineți că acest studiu a căutat cele mai ieftine pachete de bandă largă oferite, ignorând dacă aceste pachete au sau nu o limită de date, astfel încât oferă o cifră utilă, mai degrabă decât costul datelor în sine.

Numai la costul pachetului, Mauritania are cea mai scumpă bandă largă din lume, la o medie de 768,16 USD (o gamă cuprinsă între 307,26 USD și 1.368,72 USD). Acest cost enorm include construirea de linii fizice către proprietate, deoarece puține există deja în Mauritania. La 0,7 Mbps, Mauritania are, de asemenea, una dintre cele mai lente rețele de bandă largă din lume.

Taiwan are cea mai rapidă bandă largă din lume, la o viteză medie de 85 Mbps. Yemenul are cel mai lent, la 0,38 Mbps. Dar chiar și țările cu infrastructură de bandă largă bine stabilită au așa-numitele „not-spots”. Regatul Unit este pe locul 34 din 207 țări pentru viteza de bandă largă, dar în iulie 2019 mai exista o școală în Marea Britanie fără bandă largă.

Costul mediu al unui pachet de bandă largă în Marea Britanie este de 39,58 USD, iar în SUA este de 67,69 USD. Cea mai ieftină medie din lume este cea a Ucrainei, la doar 5 USD, deși cea mai ieftină ofertă de bandă largă dintre toate a fost găsită în Kârgâstan (1,27 USD - față de media pe țară de 108,22 USD).

Zimbabwe a fost cea mai costisitoare țară pentru date mobile, iar statisticile nu sunt cu mult mai bune pentru bandă largă, cu un cost mediu de 128,71 USD și un cost „pe megabit pe lună” de 6,89 USD.

Cost absolut vs cost în termeni reali

Toate costurile prezentate până acum sunt costurile absolute în USD, bazate pe cursurile de schimb din momentul studiului. Aceste costuri nu au fost luate în considerare pentru costul vieții, ceea ce înseamnă că pentru multe țări costul este de fapt mult mai mare în termeni reali.

O să-mi limitez navigarea astăzi la 50 MB, care în Zimbabwe ar costa în jur de 3,67 USD la un tarif de date mobile. Poate că nu sună prea mult, dar profesorii din Zimbabwe au fost în grevă anul acesta, deoarece salariile lor au scăzut la doar 2,50 USD pe zi.

Pentru comparație, 3,67 USD reprezintă aproximativ jumătate din salariul minim de 7,25 USD în SUA. Ca zimbabwean, ar trebui să lucrez aproximativ o zi și jumătate pentru a câștiga banii necesari pentru a cumpăra aceste date de 50 MB, comparativ cu doar o jumătate de oră în SUA. Nu este ușor să compari costul vieții între țări, dar numai pe salarii, costul de 3,67 USD a 50 MB de date în Zimbabwe ar fi considerat ca 52 USD pentru un american cu salariul minim.

Configurarea experimentului

Am lansat Chrome și am deschis instrumentele de dezvoltare, unde am accelerat rețeaua la o conexiune 3G lentă. Am vrut să simulez o conexiune lentă precum cele experimentate de utilizatorii din Uzbekistan, pentru a vedea ce fel de experiență îmi oferă site-urile web. De asemenea, mi-am accelerat CPU-ul pentru a simula că sunt pe un dispozitiv de gamă inferioară.

Am instalat ModHeader și am setat antetul „Save-Data” pentru a anunța site-urilor web că doresc să reduc la minimum utilizarea datelor. Acesta este, de asemenea, antetul setat de Chrome pentru „modul Lite” al Android, pe care îl voi trata mai detaliat mai târziu.

Am descărcat TripMode; o aplicație pentru Mac care vă oferă control asupra aplicațiilor de pe Mac care pot accesa internetul. Accesul la internet al oricărei alte aplicații este blocat automat.

Cât de departe prezic că mă va duce bugetul meu de 50 MB? Cu greutatea medie a unei pagini web fiind de aproape 1,7 MB, asta sugerează că am în jur de 29 de pagini în buget, deși probabil câteva mai mult decât atât dacă reușesc să rămân pe aceleași site-uri și să folosesc memorarea în cache a browserului.

Pe parcursul experimentului, voi sugera sfaturi de performanță pentru a accelera prima vopsea plină de conținut și timpul de încărcare perceput al paginii. Este posibil ca unele dintre aceste sfaturi să nu afecteze cantitatea de date transferată direct , dar implică, în general, amânarea descărcării resurselor mai puțin importante, ceea ce în cazul conexiunilor lente poate însemna că resursele nu sunt descărcate niciodată și datele sunt salvate.

Experimentul

Fără nicio altă prelungire, am încărcat google.com, folosind 402 KB din bugetul meu și cheltuind 0,03 USD (aproximativ 1% din bugetul meu din Zimbabwe).

Una peste alta, nu o dimensiune proastă a paginii, dar m-am întrebat de unde provin acele 24 de solicitări de rețea și dacă pagina ar putea fi mai ușoară sau nu.

Pagina de pornire Google — DOM

Privind marcajul paginii, nu există foi de stil externe - toate CSS-urile sunt inline.

Sfat de performanță #1: CSS critic inline

Acest lucru este bun pentru performanță, deoarece economisește browserul să facă o cerere suplimentară de rețea pentru a prelua o foaie de stil externă, astfel încât stilurile pot fi analizate și aplicate imediat pentru prima vopsea cu conținut. Există un compromis de făcut aici, deoarece foile de stil externe pot fi stocate în cache, dar cele inline nu (cu excepția cazului în care devii inteligent cu JavaScript).

Sfatul general este ca stilurile tale critice (orice lucru deasupra pliului) să fie în linie, iar restul stilului tău să fie extern și încărcat asincron. Încărcarea asincronă a CSS poate fi realizată într-o linie de HTML remarcabil de inteligentă:

 <link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

Devtools arată o versiune înfrumusețată a DOM. Dacă doriți să vedeți ce a fost descărcat efectiv în browser, comutați la fila Surse și găsiți documentul.

Puteți vedea că există o mulțime de JavaScript inline aici. Este demn de remarcat faptul că a fost mai degrabă urâtă decât pur și simplu miniată.

Sfatul de performanță nr. 2: reduceți și urâțiți-vă activele

Minimizarea elimină spațiile și caracterele inutile, dar urârea de fapt „scurcă” codul. Semnul indicativ este că codul conține nume de variabile scurte, generate de mașină, mai degrabă decât cod sursă neatins. Acest lucru este bun, deoarece înseamnă că scriptul este mai mic și mai rapid de descărcat.

Chiar și așa, scripturile inline par să fie aproximativ 120 KB din resursa paginii de 210 KB (aproximativ jumătate din dimensiunea gzipped de 60 KB). În plus, există cinci fișiere JavaScript externe în valoare de 291 KB din cei 402 KB descărcați:

Aceasta înseamnă că JavaScript reprezintă aproximativ 80% din greutatea totală a paginii.

Acesta nu este JavaScript inutil; Google trebuie să aibă unele pentru a afișa sugestii pe măsură ce tastați. Dar bănuiesc că o mare parte este codul de urmărire și configurarea publicității.

Pentru comparație, am dezactivat JavaScript și am reîncărcat pagina:

Versiunea JS dezactivată a căutării Google are doar 102 KB, spre deosebire de 402 KB. Deși Google nu poate oferi autosugestii în aceste condiții, site-ul este încă funcțional și tocmai mi-am redus utilizarea datelor la un sfert din ceea ce era. Dacă chiar ar fi trebuit să-mi limitez utilizarea datelor pe termen lung, unul dintre primele lucruri pe care le-aș face este să dezactivez JavaScript. Nu este atât de rău pe cât pare.

Sfatul de performanță #3: Mai puțin este mai mult

Introducerea, urârea și minimizarea activelor sunt toate bune și bune, dar cea mai bună performanță vine din faptul că nu trimiteți în jos activele în primul rând.

• Înainte de a adăuga funcții noi, aveți un buget de performanță stabilit?
• Înainte de a adăuga JavaScript pe site-ul dvs., funcția dvs. poate fi realizată folosind HTML simplu? (De exemplu, validarea formularului HTML5).
• Înainte de a introduce o bibliotecă JavaScript sau CSS mare în aplicația dvs., utilizați ceva de genul bundlephobia.com pentru a măsura cât de mare este. Comoditatea merită greutatea? Puteți realiza același lucru folosind cod vanilla la o dimensiune mult mai mică a datelor?

Analizarea informațiilor despre resurse

Sunt multe de despachetat aici, așa că haideți. Am doar 50 MB cu care să mă joc, așa că voi mulge fiecare din încărcarea acestei pagini. Pregătește-te pentru un scurt tutorial Chrome Devtools.

402 KB transferați, dar 1,1 MB de resurse: ce înseamnă asta de fapt?

Înseamnă că 402 KB de conținut au fost de fapt descărcați, dar în forma sa comprimată (folosind un algoritm de compresie, cum ar fi gzip sau brotli). Browserul a trebuit apoi să lucreze pentru a-l despacheta în ceva semnificativ. Dimensiunea totală a datelor despachetate este de 1,1 MB.

Această despachetare nu este gratuită - există câteva milisecunde de suprasarcină în decomprimarea resurselor. Dar aceasta este o suprasolicitare neglijabilă în comparație cu trimiterea a 1,1 MB pe fir.

Sfat de performanță #4: Comprimați elementele bazate pe text

Ca regulă generală, comprimați-vă întotdeauna activele, folosind ceva de genul gzip. Dar nu utilizați compresia pe imagini și alte fișiere binare - ar trebui să le optimizați în avans la sursă. Compresia ar putea ajunge să le facă mai mari.

Și, dacă puteți, evitați comprimarea fișierelor care au 1500 de octeți sau mai mici. Cea mai mică dimensiune a pachetului TCP este de 1500 de octeți, așa că prin comprimarea la, să zicem, 800 de octeți, nu economisiți nimic, deoarece este încă transmis în același pachet de octeți. Din nou, costul este neglijabil, dar pierde timp CPU de compresie pe server și timp CPU de decompresie pe client.

Acum reveniți la fila Rețea din Chrome: să cercetăm acele priorități. Observați că resursele au prioritate „Cel mai mare” la „Cel mai mic” - acestea sunt cea mai bună presupunere a browserului cu privire la care sunt resursele mai importante de descărcat. Cu cât prioritatea este mai mare, cu atât browserul va încerca mai devreme să descarce materialul.

Sfat de performanță #5: Oferiți sugestii de resurse browserului

Browserul va ghici care sunt elementele cu cea mai mare prioritate, dar puteți oferi un indiciu de resursă folosind eticheta <link rel="preload"> , indicând browserului să descarce materialul cât mai curând posibil. Este o idee bună să preîncărcați fonturi, logo-uri și orice altceva care apare deasupra pliului.

Să vorbim despre stocarea în cache. O să țin apăsat ALT și să dau clic dreapta pentru a-mi schimba antetele coloanelor pentru a debloca informații mai suculente. Vom verifica Cache-Control.

Cache-Control indică dacă o resursă poate fi sau nu stocată în cache, cât timp poate fi stocată în cache și ce reguli ar trebui să urmeze în jurul revalidării. Setarea unor valori cache adecvate este crucială pentru a menține scăzut costul datelor pentru vizite repetate.

Sfat de performanță #6: Setați anteturile de control cache pe toate activele care pot fi stocate în cache

Rețineți că valoarea cache-control începe cu o directivă public sau private , urmată de o valoare de expirare (de exemplu max-age=31536000 ). Ce înseamnă directiva și de ce este ciudat de specifică valoarea max-age ?

Valoarea 31536000 este numărul de secunde pe care există într-un an și este valoarea maximă teoretică permisă de specificația cache-control. Este obișnuit să vedeți această valoare aplicată tuturor activelor statice și înseamnă efectiv „această resursă nu se va schimba”. În practică, niciun browser nu va păstra în cache un an întreg, dar va stoca în cache activul atât timp cât are sens.

Pentru a explica directiva public/privat, trebuie să explicăm cele două cache principale care există în afara serverului. În primul rând, există cache-ul tradițional al browserului, unde resursa este stocată pe computerul utilizatorului („clientul”). Și apoi există memoria cache CDN, care se află între client și server; resursele sunt stocate în cache la nivel CDN pentru a preveni CDN-ul să solicite resursa de la serverul de origine din nou și din nou.

O directivă Cache-Control de public permite ca resursa să fie stocată în cache atât în ​​client, cât și în CDN. O valoare de private înseamnă că numai clientul o poate stoca în cache; CDN-ul nu trebuie. Această ultimă valoare este utilizată de obicei pentru paginile sau activele care există în spatele autentificării, unde este bine să fie stocate în cache pe client, dar nu am dori să scurgem informații private prin memorarea lor în cache în CDN-ul și livrarea altor utilizatori.

Un lucru care mi-a atras atenția a fost că sigla Google are un control cache de „privat”. Alte imagini de pe pagină au un cache public și nu știu de ce logo-ul ar fi tratat diferit. Dacă aveți idei, spuneți-mi în comentarii!

Am reîmprospătat pagina și majoritatea resurselor au fost servite din cache, în afară de pagina în sine, care, după cum ați văzut deja, este private, max-age=0 , ceea ce înseamnă că nu poate fi stocată în cache. Acest lucru este normal pentru paginile web dinamice, unde este important ca utilizatorul să primească întotdeauna cea mai recentă pagină când se reîmprospătează.

În acest moment, am făcut clic din greșeală pe o adresă URL „Explicație” din devtools, ceea ce m-a dus la referința de analiză a rețelei, costând aproximativ 5 MB din bugetul meu. Hopa!

Google Dev Docs

4,2 MB din această nouă pagină de 5 MB au fost doar imagini; în special SVG-uri. Cel mai greu dintre acestea a fost de 186 KB, ceea ce nu este deosebit de mare - au fost atât de multe și toate au fost descărcate simultan.

Acea încărcare a paginii de 5 MB a reprezentat 10% din bugetul meu de astăzi. Până acum am folosit 5,5 MB, inclusiv reîncărcarea fără JavaScript a paginii de pornire Google și am cheltuit 0,40 USD. Nici nu am vrut să deschid această pagină.

Care ar fi fost o experiență de utilizator mai bună aici?

Sfat de performanță #7: Încărcați-vă imaginile leneș

De obicei, dacă făceam clic accidental pe un link, apăsam butonul Înapoi din browser. Nu aș fi primit niciun beneficiu din descărcarea acelor imagini — ce pierdere de 4,2 MB!

În afară de videoclipuri, în care știi în general în ce te bagi, imaginile sunt de departe cel mai mare vinovat al utilizării datelor pe web. Un studiu al celor mai bune 500 de site-uri web din lume a constatat că imaginile ocupă până la 53% din greutatea medie a paginii. „Aceasta înseamnă că au un impact mare asupra timpilor de încărcare a paginii și, ulterior, asupra performanței generale”.

În loc să descărcați toate imaginile la încărcarea paginii, este o practică bună să încărcați leneș imaginile, astfel încât numai utilizatorii care sunt implicați cu pagina să plătească costul descărcării acestora. Utilizatorii care aleg să nu defileze sub pliul, prin urmare, nu irosesc nicio lățime de bandă inutilă descarcând imagini pe care nu le vor vedea niciodată.

Există un ghid excelent css-tricks.com pentru lansarea încărcării lene pentru imagini, care oferă un echilibru bun între cele cu conexiuni bune, cele cu conexiuni slabe și cele cu JavaScript dezactivat.

Dacă această pagină ar fi implementat încărcare leneră conform ghidului de mai sus, fiecare dintre cele 38 de SVG-uri ar fi fost reprezentat implicit de o imagine substituent de 1 KB și ar fi fost încărcat în vizualizare numai pe defilare.

Sfat de performanță #8: Utilizați formatul potrivit pentru imaginile dvs

Am crezut că Google a ratat un truc prin faptul că nu folosește WebP, care este un format de imagine cu 26% mai mic ca dimensiune în comparație cu PNG-urile (fără pierderi de calitate) și cu 25-34% mai mic ca dimensiune în comparație cu JPEG-urile (și de un calitate comparabilă). M-am gândit că voi încerca să convertesc SVG în WebP.

Convertirea în WebP a redus unul dintre SVG-uri de la 186 KB la doar 65 KB, dar, de fapt, privind imaginile una lângă alta, WebP-ul a ieșit granulat:

Apoi am încercat să convertesc unul dintre PNG-uri în WebP, care ar trebui să fie fără pierderi și ar trebui să iasă mai mic. Cu toate acestea, ieșirea WebP a fost *mai grea* (127 KB, de la 109 KB)!

Acest lucru m-a surprins. WebP nu este neapărat glonțul de argint pe care îl credem că este și chiar și Google a neglijat să-l folosească pe această pagină.

Așa că sfatul meu ar fi: acolo unde este posibil, experimentați cu diferite formate de imagine pe fiecare imagine. Formatul care păstrează cea mai bună calitate pentru cea mai mică dimensiune poate să nu fie cel la care vă așteptați.

Acum înapoi la DOM. Am dat peste asta:

Observați cuvântul cheie async din scriptul Google Analytics?

În ciuda faptului că a fost unul dintre primele lucruri din capul documentului, acesta a primit o prioritate scăzută, deoarece am optat în mod explicit să nu fie o solicitare de blocare prin utilizarea cuvântului cheie async .

O solicitare de blocare este cea care oprește redarea paginii. Un apel <script> se blochează în mod implicit, oprind analizarea HTML-ului până când scriptul este descărcat, compilat și executat. Acesta este motivul pentru care în mod tradițional punem apeluri <script> la sfârșitul documentului.

Sfat de performanță #9: Evitați să scrieți apeluri de blocare script

Adăugând atributul async la eticheta noastră <script> , îi spunem browserului să nu oprească redarea paginii, ci să descarce scriptul în fundal. Dacă HTML-ul este încă analizat până la descărcarea scriptului, analizarea este întreruptă în timp ce scriptul este executat și apoi reluată. Acest lucru este semnificativ mai bun decât blocarea redării de îndată ce este întâlnit <script> .

Există, de asemenea, un atribut defer , care este subtil diferit. <script defer> îi spune browserului să redea pagina în timp ce scriptul se încarcă în fundal și, chiar dacă HTML-ul este încă analizat până la descărcarea scriptului, scriptul trebuie să aștepte până când pagina este redată înainte de a putea fi executată. . Acest lucru face ca scriptul să fie complet neblocant. Citiți „Încărcați eficient JavaScript cu amânare și asincron” pentru mai multe informații.

Oricum, destulă disecție Google. Este timpul să încerci un alt site. Mai am aproape 45 MB din buget!

Amazon

Pagina de pornire Amazon sa încărcat cu o greutate totală de aproximativ 6 MB. Una dintre acestea a fost o imagine de 587 KB pe care nici măcar nu am putut-o găsi pe pagină. Acesta a fost un PNG, probabil pentru a avea text clar, dar pe un fundal fotografic - o combinație clasică care este teribilă pentru performanță.

De fapt, în fila mea de rețea erau câteva imagini de câteva sute de kilobyți pe care nu le puteam vedea de fapt pe pagină. Bănuiesc o configurare greșită undeva pe Amazon, dar aceste imagini invizibile combinate au mestecat cel puțin 1 MB din datele mele.

Ce zici de imaginea eroului? Este imaginea principală de pe pagină și are doar 94 KB transferați - dar ar putea fi redusă în dimensiune cu aproximativ 15% dacă ar fi decupată direct în jurul textului și al fotbaliștilor. Apoi am putea aplica aceeași culoare de fundal în CSS ca și în imagine. Acest lucru are avantajul suplimentar de a fi redimensionabil până la ecrane mai mici, păstrând în același timp lizibilitatea textului.

Am spus-o o dată și o voi spune din nou: optimizarea și încărcarea leneșă a imaginilor este cel mai mare beneficiu pe care îl puteți aduce ponderii paginii site-ului dvs. .

Optimizarea imaginilor a oferit, de departe, cea mai semnificativă reducere a datelor. Puteți face ca JavaScript este o afacere mai mare pentru performanța generală, dar nu pentru reducerea datelor. Optimizarea sau eliminarea imaginilor este cea mai sigură modalitate de a asigura o experiență mult mai ușoară și aceasta este optimizarea principală pe care se bazează Data Saver.
— Tim Kadlec, Making Sense of Chrome Lite Pages

Pentru a fi corect față de Amazon, dacă redimensionez browserul la o dimensiune mobilă și reîmprospătez pagina, site-ul este optimizat pentru mobil și greutatea totală a paginii este de doar 2,1 MB.

Dar asta mă duce la următorul meu punct...

Sfat de performanță #10: Nu faceți presupuneri despre conexiunile de date

Este dificil de detectat dacă cineva de pe un desktop are o conexiune în bandă largă sau se conectează printr-un cheie sau un dispozitiv mobil cu date limitate. Mulți oameni lucrează așa în tren sau locuiesc într-o zonă în care infrastructura de bandă largă este slabă, dar semnalul mobil este puternic. În cazul Amazon, există loc pentru a face unele economii mari de date pe site-ul desktop și nu ar trebui să ne mulțumim doar pentru că dimensiunea ecranului sugerează că nu sunt pe un dispozitiv mobil.

Da, ar trebui să ne așteptăm la o încărcare mai mare a paginii dacă fereastra noastră este „dimensiunea desktopului”, deoarece imaginile vor fi mai mari și vor fi mai bine optimizate pentru ecran decât unul mobil mai granulat. Dar pagina nu ar trebui să fie cu ordine de mărime mai mare.

Mai mult, trimiteam antetul Save-Data împreună cu solicitarea mea. Acest antet indică în mod explicit o preferință pentru utilizarea redusă a datelor și sper că mai multe site-uri web încep să ia în considerare acest lucru în viitor.

Încărcarea inițială a „desktop” poate fi de 6 MB, dar după ce am stat și l-am urmărit un minut, a urcat la 8,6 MB, pe măsură ce resursele cu prioritate inferioară și urmărirea evenimentelor au intrat în acțiune. Greutatea acestei pagini include aproape 1,7 MB de JavaScript redus. Nici nu vreau să încep să mă uit la asta.

Sfat de performanță #11: Utilizați lucrători web pentru JavaScript

Ce ar fi mai rău – 1,7 MB de JavaScript sau 1,7 MB de imagini? Răspunsul este JavaScript: cele două active nu sunt echivalente când vine vorba de performanță.

O imagine JPEG trebuie decodificată, rasterizată și pictată pe ecran. Un pachet JavaScript trebuie să fie descărcat și apoi analizat, compilat, executat - și există o serie de alți pași pe care un motor trebuie să-i parcurgă. Rețineți că aceste costuri nu sunt chiar echivalente.
— Addy Osmani, Costul JavaScript în 2018

Dacă trebuie să expediați atât de mult JavaScript, încercați să îl introduceți într-un web worker. Acest lucru împiedică cea mai mare parte a JavaScript-ului din firul principal, care este acum eliberat pentru revopsirea interfeței de utilizare, ajutând pagina dvs. web să rămână receptivă pe dispozitivele cu putere redusă.

Acum am aproximativ 15,5 MB în buget și am cheltuit 1,14 USD din bugetul meu de date din Zimbabwe. Ar fi trebuit să fi lucrat jumătate de zi ca profesor ca să câștig banii ca să ajung până aici.

Pinterest

Am auzit lucruri bune despre performanțele lui Pinterest, așa că am decis să o pun la încercare.

Poate că acesta nu este cel mai corect dintre teste; Am fost dus la pagina de conectare, după care un proces asincron a constatat că sunt conectat la Facebook și m-am conectat automat. Pagina s-a încărcat relativ repede, dar cererile s-au strecurat pe măsură ce tot mai mult conținut a fost preîncărcat.

Cu toate acestea, am văzut că la încărcările ulterioare ale paginii, lucrătorul de serviciu a scos la suprafață o mare parte din conținut - economisind aproximativ jumătate din greutatea paginii:

Site-ul Pinterest este o aplicație web progresivă; a instalat un service worker pentru a gestiona manual stocarea în cache a CSS și JS. Aș putea acum să-mi dezactivez WiFi-ul și să continui să folosesc site-ul (deși nu foarte util):

Sfat de performanță #12: Folosiți lucrătorii de servicii pentru a oferi asistență offline

Nu ar fi grozav dacă ar trebui să încarc un site doar o dată prin rețea și acum să obțin toate informațiile de care am nevoie, chiar dacă sunt offline?

Un exemplu grozav ar fi un site web care arată prognoza meteo pentru săptămână. Ar trebui să descarc pagina respectivă o singură dată. Dacă îmi opresc datele mobile și, ulterior, mă întorc la pagină la un moment dat, ar trebui să-mi poată difuza ultimul conținut cunoscut. Dacă mă conectez din nou la internet și încarc pagina, aș primi o prognoză mai actualizată, dar activele statice, cum ar fi CSS și imaginile, ar trebui să fie difuzate în continuare local de la lucrătorul de service.

Acest lucru este posibil prin configurarea unui service worker cu o strategie bună de stocare în cache, astfel încât paginile stocate în cache să poată fi reaccesate offline. Site-ul web de documentație lodash este un exemplu frumos de lucrător de service în sălbăticie:

Conținutul care se actualizează rar și este probabil să fie folosit destul de regulat este un candidat perfect pentru tratamentul lucrătorilor de servicii. Site-urile dinamice cu fluxuri de știri în continuă schimbare nu sunt prea potrivite pentru experiențele offline, dar pot beneficia în continuare.

Lucrătorii de servicii pot salva cu adevărat ziua când aveți un buget restrâns de date. Nu sunt convins că experiența Pinterest a fost cea mai optimă în ceea ce privește utilizarea datelor – paginile ulterioare erau în jurul valorii de 0,5 MB chiar și în paginile cu puține imagini – dar lăsând JavaScript să se ocupe de solicitările de pagini pentru tine și păstrând aceleași elemente de navigare în loc. poate fi foarte performant. BBC gestionează o dimensiune de transfer de doar 3,1 KB pentru vizitele de întoarcere la articolele care pot fi redate prin intermediul aplicației cu o singură pagină.

Până acum, doar Pinterest a explodat 14 MB, ceea ce înseamnă că am explodat în jur de 30 MB din bugetul meu sau 2,20 USD (salariul de aproape o zi) din bugetul meu din Zimbabwe.

Ar fi bine să fiu atent cu ultimii 20 MB... dar unde este distracția în asta?

Gamespot

L-am ales pe acesta pentru că în trecut se simțea vizibil lent pe mobil și am vrut să aflu motivele pentru care. Destul de sigur, încărcarea paginii de pornire consumă 8,5 MB de date.

6,5 MB din acesta s-au datorat unui videoclip cu redare automată la jumătatea paginii, care – pentru a fi corect – nu părea să se descarce până când am început să derulez. Cu toate acestea…

Am putut vedea doar jumătate din videoclip în fereastra mea de vizualizare - partea dreaptă a fost tăiată. A durat, de asemenea, 30 de secunde și aș paria că majoritatea oamenilor nu vor sta să se uite la tot. Acest singur material a triplat dimensiunea paginii.

Sfat de performanță #13: Nu preîncărcați videoclipul

De regulă, cu excepția cazului în care modul principal de comunicare al site-ului dvs. este video, nu îl preîncărcați.

Dacă sunteți YouTube sau Netflix, este rezonabil să presupunem că cineva care vine pe pagina dvs. va dori ca videoclipul să se încarce automat și să fie redat automat. Există o așteptare ca videoclipul să ruteze unele date, dar că este un schimb echitabil pentru conținut. Dar dacă sunteți un site al cărui mediu principal este textul și imaginea - și pur și simplu oferiți conținut video suplimentar - atunci nu preîncărcați videoclipul.

Gândiți-vă la articolele de știri cu videoclipuri încorporate. Mulți utilizatori doresc doar să treacă peste titlul articolului înainte de a trece la următorul lucru. Alții vor citi articolul, dar vor ignora orice încorporare. Și alții vor face clic cu sârguință și vor viziona fiecare videoclip încorporat. Nu ar trebui să strângem lățimea de bandă a fiecărui utilizator presupunând că vor dori să vizioneze aceste videoclipuri.

Pentru a reitera: utilizatorilor nu le place redarea automată a videoclipurilor. În calitate de dezvoltatori, o facem doar pentru că managerii noștri ne spun și ei ne spun să o facem doar pentru că toate cele mai tari aplicații o fac, iar cele mai tari aplicații o fac doar pentru că reclamele video generează de 20 până la 50 de ori mai multe venituri decât cele tradiționale. reclame. Google Chrome a început să blocheze redarea automată a videoclipurilor pentru unele site-uri, pe baza preferințelor personale, așa că, chiar dacă vă dezvoltați site-ul pentru redarea automată a videoclipurilor, nu există nicio garanție că este experiența pe care o primesc utilizatorii dvs.

Dacă suntem de acord că este o idee bună să facem din videoclip o experiență de înscriere (dați clic pentru a reda), putem face un pas mai departe și îl putem face să facem clic pentru a încărca. Aceasta înseamnă să batjocorești o imagine de substituent video cu un buton de redare deasupra ei și să descarci videoclipul numai când dai clic pe butonul de redare. People on fast connections should notice no difference in buffer speed, and people on slow connections will appreciate how fast the rest of your site loaded because it didn't have to preload a large video file.

Anyway, back to Gamespot, where I was indeed forced to preload a large video file I ended up not watching. I then clicked through to a game review page that weighed another 8.5 MB, this time with 5.4 MB of video, before I even started scrolling down the page.

What was really galling was when I looked at what the video actually was. It was an advert for a Samsung TV! This advert cost me $0.40 of my Zimbabwe wages. Not only was it pre-loaded, but it also didn't end up playing anywhere as far as I'm aware, so I never actually saw it.

The 'real' video — the gameplay footage (in other words, the content) — wasn't actually loaded until I clicked on it. And that ploughed through my remaining data in seconds.

That's it. That's my 50 MB gone. I'll need to work another 1.5 days as a Zimbabwean schoolteacher to repeat the experience.

Performance Tip #14: Optimize For First Page Load

What's striking is that I used 50 MB of data and in most cases, I only visited one or two pages on any given site. If you think about it, this is true of most user journeys today.

Think about the last time you Googled something. You no doubt clicked on the first search result. If you got your answer, you closed the tab, or else you hit the back button and moved onto the next search result.

With the exception of a few so-called 'destination sites' such as Facebook or YouTube, where users habitually go as a starting point for other activities, the majority of user journeys are ephemeral. We stumble across random sites to get the answers to our questions, never to return to those sites again.

Web development practices are heavily skewed towards optimising for repeat visitors. “Cache these assets — they'll come in handy later”. “Pre-load this onward journey, in case the user clicks to read more”. “Subscribe to our mailing list”.

Instead, I believe we should optimize heavily for one-off visitors. Call it a controversial opinion, but maybe caching isn't really all that important. How important can a cached resource that never gets surfaced again be ? And perhaps users aren't actually going to subscribe to your mailing list after reading just the one article, so downloading the JavaScript and CSS for the mail subscription modal is both a waste of data and an annoying user experience.

The Decline Of Proxy Browsers

I had hoped to try out Opera Mini as part of this experiment. Opera Mini is a mobile web browser which proxies web pages through Opera's compression servers. It accounts for 1.42% of global traffic as of June 2019, according to caniuse.com.

Opera Mini claims to save up to 90% of data by doing some pretty intensive transcoding. HTML is parsed, images are compressed, styling is applied, and a certain amount of JavaScript is executed on Opera's servers. The server doesn't respond with HTML as you might expect — it actually transcodes the data into Opera Binary Markup Language (OBML), which is progressively loaded by Opera Mini on the device. It renders what is essentially an interactive 'snapshot' of the web page — think of it as a PDF with hyperlinks inside it. Read Tiffany Brown's excellent article, “Opera Mini and JavaScript” for a technical deep-dive.

It would have been a perfect way to eek my 50 MB budget as far as possible. Unfortunately, Opera Mini is no longer available on iOS in the UK. Attempting to visit it in the app store throws an error:

It's still available “in some markets” but reading between the lines, Opera will be phasing out Opera Mini for its new app — Opera Touch — which doesn't have any data-saving functionality apart from the ability to natively block ads.

Opera desktop used to have a 'Turbo mode', acting as a traditional proxy server (returning a HTML document instead of OBML), applying data-saving techniques but less intensively than Opera Mini. According to Opera, JavaScript continues to work and “you get all the videos, photos and text that you normally would, but you eat up less data and load pages faster”. However, Opera quietly removed Turbo mode in v60 earlier this year, and Opera Touch doesn't have a Turbo mode either. Turbo mode is currently only available on Opera for Android.

Android is where all the action is in terms of data-saving technology. Chrome offers a 'Lite mode' on its mobile browser for Android, which is not available for iPhones or iPads because of “platform constraints“. Outside of mobile, Google used to provide a 'Data Saver' extension for Chrome desktop, but this was canned in April.

Lite mode for Chrome Android can be forcibly enabled, or automatically kicks in when the network's effective connection type is 2G or worse, or when Chrome estimates the page will take more than 5 seconds to reach first contentful paint. Under these conditions, Chrome will request the lite version of the HTTPS URL as cached by Google's servers, and display this stripped-down version inside the user's browser, alongside a “Lite” marker in the address bar.

I'd love to try it out — apparently it disables scripts, replaces images with placeholders, prevents loading of non-critical resources and shows offline copies of pages if one is available on the device. This saves up to 60% of data. However, it isn't available in private (Incognito) mode, which hints at some of the privacy concerns surrounding proxy browsers.

Modul simplificat partajează adresa URL HTTPS cu Google, prin urmare este logic ca acest mod să nu fie disponibil în incognito. Cu toate acestea, alte informații, cum ar fi cookie-urile, informațiile de conectare și conținutul personalizat al paginii, nu sunt partajate cu Google - conform ghacks.net - și „nu întrerupe niciodată conexiunile securizate între Chrome și un site web”. Cineva se întreabă de ce se pare că niciunul dintre aceste servicii de salvare a datelor nu este permis pe iOS (și nu există știri despre dacă modul Lite va deveni vreodată disponibil pe iOS).

Proxy-urile de economisire a datelor necesită o mare încredere; activitatea ta de navigare, cookie-urile și alte informații sensibile sunt încredințate unui server, adesea în altă țară. Mulți proxy pur și simplu nu vor mai funcționa, deoarece multe site-uri au trecut la HTTPS, ceea ce înseamnă că inițiative precum modul Turbo au devenit în mare parte o „funcție inutilă”. HTTPS previne acest tip de comportament man-in-the-middle, ceea ce este un lucru bun, deși a însemnat dispariția unora dintre aceste servicii proxy și a făcut site-urile mai puțin accesibile celor cu conexiuni slabe.

Nu am reușit să găsesc niciun instrument de salvare a datelor compatibil cu OSX sau iOS, cu excepția Bandwidth Hero pentru Firefox (care necesită configurarea propriului serviciu de comprimare a datelor - cu mult peste capacitățile tehnice ale majorității utilizatorilor!) și skyZIP Proxy (care, actualizat ultima dată în 2017 și plin de greșeli de scriere, pur și simplu nu am putut să am încredere).

Concluzie

Reducerea amprentei de date a site-ului dvs. web merge mână în mână cu îmbunătățirea performanței frontend. Este cel mai fiabil lucru pe care îl puteți face pentru a vă accelera site-ul.

Pe lângă costul datelor, există o mulțime de motive întemeiate pentru a vă concentra pe performanță, așa cum este descris într-o postare de blog GOV.UK pe acest subiect:

• 53% dintre utilizatori vor abandona un site mobil dacă durează mai mult de 3 secunde pentru a se încărca.
• Oamenii trebuie să se concentreze cu 50% mai mult atunci când încearcă să finalizeze o sarcină simplă pe un site web folosind o conexiune lentă.
• Paginile web mai performante sunt mai bune pentru durata de viață a bateriei dispozitivului utilizatorului și, de obicei, necesită mai puțină energie pe server pentru a fi livrate. Un site performant este bun pentru mediu.

Nu avem puterea de a schimba costul global al inegalității datelor. Dar avem puterea de a-i reduce impactul, îmbunătățind experiența pentru toți cei aflați în proces.