Ottimizzazione delle immagini

In breve — Ottimizzare le immagini significa rendere le foto più piccole così che le pagine si carichino velocemente, senza farle apparire male. Usa un formato moderno come WebP, comprimi il file e non servire un’immagine molto più grande di come viene mostrata sullo schermo. La regola che viene infranta più spesso è questa: l’immagine grande in cima alla pagina deve caricarsi subito: non applicare mai il «lazy load» a quella. Farlo bene non migliora magicamente il ranking e non garantisce nemmeno un punteggio di velocità sufficiente: rende semplicemente le pagine veloci, ed è la velocità che conta, quindi controlla i risultati reali prima e dopo.

Che cosa fa davvero l’ottimizzazione delle immagini

Le immagini sono quasi sempre l’elemento più pesante di una pagina web. La documentazione di Google dice che le immagini sono “often the largest contributor to overall page size, which can make pages slow and expensive to load.” (traduzione) «spesso il contributo maggiore alle dimensioni complessive della pagina, che può rendere le pagine lente e costose da caricare» Ottimizzarle significa quindi una cosa sola: ridurre i byte che il visitatore deve scaricare, così la pagina appare rapidamente.

La parte che sorprende le persone è questa: il formato in sé non è un vantaggio di ranking. Passare i JPEG a WebP non migliorerà da solo le tue posizioni. Rende i file più piccoli, la pagina più veloce, ed è la velocità ad aiutare. Questo è l’articolo gemello del più ampio hub Image SEO: quello tratta alt text, nomi dei file e ricerca immagini; questo è la guida pratica per «farla caricare velocemente».

Le poche cose che contano

• Usa un formato moderno. WebP e AVIF rendono i file molto più piccoli dei vecchi JPEG e PNG senza peggiorarne l’aspetto. Oggi WebP è il default sicuro.
• Comprimi l’immagine. Anche un WebP può essere troppo grande. Passa le immagini attraverso un compressore e trova il punto in cui il file è piccolo ma continua ad avere un buon aspetto.
• Non servire un’immagine enorme in uno spazio piccolo. Se una foto viene mostrata larga solo 500 pixel, non ti serve un file da 3 000 pixel: è un download sprecato.
• Applica il lazy loading alle immagini più in basso nella pagina. Aggiungere loading="lazy" dice al browser di aspettare a caricare un’immagine finché non scorri vicino a essa. È ottimo per le immagini sotto la piega.
• Non applicare mai il lazy loading all’immagine grande in alto. L’immagine più grande visibile al primo caricamento della pagina è quella contro cui Google misura la velocità. Deve caricarsi immediatamente.

L’errore che commette la maggior parte delle persone

Applicano il lazy loading a tutto, compresa l’immagine hero in alto. Sembra una buona idea («carica meno cose!»), ma è il contrario: l’immagine in alto è quella rispetto alla quale viene misurato il punteggio di velocità della pagina, quindi ritardarla peggiora il punteggio. Caricala subito e comunica al browser che è importante. Spiego esattamente come nella scheda Avanzata.

Vuoi la versione precisa — le citazioni esatte di Google, i compromessi WebP rispetto ad AVIF, la matematica delle dimensioni e il trucco di fetchpriority? Passa alla scheda Avanzata.

In breve — L’ottimizzazione delle immagini è una disciplina della velocità della pagina e dei Core Web Vitals, non una leva diretta di ranking. La scelta del formato (WebP, AVIF) riduce i byte ma non offre alcun vantaggio SEO: Mueller lo ha detto in tre modi diversi; considera anche trasparenza, animazione e supporto attuale dei browser, non solo il rapporto di compressione. La regola singola più importante è: non applicare mai il lazy loading all’immagine LCP (di solito l’hero), perché ritarda proprio la metrica che stai ottimizzando. Imposta loading="eager" + fetchpriority="high", anche se i suggerimenti di priorità aiutano solo un collo di bottiglia nella scoperta o nei tempi di fetch, non ogni problema di LCP. loading="lazy" nativo serve alle immagini fuori dalla viewport iniziale, non a una linea fissa di pixel del «below the fold». La compressione non ha una qualità «giusta» universale: fai test per ogni tipo di immagine. Dimensioni corrette = dimensione del contenitore renderizzato × device pixel ratio, e il contenitore cambia con il layout responsive: fornisci quindi un intervallo srcset/sizes (un valore sizes errato scarica silenziosamente un’immagine sovradimensionata) con un fallback <picture>. Le immagini sono l’elemento LCP più comune sul web, motivo per cui questo articolo è collegato anche a Web Performance; ma nulla di tutto ciò garantisce un punteggio Core Web Vitals sufficiente, un cambiamento di ranking o più traffico: misura prima e dopo.

A cosa serve l’ottimizzazione delle immagini (chiariamo subito il mito)

Partiamo dal mito più grande: il formato immagine è una leva di velocità, non una leva di ranking. Convertire in WebP o AVIF non ti regala un aumento di ranking. Ti regala file più piccoli, che producono una pagina più veloce, che alimenta i Core Web Vitals: ed è quella la parte usata dai sistemi di ricerca. La catena è reale ma indiretta, e ridurla a «i formati di nuova generazione migliorano il ranking» è l’errore della maggior parte delle guide concorrenti.

