Un'immagine larga 1920 pixel in una pagina viene scaricata per intero anche da chi usa lo smartphone, per poi essere ridotta a 390 pixel sullo schermo: cinque volte la banda e un caricamento più lento per niente. srcset lascia che sia il browser a scegliere la versione adatta allo schermo, a patto che tu abbia prodotto quelle versioni.
Perché una sola immagine non basta
L'LCP dei Core Web Vitals è di solito la grande immagine above the fold. Se a uno smartphone servi un file largo 1920 da 400KB, l'LCP raramente rientra nei 2,5 secondi; una versione larga 480 da 40KB, sulla stessa connessione, è di un ordine di grandezza più veloce. Il segnale di esperienza della pagina di Google legge direttamente quel valore.
All'opposto, un'immagine larga 768 su un desktop grande appare sfocata. Da qui le varie dimensioni, tra cui sceglie il browser.
Una tabella pratica dei breakpoint
I breakpoint seguono la larghezza con cui l'immagine viene mostrata nella pagina, non quella del viewport. Per i due casi più comuni, banner a tutta larghezza e figure negli articoli:
- Immagini a tutta larghezza (hero, banner): 480, 768, 1200, 1920. Telefono, tablet, portatile, schermo grande.
- Figure negli articoli (colonna di contenuto fino a circa 800): 400, 800, 1200; il 1200 serve gli schermi 1,5x–2x.
- Miniature e card (mostrate a circa 300): 300 e 600.
Più passaggi non significa meglio. Ognuno è un'esportazione in più e un file in più da conservare, e i browser tollerano le differenze, quindi passi distanti 1,5–2x sono il punto giusto. Quattro passi coprono più di nove combinazioni di dispositivi su dieci.
Servono le versioni 2x?
Gli schermi Retina e la maggior parte degli smartphone hanno una densità di 2x–3x; un'immagine mostrata a 400 di larghezza richiede 800 pixel per risultare nitida. I passi più grandi della tabella fanno già da versione 2x dei più piccoli: 768 è il 2x per un telefono largo 390, 1200 è il 2x per una colonna di 600.
Quindi non serve un set «@2x» separato. Mantieni una distanza di circa 2x tra i passi e il browser sceglierà quello più grande in base alla densità.
Formato: prima WebP, JPG come ripiego
A parità di qualità il WebP è dal 25 al 35% più leggero del JPG e tutti i browser moderni lo supportano. Esporta WebP a ogni dimensione e tieni un ripiego JPG tramite l'elemento picture per i browser vecchi; se per il tuo pubblico i browser precedenti al 2020 non contano più, basta il solo WebP.
L'AVIF è ancora più leggero, ma nel browser codifica molto più lentamente, il che pesa sui lotti grandi. AVIF vs WebP vs JPEG approfondisce i compromessi.
Esportare l'intero set in batch
Trascina le immagini sorgente in Elaborazione immagini in batch ed esegui una volta per passo, cambiando ogni volta larghezza e suffisso:
- Dimensioni: larghezza 480, Consenti ingrandimento disattivato, output WebP all'80%, suffisso -480.
- Stesse impostazioni a 768 con suffisso -768; poi 1200; poi 1920.
- Per il ripiego JPG, passa l'output a JPG, mantieni i suffissi ed esegui di nuovo.
Ogni esecuzione richiede pochi secondi e lo ZIP contiene già hero-480.webp, hero-768.webp e così via, pronti per la cartella delle immagini. Lascia disattivato Consenti ingrandimento, così un originale da 1000 pixel non viene mai stirato fino a 1920.
Per vedere la differenza di peso a ogni passo su una sola immagine, prova il Ridimensionatore di immagini con un file.
Scrivere l'HTML
Per un'immagine a tutta larghezza:
<img src="hero-1200.jpg"
srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1920.webp 1920w"
sizes="100vw" width="1920" height="1080" alt="...">Per le figure degli articoli, imposta sizes sulla larghezza reale, per esempio sizes="(max-width: 840px) 100vw, 800px". Includi sempre width e height, così il browser riserva lo spazio e la pagina non salta.
Fatto questo, aggiungi i consigli su lazy loading e compressione di come far caricare le immagini più velocemente e la parte di immagini del tuo punteggio di prestazioni è praticamente al massimo.