Ho usato il Web per un giorno con un budget di 50 MB

Questo articolo fa parte di una serie in cui tento di utilizzare il Web con vari vincoli, rappresentando un determinato gruppo demografico di utenti. Spero di elevare il profilo delle difficoltà incontrate dalle persone reali, che sono evitabili se progettiamo e sviluppiamo in un modo che sia comprensivo ai loro bisogni.

L'ultima volta, ho navigato sul Web per un giorno utilizzando Internet Explorer 8. Questa volta, ho navigato sul Web per un giorno con un budget di 50 MB.

Perché 50 MB?

Molti di noi hanno la fortuna di utilizzare piani mobili che consentono diversi gigabyte di trasferimento di dati al mese. In caso contrario, di solito siamo in grado di connetterci a reti Wi-Fi domestiche o pubbliche che sono su connessioni a banda larga veloci e hanno dati effettivamente illimitati.

Ma ci sono parti del mondo in cui i dati mobili sono proibitivi e dove c'è poca o nessuna infrastruttura a banda larga.

Le persone spesso acquistano pacchetti di dati di appena decine di megabyte alla volta, rendendo un gigabyte una quantità di dati relativamente grande e quindi costosa da acquistare.
— Dan Howdle, analista di telecomunicazioni di consumo presso Cable.co.uk

Di quanto stiamo parlando?

Il costo dei dati mobili

Uno studio del 2018 condotto da cable.co.uk ha rilevato che lo Zimbabwe era il paese più costoso al mondo per i dati mobili, dove 1 GB costava in media $ 75,20, da $ 12,50 a $ 138,46. L'enorme fascia di prezzo è dovuta al fatto che quantità minori di dati sono molto costose, diventando proporzionalmente più economiche quanto più grande è il piano dati a cui ti impegni. Puoi leggere la metodologia di studio per ulteriori informazioni.

Lo Zimbabwe non è affatto una tantum. Seguono la Guinea Equatoriale, Sant'Elena e le Isole Falkland, con 1 GB di dati che costano rispettivamente $ 65,83, $ 55,47 e $ 47,39. Questi paesi hanno generalmente una combinazione di scarsa infrastruttura tecnica e scarsa adozione, il che significa che i dati sono costosi da fornire e non hanno l'economia di scala per ridurre i costi.

I dati sono costosi anche in alcune parti d'Europa. Un gigabyte di dati in Grecia ti costerà $ 32,71; in Svizzera, $ 20,22. Per fare un confronto, la stessa quantità di dati costa $ 6,66 nel Regno Unito o $ 12,37 negli Stati Uniti. All'altra estremità della scala, l'India è il posto più economico al mondo per i dati, con un costo medio di $ 0,26. Kirghizistan, Kazakistan e Ucraina seguono rispettivamente a $ 0,27, $ 0,49 e $ 0,51 per GB.

Anche la velocità delle reti mobili varia considerevolmente da paese a paese. Forse sorprendentemente, gli utenti sperimentano velocità più elevate su una rete mobile rispetto al Wi-Fi in almeno 30 paesi in tutto il mondo, tra cui Australia e Francia. La Corea del Sud ha la velocità di download mobile più veloce, con una media di 52,4 Mbps, ma l'Iraq ha la velocità più lenta, con una media di 1,6 Mbps in download e 0,7 Mbps in upload. Gli Stati Uniti sono al 40° posto al mondo per velocità di download da dispositivi mobili, a circa 34 Mbps, e rischiano di rimanere indietro mentre il mondo si sposta verso il 5G.

Per quanto riguarda il tipo di connessione di rete mobile, l'84,7% delle connessioni degli utenti nel Regno Unito è in 4G, rispetto al 93% negli Stati Uniti e al 97,5% in Corea del Sud. Ciò si confronta con meno del 50% in Uzbekistan e meno del 60% in Algeria, Ecuador, Nepal e Iraq.

Il costo dei dati a banda larga

Nel frattempo, uno studio sul costo della banda larga nel 2018 mostra che una connessione a banda larga in Niger costa $ 263 "per megabit al mese". Questa metrica è un po' difficile da comprendere, quindi ecco un esempio: se il costo medio dei pacchetti a banda larga in un paese è di $ 22 e la velocità media di download offerta dai pacchetti è di 10 Mbps, il costo "per megabit al mese" sarebbe essere $ 2,20.

È una metrica interessante e riconosce che la velocità della banda larga è un fattore importante quanto il limite di dati. Un costo di $ 263 suggerisce una combinazione di banda larga estremamente lenta ed estremamente costosa. Per riferimento, la metrica è $ 1,19 nel Regno Unito e $ 1,26 negli Stati Uniti.