La documentazione di Google è molto chiara sul perché le immagini contino per la velocità: sono “often the largest contributor to overall page size, which can make pages slow and expensive to load,” (traduzione) «spesso il contributo maggiore alle dimensioni complessive della pagina, che può rendere le pagine lente e costose da caricare» e il consiglio è “apply the latest image optimization and responsive image techniques to provide a high quality and fast user experience” (traduzione) «applicare le tecniche più recenti di ottimizzazione delle immagini e delle immagini responsive per offrire un’esperienza utente di alta qualità e veloce» (Google Search Central — Immagini). Nota il framing: esperienza utente veloce, non una ricompensa di ranking per il formato del file.

“often the largest contributor to overall page size, which can make pages slow and expensive to load,” (traduzione) «è spesso il contributo più grande alle dimensioni complessive della pagina e può rendere lento e costoso il caricamento» “apply the latest image optimization and responsive image techniques to provide a high quality and fast user experience” (traduzione) «applicare le tecniche più recenti di ottimizzazione delle immagini e delle immagini responsive per offrire un’esperienza utente di alta qualità e veloce»

Per il cosa/perché della SEO delle immagini in generale — alt text, nomi dei file, sitemap delle immagini, dati strutturati e ranking nella ricerca immagini — il compito spetta all’hub principale Image SEO. Questo articolo è il come canonico: formati, compressione, dimensionamento e strategia di caricamento.

Parti dalla regola che tutti infrangono: non applicare mai il lazy loading all’immagine LCP

Se devi portare via una sola cosa da questa pagina, porta via questa. L’elemento Largest Contentful Paint (LCP) — la cosa più grande dipinta nella viewport al caricamento — è “either an image or a web font,” (traduzione) «un’immagine o un web font» secondo web.dev (Ottimizza LCP), e nella maggior parte delle pagine è un’immagine: l’hero, l’immagine in evidenza, la foto del prodotto. web.dev formula la regola in modo quasi altrettanto netto di Google:

“either an image or a web font,” (traduzione) «un’immagine oppure un font web»

Citazione da web.dev: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (traduzione) «non applicare mai il lazy loading all’immagine LCP, perché ciò causerà sempre un ritardo inutile nel caricamento della risorsa e avrà un impatto negativo sull’LCP»

È la sfumatura che i consigli «usa sempre il lazy loading» ignorano completamente. Il lazy loading è ottimo per le immagini sotto la piega. Applicalo all’immagine LCP e ritardi attivamente l’unica metrica che stai cercando di migliorare. La guida di web.dev sul lazy loading dice la stessa cosa dall’altro lato: “Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images” (traduzione) «non applicare il lazy loading alle immagini che probabilmente si trovano nella viewport quando la pagina viene caricata, soprattutto alle immagini LCP» (Lazy loading a livello browser).

Ho sostenuto la stessa tesi nel mio articolo LCP su Ahrefs: l’elemento più grande “is usually going to be a featured image or maybe the <h1> tag,” (traduzione) «di solito un’immagine in evidenza o magari il tag <h1>» e da questo seguono le correzioni. “If you don’t need the image, the most impactful solution is to simply get rid of it. If you must have the image, I suggest optimizing the size and quality to keep it as small as possible.” (traduzione) «Se non ti serve l’immagine, la soluzione più efficace è semplicemente eliminarla. Se devi tenerla, suggerisco di ottimizzarne dimensioni e qualità per mantenerla il più piccola possibile» Dovresti “lazy load any images that you don’t need immediately” (traduzione) «caricare in lazy loading le immagini che non servono subito», ma il rovescio della medaglia è una regola rigida che scrivo in maiuscolo per un motivo: “Do not lazy load images above the fold!” (traduzione) «non applicare il lazy loading alle immagini sopra la piega»

“lazy load any images that you don’t need immediately” (traduzione) «caricare in lazy loading le immagini che non servono immediatamente» “Do not lazy load images above the fold!” (traduzione) «non applicare il lazy loading alle immagini nella parte visibile iniziale»

fetchpriority="high" sull’immagine LCP

Non applicare il lazy loading all’hero è necessario ma non sufficiente. Per assicurarti che l’immagine LCP si carichi il prima possibile, indica la sua priorità al browser. Da web.dev:

Indicazione di web.dev: “You can hint to the browser as to which resources are most important using the fetchpriority attribute… It’s a good idea to set fetchpriority=\"high\" on an <img> element if you think it’s likely to be your page’s LCP element.” (traduzione) «Puoi indicare al browser quali risorse sono più importanti usando l’attributo fetchpriority… È una buona idea impostare fetchpriority=“high” su un elemento <img> se pensi che sia probabilmente l’elemento LCP della pagina»

<img src="/hero.webp" alt="…" fetchpriority="high" width="1200" height="675">

