Il Web è un mezzo visivo. La stragrande maggioranza di questo panorama visivo è grazie a file di immagini. Mentre è possibile ottenere molto con CSS e SVG in linea, la maggior parte dei siti ha ancora bisogno di file immagine.
In media, le immagini hanno rappresentato più di metà delle dimensioni della pagina l'anno scorso e le dimensioni dell'immagine anno su anno aumentano; c'era un Crescita del 21% nella dimensione dell'immagine solo nel 2014.
Allo stesso tempo, il numero e la diversità dei dispositivi che accedono al web continuano a crescere. Le risoluzioni ora variano ovunque tra 72ppi (in diminuzione comune) e oltre 600ppi.
Creare un'immagine per lo schermo di qualità sufficiente per qualsiasi dispositivo è semplice: salvalo a 1000ppi e chiamalo al giorno. L'immagine risultante sarà nitida anche sui dispositivi ad alta risoluzione. Ma mentre la tua qualità sarà alta, così anche la tua dimensione. Con il tempo di caricamento della pagina a fattore chiave in UX è nostro dovere garantire che i siti vengano consegnati prontamente ai nostri utenti. Quando le immagini sono di così alta qualità che richiedono una dozzina di secondi per il download su connessioni a banda larga, per non parlare delle connessioni mobili, sono effettivamente inutilizzabili.
L'obiettivo delle immagini reattive, quindi, non è quello di fornire un'immagine di qualità superiore agli schermi in grado di visualizzarlo (cosa che possiamo fare facilmente), l'obiettivo è quello di fornire l'immagine della massima qualità supportata e nient'altro.
Questa guida è stata progettata per insegnarti quali sono le cose che funzionano, dove sono ancora presenti i problemi e le insidie e come puoi utilizzare le immagini reattive nei siti Web oggi.
Sento il bisogno, la necessità di velocità
Perché la velocità è importante? Sicuramente nessuno è più su una connessione 3G? Nessuno usa dial-up. Se la popolazione demografica target del tuo cliente abita nella città di Manhattan, perché dovresti preoccuparti delle zone rurali del Lesotho? Il fatto è che è un mito che siamo tutti sulla banda larga superveloce, venduta da aziende che traggono profitto dal desiderio di velocità sempre maggiori.
La maggior parte delle persone trascorre almeno due ore al giorno su una connessione inferiore. Spesso mi trovo con la maggior parte del tempo a navigare quando si fa il pendolare, quando anche una connessione 3G affidabile sembra un sogno lontano.
In Aprile Google ha annunciato che la facilità di utilizzo dei dispositivi mobili sarebbe utilizzata come fattore di posizionamento per le ricerche condotte su dispositivi che considera "mobili". Anche prima, la velocità era un fattore nella classifica delle pagine - sia esplicitamente come parte dei calcoli di Google, sia implicitamente come fattore che contribuisce alla frequenza di rimbalzo.
In due siti identicamente classificati, un 1Kb in più potrebbe farti cadere dal 3 ° posto su Google, al 4 ° o 5 °. Potrebbe persino farti cadere dal 10 all'11 - in altre parole dalla pagina 1 alla pagina 2 - con tutto l'impatto associato sulle entrate del tuo cliente.
Hai davvero bisogno di quell'immagine?
L'immagine più ottimizzata che ci sia, non ha alcuna immagine. Se hai cinque immagini sul tuo sito e ne lasci cadere una, ti sei salvato del 20%, forse ancora più importante, ti sei salvato una richiesta http. Se abbandonassimo tutte le immagini dai nostri siti, ci saremmo risparmiati al 100% e tutte e cinque le richieste http. Quindi perché non farlo?
Non rilasciamo immagini dai nostri siti perché comunicano in modo più efficace del testo a breve termine. Creano una connessione emotiva che attira gli utenti nei contenuti.
Lo sappiamo gli utenti non leggono le pagine web . Pochissime persone leggono contenuti approfonditi online. Le immagini ci permettono di connetterci, comunicare e rafforzare un marchio in una frazione del tempo che il testo può gestire.
Le immagini possono essere grandi e ingombranti da scaricare, ma una volta visualizzate nel browser sono molto più efficienti del testo per stabilire il coinvolgimento degli utenti e rafforzare un messaggio di marca.
Le immagini reattive ci aiutano a garantire che le immagini di connessione emotiva costruite non vengano perse quando l'utente impaziente colpisce il pulsante Indietro.
Che ne dici di SVG?
SVG (Scaleable Vector Graphics) è una delle vere tecnologie pionieristiche del Web. È così lontano dalla curva che la maggior parte dei designer non ha ancora riconosciuto il suo vero potenziale.
SVG - come suggerisce il nome - è basato sul vettore. Ciò significa che i grafici SVG sono costruiti da punti, angoli e distanze. SVG è anche - come suggerisce il nome - scalabile, il che significa che verrà visualizzato ugualmente bene su un iMac 5k o uno smartphone Android, senza perdita di qualità e senza modifiche nelle dimensioni del file.
Se hai un'illustrazione piatta, un'icona, un logo, quasi tutto ciò che può essere visualizzato come SVG, allora SVG è la strada da percorrere.
La maggior parte delle immagini sul Web sono bitmap. In generale, il modo in cui una bitmap funziona è descrivere ciascun pixel uno alla volta, il suo colore (in RGB - rosso, verde e blu) e in alcuni casi la sua trasparenza. Se hai un'immagine che misura 100 px per 100 px, hai un'immagine con 10.000 pixel; se ogni pixel ha 4 valori per descriverlo, allora l'immagine ha 40.000 bit di dati ad esso associati. Sembra molto, no? A volte, è meno di una grafica vettoriale.
Si consideri un'immagine 1px per 1px; ciò richiederebbe 4 bit di dati da registrare come bitmap (valori rosso, verde, blu e alfa). Consideriamo ora lo stesso pixel quadrato registrato come un vettore; ciò richiederebbe x, y, larghezza e altezza del rettangolo, oltre ai valori RGBA.
Questi sono esempi rudimentali, ma sono accurati. Spesso, una versione vettoriale di un'immagine, se ne abbiamo persino una disponibile, supera la dimensione del file della bitmap equivalente e quindi la bitmap è l'unica scelta sensata.
(Mis) utilizzando JavaScript
Come la maggior parte dei problemi nella vita (se la tua vita è online) le immagini reattive possono essere risolte da JavaScript. In effetti per un certo numero di anni JavaScript è stato l'unico modo per risolvere il problema. JavaScript può testare le abilità di un utente, determinare quale tipo di browser è e scrivere un tag immagine HTML standard, contenente l'immagine appropriata.
I web designer che si oppongono all'uso di JavaScript lo fanno in genere perché alcune persone lo spengono . Tuttavia, non è più così, specialmente sul web mobile, ma ci sono alcuni problemi persistenti: la scrittura di un'immagine con JavaScript significa che l'immagine non verrà analizzata dai robot del motore di ricerca e verrà visualizzata solo dopo lo script come eseguito, per esempio.
Il più grande problema con l'utilizzo di JavaScript è che si tratta di un uso improprio dello scopo principale di JavaScript. HTML contiene dati, CSS gestisce la presentazione, JavaScript gestisce la funzionalità. Quando interrompiamo questi ruoli strutturati, iniziamo a riscontrare problemi che richiedono che gli hacker li risolvano. Le immagini sono dati e dovrebbero quindi essere gestite da HTML.
Il problema con i browser
Sin dalla prima idea di RWD, le immagini sono state il principale ostacolo. Ma ora stiamo iniziando a trovare modi per risolvere i vari problemi. Tecniche che sono temprate dalla battaglia e abbastanza efficaci da essere considerate best-practice. Gli sviluppatori dedicati hanno rinunciato al loro tempo per fare pressione sul WC3 per le soluzioni ufficiali e ora, per la prima volta, le immagini reattive sono pratiche.
La chiave per le immagini reattive è che sono state progettate con una piena consapevolezza dei difetti del Web. È stato prestato particolare attenzione affinché le soluzioni di immagine reattive non infrangano i browser esistenti, in modo che anche nei browser che non supportano le immagini reattive, il codice fallirà in modo silenzioso e non risponderà, verranno visualizzate le immagini predefinite.
In questo articolo vedremo due elementi HTML ufficiali dell'immagine reattiva: srcset e picture.
Al momento, Edge, Safari e iOS Safari supportano solo un sottoinsieme delle specifiche srcset . Firefox, Chrome, Opera, il browser Android e le prossime versioni di Safari e iOS Safari lo supportano completamente. (Discuteremo le differenze di seguito).
Al momento l'elemento immagine è completamente supportato da Firefox, Chrome, Opera e Android Browser. Edge, Safari e iOS Safari non lo supportano e non hanno annunciato un calendario per l'implementazione.
Anche tra i browser che supportano il nuovo codice, ci sono incongruenze in quanto i diversi produttori di browser interpretano le specifiche del W3C in modi diversi. Ad esempio, quando si specifica un cambio di immagine da piccolo a grande in base alla dimensione del viewport, alcuni browser passeranno all'immagine grande quando il viewport è 1px più grande della dimensione preferita dell'immagine piccola, altri passeranno all'immagine grande solo quando il viewport favorito dalla grande immagine è completamente abbinata.
In sintesi, i browser sono suddivisi in due campi: quelli che preferiscono le immagini di qualità superiore laddove possibile, e quelli che preferiscono i download più piccoli laddove possibile. I produttori di browser ne stanno ancora discutendo, alla fine l'implementazione di qualcuno verrà dimostrata la più popolare - personalmente spero che sia quest'ultima, perché come notato sopra le prestazioni sono fondamentali per l'esperienza dell'utente.
Per ora, l'opzione migliore per i web designer è attenersi alle specifiche e non provare a indovinare il browser. Dopo tutto, l'esperienza di default nel browser (download di qualità superiore o più veloce) fa parte di ciò che un utente seleziona per un browser predefinito, quindi se l'utente è a conoscenza dei diversi approcci, allora la preferenza del browser è probabilmente anche la preferenza dell'utente .
Responsive image best-practice (2015)
Nel corso della storia del Web, abbiamo utilizzato un elemento per indicare un'immagine, l'elemento img . In HTML5, l'elemento img ha subito un sottile cambiamento nel suo ruolo, uno progettato per abilitare le immagini reattive: l'elemento img non rappresenta più un'immagine, ma ora è un segnaposto per un'immagine.
Questa distinzione è importante, perché mentre un elemento img in precedenza conteneva un singolo set di dati immagine - sia quella bitmap o vettoriale - ora un'immagine può contenere più insiemi di dati.
L'elemento img (da ricapitolare per tutti i non codificatori) si presenta così:
La versione dell'immagine reattiva dell'elemento img si presenta così:
Quasi nessun cambiamento. Guardando questo codice, si nota una cosa importante: il codice è retrocompatibile. Se un browser succede lungo che non capisce l'attributo srcset , semplicemente lo ignorerà e renderà l'immagine secondo le specifiche originali del 1993.
Ciò significa che ora possiamo utilizzare le immagini reattive nel nostro markup, senza la necessità di rilevare feature.
Nel nuovo elemento img reattivo, src viene principalmente utilizzato come immagine predefinita e per i browser che non riconoscono srcset, mentre srcset contiene tutte le immagini in formato ad alta risoluzione disponibili per quel segnaposto.
Quando si esegue il rendering dell'elemento img , il browser determinerà da solo quale file immagine è il più appropriato.
Utilizzando srcset
Ora che sappiamo che srcset fallirà silenziosamente nei browser che non la supportano, siamo liberi di aggiungere un'immagine extra:
In questo caso, qualsiasi browser che supporta srcset visualizzerà image-b.jpg e qualsiasi browser che non supporta srcset visualizzerà image-a.jpg.
È importante notare che il browser scarica solo l'immagine che decide di voler visualizzare, non scarica entrambe le immagini e ne sceglie una.
Purtroppo questo non ci porta molto lontano, perché a meno che non stiamo dimostrando il supporto di srcset , non c'è un'applicazione pratica per cambiare le immagini basandosi esclusivamente sul supporto di srcset .
La soluzione è fornire al browser informazioni aggiuntive su quale immagine scegliere. Per fare ciò, dobbiamo fornire informazioni sullo spazio disponibile o sulla densità dei pixel.
Usando il x-descrittore
Il descrittore x indica a un browser quanto sono densi i pixel di un'immagine.
Se, ad esempio, si desidera fornire un'immagine retina con il doppio del numero di pixel di un'immagine standard, si specifica l'immagine retina in srcset, seguita da uno spazio, quindi la parola chiave "2x".
Abbiamo la nostra immagine:
Per aggiungere un'opzione di retina per il browser, aggiungiamo il seguente srcset:
In questo caso, ci sono tre possibili risultati:
se il browser non supporta srcset , utilizzerà il file immagine specificato nell'attributo src ;
se il browser supporta srcset e ha uno schermo capace di una doppia risoluzione, utilizzerà l'immagine specificata nell'attributo srcset;
se il browser supporta srcset ma non ha una schermata ad alta risoluzione, utilizzerà l'immagine specificata nell'attributo src (quando non viene specificata alcuna immagine "1x" nell'attributo srcset , si assume che l'attributo src sia quell'immagine opzione).
Il supporto del browser è buono e in rapido miglioramento. Con un attributo abbiamo risolto l'enigma delle immagini reattive, ci dite!
Un'ultima cosa da notare sul descrittore x: la scelta dell'immagine da caricare si basa sulla densità dei pixel, quindi se un utente ingrandisce il browser al 200% (dimezzando in modo efficace la dimensione dell'immagine e raddoppiando così la densità dei pixel) il 2x l'immagine si caricherà. Questo può avere un effetto dannoso sull'accessibilità - di certo non vogliamo vedere i siti che caricano più lentamente per i non vedenti, semplicemente perché scelgono di ingrandire il loro browser.
Usando il descrittore di w
Il w-descriptor è un po 'più avanzato del descrittore x. Il descrittore di w funziona dicendo al browser quanti pixel effettivi esistono sull'asse x (la larghezza) di una particolare opzione di immagine.
Edge, Safari e iOS Safari non supportano w-descriptor al momento della scrittura, quindi la sua utilità è in qualche modo ridotta.
Ritorniamo alla nostra immagine originale:
Se questa immagine ha una larghezza nativa di 1600 pixel e se vogliamo aggiungere un'immagine retina, come abbiamo fatto con il descrittore x sopra, dovremmo specificare un'immagine nell'attributo srcset largo 3200 pixel:
C'è un grande trucco con il descrittore w: sebbene l'attributo src sia considerato come predefinito quando si specificano le immagini usando il descrittore x, viene ignorato del tutto dai browser che supportano srcset se si usa il descrittore w. Quando si utilizza il descrittore di w, è necessario specificare esplicitamente il valore predefinito aggiungendo una seconda opzione di immagine srcset , con il proprio descrittore di w, e separandoli con una virgola:
Che ci conduce ordinatamente su ...
Utilizzando più immagini
Essere in grado di specificare un'opzione di immagine ad alta risoluzione per il browser direttamente nel nostro codice HTML è decisamente interessante, ma come probabilmente avete indovinato, diventa ancora più interessante quando specifichiamo più immagini.
L'obiettivo delle immagini reattive è quello di fornire l'immagine della migliore qualità utilizzabile dal dispositivo di accesso, ma niente di più. Quindi fornire semplicemente un'immagine di retina non è adeguato, dobbiamo fornire immagini, ad esempio, 1x, 1.5x, 2x, 2.5x e 3x.
Ancora una volta, ecco il nostro markup originale dell'immagine:
Eccolo con un'immagine di retina fornita come opzione per il browser:
Eccolo, questa volta con opzioni extra in srcset, separate da virgole:
Poiché le parole chiave significano cose diverse per persone diverse, trovo consigliabile nominare le mie immagini in base al descrittore x a cui appartengono, sia come aiuto di memoria personale, sia per garantire che le diverse dimensioni siano chiare agli altri membri del team:
Ricorda, non stiamo dicendo al browser quale immagine mostrare, stiamo facendo sapere le opzioni disponibili e permettendogli di scegliere da sé. Il browser scaricherà solo una di queste immagini.
Un trucco con più immagini: non specificare mai due immagini nell'attributo srcset con un x-descrittore e un descrittore dicodici corrispondenti , ad esempio:
L'attributo sizes è un'aggiunta particolarmente interessante alla specifica, perché l'attributo size prende i suoi valori relativi al viewport, non all'immagine.
Usando il valore vw (larghezza vista), specifichiamo l'area dell'immagine relativa alla larghezza del browser: ricorda che l'elemento img ora è effettivamente solo un segnaposto, quindi non stiamo specificando la dimensione effettiva dell'immagine, stiamo specificando dimensione del segnaposto che conterrà l'immagine.
100vw è il 100% della larghezza della finestra, 50vw è il 50% della larghezza della finestra, 25vw è il 25% della larghezza della finestra, ecc.
Se volessimo impostare la larghezza img alla metà della larghezza del browser, utilizzeremmo:
Questo non è particolarmente utile finché non lo combiniamo con le query sui media ...
Utilizzando le query multimediali
L'attributo size diventa molto più potente quando lo combiniamo con le query multimediali. Possiamo separare più larghezze della vista utilizzando le virgole e indicare al browser quale utilizzare utilizzando una query multimediale in stile CSS.
Ad esempio, immagina che vogliamo che l'immagine raggiunga l'80% della larghezza della nostra finestra sulla maggior parte dei dispositivi, ma su dispositivi di piccole dimensioni (come i telefoni) con una larghezza di 380 px o meno, vogliamo sfruttare al massimo il spazio disponibile calcolando il 100% della larghezza, dovremmo scrivere in questo modo:
Seguendo questa logica, qualsiasi browser con un viewport di 380 px o meno imposterà la larghezza dell'immagine al 100% del viewport. Qualsiasi altro browser farà sì che la query multimediale restituisca false e il browser passerà al valore successivo dell'attributo sizes , che in questo caso è 80vw.
Come regola generale, mi sento a disagio nell'usare le query multimediali in HTML. Proprio come i dati di immagine reattivi appartengono all'HTML (non a JavaScript), le query multimediali appartengono al CSS (non all'HTML). Tuttavia, l'opzione è lì per te se ne hai bisogno.
Migliori pratiche pratiche dell'immagine (2016?)
Non so voi, ma sono piuttosto eccitato dalle possibilità di srcset. È una soluzione semplice a un problema difficile e sembra fornire tutto ciò di cui abbiamo bisogno.
Ma, come gli autobus, aspetti 20 anni per una soluzione ufficiale alle immagini reattive, e poi due si presentano contemporaneamente. Oltre all'attributo srcset dell'elemento img , abbiamo anche l'elemento picture .
L'elemento grafico è un altro segnaposto, anche se più tradizionale. È stato progettato per simulare gli elementi video e audio in HTML5, quindi la sua sintassi sarà familiare ai più. L'elemento picture è pensato per essere utilizzato quando è necessario un controllo maggiore di quello che srcset può fornire.
Purtroppo, l'elemento picture ha un supporto browser molto inferiore rispetto a srcset e non sempre fallisce silenziosamente.
Utilizzando l'elemento dell'immagine
Ecco il nostro elemento dell'immagine originale:
Ecco la nostra immagine annidata all'interno di un elemento dell'immagine:
Possiamo anche specificare un srcset per un elemento img all'interno di un elemento picture :
Utilizzando l'elemento sorgente
L'elemento picture non prende vita finché non aggiungiamo l'elemento source :
Quando si seleziona il file da utilizzare, il browser inizierà con il primo elemento di origine e si sposterà tra gli elementi finché non troverà uno il cui attributo multimediale si risolve in true, quindi utilizzerà srcset di tale elemento di origine.
Ad esempio, potremmo specificare diverse immagini per i formati verticale e orizzontale:
Possiamo anche specificare più immagini usando x-descriptor e w-descriptor:
Come con l'uso delle media query nell'attributo delle taglie , metterei in dubbio la saggezza di controllare le versioni di immagini in base allo stile, in markup anziché in un foglio di stile. Tuttavia, l'opzione per utilizzare l'attributo multimediale è lì se ne hai bisogno.
Usando il tipo
L'elemento immagine diventa davvero utile quando viene utilizzato per scambiare diversi tipi di immagini.
Immagina di avere un file PNG standard, ma vogliamo usare a File WebP, che in genere è più piccolo del 26% - ricorda che le immagini reattive riguardano la migliore qualità d'immagine, alle dimensioni più ridotte - ma attualmente supportate solo da Chrome, Opera e il browser Android. Dovremo utilizzare l'attributo type per determinare se WebP è supportato:
In questo caso, il browser controllerà se il formato di immagine WebP è supportato. Se lo è, determinerà se lo schermo ha una densità di pixel sufficiente per visualizzare l'immagine retina-image.webp , altrimenti visualizzerà l'immagine image.webp . Se WebP non è supportato, il browser passerà direttamente all'elemento img e lavorerà attraverso le opzioni srcset e src nel modo in cui abbiamo già familiarità.
L'attributo type significa che possiamo fornire formati di immagine molto più piccoli dove supportati, risultando in una dimensione di file più piccola.
Problemi noti
IE9 ha un problema noto, questo impedisce che l'elemento dell'immagine non vada in silenzio. Per gestire IE9 è necessario ingannare IE9 pensando che gli elementi di origine facciano parte di un elemento video :
< !—[if IE 9]>< ![endif]—>
È una brutta soluzione, ma meglio di nessuna soluzione. Possiamo solo sperare che il rilascio di Windows 10 affronti la fine di IE9, perché mentre Edge non supporta ancora l'elemento picture , non lo supporta nel modo corretto (ignorandolo).
Ci sono polyfills ciò può aiutarti a supportare l'elemento immagine su IE, ma la mia preferenza è di evitarli. Diffido di problemi di patch con JavaScript, incide sulle prestazioni e porta a un codice meno gestibile.
Per questo motivo, consiglio di evitare l'elemento picture per ora. A meno che tu non stia utilizzando un sito di e-commerce su larga scala, è improbabile che il risparmio extra sul tempo di download offerto dal formato WebP non superi l'inconveniente di applicare patch al markup con lo script.
Una volta che IE9 scende sotto l'1%, che dovrebbe accadere ad un certo punto nel prossimo anno, l'elemento dell'immagine diventerà vitale. Se stai leggendo questo nel 2016, probabilmente sei a posto.
Creare immagini reattive
A differenza di SVG, le immagini bitmap non si ingrandiscono. La nostra strategia per gestirli, sia che stiamo usando srcset o l'elemento picture , è di fornire un'immagine diversa in base alle capacità del browser. Per gestirlo, dobbiamo fornire una varietà di dimensioni dell'immagine diverse.
La maggior parte delle applicazioni di modifica delle immagini ha automatizzato il processo di esportazione di più versioni di una singola immagine. Non importa quale applicazione si utilizza, a patto di avere più dimensioni di immagine senza dover ridimensionare manualmente e salvare ciascuna di esse.
Adobe Photoshop è l'editor di bitmap de facto. Non è una grande scelta per il lavoro di progettazione, ma il suo flusso di lavoro di elaborazione delle immagini è fluido e affidabile. Generare più risoluzioni di immagine in Photoshop è relativamente semplice:
Apri l'immagine a cui desideri generare più versioni e posizionala sul proprio livello.
Rinominare il livello come nome del file che si desidera generare (inclusa l'estensione).
Seleziona File> Genera> Risorse immagine e una cartella con la tua nuova immagine verrà salvata insieme al tuo PSD.
Rinominare il livello, specificando ogni immagine che si desidera generare preceduta dalla scala desiderata. Non è necessario ripetere il passaggio 3, una volta rinominato il livello, le immagini verranno generate automaticamente.
Il credito per l'immagine va aPhilip Collier.
Per ulteriori informazioni sulla generazione di immagini in Photoshop, Vedere qui.
Sulla base di queste immagini, possiamo offrire al browser cinque diverse opzioni:
Conclusione
L'elemento img ha fatto molta strada in 20 anni. Oppure, per essere più precisi, l'elemento img è stato inadeguato per 18 anni, poi è scattato per la linea negli ultimi due anni, al punto che ora è relativamente sofisticato.
L'importante è che siamo arrivati alla (e) soluzione (i).
Tra le due opzioni disponibili, srcset e picture, la prima è di gran lunga la più supportata. Se stai costruendo il 95% dei siti là fuori, allora il supporto superiore e l'implementazione più semplice dell'attributo srcset sono la tua migliore opzione.
Se stai utilizzando un sito di e-commerce di grandi dimensioni, con migliaia di immagini di prodotti, il lavoro extra per servire il formato WebP potrebbe essere utile, soprattutto perché il supporto per l'elemento grafico aumenta nei prossimi due anni.
Il più grande punto debole nelle opzioni attuali è che i browser non dispongono attualmente di un modo per selezionare un'immagine in base alla velocità della loro connessione. Siamo costretti a credere che dispositivi più capaci siano anche su connessioni superiori.
In definitiva, possiamo finalmente offrire le immagini della più alta qualità praticamente possibile, alle dimensioni più ridotte. Ciò significa un'esperienza migliore, in un tempo più breve, che può essere solo qualcosa da abbracciare.
Usi dell'immagine in vetrina,immagine di montagnaeimmagine del dispositivovia Shutterstock.
