Dare un'occhiata allo stato delle immagini progressive e alla percezione dell'utente
Pubblicato: 2022-03-10"Immagini progressive" è un argomento caldo in questi giorni. Spesso ci imbattiamo in articoli che spiegano tecniche su come evitare di mostrare uno spazio vuoto in cui verrà caricata un'immagine. Medium e Facebook sono esempi di siti Web e app mobili che applicano questo modello.
Di recente ho scritto di diversi modi per utilizzare SVG come segnaposto e il Calendario delle prestazioni di PerfPlanet di quest'anno includeva due post che descrivono ulteriormente SQIP, una tecnica basata su SVG sfocati: caricamento progressivo delle immagini utilizzando Intersection Observer e SQIP e SQIP — Vettori vaghi per anteprime performanti.
Quando ho documentato per la prima volta la tecnica di caricamento delle immagini di Medium, ero principalmente interessato a decodificare la loro tecnica. Avevo visto l'effetto navigando su Medium su una connessione in volo lenta. Ho pensato che il rendering di una piccola immagine in anticipo, il lazy-load e il passaggio alla versione finale fosse una buona idea.
Partiamo dal presupposto che queste tecniche migliorino le prestazioni percepite dell'utente . Il rendering veloce batte il rendering lento. Mettere qualcosa sullo schermo dell'utente in anticipo, anche se non è il contenuto finale.
Siamo sicuri di questo?
Passando attraverso alcuni commenti su Reddit, ho trovato molte opinioni perspicaci (e negative). Qui ce ne sono due:
“Odio i siti Web che mostrano una versione sfocata di un'immagine prima che venga caricata quella finale. Gioca con i miei occhi. Devo distogliere lo sguardo e sbirciare per vedere se è fatto prima di poter continuare a leggere. Vorrei che ci fosse un modo per disabilitare questa funzionalità".
— Rocky1138, Hacker News
"In che modo le persone sono giunte alla conclusione che la visualizzazione di una versione con poche informazioni dell'immagine da caricare come segnaposto si traduce in un caricamento percepito più rapido? Per me tutti questi effetti sembrano solo spazzatura e distrazione, senza alcun beneficio, certamente non la percezione della velocità. Non è che io possa mai capire cosa sia veramente l'immagine prima che sia comunque completamente caricata, con il nostro segnaposto senza fantasia".
— dwb, Hacker News
Cercando di trovare studi sulla percezione degli utenti
Volevo trovare alcune ricerche scientifiche che potessero supportare il fatto che queste tecniche per caricare le immagini fossero (o meno) vantaggiose. Questa si è rivelata una sfida. Non sono riuscito a trovare alcuno studio che dimostri che mostrare qualcosa come una miniatura sfocata prima del caricamento dell'immagine migliora la percezione dell'utente. Poi ho pensato ai JPEG progressivi.
Ritorno alla base: JPEG progressivi
In un certo senso, abbiamo avuto una simile "tecnica di caricamento progressivo delle immagini" supportata nelle immagini per molto tempo. Il JPEG progressivo è un buon esempio.
I JPEG progressivi sono stati proposti come buona pratica per le immagini, in particolare per i siti utilizzati in reti lente. Ann Robson ha scritto un post incoraggiando i JPEG progressivi, ora cinque anni fa, in cui ha riassunto perché erano superiori:
“I JPEG progressivi sono migliori perché sono più veloci. Apparire più velocemente è essere più veloci e la velocità percepita è più importante della velocità effettiva . Anche se siamo avidi di ciò che stiamo cercando di fornire, i JPEG progressivi ci danno quanto più possibile il prima possibile".
Un JPEG progressivo codifica l'immagine in più scansioni. La prima scansione esegue il rendering dell'intera immagine in bassa qualità e viene perfezionata man mano che vengono renderizzate più scansioni. Un'alternativa è la modalità di base di JPEG in cui l'immagine viene decodificata dall'alto verso il basso.
Come nota a margine, la codifica JPEG può essere personalizzata utilizzando diversi script di scansione. Questo può essere utilizzato per creare immagini codificate in una modalità ibrida tra linea di base e progressiva.
Le tecniche progressive come Blur-up, SQIP assomigliano ai JPEG progressivi dal punto di vista della percezione dell'utente. Il browser esegue prima il rendering di un'immagine di bassa qualità e la sostituisce con l'immagine finale quando viene caricata.
È interessante notare che la stragrande maggioranza delle immagini JPEG utilizza la modalità linea di base. Secondo alcune fonti, i JPEG progressivi rappresentano al massimo il 7% di tutti i JPEG. Se sembriamo concordare sul fatto che queste tecniche migliorano le prestazioni percepite dall'utente, perché i JPEG progressivi non vengono utilizzati più ampiamente dei JPEG di base?
Lo studio
Sono riuscito a trovare solo uno studio chiamato "Rendering di immagini progressivo - buono o cattivo?", che ha cercato di fare luce su questo argomento.
"Quando, come con il metodo Progressive JPEG, la resa dell'immagine è un processo in due fasi in cui un'immagine inizialmente grossolana viene messa a fuoco nitidamente, la fluidità cognitiva viene inibita e il cervello deve lavorare leggermente di più per dare un senso a ciò che viene visualizzato .”
Secondo lo studio, gli utenti trovano più difficile elaborare i JPEG progressivi, anche se a prima vista penseremmo che l'esperienza sia migliore.
Di recente ho menzionato lo studio in una conversazione su LQIP (Low-Quality Image Placeholders). Presto ho ricevuto alcune risposte che mettevano in dubbio il rigore dello studio:
Molte persone hanno messo in dubbio la validità di quello studio, però. È contrario a tutto ciò che supponiamo sui vantaggi del rendering progressivo e nessuno ha ancora presentato un secondo studio con risultati simili. Abbiamo bisogno di più dati.
— Tobias Baldauf (@tbaldauf) 9 dicembre 2017
Lo studio è stato molto limitato e controverso. Dati su larga scala per dimostrare o smentire è essenziale trarre conclusioni
— Yoav Weiss (@yoavweiss) 9 dicembre 2017
Finora, abbiamo un unico studio che è accolto con scetticismo. Cos'altro abbiamo? Possiamo utilizzare gli strumenti esistenti per misurare le prestazioni percepite come proxy?
Misurazione del tempo di caricamento percepito
Immagina queste due ipotetiche pellicole registrate da un sito:
L'accordo generale è che l'utente percepirà che la versione B si carica più velocemente della versione A. Ciò è dovuto al fatto che parti della pagina sono state visualizzate prima rispetto alla versione A.
In qualche modo, la situazione è simile a quella delle immagini progressive, ma su scala più ampia. Contenuto parziale il prima possibile, anche se non è l'ultimo.
Un tempo di caricamento della pagina di 1,2 secondi ci racconta parte della storia, ma non descrive ciò che l'utente vede durante quel periodo. In questi giorni utilizziamo metriche come Indice di velocità per valutare la velocità di caricamento di una pagina. L'indice di velocità misura l'area della pagina che non è completata visivamente. Questo viene fatto su diversi screenshot presi a intervalli. Più basso è il numero, meglio è.
Se pensiamo alle tecniche di caricamento progressivo delle immagini, come varia l'indice di velocità durante il caricamento dell'immagine? Quell'area sarà considerata "visivamente completata" se utilizziamo un segnaposto di bassa qualità?
Inizialmente, Speed Index ha misurato l'avanzamento confrontando la distanza degli istogrammi, uno per ogni colore primario (rosso, verde, blu). Questo è chiamato differenza media dell'istogramma. L'obiettivo è impedire che modifiche come i reflow, in cui tutti gli elementi della pagina vengono spostati di pochi pixel, abbiano un grande impatto sul calcolo. Per ulteriori informazioni sull'algoritmo, leggere la sezione Misurare l'avanzamento visivo del documento Speed Index.
Ho deciso di provare Webpagetest su una pagina che mostra segnaposto di bassa qualità (vedi rapporto su WebPageTest):
Possiamo notare che tra i secondi 8 e 10 l'immagine viene caricata. Il segnaposto sfocato aumenta la percentuale di completezza visiva dal 75% all'83%. Il caricamento dell'immagine finale la porta dall'83% al 93%.
Vediamo che un segnaposto contribuisce alla completezza visiva della pagina misurata dall'indice di velocità. Possiamo anche osservare che il segnaposto non conta come un'area completamente visivamente completa.
L'indice di velocità non è l'unica metrica che possiamo utilizzare per ottenere una misura della velocità di rendering della nostra pagina. Gli Strumenti per sviluppatori di Chrome includono un'opzione per eseguire un controllo delle prestazioni. Vai a Audits → Perform an audit → Check 'Performance' → Run audit .
L'esecuzione di un audit genera un rapporto come questo:
Una delle metriche riportate è "Indice di velocità percettiva". In questa corsa il valore è 4,245 . Ma cosa significa esattamente questo termine? È lo stesso di "Indice di velocità" di Webpagetest?
L'approccio dell'indice di velocità per misurare la somiglianza in termini di pixel, chiamato anche "differenza dell'istogramma medio", presenta alcuni inconvenienti. L'MHD non cattura la percezione visiva della forma, del colore o della somiglianza degli oggetti.
Nella maggior parte dei casi, questo non farà una grande differenza quando si esegue una valutazione della completezza visiva. In pratica, l'Indice di Velocità così come l'Indice di Velocità Percettiva hanno un'alta correlazione:
"Negli studi empirici su larga scala che abbiamo condotto (utilizzando oltre 500 video delle migliori pagine Web mobili di Alexa raccolti tramite WebPagetest), scopriamo che SI e PSI sono linearmente correlati (a 0,91, per essere precisi)." — Indice di velocità percettiva (PSI) per misurare le prestazioni Web above-the-Fold
Indice di velocità percettiva
Secondo la documentazione di Google Lighthouse, l'indice di velocità percettiva viene calcolato utilizzando un modulo nodo chiamato Speedline. Questo pacchetto calcola l'indice di velocità percettivo, basato sullo stesso principio dell'indice di velocità originale, ma calcola la progressione visiva tra i frame utilizzando l'SSIM invece della distanza dell'istogramma .
SSIM (Somiglianza strutturale) viene utilizzato per misurare la somiglianza tra due immagini. Questo metodo cerca di modellare il modo in cui gli esseri umani percepiscono le immagini e cattura la somiglianza di forma, colore e oggetto. SSIM ha altre applicazioni interessanti: una di queste è l'ottimizzazione delle impostazioni di compressione dell'immagine, come cjpeg-dssim che sceglie il livello di compressione JPEG più alto e genera un'immagine con un SSIM sufficientemente vicino.
Di seguito puoi vedere i punteggi di Image SSIM JS per le immagini SVG create usando Primitive. Più forme utilizziamo, più è vicino all'immagine originale (SSIM = 1).
Alternative più recenti a SSIM sono butteraugli (usato da Guetzli, Perceptually Guided JPEG Encoder di Google) e SSIMULACRA (usato da Cloudinary).
Conclusione
Non esiste un modo semplice per sintetizzare la percezione di un utente del caricamento di un'immagine nel tempo. Siamo spinti dalla sensazione viscerale che mostrare prima sia meglio, anche se non è il contenuto finale, anche se alcuni utenti non saranno d'accordo.
Come sviluppatori, dobbiamo misurare le prestazioni . È l'unico modo in cui possiamo fissare obiettivi per migliorarlo e sapere quando non raggiungiamo un budget di performance. Il vantaggio di scommettere sul caricamento progressivo delle immagini è che possiamo misurarlo con strumenti basati sulla percezione dell'utente. Ci danno un punteggio, sono riproducibili e scalabili. Si adattano al nostro flusso di lavoro e ai nostri strumenti e sono qui per restare.
Come sviluppatori web, dovremmo preoccuparci di più dell'esperienza di caricamento dei siti web che creiamo. È fantastico che ora disponiamo di strumenti come WebPageTest e Lighthouse che possono aiutarci a misurare facilmente l'effetto dell'utilizzo di tecniche di caricamento progressivo delle immagini. Niente più scuse!