Nel mio articolo sull’LCP descrivo fetchpriority="high" allo stesso modo: si “can be used on <img> or <link> tags and tells browsers to get the image early” (traduzione) «può essere usato sui tag <img> o <link> e indica ai browser di recuperare presto l’immagine»; lo abbino agli Early Hints (una risposta 103) come metodo complementare per avviare il fetch prima che arrivi l’HTML principale. La ricetta LCP è quindi: caricamento eager + fetchpriority="high" (+ Early Hints se lo stack li supporta). Tutto il resto della pagina può usare il lazy loading.

Tratta fetchpriority e il preload come strumenti specifici per un collo di bottiglia, non come una correzione garantita. Aiutano quando l’immagine LCP viene scoperta o recuperata in ritardo; non fanno nulla per una risposta lenta del server, una risorsa che blocca il rendering prima dell’immagine o un file davvero sovradimensionato. Conferma quale collo di bottiglia hai davvero (PageSpeed Insights o Lighthouse scompongono l’LCP nelle sue parti) prima di presumere che un suggerimento di priorità basti a spostare il numero.

loading="lazy" nativo — gratuito, semplice e corretto sotto la piega

Per ogni immagine che non si trova nella viewport iniziale, il lazy loading nativo è il modo più semplice di ottenere un miglioramento prestazionale. web.dev: “You can use the loading attribute to lazy-load images without the need to write custom lazy-loading code or use a separate JavaScript library.” (traduzione) «Puoi usare l’attributo loading per applicare il lazy loading alle immagini senza scrivere codice personalizzato né usare una libreria JavaScript separata»

<img src="/below-the-fold.webp" alt="…" loading="lazy" width="800" height="600">

Due aspetti lo mantengono sicuro:

• Basalo sulla viewport iniziale, non su una linea fissa del «below the fold». La «piega» non è un conteggio fisso di pixel: cambia in base alla dimensione della viewport e al layout. Il test effettivo è se l’immagine sarà probabilmente visibile quando la pagina viene dipinta per la prima volta. Tutto ciò che lo sarà — soprattutto l’immagine LCP — riceve loading="eager" (il default), mai lazy.
• Preferisci l’attributo nativo ai trucchi JavaScript. I lazy loader JavaScript che nascondono il vero URL in data-src e non espongono mai un src rischiano di impedire del tutto l’indicizzazione. loading="lazy" nativo (o un IntersectionObserver pulito) mantiene src visibile ai crawler. L’hub principale Image SEO tratta in dettaglio questa cautela sull’indicizzazione.

Formati moderni: WebP vs. AVIF vs. JPEG/PNG

I formati sono il punto in cui il chiarimento del mito conta di più, quindi precisiamo che cosa ti offre ciascuno: byte, non ranking.

• WebP — “often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression” (traduzione) «spesso offre una compressione migliore di JPEG, PNG o GIF, con compressione sia con perdita sia senza perdita» (web.dev — Prestazioni delle immagini). È circa il 25–35% più piccolo di JPEG con un supporto browser quasi universale. Oggi è il default sicuro per le foto.
• AVIF — “supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases.” (traduzione) «supporta la compressione con e senza perdita e in alcuni casi i test hanno mostrato un risparmio superiore al 50% rispetto a JPEG» Ha una compressione ai vertici, ma un supporto leggermente meno universale: abbinalo a un fallback WebP o JPEG.
• JPEG — il fallback universale per le fotografie.
• PNG — quando servono trasparenza o grafica con bordi netti.
• SVG — loghi e icone: vettoriale, si ridimensiona all’infinito, piccolo.

“supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases.” (traduzione) «supporta la compressione con e senza perdita e alcuni test hanno mostrato un risparmio superiore al 50% rispetto a JPEG»

Il formato da scegliere dipende anche da ciò che l’immagine deve fare, non solo da quello che comprime di più: trasparenza, animazione e coerenza con cui un browser o uno strumento supporta quella combinazione specifica entrano nella scelta insieme al risparmio di dimensioni grezzo qui sopra. Controlla il supporto attuale per la funzione esatta che ti serve, soprattutto per gli elementi animati, prima di adottare un formato come default.

Google Search supporta “BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF” (traduzione) «BMP, GIF, JPEG, PNG, WebP, SVG e AVIF» referenziati nel src di un <img>. Servi il formato moderno con un fallback graduale usando <picture>:

<picture>
  <source srcset="/photo.avif" type="image/avif">
  <source srcset="/photo.webp" type="image/webp">
  <img src="/photo.jpg" alt="…" width="1200" height="800" loading="lazy">
</picture>

L’<img src> in fondo è la tua rete di sicurezza: i browser più vecchi e i crawler vi ricadono e quello è l’URL che Google indicizza davvero.

Il formato influisce sul ranking? (No: e Mueller lo ha detto in tre modi)

Questo è l’unico filo di chiarimento del mito che vale la pena seguire per tutto il tema. Tre dichiarazioni di John Mueller, separate e indipendenti nel tempo, arrivano alla stessa conclusione: il formato influenza la meccanica di crawl/indicizzazione e il peso della pagina, mai il ranking direttamente:

1. AVIF non offre alcun vantaggio SEO. Dopo l’aggiunta del supporto AVIF nativo da parte di Google, Mueller ha confermato che non c’è alcun vantaggio SEO nell’usare AVIF rispetto agli altri formati supportati (copertura SE Roundtable).
2. WebP è «sufficiente». “WebP images are fine for Image Search” (traduzione) «le immagini WebP vanno bene per la ricerca immagini» — «sufficiente», in modo significativo, non «migliore» (copertura SE Roundtable).
3. Le particolarità dell’indicizzazione WebP non sono specifiche del formato. Quando le persone hanno visto file WebP apparire come «Crawled – currently not indexed» in GSC, il punto di Mueller era che i file immagine non vengono indicizzati come pagine HTML e che non riteneva affatto che il fenomeno fosse limitato a WebP (copertura SEJ).

Compressione e qualità: non esiste un’impostazione «giusta» universale

Il consiglio sbagliato più comune nelle guide alle immagini è una singola indicazione del tipo «comprimi all’80%». web.dev è esplicito: non esiste un numero magico:

Indicazione di web.dev: “When compressing, there isn’t a universal setting suitable for all cases. The recommended approach would be to experiment with different compression levels until you find a good compromise between image quality and file size.” (traduzione) «Quando comprimi, non esiste un’impostazione universale adatta a tutti i casi. L’approccio consigliato è sperimentare con diversi livelli di compressione finché trovi un buon compromesso tra qualità dell’immagine e dimensione del file»

In pratica: fai test per ogni tipo di immagine. Le fotografie tollerano bene una compressione lossy aggressiva; grafica, loghi e screenshot con testo mostrano rapidamente gli artefatti e spesso richiedono lossless o un’impostazione di qualità maggiore. Invece di fidarti di un solo cursore, esporta la stessa immagine a due o tre livelli di qualità e guardala alla dimensione di visualizzazione: la più piccola che non riesci a distinguere visivamente dall’originale è la tua risposta. È un flusso di lavoro reale, non «passala in TinyPNG e spera».

Dimensioni corrette: dimensione del contenitore × device pixel ratio

La regola non è «rendila semplicemente più piccola»: è abbinare la dimensione renderizzata × il device pixel ratio (DPR). Da web.dev:

Esempio di dimensionamento secondo web.dev: “An image displayed in a 500 pixel by 500 pixel container would be optimally sized at 500 pixels by 500 pixels.” (traduzione) «Un’immagine mostrata in un contenitore di 500 per 500 pixel ha dimensioni ottimali di 500 per 500 pixel»

Esempio di dimensionamento secondo web.dev: “If the device has a DPR of 2 and the image is displayed in a 500 pixel by 500 pixel container, then a square 1000 pixel image… is now the optimal size.” (traduzione) «Se il dispositivo ha un DPR pari a 2 e l’immagine è mostrata in un contenitore di 500 per 500 pixel, un’immagine quadrata da 1000 pixel è ora della dimensione ottimale»

Quindi un contenitore da 500×500 su uno schermo 2× (di classe Retina) richiede una sorgente da 1 000×1 000. Vai oltre e sprechi byte senza un guadagno percepibile; vai sotto e l’immagine appare morbida sugli schermi ad alto DPR. Per questo servi un intervallo di dimensioni e lascia scegliere il browser, usando srcset + sizes:

<img
  src="/photo-800.webp"
  srcset="/photo-400.webp 400w, /photo-800.webp 800w, /photo-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 500px"
  alt="…" width="800" height="600" loading="lazy">

Il browser legge la larghezza del contenitore (sizes) e il proprio DPR, poi sceglie il candidato giusto da srcset: la versione per la distribuzione responsive della matematica DPR qui sopra. Google raccomanda <picture> o srcset per le immagini responsive e dice di “always specify a fallback URL using the src attribute.” (traduzione) «specifica sempre un URL di fallback usando l’attributo src»

“always specify a fallback URL using the src attribute.” (traduzione) «indica sempre un URL di fallback tramite l’attributo src»

Se sbagli sizes, nulla ti avvisa. Se il valore dichiarato non corrisponde alla larghezza a cui l’immagine viene davvero renderizzata — un bug comune dopo una modifica del layout o del CSS — il browser non può saperlo e sceglie semplicemente un candidato in base al numero inaccurato che gli hai fornito; di solito scarica un file più grande di quanto il layout richieda. Questo annulla silenziosamente il lavoro su formato e compressione. L’unico modo affidabile per scoprirlo è aprire il pannello Network degli strumenti per sviluppatori, trovare la richiesta dell’immagine e confrontare le dimensioni del file consegnato con la larghezza effettiva del contenitore renderizzato.

L’esempio 500×500 qui sopra è illustrativo, non un numero da fissare per tutto il sito: la stessa immagine hero può essere renderizzata a una larghezza diversa su mobile e desktop, quindi la «dimensione del contenitore» cambia con il layout responsive invece di restare fissa. Ecco esattamente perché devi fornire un intervallo srcset anziché esportare una sola dimensione «ottimale» e considerare il lavoro concluso.

Perché tutto questo riconduce ai Core Web Vitals

