Tecnologia

Ottimizzare immagini web 2026: 8 strategie per Core Web Vitals

Pubblicato il08/03/202610 min read

Le immagini sono il collo di bottiglia numero uno

Partiamo da un dato schiacciante: secondo HTTP Archive (dicembre 2025), la pagina web desktop mediana pesa 2.312 KB, di cui 1.026 KB sono immagini — il 44,4%. Su mobile arriva al 47%.

Tradotto: se puoi ottimizzare una sola cosa del tuo sito, scegli le immagini. Nessun'altra categoria di asset ha pari leva di miglioramento.

Più critico ancora: le immagini sono direttamente legate ai Core Web Vitals di Google, in particolare al LCP (Largest Contentful Paint). Secondo i dati CrUX (Chrome User Experience Report), oltre il 70% degli elementi LCP sono immagini o blocchi con background image. LCP sopra 2,5 secondi → "needs improvement". Oltre 4 secondi → "poor". Impatto diretto sul ranking SEO.

Per sviluppatori e tecnici italiani che gestiscono siti con audience europea, vediamo come mettere in piedi una strategia ottimale.

Un caso reale di pestate: LCP da 1,8 s a 6,2 s

Partiamo dalla conclusione: l'anno scorso ho gestito un progetto cliente dove l'LCP è esploso dalla zona verde (1,8 s) alla zona rossa (6,2 s) — cambiando una sola immagine hero in homepage. All'inizio pensavo fosse il bundle JS ad essere saltato, ho fatto debug per tre giorni prima di scoprire la verità: a dire il vero, la nuova designer aveva caricato un PNG da 4,5 MB a 1920×1080 sulla homepage, senza compressione, senza attributo loading, senza fetchpriority e senza CDN. Quella singola immagine bastava a mandare in tilt l'LCP.

Fatte tre cose, l'LCP è tornato a 1,9 s:

Convertito il PNG in WebP, compresso a 180 KB (−96%)
Aggiunti fetchpriority="high" e <link rel="preload">
Spostata l'immagine su Cloudflare R2 + Transform Rules con fallback AVIF automatico

Francamente, questa trappola l'hanno pestata in tanti. Diciamolo chiaramente: l'immagine hero della homepage è il punto critico dell'LCP e se anche un solo tassello è sbagliato, tutto il report Core Web Vitals si tinge di rosso. Ogni sezione qui sotto nasce da casi reali come questo — non è copia-incolla dalla documentazione.

Lazy Loading: carica solo quello che serve

Soluzione nativa HTML

Il modo più semplice — attributo loading="lazy":

<img src="foto.webp" loading="lazy" alt="esempio" width="800" height="600">

Sotto il cofano: il browser ritarda la HTTP request finché l'immagine non è vicina al viewport. Chrome scatta a circa 1250px di distanza (desktop) o 2500px (reti lente), così quando lo scroll arriva lì, l'immagine è già caricata.

Attenzione: le immagini above-the-fold (subito visibili) NON devono avere lazy loading — ritarderesti il LCP. Usa loading="eager" (default) e aggiungi fetchpriority="high" per prioritizzare il download.

JavaScript: Intersection Observer

Per controllo più fine:

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      img.src = img.dataset.src;
      observer.unobserve(img);
    }
  });
}, { rootMargin: '200px' });

document.querySelectorAll('img[data-src]').forEach(img => observer.observe(img));

Vantaggi: trigger distance customizzabile (rootMargin), animazioni di fade-in, LQIP (Low Quality Image Placeholder) prima del caricamento completo.

Quando usare cosa

Criterio	`loading="lazy"` nativo	Intersection Observer
Complessità	Minima (un attributo)	Media (richiede JS)
Supporto browser	95%+ (2026)	97%+
Trigger distance	Fissa	Custom
LQIP placeholder	No	Sì
SEO-friendly	Sì (nativo)	Serve `<noscript>` fallback
Rischio uso errato above-fold	Presente	Gestibile in codice

Regola: nativo per la maggior parte dei casi, Observer quando serve LQIP o controllo fine.

Responsive Images: device scarica solo la dimensione giusta

Un'immagine hero 3000px larga, su mobile serve magari a 750px. Senza responsive images, l'utente mobile scarica 4 volte i byte necessari. Su rete 4G in metro Milano è una tragedia.

srcset + sizes

<img
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w, hero-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px"
  src="hero-800.webp"
  alt="Banner homepage"
