Ottimizzazione immagini WebP in WordPress: formato, dimensioni e quando il lazy load non serve

Le immagini sono il primo fattore di LCP su quasi tutti i siti WordPress. Convertire in WebP è necessario ma non sufficiente: servono dimensioni corrette, srcset responsive e attributi width/height. E il lazy load, su alcune immagini, fa più male che bene.
Se apri PageSpeed Insights su quasi qualsiasi sito WordPress, il primo suggerimento è sulle immagini. Non è un caso: le immagini sono l'elemento più pesante di una pagina tipica e, nella maggior parte dei casi, sono anche l'elemento LCP — quello che determina quando il contenuto principale diventa visibile. Ottimizzarle male significa partire con un LCP sopra i 4 secondi prima ancora di toccare il resto.
La conversione in WebP è il passo più noto, ma è solo il primo. Un'immagine WebP con dimensioni sbagliate (un banner 2000px largo servito su un mobile) pesa comunque troppo. Un'immagine senza attributi width e height sposta il layout mentre carica e rovina il CLS. Un'immagine above-the-fold con lazy load attivo ritarda l'LCP invece di migliorarlo. Il formato è necessario, non sufficiente.
Perché WebP (e non solo)
WebP comprime le immagini meglio del JPEG e del PNG, spesso del 25-35% a parità di qualità visiva. È supportato da tutti i browser moderni da anni. Su un sito con 30 immagini per pagina, la differenza tra JPEG e WebP può essere 500KB di trasferimento in meno — che su connessione mobile 4G lenta è un secondo intero di LCP risparmiato.
La conversione si fa una volta e si automatizza. WordPress, dalla 5.8, genera automaticamente versioni WebP della libreria media se il server supporta GD o Imagick con WebP. Puoi forzare la generazione e servire WebP con un filtro:
// Forza la generazione di versioni WebP nella libreria media (WP 5.8+)
add_filter( 'image_editor_output_default_mime_type', function( $mime ) {
return 'image/webp';
});
// Aggiungi WebP ai formati generati per ogni immagine caricata
add_filter( 'big_image_size_threshold', function( $threshold ) {
return 2560; // limite massimo di ridimensionamento
});Dimensioni corrette e srcset responsive
Il formato conta, ma le dimensioni contano di più. Servire un'immagine 1920px larga a un telefono con schermo 390px è uno spreco di banda e di tempo. WordPress genera automaticamente più versioni di ogni immagine (thumbnail, medium, large, ecc.) e, se l'HTML usa `srcset`, il browser sceglie quella giusta in base allo schermo.
Il problema è che molti temi e page builder non usano `srcset` o lo usano male. Le immagini inserite via CSS di background non hanno srcset. Le immagini caricate manualmente in HTML spesso puntano al file originale. La verifica è semplice: apri il sorgente e cerca `srcset` sull'immagine LCP. Se non c'è, il browser sta scaricando l'immagine più grande disponibile.
<!-- CORRETTO: srcset + sizes + width/height per zero CLS -->
<img
src="hero-1200.webp"
srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
sizes="(max-width: 600px) 100vw, 50vw"
width="1200" height="675"
alt="Dashboard di monitoraggio WordPress"
fetchpriority="high"
decoding="async"
>
<!-- SBAGLIATO: immagine originale, niente srcset, niente dimensioni -->
<img src="hero-3840x2160.jpg" alt="hero">Quando il lazy load fa più male che bene
Il lazy loading è utile per le immagini below-the-fold: ritarda il caricamento di ciò che l'utente non vede subito, risparmiando banda. WordPress lo attiva di default dalla 5.5. Ma sull'immagine LCP — quella above-the-fold, visibile appena la pagina si apre — il lazy load è un errore. Ritarda l'elemento che determina il punteggio LCP, peggiorando esattamente la metrica che vorresti migliorare.
WordPress dalla 5.9 esclude automaticamente dalla prima immagine del contenuto il lazy load, ma non sempre ci azzecca. Se la tua immagine LCP è in un header custom, in un blocco hero o in un template di pagina, potrebbe essere lazy-loaded per errore. Puoi forzare il comportamento corretto:
// Disabilita il lazy load sull'immagine LCP (above the fold)
add_filter( 'wp_lazy_loading_enabled', function( $default, $tag, $context ) {
// Non applicare lazy load alle immagini con fetchpriority high
if ( false !== strpos( $context, 'fetchpriority' ) ) {
return false;
}
return $default;
}, 10, 3 );
// Assegna fetchpriority high all'immagine hero del template
add_filter( 'wp_get_attachment_image_attributes', function( $attr, $attachment ) {
if ( $attachment->ID === (int) get_theme_mod( 'hero_image_id' ) ) {
$attr['fetchpriority'] = 'high';
$attr['loading'] = 'eager'; // sovrascrive il lazy di default
}
return $attr;
}, 10, 2 );Le immagini sono il primo posto dove guardare quando l'LCP è alto. Non è un lavoro di un plugin magico: è formato giusto, dimensioni giuste, srcset corretto e lazy load solo dove serve. Fatto bene una volta, si mantiene nel tempo.
Misura LCP, INP e CLS sui tuoi utenti reali, non su un test di laboratorio.
Un audit Core Web Vitals identifica esattamente cosa rallenta il tuo sito e dove intervenire con priorità.
Articoli correlati

Caching avanzata WordPress: livelli, configurazione e quando il caching sbagliato rompe il checkout
Leggi
CLS e stabilità visiva: eliminare il layout shift che penalizza il sito WordPress sul mobile
Leggi
