Considerare come si usa HTTP/2

Osservare i risultati della performance#section1

Sviluppare una metodologia di testing#section2

Le connessioni mobile a bassa velocità sono piuttosto comuni nei paesi in via di sviluppo. Per pura curiosità, volevo simulare degli scenari HTTP/1 e HTTP/2 con il mio sito su una vera connessione mobile a bassa velocità.

Per una combinazione stranamente casuale degli eventi, ho finito i dati mobile ad alta velocità a mia disposizione nel mese in cui ho pianificato i test. Al posto di farmi pagare un extra, il mio provider riduce semplicemente la velocità di connessione al 2G. Dato il tempismo perfetto, ho fatto tethering con il mio iPhone e ho cominciato.

Per misurare la performance in ogni scenario, vi serve una buona metodologia di testing. Volevo testare tre diversi scenari:

1. Sito ottimizzato per HTTP/2: questa è la strategia di ottimizzazione di default quando il sito viene inviato usando HTTP/2. Se il protocollo rilevato è HTTP/2, viene inviato un numero più alto di asset piccoli, granulari.
2. Sito non ottimizzato per HTTP/1: si ha questo scenario quando HTTP/2 non è supportato dal browser e quando l’invio del contenuto non è adattato in accordo a questi limiti. In altre parole, il contenuto e gli asset sono ottimizzati per l’invio su HTTP/2, rendendoli tutt’altro che ottimali per gli utenti su HTTP/1.
3. Sito ottimizzato per HTTP/1: ai browser incompatibili con HTTP/2 vengono fornite delle ottimizzazione per HTTP/1 dopo che la strategia per l’invio dei contenuti si adatta a soddisfare i limiti del browser.

Il tool che ho scelto per i test era sitespeed.io. sitespeed.io è un ingegnoso tool da riga di comando, installabile con il package manager di Node (npm), pieno di opzioni per automatizzare i test di performance. Ogni volta che finisce una sessione, sitespeed.io raccoglie varie metriche di performance della pagina.

Per raccogliere i dati di performance in ogni scenario, ho usato il seguente comando nella finestra del terminale:

sitespeed.io -b chrome -n 200 --browsertime.viewPort 320x480 -c native -d 1 -m 1 https://jeremywagner.me

Ci sono molte opzioni in questo caso, ma il succo è che sto testando l’URL del mio sito usando Chrome. Il test verrà fatto 200 volte per ciascuno dei tre scenari e userà una dimensione della viewport di 320×480. Per una lista completa delle opzioni di runtime di sitespeed.io, controllate la sua documentazione.

I risultati del test#section3

Stiamo tracciando tre aspetti della performance della pagina: il tempo totale impiegato per il caricamento della pagina, la quantità di tempo necessaria perché l’evento DOMContentLoaded parta sul client e il tempo necessario perché il browser cominci a fare l’operazione di painting della pagina.

Per prima cosa, osserviamo i tempi di caricamento totale della pagina per ciascuno scenario (Fig. 1).

Questo grafico illustra un trend che vedrete più avanti. Gli scenari ottimizzati per HTTP/1 e HTTP/2 dimostrano livelli simili di performance quando girano sulle loro rispettive versioni del protocollo. Lo scenario più lento gira su HTTP/1, tuttavia è stato ottimizzato per HTTP/2.

In questi grafici, stiamo progettando due stime: la media e il novantacinquesimo percentile (che significa che i tempi di caricamento sono sotto a questo valore il 95% delle volte). Quello che questi dati mi dicono è che se spostassi il mio sito su HTTP/2 ma non lo ottimizzassi per i browser che non sono compatibili con HTTP/2, il tempo di caricamento medio della pagina per quel segmento di utenti sarebbe il 10% più lento il 95% delle volte. E il 5% delle volte, il caricamento della pagina potrebbe essere più lento del 15%.

Per un sito piccolo e poco complicato come il mio blog questo risultato potrebbe sembrare insignificante, ma in realtà non lo è. E se sul mio sito arrivasse molto traffico? Cambiare il modo in cui invio il contenuto perché sia più inclusivo per gli utenti con capacità limitate potrebbe fare la differenza tra un utente che rimane e uno che decide di andarsene perché ha aspettato troppo.

Diamo un’occhiata a quanto ci vuole perché il DOM sia pronto in ciascuno scenario (Fig. 2).

Nuovamente, vediamo livelli simili di performance quando un sito è ottimizzato per il suo particolare protocollo. Per lo scenario nel quale il sito è ottimizzato per HTTP/2 ma gira su HTTP/1, l’evento DOMContentLoaded si attiva il 10% più lentamente rispetto a ciascuno degli scenari “ottimali”. Questo capita il 95% delle volte. Tuttavia, il 5% delle volte, potrebbe essere più lento addirittura del 26%.

E per quello che riguarda il tempo per il primo paint? Probabilmente questa è la metrica di performance più importante perché è il primo punto in cui l’utente vede effettivamente il vostro sito web. Cosa succede a questa metrica quando ottimizziamo la nostra strategia di content delivery per ogni versione del protocollo? (Fig. 3)

Il trend persiste di nuovo. Nello scenario HTTP/1 Unoptimized, il paint time è del 10% più lungo che in ciascuno degli scenari ottimizzati il 95% delle volte e quasi due volte quella durata durante l’altro 5%.