Quello che forse è più facile da comprendere è il costo medio di un pacchetto a banda larga. Si noti che questo studio era alla ricerca dei pacchetti a banda larga più economici in offerta, ignorando se questi pacchetti avevano o meno un limite di dati, quindi fornisce un'utile cifra da campo piuttosto che il costo dei dati in sé.

Solo sul costo del pacchetto, la Mauritania ha la banda larga più costosa al mondo, con una media di $ 768,16 (una gamma da $ 307,26 a $ 1.368,72). Questo enorme costo include la costruzione di linee fisiche alla proprietà, poiché in Mauritania ne esistono già poche. A 0,7 Mbps, la Mauritania ha anche una delle reti a banda larga più lente al mondo.

Taiwan ha la banda larga più veloce al mondo, con una velocità media di 85 Mbps. Lo Yemen è il più lento, a 0,38 Mbps. Ma anche i paesi con una buona infrastruttura a banda larga consolidata hanno i cosiddetti "non-spot". Il Regno Unito è al 34° posto su 207 paesi per velocità della banda larga, ma a luglio 2019 c'era ancora una scuola nel Regno Unito senza banda larga.

Il costo medio di un pacchetto a banda larga nel Regno Unito è di $ 39,58 e negli Stati Uniti è di $ 67,69. La media più economica del mondo è quella dell'Ucraina, a soli $ 5, anche se l'offerta di banda larga più economica di tutte è stata trovata in Kirghistan ($ 1,27, contro la media del paese di $ 108,22).

Lo Zimbabwe era il paese più costoso per i dati mobili e le statistiche non sono molto migliori per la sua banda larga, con un costo medio di $ 128,71 e un costo "per megabit al mese" di $ 6,89.

Costo assoluto vs costo in termini reali

Tutti i costi descritti finora sono i costi assoluti in USD, basati sui tassi di cambio al momento dello studio. Questi costi non sono stati contabilizzati come costo della vita, il che significa che per molti paesi il costo è in realtà molto più alto in termini reali.

Limiterò la mia navigazione oggi a 50 MB, che in Zimbabwe costerebbero circa $ 3,67 con una tariffa dati mobile. Potrebbe non sembrare molto, ma gli insegnanti dello Zimbabwe quest'anno hanno scioperato perché i loro stipendi erano scesi a soli $ 2,50 al giorno.

Per fare un confronto, $ 3,67 è circa la metà del salario minimo di $ 7,25 negli Stati Uniti. Come cittadino dello Zimbabwe, dovrei lavorare per circa un giorno e mezzo per guadagnare i soldi per acquistare questi 50 MB di dati, rispetto a solo mezz'ora negli Stati Uniti. Non è facile confrontare il costo della vita tra i paesi, ma solo con i salari il costo di 3,67 dollari di 50 MB di dati in Zimbabwe sembrerebbe di 52 dollari per un americano con il salario minimo.

Impostazione dell'esperimento

Ho avviato Chrome e aperto gli strumenti di sviluppo, dove ho limitato la rete a una connessione 3G lenta. Volevo simulare una connessione lenta come quelle vissute dagli utenti in Uzbekistan, per vedere che tipo di esperienza mi darebbero i siti web. Ho anche limitato la mia CPU per simulare di essere su un dispositivo di fascia bassa.

Ho installato ModHeader e impostato l'intestazione "Salva-dati" per far sapere ai siti Web che voglio ridurre al minimo l'utilizzo dei dati. Questa è anche l'intestazione impostata da Chrome per la "modalità Lite" di Android, che tratterò più dettagliatamente in seguito.

Ho scaricato TripMode; un'applicazione per Mac che ti dà il controllo su quali app sul tuo Mac possono accedere a Internet. L'accesso a Internet di qualsiasi altra applicazione viene automaticamente bloccato.

Quanto prevedo che mi porterà il mio budget di 50 MB? Con il peso medio di una pagina Web di quasi 1,7 MB, ciò suggerisce che ho circa 29 pagine nel mio budget, anche se probabilmente un po' di più se sono in grado di rimanere sugli stessi siti e sfruttare la memorizzazione nella cache del browser.

Durante l'esperimento suggerirò suggerimenti sulle prestazioni per velocizzare la prima pittura di contenuto e il tempo di caricamento percepito della pagina. Alcuni di questi suggerimenti potrebbero non influire sulla quantità di dati trasferiti direttamente , ma in genere comportano il rinvio del download di risorse meno importanti, che su connessioni lente può significare che le risorse non vengono mai scaricate e i dati vengono salvati.

L'esperimento