Il filo conduttore che collega ogni tecnica qui sopra è LCP. Le immagini sono l’elemento LCP più comune sul web e LCP è uno dei tre Core Web Vitals. L’obiettivo di Google è: “LCP should occur within 2.5 seconds” (traduzione) «LCP dovrebbe verificarsi entro 2,5 secondi» al 75° percentile dei caricamenti delle pagine su mobile e desktop (web.dev — Vitals). I Core Web Vitals “apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (traduzione) «si applicano a tutte le pagine web, devono essere misurati da tutti i proprietari dei siti e saranno mostrati in tutti gli strumenti Google»

L’ottimizzazione delle immagini non è quindi un fattore di ranking autonomo: è un contributo a un segnale di esperienza della pagina (Core Web Vitals) che i sistemi di ranking usano davvero. Questo è il framing corretto e spiega perché l’articolo vive sia nel cluster Image SEO sia in quello Web Performance. Per l’analisi approfondita della metrica, consulta Core Web Vitals e LCP in Web Performance.

È importante dichiarare un’altra cautela: nessuna correzione di questa pagina garantisce qualcosa. I byte delle immagini sono solo una possibile componente dell’LCP — la scomposizione delle parti LCP di web.dev include anche tempo di risposta del server e risorse che bloccano il rendering prima dell’immagine, aspetti che formato e compressione non modificano — e le dimensioni dell’immagine sono solo un input del CLS, non una garanzia di un punteggio preciso. Ridurre un’immagine hero può aiutare in modo misurabile, non fare nulla o, se il vero collo di bottiglia è altrove, spostare a malapena il numero. Ottimizzare le immagini non garantisce da solo una valutazione Core Web Vitals sufficiente, un cambiamento di ranking, più traffico, più conversioni o una citazione nelle ricerche AI: questi risultati dipendono da molto più dei byte delle immagini. Tratta ogni correzione come un’ipotesi, non come un risultato acquisito: misura LCP e CLS prima e dopo, in laboratorio e sul campo, e lascia che siano i dati — non l’ipotesi che l’ottimizzazione abbia «funzionato» — a dirti se è cambiato qualcosa.

Problemi comuni di implementazione

• Le immagini di sfondo CSS non vengono indicizzate. A volte gli sviluppatori sostituiscono un <img> con un background-image per comodità di layout. Google “can find images in the src attribute of <img> element (even when it’s a child of other elements, such as the <picture> element)” (traduzione) «può trovare immagini nell’attributo src dell’elemento <img> (anche quando è figlio di altri elementi, come l’elemento <picture>)» ma “doesn’t index CSS images.” (traduzione) «non indicizza le immagini CSS» Se vuoi che l’immagine compaia nella ricerca immagini, mantienila in un <img>. (È un aspetto vicino alle prestazioni, ma l’errore è abbastanza comune da meritare una segnalazione.)
• Non rinominare in blocco i file esistenti per un «refresh» prestazionale/SEO. Mueller ha detto che serve “a lot of time” (traduzione) «molto tempo» ai sistemi di Google per rielaborare le immagini rinominate e che l’effetto è minimo se il contesto è già buono: l’hub principale Image SEO lo tratta in dettaglio.
• Larghezza/altezza mancanti. Imposta sempre width e height intrinseci (o CSS aspect-ratio) così il browser può riservare spazio prima che l’immagine si carichi: riduce lo spostamento del layout dovuto alle immagini, ma è uno degli input del CLS, non una garanzia di un punteggio preciso.

Ricetta rapida

• Immagine hero / LCP: formato moderno, dimensioni corrette, loading="eager", fetchpriority="high".
• Tutto ciò che si trova sotto la piega: loading="lazy".
• Servi WebP/AVIF con un fallback src di <picture>.
• Dimensiona in base a contenitore × DPR; fornisci un intervallo srcset con sizes.
• Comprimi per tipo di immagine: prova 2–3 livelli di qualità, non fidarti di un solo cursore.
• Imposta sempre width/height.

Per il resto della SEO delle immagini — alt text, nomi dei file, sitemap delle immagini, dati strutturati e ranking nella ricerca immagini — torna all’hub Image SEO.

Riepilogo AI

Una sintesi della versione Avanzata:

• Ottimizzazione delle immagini = velocità, non leva di ranking. La scelta del formato (WebP/AVIF) riduce i byte → pagina più veloce → Core Web Vitals migliori. Il formato in sé non offre alcun vantaggio diretto sul ranking: Mueller lo ha confermato in tre modi diversi (AVIF «nessun vantaggio SEO», WebP «sufficiente», le particolarità di indicizzazione WebP non sono specifiche del formato).
• La regola n. 1: non applicare mai il lazy loading all’immagine LCP. L’immagine che probabilmente sarà visibile al primo rendering (di solito l’hero) determina il tuo LCP; applicarle il lazy loading ritarda proprio la metrica che stai correggendo. Imposta loading="eager" + fetchpriority="high" (facoltativamente Early Hints), anche se i suggerimenti di priorità correggono solo un collo di bottiglia nella scoperta o nei tempi di fetch, non ogni problema LCP (controlla le parti dell’LCP prima di presumere che basti un suggerimento).
• loading="lazy" nativo è gratuito e corretto per le immagini fuori dalla viewport iniziale, non per una linea fissa di pixel del «below the fold». Evita i lazy loader JS che nascondono l’URL in data-src.
• Formati: WebP è il default sicuro (~25–35% più piccolo di JPEG); AVIF comprime di più (oltre il 50% in alcuni test) con un fallback. La scelta dipende anche da trasparenza, animazione e supporto attuale di browser/strumenti, non solo dal rapporto di compressione. Servi tramite <picture> con un fallback <img src> che Google indicizza.
• Compressione: nessuna qualità «giusta» universale: fai test per tipo di immagine (le foto reggono una compressione forte; testo e grafica mostrano rapidamente artefatti).
• Dimensionamento: dimensione corretta = dimensione del contenitore renderizzato × device pixel ratio (contenitore da 500px a DPR 2 = sorgente da 1 000 px) e il contenitore cambia con il layout responsive: fornisci un intervallo tramite srcset + sizes anziché un export fisso. Un valore sizes errato fa scaricare silenziosamente al browser un candidato sovradimensionato.
• Perché conta: le immagini sono l’elemento LCP più comune; l’obiettivo LCP è 2,5 s al 75° percentile. Ecco perché questo articolo è collegato a Web Performance, ma LCP ha altre parti (tempo di risposta del server, risorse che bloccano il rendering) che i soli byte delle immagini non correggono.
• Nessuna garanzia: ottimizzare le immagini non garantisce da solo un punteggio Core Web Vitals sufficiente, un cambiamento di ranking, più traffico, più conversioni o una citazione nelle ricerche AI. Misura LCP/CLS prima e dopo, in laboratorio e sul campo.
• Problemi: background-image CSS non viene indicato; non rinominare file in blocco; imposta sempre width/height: può ridurre lo spostamento del layout, ma non garantisce un punteggio CLS preciso.

Documentazione ufficiale

Documentazione da fonti primarie dei motori di ricerca e del Chrome team.

Google / web.dev

• Prestazioni delle immagini (web.dev «Learn Performance») — formati, il punto sull’assenza di un’«impostazione di compressione universale» e la matematica del dimensionamento DPR.
• Lazy loading delle immagini a livello browser (web.dev) — come funziona il loading="lazy" nativo e l’eccezione «non applicarlo alle immagini nella viewport/LCP».
• Ottimizza LCP (web.dev) — fetchpriority, la risorsa LCP è un’immagine o un font e «non applicare mai il lazy loading all’immagine LCP».
• Fetch Priority API (web.dev) — spiegazione completa di fetchpriority="high" per le immagini LCP.
• Web Vitals (web.dev) — definizioni dei Core Web Vitals e soglia LCP ≤ 2,5 s / 75° percentile.
• Best practice per Google Immagini — formati supportati, indicizzazione di <img>/<picture> (non degli sfondi CSS), immagini responsive e raccomandazione per il fallback src.

Bing / Microsoft

• Bing non pubblica una guida tecnica specifica sull’ottimizzazione delle immagini dettagliata quanto quella di Google; le indicazioni pertinenti si trovano nelle linee guida generali per i webmaster di Bing, che considerano la velocità della pagina (compreso il peso delle immagini). Lo segnalo onestamente anziché inventare una «citazione» di Bing che non esiste.
• Bing Visual Search — ricerca visuale a livello di oggetto, pertinente alla scoperta delle immagini e separata dagli effetti di velocità della pagina dati da formato e compressione.

Citazioni dalla fonte

Dichiarazioni pubbliche del Chrome team e dei Search Advocates di Google. Quando una pagina rende disponibile il testo, il link profondo porta direttamente al passaggio citato.

web.dev (Chrome team di Google) — le regole LCP

• “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (traduzione) «non applicare mai il lazy loading all’immagine LCP, perché ciò causerà sempre un ritardo inutile nel caricamento della risorsa e avrà un impatto negativo sull’LCP» Vai alla citazione
• “Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images.” (traduzione) «non applicare il lazy loading alle immagini che probabilmente si trovano nella viewport quando la pagina viene caricata, soprattutto alle immagini LCP» Vai alla citazione
• “It’s a good idea to set fetchpriority=\"high\" on an <img> element if you think it’s likely to be your page’s LCP element.” (traduzione) «è una buona idea impostare fetchpriority=“high” su un elemento <img> se pensi che sia probabilmente l’elemento LCP della pagina» — web.dev, Optimize LCP.

web.dev (Chrome team di Google) — formati, compressione, dimensionamento