Un ritardo del 10-20% nel page paint time è una cosa seria. Se aveste la possibilità di accelerare il rendering per un segmento significativo del vostro pubblico, non vorreste farlo?

Un altro modo per migliorare questa metrica per gli utenti su HTTP/1 è di implementare un CSS critico. Per me è un’opzione dal momento che il CSS del mio sito è 2.2KB dopo la compressione Brotli. Sui si HTTP/2, potete ottenere dei benefit di performance simili all’inlining utilizzando la feature Server Push del protocollo.

Ora che abbiamo esaminato le implicazioni di performance dell’adeguare l’invio del contenuto alla versione del protocollo HTTP dell’utente, impariamo come generare automaticamente degli asset ottimizzati per entrambe i segmenti dei vostri utenti.

Un aiuto dai build tools#section4

Siete già abbastanza presi, lo so. Mantenere due insiemi di asset ottimizzati per due diversi tipi di utenti suona come un grande impegno, ma qui è dove entrano in gioco i build tool come gulp.

Se usate gulp (o altri tool di automazione come Grunt o webpack), ci sono buone probabilità che stiate già automatizzando cose come la minimizzazione degli script (o uglification, a seconda di quanto sono aggressive le vostre ottimizzazioni). Quello che segue è un esempio generalizzato del modo in cui potreste usare i plugin gulp-uglify e gulp-concat per fare l’uglify dei files e poi concatenare quegli asset “uglified” separati in uno unico.

var gulp = require("gulp"),
   uglify = require("gulp-uglify"),
   concat = require("gulp-concat");

// Uglification
gulp.task("uglify", function(){
   var src = "src/js/*.js",
       dest = "dist/js";

   return gulp.src(src)
       .pipe(uglify())
       .pipe(gulp.dest(dest));
});

// Concatenation
gulp.task("concat", ["uglify"], function(){
   var src = "dist/js/*.js",
       dest = "dist/js";

   return gulp.src(src)
       .pipe(concat("script-bundle.js"))
       .pipe(gulp.dest(dest));
});

In questo esempio, tutti gli script nella directory src/js sono “uglified” dal task uglify. Ogni script processato viene inviato separatamente su dist/js. Quando questo accade, il task concat si attiva e raggruppa tutti questi script in un singolo file chiamato script-bundle.js. Potete poi usare la tecnica di protocol detection mostrata nella prima parte di questa serie di articoli per cambiare gli script che vengono inviati a seconda della versione del protocollo del visitatore.

Ovviamente, questa non è l’unica cosa che potete fare con un build system. Potete usare lo stesso approccio per raggruppare i vostri files CSS o addirittura generare delle image sprite da immagini separate con il plugin gulp.spritesmith.

Il punto qui è che un build system rende semplice mantenere due insiemi di asset ottimizzati (tra le molte altre cose, ovviamente). Può essere fatto facilmente ed automaticamente, permettendovi di concentrarvi sullo sviluppo e sul miglioramento della performance per i visitatori del vostro sito.

Riflessioni#section5

Abbiamo visto come un sito ottimizzato per HTTP/2 possa avere una performance scarsa per gli utenti con browser incompatibili con HTTP/2.

Ma perché le capacità di questi utenti sono limitate? Dipende, davvero.

Le condizioni socio-economiche hanno un ruolo nella faccenda. Gli utenti tendono a comprare il tipo di device che possono permettersi, quindi le capacità del device “medio” varia in maniera significativa, specialmente tra le nazioni in via di sviluppo e quelle più avanzate.

La mancanza di risorse finanziarie potrebbe inoltre guidare gli utenti a piani dati ristretti e i browser come Opera Mini che minimizzano l’uso di dati. Finché questi browser non supporteranno HTTP/2, una percentuale significativa di utenti là fuori potrebbero non tornare più.

Per qualcuno potrebbe anche essere problematico aggiornare le app con un piano dati ristretto. Non ci si può aspettare l’adozione immediata e alcuni potrebbero rinunciare ad aggiornare il browser per risparmiare dati nel loro piano. Nelle nazioni in via di sviluppo, la qualità dell’infrastruttura internet è significativamente più indietro rispetto al resto del mondo più sviluppato.

Non possiamo cambiare il comportamento di ogni utente perché segua le nostre preferenze di sviluppo. Quello che possiamo fare, però, è identificare i segmenti di pubblico che non possono supportare HTTP/2, poi prendere una decisione oculata se vale la pena oppure no adattare il modo in cui inviamo loro il contenuto. Se una porzione considerevole del pubblico usa dei browser incompatibili con HTTP/2, possiamo cambiare il modo in cui inviamo loro il contenuto. Possiamo inviargli un’esperienza ottimizzata e favorirli, e possiamo farlo mentre forniamo dei vantaggi in termini di performance per quegli utenti che possono supportare HTTP/2.

Ci sono molte persone là fuori che affrontano sfide significative mentre navigano nel web. Prima di adottare completamente le nuove tecnologie, cerchiamo di capire in che modo possiamo farlo senza piantare in asso un segmento significativo del nostro pubblico. La ricompensa per quello che facciamo deriva dal fornire soluzioni che funzionano per tutti. Adottiamo le nuove tecnologie responsabilmente. Sta a noi agire con cura.

Ulteriori letture#section6

Imparate come aumentare la performance del vostro sito con il libro di Jeremy Web Performance in Action. Avrete il 39% di sconto usando il codice ALAWPA.