Senza ulteriori indugi, ho caricato google.com, utilizzando 402 KB del mio budget e spendendo $ 0,03 (circa l'1% del mio budget per lo Zimbabwe).

Tutto sommato, non una cattiva dimensione della pagina, ma mi chiedevo da dove provenissero quelle 24 richieste di rete e se la pagina potesse essere alleggerita o meno.

Pagina iniziale di Google — DOM

Guardando il markup della pagina, non ci sono fogli di stile esterni: tutto il CSS è in linea.

Suggerimento per le prestazioni n. 1: CSS critico in linea

Questo è buono per le prestazioni in quanto evita al browser di dover fare una richiesta di rete aggiuntiva per recuperare un foglio di stile esterno, quindi gli stili possono essere analizzati e applicati immediatamente per la prima pittura di contenuto. C'è un compromesso da fare qui, poiché i fogli di stile esterni possono essere memorizzati nella cache ma quelli inline no (a meno che tu non diventi intelligente con JavaScript).

Il consiglio generale è che i tuoi stili critici (qualsiasi cosa above-the-fold) siano in linea e che il resto del tuo stile sia esterno e caricato in modo asincrono. Il caricamento asincrono di CSS può essere ottenuto in una linea di HTML straordinariamente intelligente:

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

Gli strumenti di sviluppo mostrano una versione abbellita del DOM. Se vuoi vedere cosa è stato effettivamente scaricato sul browser, passa alla scheda Sorgenti e trova il documento.

Puoi vedere che c'è MOLTO JavaScript in linea qui. Vale la pena notare che è stato sminuito piuttosto che semplicemente minimizzato.

Suggerimento per le prestazioni n. 2: riduci al minimo e brutti i tuoi beni

La minimizzazione rimuove gli spazi e i caratteri non necessari, ma l'uglificazione in realtà "distorce" il codice per renderlo più breve. Il segno rivelatore è che il codice contiene nomi di variabili brevi e generati dalla macchina piuttosto che codice sorgente intatto. Questo è positivo in quanto significa che lo script è più piccolo e più veloce da scaricare.

Anche così, gli script inline sembrano essere circa 120 KB della risorsa della pagina di 210 KB (circa la metà della dimensione gzippata di 60 KB). Inoltre, ci sono cinque file JavaScript esterni che ammontano a 291 KB dei 402 KB scaricati:

Ciò significa che JavaScript rappresenta circa l'80% del peso complessivo della pagina.

Questo non è JavaScript inutile; Google deve averne alcuni per visualizzare i suggerimenti durante la digitazione. Ma sospetto che molto sia il codice di monitoraggio e l'impostazione della pubblicità.

Per fare un confronto, ho disabilitato JavaScript e ricaricato la pagina:

La versione disabilitata di JS della ricerca di Google è di soli 102 KB, invece di 402 KB. Sebbene Google non possa fornire suggerimenti automatici in queste condizioni, il sito è ancora funzionante e ho appena ridotto l'utilizzo dei miei dati a un quarto di quello che era. Se dovessi davvero limitare l'utilizzo dei dati a lungo termine, una delle prime cose che farei è disabilitare JavaScript. Non è così male come sembra.

Suggerimento per le prestazioni n. 3: meno è meglio

Inlining, bruttezza e minimizzazione delle risorse va bene, ma la migliore prestazione deriva dal non mandare giù le risorse in primo luogo.

• Prima di aggiungere nuove funzionalità, disponi di un budget per le prestazioni?
• Prima di aggiungere JavaScript al tuo sito, la tua funzione può essere realizzata utilizzando HTML semplice? (Ad esempio, la convalida del modulo HTML5).
• Prima di inserire una grande libreria JavaScript o CSS nella tua applicazione, usa qualcosa come bundlephobia.com per misurare quanto è grande. La comodità vale il peso? Puoi ottenere la stessa cosa usando il codice vanilla con una dimensione dei dati molto più piccola?

Analizzare le informazioni sulla risorsa

C'è molto da disfare qui, quindi diamoci da fare. Ho solo 50 MB con cui giocare, quindi ho intenzione di mungere ogni bit di questa pagina caricata. Accomodati per un breve tutorial di Chrome Devtools.

402 KB trasferiti, ma 1,1 MB di risorse: cosa significa esattamente?

Significa che 402 KB di contenuto sono stati effettivamente scaricati, ma nella sua forma compressa (utilizzando un algoritmo di compressione come gzip o brotli). Il browser ha quindi dovuto fare un po' di lavoro per decomprimerlo in qualcosa di significativo. La dimensione totale dei dati decompressi è 1,1 MB.

Questo spacchettamento non è gratuito: ci sono alcuni millisecondi di sovraccarico nella decompressione delle risorse. Ma questo è un sovraccarico trascurabile rispetto all'invio di 1,1 MB lungo il cavo.

Suggerimento per le prestazioni n. 4: comprimi le risorse basate su testo

Come regola generale, comprimi sempre le tue risorse, usando qualcosa come gzip. Ma non usare la compressione sulle tue immagini e altri file binari: dovresti ottimizzarli in anticipo alla fonte. La compressione potrebbe effettivamente finire per ingrandirli.

E, se puoi, evita di comprimere file di dimensioni pari o inferiori a 1500 byte. La dimensione minima del pacchetto TCP è 1500 byte, quindi comprimendo, diciamo, a 800 byte, non si risparmia nulla, poiché viene comunque trasmesso nello stesso pacchetto di byte. Anche in questo caso, il costo è trascurabile, ma spreca un po' di tempo di compressione della CPU sul server e tempo di decompressione della CPU sul client.

Ora torniamo alla scheda Rete in Chrome: analizziamo queste priorità. Si noti che le risorse hanno priorità da "Più alto" a "Più basso": queste sono le migliori ipotesi del browser su quali sono le risorse più importanti da scaricare. Maggiore è la priorità, prima il browser tenterà di scaricare la risorsa.

Suggerimento per le prestazioni n. 5: fornire suggerimenti per le risorse al browser

Il browser indovinerà quali sono le risorse con la priorità più alta, ma puoi fornire un suggerimento sulla risorsa utilizzando il <link rel="preload"> , indicando al browser di scaricare la risorsa il prima possibile. È una buona idea precaricare font, loghi e qualsiasi altra cosa che appare above the fold.

Parliamo di memorizzazione nella cache. Tengo premuto ALT e faccio clic con il pulsante destro del mouse per modificare le intestazioni delle colonne per sbloccare alcune informazioni più succose. Daremo un'occhiata a Cache-Control.

Cache-Control indica se una risorsa può essere memorizzata nella cache o meno, per quanto tempo può essere memorizzata nella cache e quali regole dovrebbe seguire per la riconvalida. L'impostazione di valori di cache corretti è fondamentale per mantenere basso il costo dei dati delle visite ripetute.

Suggerimento per le prestazioni n. 6: imposta le intestazioni di controllo della cache su tutte le risorse memorizzabili nella cache

Si noti che il valore di controllo della cache inizia con una direttiva public o private , seguita da un valore di scadenza (ad esempio max-age=31536000 ). Cosa significa la direttiva e perché il valore max-age stranamente specifico?

Il valore 31536000 è il numero di secondi presenti in un anno ed è il valore massimo teorico consentito dalla specifica di controllo della cache. È comune vedere questo valore applicato a tutte le risorse statiche e significa effettivamente "questa risorsa non cambierà". In pratica, nessun browser memorizzerà nella cache per un anno intero, ma memorizzerà nella cache la risorsa per tutto il tempo necessario.

Per spiegare la direttiva public/private, dobbiamo spiegare le due cache principali che esistono fuori dal server. Innanzitutto, c'è la tradizionale cache del browser, in cui la risorsa è archiviata sulla macchina dell'utente (il "client"). E poi c'è la cache CDN, che si trova tra il client e il server; le risorse vengono memorizzate nella cache a livello di CDN per impedire che la CDN richieda più e più volte la risorsa dal server di origine.

Una direttiva Cache-Control di public consente alla risorsa di essere memorizzata nella cache sia nel client che nella CDN. Un valore di private significa che solo il client può memorizzarlo nella cache; la CDN non dovrebbe. Quest'ultimo valore viene in genere utilizzato per le pagine o le risorse che esistono dietro l'autenticazione, dove va bene essere memorizzato nella cache del client ma non vorremmo perdere informazioni private memorizzandole nella cache nella CDN e consegnandole ad altri utenti.

Una cosa che ha attirato la mia attenzione è che il logo di Google ha un controllo della cache di "privato". Altre immagini sulla pagina hanno una cache pubblica e non so perché il logo verrebbe trattato in modo diverso. Se avete qualche idea fatemelo sapere nei commenti!

Ho aggiornato la pagina e la maggior parte delle risorse sono state servite dalla cache, a parte la pagina stessa, che come hai già visto è private, max-age=0 , il che significa che non può essere memorizzata nella cache. Ciò è normale per le pagine Web dinamiche in cui è importante che l'utente riceva sempre la pagina più recente quando si aggiorna.

È stato a questo punto che ho accidentalmente fatto clic su un URL "Spiegazione" in devtools, che mi ha portato al riferimento dell'analisi di rete, costandomi circa 5 MB del mio budget. Ops.

Google Dev Docs

4,2 MB di questa nuova pagina da 5 MB erano ridotti alle immagini; in particolare SVG. Il più pesante di questi era 186 KB, che non è particolarmente grande: ce n'erano così tanti e sono stati scaricati tutti in una volta.

Quel caricamento della pagina di 5 MB era il 10% del mio budget per oggi. Finora ho utilizzato 5,5 MB, incluso il ricaricamento senza JavaScript della home page di Google, e ho speso $ 0,40. Non volevo nemmeno aprire questa pagina.

Quale sarebbe stata un'esperienza utente migliore qui?

Suggerimento per le prestazioni n. 7: carica pigramente le tue immagini

Di solito, se per sbaglio facevo clic su un collegamento, premevo il pulsante Indietro nel mio browser. Non avrei ricevuto alcun vantaggio dal download di quelle immagini: che spreco di 4,2 MB!

A parte i video, in cui generalmente sai in cosa ti stai cacciando, le immagini sono di gran lunga il principale colpevole dell'utilizzo dei dati sul web. Uno studio sui 500 siti Web più importanti del mondo ha rilevato che le immagini occupano fino al 53% del peso medio della pagina. "Ciò significa che hanno un grande impatto sui tempi di caricamento della pagina e, di conseguenza, sulle prestazioni complessive".

Invece di scaricare tutte le immagini al caricamento della pagina, è buona norma caricare le immagini in modo lazy in modo che solo gli utenti coinvolti nella pagina paghino il costo del download. Gli utenti che scelgono di non scorrere below the fold quindi non sprecano larghezza di banda non necessaria scaricando immagini che non vedranno mai.

C'è un'ottima guida css-tricks.com per implementare il caricamento lento per le immagini che offre un buon equilibrio tra quelle con buone connessioni, quelle con connessioni scadenti e quelle con JavaScript disabilitato.

Se questa pagina avesse implementato il caricamento lento secondo la guida sopra, ciascuno dei 38 SVG sarebbe stato rappresentato da un'immagine segnaposto da 1 KB per impostazione predefinita e caricato solo in vista durante lo scorrimento.

Suggerimento per le prestazioni n. 8: usa il formato giusto per le tue immagini

Pensavo che Google si fosse perso un trucco non usando WebP, che è un formato immagine più piccolo del 26% rispetto ai PNG (senza perdita di qualità) e del 25-34% più piccolo rispetto ai JPEG (e di un qualità comparabile). Ho pensato di provare a convertire SVG in WebP.

La conversione in WebP ha ridotto uno degli SVG da 186 KB a soli 65 KB, ma in realtà, guardando le immagini fianco a fianco, WebP è risultato granuloso:

Ho quindi provato a convertire uno dei PNG in WebP, che dovrebbe essere senza perdite e dovrebbe risultare più piccolo. Tuttavia, l'output WebP era *più pesante* (127 KB, da 109 KB)!

Questo mi ha sorpreso. WebP non è necessariamente il proiettile d'argento che pensiamo che sia, e persino Google ha trascurato di usarlo in questa pagina.

Quindi il mio consiglio sarebbe: ove possibile, sperimenta diversi formati di immagine in base all'immagine. Il formato che mantiene la migliore qualità per il formato più piccolo potrebbe non essere quello che ti aspetti.

Ora torniamo al DOM. mi sono imbattuto in questo:

Notare la parola chiave async nello script di analisi di Google?

Nonostante fosse una delle prime cose nell'intestazione del documento, a questa è stata assegnata una priorità bassa, poiché abbiamo esplicitamente scelto di non essere una richiesta di blocco utilizzando la parola chiave async .

Una richiesta di blocco è quella che interrompe il rendering della pagina. Una chiamata <script> si blocca per impostazione predefinita, interrompendo l'analisi dell'HTML fino a quando lo script non è stato scaricato, compilato ed eseguito. Questo è il motivo per cui tradizionalmente mettiamo chiamate <script> alla fine del documento.

Suggerimento per le prestazioni n. 9: evitare di scrivere chiamate di script di blocco

Aggiungendo l'attributo async al nostro tag <script> , stiamo dicendo al browser di non interrompere il rendering della pagina ma di scaricare lo script in background. Se l'HTML è ancora in fase di analisi al momento del download dello script, l'analisi viene sospesa durante l'esecuzione dello script e quindi ripresa. Questo è significativamente meglio che bloccare il rendering non appena si incontra <script> .

C'è anche un attributo di defer , che è leggermente diverso. <script defer> dice al browser di eseguire il rendering della pagina mentre lo script viene caricato in background, e anche se l'HTML è ancora in fase di analisi quando lo script viene scaricato, lo script deve attendere il rendering della pagina prima di poter essere eseguito . Questo rende lo script completamente non bloccante. Leggi "Carica in modo efficiente JavaScript con differimento e asincrono" per ulteriori informazioni.

Comunque, abbastanza dissezione su Google. È ora di provare un altro sito. Ho ancora quasi 45 MB del mio budget rimasti!

Amazon

La home page di Amazon è stata caricata con un peso totale di circa 6 MB. Uno di questi era un'immagine da 587 KB che non riuscivo nemmeno a trovare sulla pagina. Questo era un PNG, presumibilmente per avere un testo nitido, ma su uno sfondo fotografico: una combinazione classica che è terribile per le prestazioni.

In effetti, c'erano alcune immagini di diverse centinaia di kilobyte nella mia scheda di rete che non potevo effettivamente vedere sulla pagina. Sospetto un'errata configurazione da qualche parte su Amazon, ma queste immagini invisibili combinate hanno masticato almeno 1 MB dei miei dati.

Che ne dici dell'immagine dell'eroe? È l'immagine principale sulla pagina e sono trasferiti solo 94 KB, ma potrebbe essere ridotta di circa il 15% se fosse ritagliata direttamente attorno al testo e ai calciatori. Potremmo quindi applicare lo stesso colore di sfondo in CSS come nell'immagine. Questo ha l'ulteriore vantaggio di essere ridimensionabile fino a schermi più piccoli, pur mantenendo la leggibilità del testo.

L'ho detto una volta e lo ripeto: l' ottimizzazione e il caricamento lento delle immagini è il più grande vantaggio che puoi apportare al peso della pagina del tuo sito .

L'ottimizzazione delle immagini ha fornito, di gran lunga, la riduzione dei dati più significativa. Puoi fare in modo che JavaScript sia un affare maggiore per le prestazioni complessive, ma non per la riduzione dei dati. L'ottimizzazione o la rimozione delle immagini è il modo più sicuro per garantire un'esperienza molto più leggera e questa è l'ottimizzazione principale su cui si basa Data Saver.
— Tim Kadlec, Dare un senso alle pagine di Chrome Lite

Per essere onesti con Amazon, se ridimensiono il browser a una dimensione mobile e aggiorno la pagina, il sito è ottimizzato per dispositivi mobili e il peso totale della pagina è di soli 2,1 MB.

Ma questo mi porta al punto successivo...

Suggerimento per le prestazioni n. 10: non fare supposizioni sulle connessioni dati

È difficile rilevare se qualcuno su un desktop è connesso a una connessione a banda larga o sta effettuando il tethering tramite un dongle o un dispositivo mobile con dati limitati. Molte persone lavorano sul treno in questo modo o vivono in una zona in cui l'infrastruttura della banda larga è scarsa ma il segnale mobile è forte. Nel caso di Amazon, c'è spazio per risparmiare grandi quantità di dati sul sito desktop e non dovremmo accontentarci solo perché le dimensioni dello schermo suggeriscono che non sono su un dispositivo mobile.

Sì, dovremmo aspettarci un caricamento della pagina maggiore se il nostro viewport è "di dimensioni desktop", poiché le immagini saranno più grandi e ottimizzate per lo schermo rispetto a quelle mobili più sgranate. Ma la pagina non dovrebbe essere di ordini di grandezza più grande.

Inoltre, stavo inviando l'intestazione Save-Data con la mia richiesta. Questa intestazione indica esplicitamente una preferenza per un utilizzo ridotto dei dati e spero che più siti Web inizino a prenderne atto in futuro.

Il carico iniziale del "desktop" potrebbe essere stato di 6 MB, ma dopo averlo osservato per un minuto è salito a 8,6 MB quando le risorse a priorità inferiore e il monitoraggio degli eventi sono entrati in azione. Il peso di questa pagina include quasi 1,7 MB di JavaScript ridotto. Non voglio nemmeno cominciare a guardarlo.

Suggerimento per le prestazioni n. 11: utilizza i Web worker per JavaScript

Quale sarebbe peggio: 1,7 MB di JavaScript o 1,7 MB di immagini? La risposta è JavaScript: le due risorse non sono equivalenti quando si tratta di prestazioni.

Un'immagine JPEG deve essere decodificata, rasterizzata e dipinta sullo schermo. Un bundle JavaScript deve essere scaricato e quindi analizzato, compilato, eseguito e ci sono una serie di altri passaggi che un motore deve completare. Tieni presente che questi costi non sono del tutto equivalenti.
— Addy Osmani, Il costo di JavaScript nel 2018

Se devi spedire così tanto JavaScript, prova a inserirlo in un web worker. Ciò mantiene la maggior parte di JavaScript fuori dal thread principale, che ora è liberato per ridisegnare l'interfaccia utente, aiutando la tua pagina web a rimanere reattiva su dispositivi a bassa potenza.

Ora ho circa 15,5 MB nel mio budget e ho speso $ 1,14 del mio budget per i dati dello Zimbabwe. Avrei dovuto lavorare mezza giornata come insegnante per guadagnare i soldi per arrivare fin qui.

Pinterest

Ho sentito parlare bene delle prestazioni di Pinterest, quindi ho deciso di metterlo alla prova.

Forse questo non è il più giusto dei test; Sono stato indirizzato alla pagina di accesso, in cui un processo asincrono ha rilevato che ero connesso a Facebook e mi ha effettuato l'accesso automaticamente. La pagina si è caricata in tempi relativamente brevi, ma le richieste sono aumentate man mano che sempre più contenuti venivano precaricati.

Tuttavia, ho visto che nei successivi caricamenti della pagina, l'operatore del servizio ha fatto emergere gran parte del contenuto, risparmiando circa la metà del peso della pagina:

Il sito Pinterest è un'app web progressiva; ha installato un service worker per gestire manualmente la memorizzazione nella cache di CSS e JS. Ora potrei spegnere il mio WiFi e continuare a utilizzare il sito (anche se non molto utile):

Suggerimento per le prestazioni n. 12: utilizzare gli addetti ai servizi per fornire supporto offline

Non sarebbe fantastico se dovessi caricare un sito Web solo una volta in rete e ora ottenere tutte le informazioni di cui ho bisogno anche se sono offline?

Un ottimo esempio potrebbe essere un sito Web che mostra le previsioni del tempo per la settimana. Dovrei solo scaricare quella pagina una volta. Se spengo i miei dati mobili e successivamente torno alla pagina a un certo punto, dovrebbe essere in grado di fornirmi l'ultimo contenuto noto. Se mi collego di nuovo a Internet e carico la pagina, otterrei una previsione più aggiornata, ma le risorse statiche come CSS e immagini dovrebbero comunque essere servite localmente dal lavoratore del servizio.

Ciò è possibile configurando un addetto al servizio con una buona strategia di memorizzazione nella cache in modo che le pagine memorizzate nella cache possano essere nuovamente accessibili offline. Il sito Web della documentazione di lodash è un bell'esempio di lavoratore di servizio in natura:

I contenuti che si aggiornano raramente ed è probabile che vengano utilizzati abbastanza regolarmente sono un candidato perfetto per il trattamento degli operatori dei servizi. I siti dinamici con feed di notizie in continua evoluzione non sono così adatti per le esperienze offline, ma possono comunque trarne vantaggio.

Gli addetti all'assistenza possono davvero salvare la situazione quando hai un budget limitato per i dati. Non sono convinto che l'esperienza di Pinterest sia stata la più ottimale in termini di utilizzo dei dati – le pagine successive erano di circa 0,5 MB anche su pagine con poche immagini – ma lasciare che il tuo JavaScript gestisca le richieste di pagina per te e mantenendo gli stessi elementi di navigazione in posizione può essere molto performante. La BBC gestisce una dimensione di trasferimento di soli 3,1 KB per le visite di ritorno ad articoli che possono essere visualizzati tramite l'applicazione a pagina singola.

Finora, Pinterest da solo ha masticato 14 MB, il che significa che ho esaurito circa 30 MB del mio budget o $ 2,20 (quasi lo stipendio giornaliero) del mio budget per lo Zimbabwe.

Farei meglio a stare attento con i miei 20 MB finali... ma dov'è il divertimento?

Punto di gioco

Ho scelto questo perché in passato mi sembrava visibilmente lento sul mio telefonino e volevo approfondire i motivi. Abbastanza sicuro, il caricamento della home page consuma 8,5 MB di dati.

6,5 MB di questo erano dovuti a un video a riproduzione automatica a metà pagina, che, per essere onesti, non sembrava essere scaricato fino a quando non ho iniziato a scorrere. Tuttavia…

Riuscivo a vedere solo metà del video nel mio viewport: il lato destro era tagliato. Era anche lungo 30 secondi, e scommetterei che la maggior parte delle persone non si siederà a guardare tutto. Questa singola risorsa ha più che triplicato le dimensioni della pagina.

Suggerimento per le prestazioni n. 13: non precaricare il video

Di norma, a meno che la modalità di comunicazione principale del tuo sito non sia il video, non precaricarlo.

Se sei YouTube o Netflix, è ragionevole presumere che qualcuno che visita la tua pagina vorrà che il video si carichi automaticamente e venga riprodotto automaticamente. C'è un'aspettativa che il video masticerà alcuni dati, ma che è uno scambio equo per il contenuto. Ma se sei un sito il cui mezzo principale è il testo e l'immagine, e ti capita di offrire contenuti video aggiuntivi, non precaricare il video.

Pensa agli articoli di notizie con video incorporati. Molti utenti vogliono solo scorrere il titolo dell'articolo prima di passare alla cosa successiva. Altri leggeranno l'articolo ma ignoreranno qualsiasi incorporamento. E altri faranno clic diligentemente e guarderanno ogni video incorporato. Non dovremmo monopolizzare la larghezza di banda di ogni utente partendo dal presupposto che vorranno guardare questi video.

Per ribadire: agli utenti non piace la riproduzione automatica dei video. Come sviluppatori, lo facciamo solo perché i nostri manager ce lo dicono e ci dicono solo di farlo perché tutte le app più interessanti lo fanno e le app più interessanti lo fanno solo perché gli annunci video generano da 20 a 50 volte più entrate rispetto ai tradizionali Annunci. Google Chrome ha iniziato a bloccare la riproduzione automatica dei video per alcuni siti, in base alle preferenze personali, quindi anche se sviluppi il tuo sito per la riproduzione automatica dei video, non vi è alcuna garanzia che sia l'esperienza che i tuoi utenti stanno ottenendo.

Se siamo d'accordo sul fatto che sia una buona idea rendere il video un'esperienza di attivazione (clicca per riprodurre), possiamo fare un ulteriore passo avanti e fare clic anche per caricare. Ciò significa prendere in giro un'immagine segnaposto video con un pulsante di riproduzione su di essa e scaricare il video solo quando si fa clic sul pulsante di riproduzione. 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.

Questo è tutto. 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.

La modalità Lite condivide l'URL HTTPS con Google, quindi è logico che questa modalità non sia disponibile in Incognito. Tuttavia, altre informazioni come cookie, informazioni di accesso e contenuto di pagine personalizzate non vengono condivise con Google – secondo ghacks.net – e “non interrompono mai le connessioni sicure tra Chrome e un sito web”. Viene da chiedersi perché apparentemente nessuno di questi servizi di salvataggio dei dati sia consentito su iOS (e non ci sono notizie sul fatto che la modalità Lite sarà mai disponibile su iOS).

I proxy dei risparmiatori di dati richiedono molta fiducia; la tua attività di navigazione, cookie e altre informazioni sensibili sono affidati ad alcuni server, spesso in un altro paese. Molti proxy semplicemente non funzioneranno più perché molti siti sono passati a HTTPS, il che significa che iniziative come la modalità Turbo sono diventate in gran parte una "funzione inutile". HTTPS impedisce questo tipo di comportamento man-in-the-middle, il che è positivo, anche se ha significato la scomparsa di alcuni di questi servizi proxy e ha reso i siti meno accessibili a chi ha connessioni scadenti.

Non sono riuscito a trovare alcuno strumento di salvataggio dei dati compatibile con OSX o iOS ad eccezione di Bandwidth Hero per Firefox (che richiede la configurazione del proprio servizio di compressione dei dati, ben oltre le capacità tecniche della maggior parte degli utenti!) e skyZIP Proxy (che, aggiornato l'ultima volta in 2017 e pieno di errori di battitura, non riuscivo proprio a fidarmi di me stesso).

Conclusione

La riduzione dell'impronta di dati del tuo sito Web va di pari passo con il miglioramento delle prestazioni del frontend. È la cosa più affidabile che puoi fare per velocizzare il tuo sito.

Oltre al costo dei dati, ci sono molte buone ragioni per concentrarsi sulle prestazioni, come descritto in un post sul blog di GOV.UK sull'argomento:

• Il 53% degli utenti abbandonerà un sito mobile se impiega più di 3 secondi per caricarsi.
• Le persone devono concentrarsi il 50% in più quando cercano di completare un'attività semplice su un sito Web utilizzando una connessione lenta.
• Le pagine Web più performanti sono migliori per la durata della batteria del dispositivo dell'utente e in genere richiedono meno energia sul server per essere erogate. Un sito performante fa bene all'ambiente.

Non abbiamo il potere di modificare il costo globale della disuguaglianza dei dati. Ma abbiamo il potere di ridurne l'impatto, migliorando l'esperienza per tutti nel processo.