• “WebP often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression.” (traduzione) «WebP spesso offre una compressione migliore di JPEG, PNG o GIF, con compressione sia con perdita sia senza perdita» Vai alla citazione
• “AVIF supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases.” (traduzione) «AVIF supporta la compressione con e senza perdita e in alcuni casi i test hanno mostrato un risparmio superiore al 50% rispetto a JPEG» — web.dev, Image performance.
• “When compressing, there isn’t a universal setting suitable for all cases. The recommended approach would be to experiment with different compression levels until you find a good compromise between image quality and file size.” (traduzione) «Quando comprimi, non esiste un’impostazione universale adatta a tutti i casi. L’approccio consigliato è sperimentare con diversi livelli di compressione finché trovi un buon compromesso tra qualità dell’immagine e dimensione del file» — web.dev, Image performance.
• “An image displayed in a 500 pixel by 500 pixel container would be optimally sized at 500 pixels by 500 pixels.” (traduzione) «Un’immagine mostrata in un contenitore di 500 per 500 pixel ha dimensioni ottimali di 500 per 500 pixel» … “If the device has a DPR of 2 … then a square 1000 pixel image … is now the optimal size.” (traduzione) «Se il dispositivo ha un DPR pari a 2 … un’immagine quadrata da 1000 pixel è ora della dimensione ottimale» — web.dev, Image performance.

Google Search Central — perché le immagini contano per la velocità

• “images are often the largest contributor to overall page size, which can make pages slow and expensive to load.” (traduzione) «le immagini sono spesso il contributo più grande alle dimensioni complessive della pagina, che può rendere le pagine lente e costose da caricare» Vai alla citazione

web.dev — Core Web Vitals (segnali essenziali del web)

Citazione di web.dev:

• “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (traduzione) «i Core Web Vitals sono il sottoinsieme dei Web Vitals che si applica a tutte le pagine web, deve essere misurato da tutti i proprietari dei siti e sarà mostrato in tutti gli strumenti Google» Vai alla citazione In altre parole, i Core Web Vitals si applicano a tutte le pagine web, devono essere misurati da tutti i proprietari dei siti e vengono mostrati in tutti gli strumenti di Google.

John Mueller, Google — il formato non è una leva di ranking

• Su AVIF: non c’è alcun «vantaggio SEO» nell’usare file AVIF. Copertura
• Su WebP: “WebP images are fine for Image Search.” (traduzione) «le immagini WebP vanno bene per la ricerca immagini» Copertura

Checklist per l’ottimizzazione delle immagini

Esegui questo controllo su ogni pagina sensibile alle prestazioni:

• Hai identificato l’immagine LCP (di solito hero / immagine in evidenza / primo scatto del prodotto).
• L’immagine LCP non usa il lazy loading: ha loading="eager" (il default).
• L’immagine LCP ha fetchpriority="high" (considera Early Hints se lo stack li supporta).
• Ogni immagine sotto la piega ha loading="lazy".
• Il formato moderno è servito (WebP come default, AVIF dove supportato) con un fallback src di <picture>.
• Ogni immagine è dimensionata in base a contenitore × device pixel ratio: nessun file da 3 000 px in uno spazio da 500px.
• La distribuzione responsive usa srcset + sizes quando le immagini vengono renderizzate a larghezze diverse.
• La compressione è stata testata per tipo di immagine (2–3 livelli di qualità confrontati alla dimensione di visualizzazione), non con un’unica impostazione generale.
• width e height intrinseci (o CSS aspect-ratio) sono impostati su ogni immagine per ridurre lo spostamento del layout (CLS): non è una garanzia di un punteggio specifico.
• Nessuna immagine di contenuto vive solo in un CSS background-image (non vengono indicizzate).
• Il lazy loading usa l’attributo nativo (o un IntersectionObserver pulito), non un trucco JS che nasconde l’URL in data-src.
• LCP è stato verificato sul campo (CrUX / PageSpeed Insights), puntando a ≤ 2,5 s al 75° percentile.

Scheda rapida dell’ottimizzazione delle immagini

Le leve — che cosa fanno e best practice

Fatti rapidi

• Il formato è una leva di velocità, non di ranking: Mueller dice nessun «vantaggio SEO» per AVIF; WebP è «sufficiente».
• WebP è circa il 25–35% più piccolo di JPEG; AVIF è spesso oltre il 50% più piccolo nei test.
• La regola singola di maggior valore: non applicare mai il lazy loading all’immagine LCP.
• Obiettivo LCP: ≤ 2,5 s al 75° percentile (mobile + desktop).
• Formati supportati: BMP, GIF, JPEG, PNG, WebP, SVG, AVIF.
• Dimensione corretta = dimensione del contenitore renderizzato × device pixel ratio.

L’errore che ti costa il punteggio LCP

Applicare il lazy loading all’immagine hero è l’errore singolo più costoso trattato in questo articolo, e vale la pena richiamarlo da solo prima del resto.

• Sbagliato: applicare loading="lazy" (o un lazy loader JS) all’immagine più grande above-the-fold, di solito l’hero, l’immagine in evidenza o il primo scatto del prodotto. Perché è sbagliato: quell’immagine è quasi sempre il tuo elemento LCP e web.dev è esplicito: applicare il lazy loading “will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (traduzione) «causerà sempre un ritardo inutile nel caricamento della risorsa e avrà un impatto negativo sull’LCP» Finisci per ritardare proprio la metrica che cercavi di migliorare. Fai invece così: assegna all’immagine LCP loading="eager" (il default) più fetchpriority="high" e riserva loading="lazy" a tutto ciò che si trova sotto la piega.

