Rendi la generazione di origini di immagini ad alte prestazioni una parte perfetta del tuo il processo di sviluppo.
Tutte le sintassi presenti in questo corso, dalla codifica dei dati immagine alla codifica
markup alla base delle immagini adattabili: sono metodi di comunicazione tra le macchine e le macchine. Hai
ha scoperto vari modi per far sì che un browser client comunichi le sue esigenze a un server e che un server risponda in natura.
Il markup delle immagini adattabili (srcset
e sizes
in particolare) riesce a descrivere una quantità scioccante di informazioni relativamente
con pochi caratteri. Meglio o peggio, la brevità è dovuta alla progettazione: rende queste sintassi meno concise e così più facili per gli sviluppatori
potrebbero renderli più difficili da analizzare per un browser. Maggiore è la complessità aggiunta a una stringa, più
possibili errori dei parser o differenze involontarie di comportamento da un browser all'altro.
Tuttavia, la stessa caratteristica che può rendere questi soggetti così intimidatori può anche fornirti delle soluzioni: una sintassi semplice read dalle macchine è una sintassi scritta più facilmente dalle loro macchine. Quasi certamente hai visto molti esempi di modelli codifica e compressione di immagini come utente del web: qualsiasi immagine caricata sul Web tramite piattaforme di social media, contenuti sistemi di gestione dei contenuti (CMS) e persino i client di posta passeranno quasi inevitabilmente attraverso un sistema che ridimensiona, ricodifica, e li comprime.
Analogamente, attraverso plug-in, librerie esterne, strumenti autonomi per il processo di compilazione o un uso responsabile dello scripting lato client, il markup dell'immagine adattabile si presta subito all'automazione.
Queste sono le due preoccupazioni principali relative all'automazione delle prestazioni delle immagini: gestione della creazione delle immagini (le loro codifiche),
compressione e le origini alternative che utilizzerai per compilare un attributo srcset
, generando così il nostro markup rivolto agli utenti.
In questo modulo scoprirai alcuni approcci comuni alla gestione delle immagini nell'ambito di un flusso di lavoro moderno, che sia
fase automatizzata del processo di sviluppo, attraverso il framework o il sistema di gestione dei contenuti alla base del tuo sito, oppure
sono quasi completamente astratti da una rete CDN (Content Delivery Network) dedicata.
Automatizzare la compressione e la codifica
Difficilmente ti ritroverai in una posizione in cui poter determinare manualmente la codifica e il livello ideali una compressione di ogni singola immagine da usare in un progetto, come non faresti. Come è importante che le dimensioni di trasferimento delle immagini siano il più piccolo possibile, delle impostazioni di compressione e il salvataggio di origini alternative per ogni asset immagine destinato a un sito web di produzione introdurrà un enorme collo di bottiglia nel lavoro quotidiano.
Come hai appreso durante la lettura dei vari formati e tipi di compressione delle immagini, la codifica più efficiente per un'immagine sarà sempre dettata da questa impostazione. dei relativi contenuti e, come hai imparato nelle immagini adattabili, le dimensioni alternative necessarie per le origini delle immagini saranno dettate dalla posizione che queste immagini occupano nel layout della pagina. In un flusso di lavoro moderno, dovrai affrontare queste decisioni a livello olistico piuttosto che individualmente, determinando una serie di valori predefiniti sensibili per le immagini, più adatti ai contesti in cui il loro utilizzo.
Quando si scelgono le codifiche per una directory di immagini fotografiche, AVIF è il chiaro vincitore per qualità e dimensioni di trasferimento. ma ha un supporto limitato, WebP offre un'alternativa moderna e ottimizzata e JPEG è l'impostazione predefinita più affidabile. L'opzione alternativa dimensioni che dobbiamo produrre per le immagini destinate a occupare una barra laterale in un layout di pagina varieranno molto dalle immagini significate per occupare l'intera area visibile del browser nei punti di interruzione più alti. Per le impostazioni di compressione è necessario controllare la sfocatura e artefatti di compressione su più file risultanti, lasciando meno spazio per il ritaglio di ogni possibile byte da ogni immagine in cambio di un flusso di lavoro più flessibile e affidabile. In breve, seguirai lo stesso processo decisionale che hai utilizzato per capire meglio questo corso.
Per quanto riguarda l'elaborazione stessa, ci sono un enorme numero di librerie di elaborazione di immagini open source che forniscono metodi di convertendo, modificando e modificando le immagini in batch, concorrendo su velocità, efficienza e affidabilità. Queste elaborazioni consente di applicare le impostazioni di codifica e compressione a intere directory delle immagini contemporaneamente, senza aprire un software di modifica delle immagini e in modo da preservare le fonti delle immagini originali, qualora queste impostazioni poterla regolare all'istante. Sono progettate per essere eseguite in una vasta gamma di contesti, dall'ambiente di sviluppo locale lo stesso server web, ad esempio ImageMin incentrato sulla compressione per Node.js può essere esteso per adattarsi ad applicazioni specifiche attraverso un array di plug-in, mentre ImageMagick multipiattaforma e Sharp basati su Node.js offrono un numero sbalorditivo di funzionalità pronte all'uso.
Queste librerie di elaborazione delle immagini consentono agli sviluppatori di creare strumenti dedicati all'ottimizzazione delle immagini senza problemi come parte dei tuoi processi di sviluppo standard, assicurandoti che il progetto faccia sempre riferimento a un'immagine pronta per la produzione con il minor overhead possibile.
Flussi di lavoro e strumenti per lo sviluppo locale
È possibile usare Task-runner e bundler come Grunt, Gulp o Webpack ottimizzare gli asset immagine insieme ad altre attività comuni correlate al rendimento, come la minimizzazione di CSS e JavaScript. A illustra, prendiamo un caso d'uso relativamente semplice: una directory nel tuo progetto contiene una decina di immagini fotografiche, destinati a essere utilizzati su un sito web rivolto al pubblico.
Innanzitutto, dovrai garantire una codifica coerente ed efficiente per queste immagini. Come hai appreso nei moduli precedenti,
WebP è uno standard efficiente per le immagini fotografiche in termini di qualità e dimensioni del file. WebP è ben supportato,
ma non è universalmente supportato, quindi ti consigliamo di includere anche un'immagine di riserva sotto forma di JPEG progressivo. Poi,
per usare l'attributo srcset
per una pubblicazione efficiente di questi asset, dovrai generare più
dimensioni alternative per ogni codifica.
Anche se sarebbe un'attività ripetitiva e dispendiosa in termini di tempo se eseguita con un software di modifica delle immagini, gli addetti alle attività come
I gulp sono progettati per automatizzare esattamente questo tipo di ripetizione. Il componente gulp-adattabile
che utilizza Sharp, è un'opzione tra molte che seguono uno schema simile:
raccogliendo tutti i file in una directory di origine, ricodificandoli e comprimindoli in base alla stessa "qualità" standardizzata
una forma breve che hai imparato in Formati delle immagini e compressione. I file risultanti vengono quindi restituiti in un percorso da te definito,
pronto per essere consultato negli attributi src
degli elementi img
rivolti agli utenti lasciando i file originali intatti.
const { src, dest } = require('gulp');
const respimg = require('gulp-responsive');
exports.webp = function() {
return src('./src-img/*')
.pipe(respimg({
'*': [{
quality: 70,
format: ['webp', 'jpeg'],
progressive: true
}]
}))
.pipe(dest('./img/'));
}
Con un processo come questo in atto, non subirebbero danni a un ambiente di produzione se qualcuno sul progetto inavvertitamente ha aggiunto una fotografia codificata come enorme PNG truecolor alla directory contenente le fonti delle immagini originali, indipendentemente la codifica dell'immagine originale, questa attività produrrà un file di riserva WebP efficiente e un file JPEG progressivo affidabile, livello di compressione che può essere regolato facilmente e all'istante. Naturalmente, questo processo garantisce anche che l'immagine originale file verranno conservati all'interno dell'ambiente di sviluppo del progetto, il che significa che queste impostazioni possono essere e solo l'output automatico sarà sovrascritto.
Per ottenere l'output di più file, occorre passare più oggetti di configurazione, tutti gli stessi, a parte l'aggiunta di
una chiave width
e un valore in pixel:
const { src, dest } = require('gulp');
const respimg = require('gulp-responsive');
exports.default = function() {
return src('./src-img/*')
.pipe(respimg({
'*': [{
width: 1000,
format: ['jpeg', 'webp'],
progressive: true,
rename: { suffix: '-1000' }
},
{
width: 800,
format: ['jpeg', 'webp'],
progressive: true,
rename: { suffix: '-800' }
},
{
width: 400,
format: ['jpeg', 'webp'],
progressive: true,
rename: { suffix: '-400' },
}]
})
)
.pipe(dest('./img/'));
}
Nel caso dell'esempio precedente, l'immagine originale (monarch.png) era superiore a 3,3 MB. Il file più grande generato questa attività (monarch-1000.jpeg) è di circa 150 KB. Il più piccolo, monarch-400.web, è di soli 32 KB.
[10:30:54] Starting 'default'...
[10:30:54] gulp-responsive: monarch.png -> monarch-400.jpeg
[10:30:54] gulp-responsive: monarch.png -> monarch-800.jpeg
[10:30:54] gulp-responsive: monarch.png -> monarch-1000.jpeg
[10:30:54] gulp-responsive: monarch.png -> monarch-400.webp
[10:30:54] gulp-responsive: monarch.png -> monarch-800.webp
[10:30:54] gulp-responsive: monarch.png -> monarch-1000.webp
[10:30:54] gulp-responsive: Created 6 images (matched 1 of 1 image)
[10:30:54] Finished 'default' after 374 ms
Ovviamente ti consigliamo di esaminare attentamente i risultati per individuare gli artefatti di compressione ed eventualmente aumentare la compressione per ulteriori risparmi. Poiché questa attività non è distruttiva, queste impostazioni possono essere modificate facilmente.
Detto ciò, in cambio dei pochi kilobyte che potresti ottenere con un'attenta ottimizzazione manuale, ottieni un processo non solo efficiente, ma resiliente: uno strumento che applica perfettamente le tue conoscenze sugli asset immagine ad alte prestazioni. a un intero progetto, senza alcun intervento manuale.
Markup delle immagini adattabili nella pratica
Il completamento degli attributi srcset
in genere è una procedura manuale semplice, poiché in realtà l'attributo acquisisce solo
informazioni sulla configurazione che hai già eseguito durante la generazione delle origini. Nelle attività descritte sopra, abbiamo definito
i nomi dei file e le informazioni sulla larghezza che il nostro attributo seguirà:
srcset="filename-1000.jpg 1000w, filename-800.jpg 800w, filename-400.jpg 400w"
Ricorda che i contenuti dell'attributo srcset
sono descrittivi, non prescrittivi. Non c'è niente di male nel sovraccaricare
srcset
, purché le proporzioni di ogni origine siano coerenti. Un attributo srcset
può contenere l'URI
e la larghezza di ogni taglio alternativo generato dal server senza generare richieste non necessarie; più
da cui forniamo un'immagine visualizzata, più efficiente sarà il browser in grado di personalizzare le richieste.
Come hai imparato con le immagini adattabili, ti consigliamo di utilizzare l'elemento <picture>
per gestire senza problemi il WebP
o JPEG di riserva. In questo caso, utilizzerai l'attributo type
insieme a srcset
.
<picture>
<source type="image/webp" srcset="filename-1000.webp 1000w, filename-800.webp 800w, filename-400.webp 400w">
<img srcset="filename-1000.jpg 1000w, filename-800.jpg 800w, filename-400.jpg 400w" sizes="…" alt="…">
</picture>
Come hai appreso, i browser che supportano WebP riconosceranno i contenuti dell'attributo type
e selezioneranno tale <source>
srcset
dell'elemento come elenco di immagini candidati. Browser che non riconoscono image/webp
come contenuto multimediale valido
ignora questo <source>
e utilizza invece l'attributo srcset
dell'elemento <img>
interno.
C'è un'altra considerazione da considerare in termini di supporto dei browser: i browser che non supportano il markup di immagini reattive
hanno comunque bisogno di un video di riserva, altrimenti potremmo correre il rischio che l'immagine venga danneggiata in particolari contesti di navigazione. Poiché <picture>
,
<source>
e srcset
vengono tutte ignorate in questi browser, pertanto è consigliabile specificare una sorgente predefinita nel browser <img>
src
.
Poiché il ridimensionamento di un'immagine verso il basso è semplice visivamente e la codifica JPEG è universalmente supportata, il formato una scelta sensata.
<picture>
<source type="image/webp" srcset="filename-1000.webp 1000w, filename-800.webp 800w, filename-400.webp 400w">
<img src="filename-1000.jpg" srcset="filename-1000.jpg 1000w, filename-800.jpg 800w, filename-400.jpg 400w" sizes="…" alt="…">
</picture>
sizes
può essere un po' più difficile da gestire. Come hai imparato, sizes
è necessariamente contestuale:
non possono completare l'attributo senza conoscere la quantità di spazio che l'immagine deve occupare nel layout visualizzato. Per
richieste più efficienti possibili, un attributo sizes
preciso deve essere nel nostro markup al momento in cui queste richieste
vengono creati dall'utente finale, molto prima che vengano richiesti gli stili che regolano il layout della pagina. sizes
ometti del tutto
non solo una violazione della specifica HTML, ma determina un comportamento predefinito equivalente a sizes="100vw"
, informando
al browser che l'immagine sia vincolata solo dall'area visibile stessa, il che genera il numero maggiore di origini candidati possibili
in fase di selezione.
Come nel caso di qualsiasi attività di sviluppo web particolarmente gravosa, sono stati creati numerosi strumenti per astrarre
il processo di scrittura a mano libera degli attributi sizes
. respImageLint
è assolutamente
Snippet di codice essenziale destinato a controllare l'accuratezza degli attributi sizes
e fornire suggerimenti per migliorare.
Viene eseguito come un bookmarklet, uno strumento che esegui nel browser, mentre l'utente punta alla pagina con il rendering completo contenente l'immagine
elementi. In un contesto in cui il browser comprende appieno il layout della pagina, avrà una resa quasi perfetta
consapevolezza dello spazio che un'immagine deve occupare in quel layout per ogni possibile dimensione dell'area visibile.
Uno strumento per l'analisi tramite lint degli attributi sizes
è sicuramente utile, ma ha ancora più valore come strumento per generarli all'ingrosso.
Come saprai, la sintassi srcset
e sizes
ha lo scopo di ottimizzare le richieste di asset immagine in modo visivamente semplice. Sebbene
non dovrebbe essere mai utilizzato in produzione, un valore segnaposto sizes
predefinito pari a 100vw
è perfettamente ragionevole
mentre lavori al layout di una pagina nel tuo ambiente di sviluppo locale. Una volta definiti gli stili di layout, esecuzione di respImageLint
ti fornirà attributi sizes
personalizzati che puoi copiare e incollare nel tuo markup, a un livello di dettaglio molto maggiore
rispetto a quelli scritti a mano.
Anche se le richieste di immagini avviate dal markup con rendering eseguito dal server avvengono troppo rapidamente e non è possibile generare un attributo sizes
lato client da parte di JavaScript,
lo stesso ragionamento non vale se le richieste vengono avviate lato client. Il progetto Lazysizes,
Ad esempio, è possibile rinviare completamente le richieste di immagini fino a quando non è stato stabilito il layout, consentendo a JavaScript di generare
i valori di sizes
per noi: una grande comodità per te e una garanzia delle richieste più efficienti possibili per i tuoi utenti.
Tieni presente, tuttavia, che questo approccio significa sacrificare l'affidabilità del markup del rendering eseguito dal server e la velocità
ottimizzazioni integrate nei browser e l'avvio di queste richieste solo dopo il rendering della pagina avrà
un impatto negativo sul punteggio LCP.
Ovviamente, se dipendi già da un framework di rendering lato client come React o Vue, si tratta di un debito che
e, in questi casi, utilizzando Lazysizes, gli attributi sizes
possono essere quasi completamente astratti.
Meglio ancora: man mano che sizes="auto"
su immagini con caricamento lento ottiene consenso e
per le implementazioni native, il formato Lazysize diventerà di fatto un polyfill per il nuovo comportamento standardizzato del browser.