>

Il browser sceglie dimensione ottimale in base a viewport width e device pixel ratio. sizes gli dice quanto spazio occuperà l'immagine ai vari breakpoint, permettendo scelta più accurata.

`<picture>`: format e art direction

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Banner">
</picture>

<picture> serve formati diversi a browser diversi. Ordine: AVIF → WebP → JPEG fallback. Browser moderni ricevono peso minimo, browser vecchi fallback JPEG.

Scelta formato: confronto empirico

Confronto su stessa immagine 1920×1080, qualità percepita equivalente:

Formato	Dimensione tipica	Supporto browser	Alpha	Animazione	Scenario
JPEG	100% baseline	100%	No	No	Foto (max compat)
WebP	~70% di JPEG	97%+	Sì	Sì	Default consigliato
AVIF	~50% di JPEG	92%+	Sì	Sì	Foto (compressione top)
PNG	300-500% di JPEG	100%	Sì	No	Grafica con trasparenza
SVG	Minuscolo (vector)	100%	Sì	Sì	Icone, loghi, grafici

Strategia: AVIF → WebP → JPEG fallback con <picture>. Browser sceglie il migliore disponibile.

CDN e caching

Il valore del CDN

Da un server a Milano verso un utente a Palermo, circa 1.300 km — latenza via fibra ~15 ms. Verso un utente USA, 8.000 km → 80+ ms solo velocità della luce. Aggiungi TCP handshake, TLS, HTTP roundtrip — una singola immagine può avere TTFB oltre 200 ms senza CDN.

Un CDN edge-cached riduce TTFB a 20-50 ms tipicamente. Per siti italiani con traffico UE/globale, impatto enorme.

Header di cache

Cache-Control: public, max-age=31536000, immutable

Le immagini raramente cambiano. Cache 1 anno con immutable: nessuna revalidation necessaria. Se devi aggiornare, cambia il filename (aggiungi hash) — cache-busting pulito.

Image CDN specializzati

Cloudflare Images, Imgix, Cloudinary offrono oltre al CDN:

Format negotiation on-the-fly (Accept header → AVIF/WebP/JPEG automatico).
Ridimensionamento via URL params.
Quality adaptive in base a network speed (Network Information API).

Per e-commerce italiani con catalogo grande, questi servizi ripagano il costo rapidamente — la banda risparmiata compensa la fattura mensile.

Pipeline di compressione server-side

Una pipeline completa include:

Compressione upload: Sharp (Node.js), Pillow (Python), ImageMagick in CI/CD.
Multi-size generation: 3-5 varianti per immagine (400w, 800w, 1200w, 1600w, originale).
Multi-format: per ogni size, genera AVIF + WebP + JPEG.
Quality tuning: JPEG 75-85, WebP 75-80, AVIF 60-70.
EXIF strip: rimuovi metadati (riduce peso + protegge privacy).

Esempio concreto: foto 1920×1080. Dopo pipeline, un utente mobile italiano scarica 400w AVIF da ~30 KB invece dell'originale 2 MB. Riduzione 98,5% del traffico.

Core Web Vitals: obiettivi misurabili

LCP (Largest Contentful Paint)

Misura quando l'elemento più grande visibile è renderizzato:

Good: ≤ 2,5 s
Needs improvement: 2,5-4 s
Poor: > 4 s

Per siti dove il LCP è un'immagine (tipicamente hero):

fetchpriority="high" sull'immagine hero.
<link rel="preload" as="image" href="hero.webp"> in <head>.
MAI lazy loading sul LCP.
Assicurati che l'hero sia cache-hit su CDN.

CLS (Cumulative Layout Shift)

Se le immagini caricano senza spazio riservato, il layout salta. Fix banale: sempre width e height su <img>. Il browser pre-calcola l'aspect ratio e alloca lo spazio prima del caricamento.

<img src="foto.webp" width="800" height="600" alt="esempio">

INP (Interaction to Next Paint)

Dal marzo 2024 sostituisce FID. Meno legato alle immagini dirette, ma immagini grosse che bloccano il main thread impattano. Mitigazione: async decoding con decoding="async".

Checklist pre-deploy

Prima di andare live, verifica uno per uno:

Contesto italiano: considerazioni specifiche

Core Web Vitals e Google Italia: Google Italia premia fortemente LCP buono. Siti italiani (e-commerce locali, testate giornalistiche, PMI) che hanno migrato a pipeline immagini moderna hanno visto incrementi +15-30% di traffico organico in 6 mesi.