“will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (traduzione) «porta sempre a un ritardo inutile nel caricamento della risorsa e incide negativamente sull’LCP»

Fidarsi di un’unica impostazione generale di compressione

• Sbagliato: passare ogni immagine attraverso lo stesso preset «comprimi all’80%», indipendentemente dal contenuto. Perché è sbagliato: web.dev lo dice chiaramente: “there isn’t a universal setting suitable for all cases” (traduzione) «non esiste un’impostazione universale adatta a tutti i casi»; un preset regolato sulle fotografie comprimerà troppo loghi, screenshot e grafica ricca di testo, creando artefatti visibili. Fai invece così: esporta la stessa immagine a due o tre livelli di qualità e confrontali alla dimensione effettiva di visualizzazione; scegli la più piccola che non riesci a distinguere dall’originale, per ogni tipo di immagine.

“there isn’t a universal setting suitable for all cases” (traduzione) «non c’è una regolazione universale adatta a ogni caso»

Dimensionare le immagini in base al file che hai, non al contenitore

• Sbagliato: servire la risoluzione casuale del file originale (o una singola dimensione fissa per ogni layout), invece di abbinare l’immagine al punto in cui viene effettivamente renderizzata. Perché è sbagliato: secondo la matematica di web.dev, la dimensione corretta è la dimensione del contenitore renderizzato × il rapporto di pixel del dispositivo: un contenitore da 500×500 a DPR 2 richiede una sorgente da 1 000×1 000, non da 500×500 e non da 3 000×3 000. Vai più grande e sprechi byte senza un guadagno visibile; vai più piccolo e l’immagine appare morbida sugli schermi ad alto DPR. Fai invece così: fornisci un intervallo srcset con sizes così il browser può scegliere il candidato giusto per il contenitore e il dispositivo.

Nascondere le vere immagini di contenuto dietro il CSS

• Sbagliato: sostituire un <img> con un background-image per comodità di layout. Perché è sbagliato: Google “doesn’t index CSS images” (traduzione) «non indicizza le immagini CSS»: un’immagine di contenuto che esiste solo come background-image è invisibile nella ricerca immagini anche se è ottimizzata perfettamente. Fai invece così: mantieni le immagini di contenuto in un <img> (o nel fallback <img> dentro un <picture>) e riserva gli sfondi CSS ai trattamenti puramente decorativi.

Saltare width/height per «risparmiare markup»

• Sbagliato: lasciare fuori dai tag <img> width e height intrinseci (o un CSS aspect-ratio). Perché è sbagliato: il browser non può riservare lo spazio del layout prima che l’immagine si carichi, quindi la pagina salta mentre arrivano le immagini: peggiora il CLS, il Core Web Vital che si affianca all’LCP. Fai invece così: imposta sempre width/height (o aspect-ratio) su ogni immagine, anche su quelle che stai ottimizzando anche per formato e dimensioni.

Modelli mentali

1. Non applicare mai il lazy loading all’immagine LCP. La regola di maggior valore dell’intero tema. L’elemento above-the-fold più grande, di solito un’immagine, è quello rispetto al quale viene misurato l’LCP. Applicargli il lazy loading non fa risparmiare nulla: ritarda solo la metrica che stai ottimizzando. Tutto il resto della pagina può usare loading="lazy"; l’immagine LCP mai.

2. Non esiste un’impostazione di compressione universale. Tratta «a quale qualità devo comprimere?» come una domanda per singola immagine, non come una policy per tutto il sito. Le fotografie tollerano una compressione lossy aggressiva; grafica ricca di testo e screenshot no. Il flusso è comparativo: esporta a due o tre livelli di qualità e osserva alla dimensione di visualizzazione, non usare un solo cursore impostato una volta e dimenticato.

3. Dimensione corretta = dimensione del contenitore × device pixel ratio. «Più piccolo è meglio» non è la regola: conta l’abbinamento. Le dimensioni ottimali della sorgente sono quelle a cui l’immagine viene effettivamente renderizzata, moltiplicate per il rapporto di pixel del dispositivo: un contenitore da 500×500 a DPR 2 richiede una sorgente da 1 000×1 000. Questa è la formula singola che dovrebbe decidere la dimensione di export di ogni immagine e spiega perché fornisci un intervallo tramite srcset anziché un file fisso.

4. Il formato è una leva di velocità, non di ranking. Riduci correttamente la catena: scelta del formato → file più piccoli → pagina più veloce → Core Web Vitals migliori → un segnale usato dai sistemi di ranking. Saltare direttamente a «i formati di nuova generazione migliorano il ranking» è il modo più comune in cui le guide concorrenti sbagliano questo tema: Mueller ha detto tre volte che il formato in sé non offre alcun vantaggio SEO diretto.

I KPI permanenti per la velocità delle pagine guidata dalle immagini

Questi sono i numeri ricorrenti che ti dicono se il lavoro di ottimizzazione delle immagini sta davvero producendo risultati, separati da una singola immagine che ridimensioni o converti questa settimana.

Mettiti alla prova: ottimizzazione delle immagini

Cinque domande rapide su formati, compressione, dimensionamento e strategia di caricamento. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche