Ottimizza Immagini WordPress per la Velocità: Web Vitals e WebP

Ultimo aggiornamento: June 28, 2026

Questo è il compagno focalizzato sulla velocità della mia guida all'ottimizzazione delle immagini per WordPress del 2026. Quella guida copre l'allestimento generale: plugin, srcset, CDN e htaccess. Questa si concentra su una singola domanda: come rendere le immagini di WordPress abbastanza veloci da trasformare i Core Web Vitals in verde? Ho misurato ogni passaggio sul mio blog, ricco di contenuti multimediali, e i successi qui sotto sono ciò che ha effettivamente spostato il Largest Contentful Paint da 3.8s a 1.1s.

Risposta rapida: cosa rende veloci le immagini di WordPress?

Comprimi ogni immagine in WebP prima del caricamento, limita la sua larghezza di visualizzazione in modo che il browser non scarichi mai un file da 4000px per uno slot da 400px, implementa il lazy-loading per tutto sotto la piega e posiziona una CDN davanti a /wp-content/uploads/. Sul mio blog, questi quattro passaggi hanno ridotto il peso totale delle immagini dell'84 percento e abbassato l'LCP mobile da 3.8s a 1.1s. Il Largest Contentful Paint su un blog WordPress è quasi sempre un'immagine, quindi è qui che risiede la velocità.

Perché le immagini di WordPress dominano i tuoi Core Web Vitals?

I Core Web Vitals valutano la percezione della velocità, e quello che fallisce più spesso su WordPress è il Largest Contentful Paint, che per un sito di contenuti è solitamente l'immagine eroe o la prima immagine inline. Ho eseguito PageSpeed Insights su 40 dei miei post e l'elemento LCP era un'immagine in 37 di essi.

Le immagini guidano anche le altre metriche indirettamente:

• Un hero da 4MB blocca l'LCP finché non termina il download su Slow 4G.
• Lo shift del layout aumenta quando le immagini arrivano senza larghezza e altezza definite.
• L'INP soffre quando una gigantesca coda di immagini affama il thread principale durante l'analisi.

Google misura queste metriche da utenti reali di Chrome e le incorpora nei segnali di ranking di ricerca, documentati in web.dev fast loading guidance. La soluzione è raramente il server. È quasi sempre l'immagine stessa.

Quanto peso da immagine puoi tagliare?

Ho registrato i numeri su un blog prima e dopo l'ottimizzazione. Stessi post, stesso contenuto, solo le immagini sono cambiate.

Quel calo da 9.4MB a 1.1MB non è un caso speciale. È ciò che accade quando smetti di inviare JPEG non compressi alla risoluzione nativa. La leva più grande è il formato e le dimensioni, che la guida optimize images for web speed analizza metrica per metrica.

Cos'è l'LCP e perché è quasi sempre un'immagine?

Largest Contentful Paint segna il momento in cui viene renderizzato il più grande elemento visibile. Su un blog WordPress, quell'elemento è una foto eroe, un'immagine in evidenza o la prima immagine inline grande — non testo. Finché quell'immagine non viene scaricata, decodificata e dipinta, la pagina appare come "ancora in caricamento" per l'utente e per Google.

Ci sono tre cose che estendono l'LCP delle immagini, e ne controllo tutte e tre in ogni audit:

• Il file è troppo grande per il viewport che occupa.
• L'immagine LCP viene lazy-loadata per errore, quindi inizia tardi.
• Non c'è CDN, quindi il file viaggia da un singolo punto di origine dall'altra parte del mondo.

Le due ultime sono errori di configurazione che puoi correggere in pochi minuti. La prima è un'abitudine di caricamento, trattata nella guida alle dimensioni dei file immagine.

Quale formato immagine è il più veloce per WordPress?

WebP. È dal 25 al 35 percento più piccolo rispetto a JPEG con uguale qualità percepita, e il core di WordPress supporta il suo caricamento dalla versione 6.5. AVIF comprime un altro 20-30 percento in meno, ma il supporto browser e CDN è ancora disomogeneo, quindi lo considero uno strato di miglioramento piuttosto che la base.

Comprimo in WebP prima del caricamento e lascio che la CDN negozzi AVIF per i browser che lo gestiscono. Per i compromessi di formato in dettaglio, JPG PNG WebP comparison è il riferimento che invio alle persone.

Come servi la giusta dimensione immagine a ogni dispositivo?

Questo è il trucco che la gente salta. WordPress genera automaticamente dimensioni thumbnail, medium, large e intermediate ed emette un srcset, ma solo se il tuo tema chiama wp_get_attachment_image() invece di codificare in modo fisso un tag <img>. Un telefono non dovrebbe mai scaricare il file da 2560px.

Il markup che emette WordPress assomiglia a questo:

<img
  src="hero-1536x800.webp"
  srcset="hero-768x400.webp 768w,
          hero-1200x628.webp 1200w,
          hero-1536x800.webp 1536w"
  sizes="(max-width: 768px) 100vw, 1200px"
  width="1536" height="800"
  alt="Fotografia eroe di Storefront a larghezza intera">

Come verifico che funzioni: apri DevTools, limita la banda su Slow 4G, ricarica e osserva la scheda Network. Il telefono dovrebbe richiedere il file da 768w. Se ogni dispositivo preleva lo stesso URL, il tema è rotto o un page builder sta bypassando il markup responsive. La logica dei breakpoint risiede nella guida responsive image breakpoints.

Come si attiva il lazy loading in WordPress?

Da WordPress 5.5 ogni <img> riceve loading="lazy" di default, e la versione 6.1 ha aggiunto un suggerimento fetchpriority="high" alla prima grande immagine in modo che non combatti più con il lazy loader. Raramente hai bisogno di un plugin per questo, ed è un vero guadagno di velocità senza configurazione.

Due regole che impongo, perché entrambe mi hanno fatto perdere LCP prima che le scoprissi:

• Non fare mai lazy-load dell'immagine LCP sopra la piega.
• Imposta sempre larghezza e altezza esplicite per prevenire lo shift del layout.

La documentazione ufficiale WordPress lazy-loading documentation elenca i filtri per escludere l'elemento LCP e fare lazy-load degli iframe. Per le trappole comuni, incluso l'errore dell'immagine eroe, leggi il nostro articolo lazy load images.

Come una CDN accelera le immagini di WordPress?

Una CDN serve ogni immagine dal punto più vicino al visitatore e rimuove i round-trip verso il tuo origin. Dopo aver spostato un cliente da JPEG ospitati sull'origin a Cloudflare con Polish abilitato, l'TTFB delle immagini è sceso da 420ms a 60ms per i visitatori di Singapore e Brasile — le due regioni in cui il loro report PageSpeed era rosso.

Cosa configuro su ogni sito:

• Cloudflare con Polish attivo, lossless più WebP.
• Cache tutto sotto /wp-content/uploads/.
• Una cache browser di un anno per i tipi MIME delle immagini.
• Uno strato AVIF negoziato dalla CDN sopra WebP.

L'edge caching è più importante per gli store WooCommerce ricchi di immagini e i blog multi-autore. L'allestimento completo, inclusi i cache header e le regole di purge, si trova nella guida all'immagine CDN.

Punto chiave: lo stack velocità in quattro passaggi

Se non ti ricordi nient'altro, ricorda questi quattro punti, perché sono responsabili del calo LCP che ho misurato:

1. Comprimere in WebP prima del caricamento, sotto i 200KB per immagine.
2. Limitare la larghezza di visualizzazione e lasciare che srcset serva il file giusto.
3. Lazy-load sotto la piega, mai l'immagine LCP.
4. Cacheggiare le immagini a un edge CDN con un TTL di un anno.

Fai queste cose e il tuo report Core Web Vitals diventa verde. Saltare il passaggio responsive srcset e anche un WebP perfettamente compresso invierà comunque un file da desktop su un telefono.

Checklist velocità prima del rilascio

• L'immagine LCP è in WebP e sotto i 200KB.
• L'immagine LCP ha fetchpriority="high", non loading="lazy".
• È presente srcset e il telefono carica il file piccolo.
• Ogni immagine ha larghezza e altezza esplicite.
• Una CDN cacheggia /wp-content/uploads/.
• La cache browser per le immagini è impostata su un anno.
• LCP mobile inferiore a 2.5s in PageSpeed.
• CLS inferiore a 0.1 senza shift indotto da immagini.

Un vero avvertimento: il WebP con perdita di dati (lossy) con qualità inferiore al 70 alla fine ti farà pagare sul product photography e sugli schermi retina dove texture e dettaglio dei bordi vendono il prodotto. Conservo sempre l'originale in cloud storage e lo riesporto da lì, perché una volta che sovrascrivi la sorgente con una copia lossy, il dettaglio è perso per sempre. Testa su cinque immagini reali prima di convertire in blocco mille.

Crediti delle immagini

• Spazio di lavoro luminoso con un computer desktop utilizzato per gestire un sito WordPress — foto di SHVETS Production su Pexels
• Ufficio domestico accogliente con un laptop aperto su un post del blog WordPress — foto di Pixabay su Pexels
• MacBook che visualizza una pagina di ricerca Google su un tavolo di legno all'aperto — foto di Pixabay su Pexels
• Programmatore che scrive codice su un laptop e monitor in un ufficio moderno — foto di Claudio Emanuel su Pexels