Aruba e servizi hosting italiani: molti clienti italiani ospitano su Aruba, Register.it, SiteGround. Questi provider offrono CDN basilari ma non image CDN specializzati. Integrare Cloudflare (free tier include CDN base ottimo) davanti al sito Aruba è un pattern comune ed efficace.

Mobile-first italiano: il 73% del traffico e-commerce italiano è mobile. Le reti 4G italiane (TIM, Vodafone, Wind3, Iliad) hanno latenze variabili — siti con immagini mal ottimizzate soffrono di più al Sud e nelle isole. Responsive images e AVIF diventano investimenti chiave.

Accessibility Act 2025: l'European Accessibility Act entrato in vigore giugno 2025 richiede alt text strutturati per siti e-commerce in UE. L'ottimizzazione immagini deve andare di pari passo con accessibility: mai immagini senza alt significativo.

Il ruolo degli image host

Se non vuoi costruire e manutenere una pipeline immagini + CDN tua, un image host dedicato è scorciatoia ragionevole.

lpic.cc offre upload senza registrazione, distribuzione CDN globale, protezione password. Per blogger italiani, sviluppatori side-project, o piccoli siti, risparmia il costo di setup infrastruttura. Francamente, lpic.cc non è un image CDN professionale: niente API, niente resize on-the-fly. Per progetti seri con catalogo grande o traffico sostenuto, Cloudinary / Imgix / Cloudflare Images restano la strada.

FAQ

Lazy loading impatta il SEO?

No. Googlebot esegue JavaScript e simula scrolling, indicizza correttamente le immagini con loading="lazy". Se usi JS custom per lazy loading, aggiungi <noscript> con il tag <img> normale come fallback per assicurare il crawler.

WebP o AVIF come priorità?

AVIF batte WebP in compressione (~50% vs ~70% di JPEG), ma encoda più lentamente. Strategia migliore: servi entrambi via <picture>, browser sceglie. Se devi sceglierne uno, WebP ha supporto browser più ampio (97% vs 92%) — scelta più sicura per e-commerce che servono anche device più vecchi (rilevante per segmenti italiani meno tech).

Image CDN: vale la spesa?

Dipende dal volume. Sotto 100k PV/mese, Cloudflare free tier con CDN base copre bene. Sopra, image CDN tipo Imgix o Cloudinary con automazione formato e resize risparmiano banda e developer-hours. ROI tipicamente positivo in 3-6 mesi per e-commerce medi.

Compressione degrada la qualità?

La lossy sempre introduce perdita, ma a quality sensati (JPEG 75-85, WebP 75-80) l'occhio non distingue. Per misurazione oggettiva, usa SSIM: sopra 0,95 la differenza è impercettibile per la maggior parte degli utenti. Test il tuo use case: foto prodotto richiedono quality alta, illustrazioni decorative reggono quality più aggressiva.

Ho già un CDN, serve ancora ottimizzare le immagini?

Sì. Il CDN risolve la distanza, non il volume. Una foto da 5 MB servita via CDN resta 5 MB di banda. Compressione, resize, conversione formato riducono il volume 80-95%: impatto ben maggiore del solo CDN. Usa entrambi.

PageSpeed Insights segna LCP rosso anche dopo ottimizzazione. Cosa controllare?

Primi sospetti: (1) immagine LCP non preloadata in <head>; (2) render-blocking CSS/JS che ritarda il rendering; (3) TTFB lento del server (controllare Time To First Byte oltre a LCP); (4) fonti custom che bloccano il rendering. Chrome DevTools → Performance tab → analisi Flame Graph rivela il vero bottleneck.

Quando un blogger individuale ha senso fare tutta questa ottimizzazione?

Per un blog personale con meno di 5-10k visite mese, ottimizzazione base basta: compressione pre-upload (Squoosh), loading="lazy", width/height sugli img. Plugin WordPress (ShortPixel, EWWW) automatizzano il resto. Il livello "enterprise" serve quando il traffico aumenta o stai monetizzando seriamente.

Riferimenti

#performance web#ottimizzazione immagini#lazy loading#responsive images#CDN#Core Web Vitals

Scritto da

Harvey Zhang

Co-Fondatore & CTO

Ingegnere backend diventato architetto, offre un'analisi tecnica approfondita dell'infrastruttura di hosting di immagini.