Effetti sulle prestazioni di un caricamento troppo lento

Consigli basati sui dati per immagini con caricamento lento tenendo a mente i Segnali web essenziali.

Felix Arntz

Rick Viscomi

Il caricamento lento è una tecnica per posticipare il download di una risorsa finché non è necessario, in modo da risparmiare dati e ridurre i conflitti di rete per gli asset critici. È diventato uno standard web nel 2019 e oggi loading="lazy" per le immagini è supportato dalla maggior parte dei principali browser. Sembra fantastico, ma c'è qualcosa come il caricamento troppo lento?

Questo post riassume il modo in cui abbiamo analizzato i dati sulla trasparenza web disponibili pubblicamente e i test A/B ad hoc per comprendere le caratteristiche di adozione e prestazioni del caricamento lento delle immagini native. Abbiamo scoperto che il caricamento lento può essere uno strumento incredibilmente efficace per ridurre i byte delle immagini non necessari, ma un utilizzo eccessivo può influire negativamente sulle prestazioni. In concreto, la nostra analisi mostra che caricare con maggiore entusiasmo le immagini nell'area visibile iniziale, mentre viene caricato liberamente il resto, può darci il meglio di entrambi i mondi: meno byte caricati e Segnali web essenziali migliorati.

Adozione

Secondo i dati più recenti in HTTP Archive, il caricamento lento nativo delle immagini è utilizzato dal 17% dei siti web e l'adozione è in rapida crescita. Questo punto d'appoggio nell'ecosistema è notevole per un'API relativamente nuova.

L'esecuzione di query sui dati non elaborati nel progetto HTTP Archive ci consente di capire meglio quali tipi di siti web ne favoriscono l'adozione: l'84% dei siti che utilizzano il caricamento lento delle immagini native utilizza WordPress, il 2% utilizza un altro CMS e il restante 14% non utilizza un CMS noto. Questi risultati chiariscono in che modo WordPress è in testa nell'adozione.

Vale anche la pena notare il tasso di adozione. Un anno fa, a luglio 2020, i siti WordPress che utilizzano il caricamento lento comprendevano decine di migliaia di siti web nel corpus di circa 6 milioni (1% del totale). L'adozione del caricamento lento da solo solo in WordPress è cresciuta fino a raggiungere oltre 1 milione di siti web (il 14% del totale).

Prestazioni correlazionali

Approfondendo l'archivio HTTP, possiamo confrontare le prestazioni delle pagine con e senza caricamento lento delle immagini native con la metrica Largest Contentful Paint (LCP). I dati di LCP provengono da esperienze utente reali tratte dal Report sull'esperienza utente di Chrome (CrUX) anziché da test sintetici in laboratorio. Il grafico riportato di seguito utilizza un grafico a box e baffi per visualizzare le distribuzioni dell'LCP del 75° percentile di ogni pagina: le linee rappresentano il 10° e il 90° percentile, mentre le caselle rappresentano il 25° e il 75° percentile.

La pagina mediana senza caricamento lento ha un LCP del 75° percentile di 2922 ms, rispetto ai 3546 ms della pagina mediana con caricamento lento. Nel complesso, i siti web che utilizzano il caricamento lento tendono ad avere prestazioni LCP peggiori.

È importante sottolineare che si tratta di risultati correlazionali e non puntano necessariamente al caricamento lento come causa delle prestazioni più lente. Ipoteticamente, se i siti WordPress tendono a essere un po' più lenti e dato quanto costituiscono la coorte di caricamento lento, questo potrebbe spiegare la differenza. Cerchiamo quindi di eliminare questa variabilità esaminando solo i siti WordPress.

Sfortunatamente, lo stesso modello emerge quando visualizziamo in dettaglio le pagine WordPress. Quelle che utilizzano il caricamento lento tendono ad avere prestazioni LCP più lente. La pagina WordPress media senza caricamento lento ha un LCP del 75° percentile di 3495 ms, rispetto ai 3768 ms della pagina mediana con caricamento lento.

Ciò ancora non dimostra che il caricamento lento causa la lentezza delle pagine, ma il suo utilizzo coincide con l'avere prestazioni più lente. Per cercare di dare una risposta alla domanda di causalità, abbiamo istituito un test A/B basato in laboratorio.

Prestazioni causali

L'obiettivo del test A/B era provare o confutare l'ipotesi che il caricamento lento delle immagini native, come implementato nel core di WordPress, comportasse un rallentamento delle prestazioni LCP e un minor numero di byte immagine. La metodologia che abbiamo utilizzato è quella di testare un sito web demo di WordPress con il tema twentytwentyone. Abbiamo testato sia i tipi di archiviazione sia di pagina singola, come la home page e la pagina degli articoli, su computer ed emulati su dispositivi mobili utilizzando WebPageTest. Abbiamo testato ogni combinazione di pagine con e senza caricamento lento attivato ed abbiamo eseguito ogni test nove volte per ottenere il valore LCP mediano e il numero di byte immagine.

I risultati riportati sopra confrontano l'LCP mediano in millisecondi per i test su archivio e su singole pagine per desktop e dispositivi mobili. Quando abbiamo disabilitato il caricamento lento nelle pagine di archivio, abbiamo osservato un miglioramento di LCP di un margine significativo. Sulle singole pagine, invece, la differenza era più neutra.

Vale la pena notare che l'effetto della disattivazione del caricamento lento in realtà sembra rendere le singole pagine leggermente più veloci. Tuttavia, la differenza di LCP è inferiore a una deviazione standard per i test su computer e dispositivi mobili, pertanto la attribuiamo alla varianza e consideriamo la variazione neutra nel complesso. In confronto, la differenza per le pagine di archivio è più simile a due o tre deviazioni standard.

I risultati riportati sopra confrontano il numero mediano di byte immagine (in kB) per ogni test. Come previsto, il caricamento lento ha un effetto positivo molto evidente sulla riduzione del numero di byte immagine. Se un utente reale scorresse l'intera pagina verso il basso, tutte le immagini verrebbero comunque caricate quando entrano nell'area visibile, ma questi risultati mostrano il miglioramento delle prestazioni del caricamento iniziale della pagina.

Per riepilogare i risultati del test A/B, la tecnica di caricamento lento utilizzata da WordPress aiuta in modo molto chiaro a ridurre i byte delle immagini, ma a scapito di un LCP ritardato.

Verifica della correzione in corso...

Prima di vedere come è stata implementata la correzione, vediamo come funziona oggi il caricamento lento in WordPress. L'aspetto più importante dell'attuale implementazione è il caricamento lento delle immagini above the fold (all'interno dell'area visibile). Il post del blog di CMS riconosce questo aspetto come schema da evitare, ma i dati sperimentali all'epoca indicavano che l'effetto sulla metrica LCP era minimo, pertanto vale la pena semplificare l'implementazione nel core di WordPress.

Dati questi nuovi dati, abbiamo creato una correzione sperimentale che evita il caricamento lento delle immagini above the fold e l'abbiamo testata nelle stesse condizioni del primo test A/B.

Questi risultati sono molto più promettenti. Il caricamento lento solo delle immagini below the fold comporta un'inversione completa della regressione LCP e probabilmente anche un leggero miglioramento rispetto alla disattivazione completa di LCP. Come potrebbe essere più veloce del caricamento lento? Una spiegazione è che, se non carichi immagini below the fold, viene ridotta la contesa di rete con l'immagine LCP, il che consente un caricamento più rapido.

Per quanto riguarda i byte delle immagini, la correzione non ha assolutamente alcun cambiamento rispetto al comportamento predefinito. Questo è ottimo perché era uno dei punti di forza dell'approccio attuale.

Questa correzione presenta alcune avvertenze. WordPress determina quali immagini caricare tramite caricamento lento sul lato server, il che significa che non ha informazioni sulle dimensioni dell'area visibile dell'utente o se le immagini verranno inizialmente caricate al suo interno. La correzione utilizza quindi un'euristica sulla posizione relativa delle immagini nel markup per indovinare se verrà inclusa nell'area visibile. In particolare, se l'immagine è la prima in primo piano nella pagina o la prima immagine nei contenuti principali, si presume che sia above the fold (o vicina a quest'ultima) e non verrà eseguita il caricamento lento. Condizioni a livello di pagina come il numero di parole nell'intestazione o la quantità di testo del paragrafo all'inizio dei contenuti principali possono influire sulla presenza dell'immagine all'interno dell'area visibile. Esistono anche condizioni a livello di utente che possono influire sulla precisione dell'euristica, in particolare le dimensioni dell'area visibile e l'utilizzo di link di ancoraggio che cambiano la posizione di scorrimento della pagina. Per questi motivi, è importante riconoscere che la correzione viene calibrata solo per fornire buone prestazioni in generale e potrebbe essere necessaria un'ottimizzazione per rendere questi risultati applicabili a tutti gli scenari reali.

Implementazione

Dopo aver identificato un modo migliore per eseguire il caricamento lento delle immagini, ridurre i costi delle immagini e aumentare le prestazioni di LCP, come possiamo indurre i siti a iniziare a utilizzarla? La modifica con la massima priorità consiste nell'inviare una patch al core di WordPress per implementare la correzione sperimentale. Aggiorneremo anche le indicazioni nel post del blog sul caricamento lento a livello di browser per i CMS per chiarire gli effetti negativi del caricamento lento above the fold e in che modo i CMS possono utilizzare l'euristica per evitarlo.

Poiché queste best practice sono applicabili a tutti gli sviluppatori web, può essere utile anche segnalare gli anti-pattern di caricamento lento in strumenti come Lighthouse. Fai riferimento alla richiesta di funzionalità su GitHub se vuoi seguire lo stato di avanzamento del controllo. Fino ad allora, per trovare istanze di elementi LCP a caricamento lento, gli sviluppatori potrebbero aggiungere log più dettagliati ai dati dei campi.

new PerformanceObserver((list) => {
  const latestEntry = list.getEntries().at(-1);

  if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
    console.warn('Warning: LCP element was lazy loaded', latestEntry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

Lo snippet JavaScript riportato sopra valuta l'elemento LCP più recente e registra un avviso in caso di caricamento lento.

Questo evidenzia anche un netto vantaggio della tecnica di caricamento lento e il potenziale di miglioramenti dell'API a livello di piattaforma. Ad esempio, in Chromium è presente un problema in corso per sperimentare il caricamento nativo delle prime immagini con entusiasmo, in modo simile alla correzione, nonostante l'attributo loading.

Conclusione

Se il tuo sito utilizza il caricamento lento delle immagini native, controlla come è implementato ed esegui test A/B per comprendere meglio i costi delle prestazioni. Può essere utile caricare più immagini above the fold. Se hai un sito WordPress, a breve arriverai una patch nel core WordPress. Se utilizzi un altro CMS, assicurati che sia a conoscenza dei potenziali problemi di rendimento descritti qui.

Provare API relativamente nuove per piattaforme web può comportare rischi e vantaggi. Per un motivo, sono chiamate funzionalità all'avanguardia. Stiamo iniziando a percepire la spinta del caricamento lento delle immagini native, ma stiamo notando anche i lati positivi di come utilizzarlo per ottenere prestazioni migliori.

Foto di Frankie Lopez su Unsplash