Se avete passato un tempo sufficientemente lungo a sviluppare per il web, da tempo immemore riceverete questo tipo di feedback nella vostra inbox:<\/p>\n
\u201cQuesta foto sembra sfuocata. Possiamo sostituirla con una versione migliore?\u201d<\/em><\/p>\n Ogni volta che mi arriva questo feedback, sono incline a questionarlo: \u201cCosa nella foto ti sembra che non vada bene e puoi dirmi perch\u00e9?<\/em>\u201d<\/p>\n Non \u00e8 una domanda del tutto giusta con cui controbattere. La lamentela ha le sue radici in una percezione soggettiva della qualit\u00e0 dell’immagine, che a sua volta \u00e8 influenzata da molti fattori, alcuni tecnici, come la qualit\u00e0 dell’esportazione dell’immagine o del metodo di compressione (spesso lossy, come nel caso delle foto in formato JPEG), altri sono pi\u00f9 intuitivi o percettivi, come il contenuto dell’immagine e il modo in cui si mescolano gli artefatti di compressione al suo interno. Forse anche la performance gioca un ruolo di cui non siamo completamente consci.<\/p>\n Rispondere per molti anni a questo tipo di feedback alla fine mi ha spinto a progettare e sviluppare un questionario sulla qualit\u00e0 dell’immagine<\/a>, che \u00e8 stato il mio primo tentativo nella creazione di un progetto di ricerca sul web. Ho cominciato con venticinque foto di un fotografo professionista. Con esse, ho generato una gran quantit\u00e0 di immagini a vari livelli di qualit\u00e0 e dimensioni. Le immagini di questo gruppo venivano inviate a caso agli utenti a cui veniva chiesto di valutare quello che pensavano della loro qualit\u00e0.<\/p>\n I risultati dal primo round sono stati interessanti ma non completamente chiari: gli utenti sembrava avessero la tendenza di sovrastimare l’effettiva qualit\u00e0 delle immagini e una performance scarsa apparentemente<\/em> aveva un impatto negativo sulla percezione della qualit\u00e0 dell’immagine, ma non si poteva affermare ci\u00f2 in maniera definitiva. Un numero di questioni di UX e tecniche ha reso necessaria l’implementazione di importanti miglioramenti e di condurre una seconda tornata di ricerca. Invece di scervellarmi sull’estrazione di conclusioni dal mio primo giro di risultati, ho deciso che sarebbe stato meglio migliorare il questionario quanto pi\u00f9 possibile e di condurre un altro giro di ricerca per avere dei dati migliori. Questo articolo fa la cronaca di come ho costruito in primo luogo il questionario e poi come ho in seguito ascoltato il feedback degli utenti per migliorarlo.<\/p>\n Tra i soggetti che rientrano nella performance web, l’ottimizzazione delle immagini \u00e8 particolarmente vasta. C’\u00e8 una gran variet\u00e0 di formati, codifiche e tool di ottimizzazione, ciascuno dei quali \u00e8 progettato per rendere le immagini sufficientemente piccole per l’uso sul web, mantenendo una qualit\u00e0 visuale ragionevole. Trovare l’equilibrio tra velocit\u00e0 e qualit\u00e0 \u00e8 davvero tutto quello che c’\u00e8 nell’ottimizzazione delle immagini.<\/p>\n Questo equilibrio tra performance e qualit\u00e0 visiva mi ha indotto a considerare il modo in cui le persone percepiscono<\/em>la qualit\u00e0 delle immagini. La qualit\u00e0 dell’immagine lossy<\/a>, in particolare. Alla fine, questo flusso di pensieri mi ha portato a una serie di domande che hanno incoraggiato la progettazione e lo sviluppo di un questionario sulla percezione della qualit\u00e0 delle immagini. L’idea del sondaggio \u00e8 che gli utenti forniscono delle valutazioni soggettive<\/em> sulla qualit\u00e0. Questo viene fatto chiedendo ai partecipanti di dare un voto alle immagini senza un riferimento oggettivo a quella che \u00e8 la \u201cperfezione\u201d. Questo \u00e8, dopo tutto, il modo in cui le persone vedono le immagini in situ<\/em>.<\/p>\n Quando si vuole quantificare il comportamento degli utenti, \u00e8 inevitabile almeno prendere in considerazione un sondaggio se non addirittura sceglierlo alla fine per raccogliere dei dati da un gruppo di persone. Dopo tutto, i sondaggi sono perfetti quando il vostro obiettivo \u00e8 ottenere qualcosa di misurabile. Tuttavia, il sondaggio \u00e8 uno strumento seducente ma pericoloso, come ci avverte Erika Hall<\/a>. Sono semplici da fare e condurre e se ne abusa regolarmente nella loro divulgazione. Non sono degli ottimi tool per valutare il comportamento passato. Sono altrettanto scarsi (se non peggio) nel predire il comportamento futuro. Per esempio, la scala da 1 a 10 spesso usata per i questionari di soddisfazione dei clienti non dicono davvero molto riguardo a quanto siano effettivamente soddisfatti i clienti o quanto sia probabile che compreranno un prodotto in futuro.<\/p>\n La sfortunata realt\u00e0, tuttavia, \u00e8 che al posto del mio controllo su centinaia di partecipanti di persona, il sondaggio \u00e8 l’unico strumento veramente pratico che ho per misurare come le persone percepiscono la qualit\u00e0 dell’immagine cos\u00ec come se (e potenzialmente come) le misurazioni della performance sono collegate a queste percezioni. Quando ho progettato il sondaggio, mi sono attenuto alle seguenti linee guida:<\/p>\n Procedendo, tutto quello che possiamo fare \u00e8 riconoscere che stiamo interpretando dei dati ottenuti sotto l’ipotesi che i partecipanti siano sinceri e comprendano il task che gli \u00e8 stato assegnato. Anche se la metrica della percezione viene scartata dai dati, ci sono ancora delle metriche di performance oggettive raccolte che potrebbero narrare una storia avvincente. Da qui, si tratta di definire le domande che guideranno la ricerca.<\/p>\n Nella ricerca, state cercando delle risposte a delle domande. Nel caso di questo particolare lavoro, volevo risposte alle seguenti domande:<\/p>\n Sono domande importanti. Per me, tuttavia, rispondere all’ultima domanda era l’obiettivo primario. Ma la strada per le risposte era (e continua ad essere) un viaggio complesso di scelte di design e sviluppo. Cominciamo coprendo alcune delle tecniche usate per raccogliere informazioni dai partecipanti al sondaggio.<\/p>\n Quando si misura la percezione della qualit\u00e0 delle immagini da parte delle persone, bisogna tenere in considerazione i device. Dopo tutto, lo schermo di un determinato device sar\u00e0 pi\u00f9 o meno capace di altri. Fortunatamente, feature HTML quali Rispetto alle caratteristiche e condizioni del browser, JavaScript ci d\u00e0 moltissimi strumenti per identificare aspetti importanti del device di un utente. Per esempio, la propriet\u00e0 In merito alle capacit\u00e0 di schermo, Il fedele metodo Nei casi in cui JavaScript non \u00e8 disponibile, non possiamo raccogliere nessuno<\/em> di questi dati. Quando raccogliamo le valutazioni dagli utenti che hanno disabilitato JavaScript (o che in alternativa non possono far girare JavaScript), devo accettare che ci saranno dei gap nei dati. L’informazione base che siamo ancora in grado di raccogliere fornisce per\u00f2 alcuni valori.<\/p>\n Come ricorderete, una delle domande iniziali che ho posto era come gli utenti percepissero la qualit\u00e0 delle immagini WebP. Il request header Come potete vedere, il content type WebP di In questo esempio, sto registrando il support status del browser per WebP in una costante JavaScript<\/a> che posso usare in seguito per modificare l’invio dell’immagine. Avrei potuto<\/em> usare l’elemento Ricorderete che una delle prime domande a cui mi sono prefissato di rispondere era se la performance avesse un impatto sulla percezione della qualit\u00e0 dell’immagine. A questo punto dello sviluppo della web platform, ci sono varie API che aiutano a cercare una risposta:<\/p>\n Usando queste API, possiamo registrare le metriche di performance per la maggior parte dei partecipanti. Ecco un esempio semplificato di come il sondaggio usi la Resource Timing API per raccogliere metriche di performance per il campione di immagine caricato:<\/p>\n Se \u00e8 disponibile la Resource Timing API e il metodo Definire la ricerca<\/h2>\n
Una parola sui sondaggi<\/h3>\n
\n
Fare le domande giuste<\/h3>\n
\n
Scoprire le caratteristiche del device e del browser<\/h3>\n
srcset<\/a><\/code> e picture<\/a><\/code> sono molto appropriate per inviare l’immagine migliore a ogni dato schermo. Ed \u00e8 di vitale importanza perch\u00e9 la percezione della qualit\u00e0 dell’immagine secondo una persona pu\u00f2 essere influenzata negativamente se un’immagine \u00e8 della dimensione sbagliata per lo schermo del device. Di contro, la performance pu\u00f2 subire un impatto negativo se un’immagine di qualit\u00e0 eccessivamente alta viene mandata a un device con uno schermo piccolo. Questi sono fattori che meritano di essere presi in considerazione quando si scoprono le relazioni potenziali tra la performance e la qualit\u00e0 percepita.<\/p>\ncurrentSrc<\/code> rivela quale immagine si sta mostrando da un array di immagini responsive. In assenza di currentSrc<\/code>, posso in qualche modo assumere con sicurezza che manchi il supporto per srcset<\/code> o picture<\/code> e utilizzare il fall-back al valore src<\/code> del tag img<\/code>:<\/p>\nconst surveyImage =<\/span> document.<\/span>querySelector(<\/span>\".survey-image\"<\/span>)<\/span>;<\/span>\nlet<\/span> loadedImage =<\/span> surveyImage.<\/span>currentSrc ||<\/span> surveyImage.<\/span>src;<\/span><\/code><\/pre>\ndevicePixelRatio<\/a><\/code> ci dice la densit\u00e0 di pixel<\/a> dello schermo di un determinato device. In assenza di devicePixelRatio<\/code>, potete tranquillamente assumere un valore di fallback di 1<\/code>:<\/p>\nlet<\/span> dpr =<\/span> window.<\/span>devicePixelRatio ||<\/span> 1<\/span>;<\/span><\/code><\/pre>\ndevicePixelRatio<\/code> \u00e8 supportato in maniera eccellente dai browser<\/a>. \u00c8 altamente improbabile che quei pochi browser che non lo supportano (i.e., IE 10 e precedenti) siano usati su display ad alta densit\u00e0.<\/p>\ngetBoundingClientRect<\/code><\/a> recupera la larghezza resa di un elemento img<\/code>, mentre la propriet\u00e0 complete<\/code> dell’interfaccia di HTMLImageElement<\/code><\/a> determina se un’immagine abbia finito di caricarsi. L’ultima di queste due \u00e8 importante, perch\u00e9 potrebbe essere preferibile scartare risultati individuali in situazioni in cui le immagini non si sono caricate.<\/p>\nFare sniffing per il supporto di WebP#section5<\/a><\/h3>\n
Accept<\/code> di HTTP rende pubblico il supporto di WebP in browser come Chrome. In questi casi, l’header Accept<\/code> potrebbe essere cos\u00ec:<\/p>\nAccept: image\/webp,image\/apng,image\/*,*\/*;q=0.8<\/code><\/pre>\nimage\/webp<\/code> \u00e8 uno dei content type pubblicizzati nel contenuto dell’header. Nel codice server side, potete controllare Accept<\/code> per la sotto-stringa image\/webp<\/code>. Ecco come potrebbe apparire nel codice back-end in Express<\/a>:<\/p>\nconst WebP =<\/span> req.<\/span>get(<\/span>\"Accept\"<\/span>)<\/span>.<\/span>indexOf(<\/span>\"image\/webp\"<\/span>)<\/span> !<\/span>==<\/span> -<\/span>1<\/span> ?<\/span> true<\/span> :<\/span> false<\/span>;<\/span><\/code><\/pre>\npicture<\/code> con pi\u00f9 source<\/code> e lasciare che fosse il browser a capire quale usare basandosi sul valore dell’attributo type<\/code> dell’elemento source<\/code>, ma questo approccio ha dei chiari vantaggi. Primo, c’\u00e8 meno markup. Secondo, il sondaggio non dovrebbe sempre<\/em> scegliere una sorgente WebP semplicemente perch\u00e9 il browser \u00e8 in grado di usarla. Per ogni determinato campione del sondaggio, l’app dovrebbe decidere a caso tra un’immagine WebP e una JPEG. Non tutti<\/code> i partecipanti che usano Chrome dovrebbero valutare solo<\/em> immagini WebP, ma piuttosto un mix di entrambe i formati.<\/p>\nRegistrare i dati della performance della API<\/h3>\n
\n
Server-Timing<\/code>. Questo header \u00e8 open-ended e pu\u00f2 essere popolato con le tempistiche relative alle fasi di processing back-end. Questo \u00e8 stato aggiunto al secondo giro del sondaggio per quantificare il tempo di processing back-end in generale.<\/li>\n\/\/ Get information about the loaded image\n<\/span>const surveyImageElement =<\/span> document.<\/span>querySelector(<\/span>\".survey-image\"<\/span>)<\/span>;<\/span>\nconst fullImageUrl =<\/span> surveyImageElement.<\/span>currentSrc ||<\/span> surveyImageElement.<\/span>src;<\/span>\nconst imageUrlParts =<\/span> fullImageUrl.<\/span>split(<\/span>\"\/\"<\/span>)<\/span>;<\/span>\nconst imageFilename =<\/span> imageUrlParts[<\/span>imageUrlParts.<\/span>length -<\/span> 1<\/span>]<\/span>;<\/span>\n\n\/\/ Check for performance API methods\n<\/span>if<\/span> (<\/span>\"performance\"<\/span> in<\/span> window &&<\/span> \"getEntriesByType\"<\/span> in<\/span> performance)<\/span> {<\/span>\n \/\/ Get entries from the Resource Timing API\n<\/span> let<\/span> resources =<\/span> performance.<\/span>getEntriesByType(<\/span>\"resource\"<\/span>)<\/span>;<\/span>\n\n \/\/ Ensure resources were returned\n<\/span> if<\/span> (<\/span>typeof<\/span> resources ==<\/span>=<\/span> \"object\"<\/span> &&<\/span> resources.<\/span>length ><\/span> 0<\/span>)<\/span> {<\/span>\n resources.<\/span>forEach(<\/span>(<\/span>resource)<\/span> =><\/span> {<\/span>\n \/\/ Check if the resource is for the loaded image\n<\/span> if<\/span> (<\/span>resource.<\/span>name.<\/span>indexOf(<\/span>imageFilename)<\/span> !<\/span>==<\/span> -<\/span>1<\/span>)<\/span> {<\/span>\n \/\/ Access resource images for the image here\n<\/span> }<\/span>\n }<\/span>)<\/span>;<\/span>\n }<\/span>\n}<\/span><\/code><\/pre>\ngetEntriesByType<\/code> ritorna dei risultati, viene ritornato un oggetto con le tempistiche, che assomiglia a questo:<\/p>\n{<\/span>\n connectEnd:<\/span> 1156.5999999947962<\/span>,<\/span>\n connectStart:<\/span> 1156.5999999947962<\/span>,<\/span>\n decodedBodySize:<\/span> 11110<\/span>,<\/span>\n domainLookupEnd:<\/span> 1156.5999999947962<\/span>,<\/span>\n domainLookupStart:<\/span> 1156.5999999947962<\/span>,<\/span>\n duration:<\/span> 638.1000000037602<\/span>,<\/span>\n encodedBodySize:<\/span> 11110<\/span>,<\/span>\n entryType:<\/span> \"resource\"<\/span>,<\/span>\n fetchStart:<\/span> 1156.5999999947962<\/span>,<\/span>\n initiatorType:<\/span> \"img\"<\/span>,<\/span>\n name:<\/span> \"https:<\/span>\/\/imagesurvey.site\/img-round-2\/1-1024w-c2700e1f2c4f5e48f2f57d665b1323ae20806f62f39c1448490a76b1a662ce4a.webp\",\n<\/span> nextHopProtocol