Ottimizzare le immagini per il web: WebP, AVIF e dimensioni

Per ottimizzare le immagini per il web devi servire ogni immagine in un formato moderno (WebP o AVIF, con un fallback), alle dimensioni in pixel con cui viene davvero mostrata, con una compressione sensata, e caricarla al momento giusto: subito per l'immagine principale, in lazy loading per tutto ciò che sta sotto la piega. Se sistemi queste quattro cose, le immagini smettono di essere la parte più pesante delle tue pagine. Questa guida spiega ogni passaggio, cosa cambiano davvero WebP e AVIF e come verificare il risultato.

Perché le immagini contano per la velocità

In molti siti di contenuti e negozi online, le immagini sono la quota più grande dei byte che una pagina scarica. Decidono anche uno dei tre Core Web Vitals: su molte pagine l'elemento del Largest Contentful Paint è un'immagine, di solito un banner hero o una foto prodotto. L'articolo di web.dev sull'LCP indica il tempo di download dell'immagine come una delle quattro parti che compongono la metrica.

Le immagini influiscono anche sulla stabilità del layout. Un'immagine senza spazio riservato spinge in basso il testo quando arriva, e questo pesa sul Cumulative Layout Shift. Se vuoi il quadro completo di come interagiscono queste metriche, leggi Core Web Vitals spiegati.

La buona notizia: i problemi delle immagini di solito sono facili da individuare e da risolvere, e le soluzioni non toccano la logica della tua applicazione.

Scegli il formato giusto

Ogni formato ha il suo compito. Scegliere quello sbagliato è una causa frequente di file troppo grandi.

Alcune regole pratiche:

• Non usare mai PNG per le foto. Una foto salvata in PNG è spesso molto più grande della stessa foto in JPEG, senza alcun vantaggio visibile.
• Usa SVG per loghi e icone invece degli sprite PNG. Assicurati che gli SVG provengano da una fonte affidabile, perché possono contenere script.
• Sostituisci le GIF animate con un video. Un breve loop in MP4 o WebM è molto più leggero della stessa animazione in GIF.

Cosa cambiano davvero WebP e AVIF

WebP e AVIF sono formati di compressione più recenti. A parità di qualità visiva producono in genere file più piccoli di JPEG e PNG, e AVIF spesso va oltre WebP, soprattutto sulle foto con sfumature morbide. Quanto risparmi dipende dall'immagine e dall'impostazione di qualità, quindi non esiste un numero universale affidabile.

Cosa non cambiano: le dimensioni in pixel. Un AVIF largo 4000 pixel mostrato in una colonna da 600 pixel resta uno spreco. Formato e dimensioni sono problemi separati, e devi risolverli entrambi.

I browser più vecchi che non riconoscono un formato hanno bisogno di un fallback. Puoi gestirlo nel markup con <picture>, oppure sul server leggendo l'header Accept del browser e scegliendo il formato a ogni richiesta.

<picture>
  <source srcset="/images/team.avif" type="image/avif">
  <source srcset="/images/team.webp" type="image/webp">
  <img src="/images/team.jpg" alt="Our team at the office" width="1200" height="800">
</picture>

Servi le dimensioni giuste

Caricare una foto direttamente dalla fotocamera o dal telefono e lasciare che il CSS la rimpicciolisca è l'errore classico. Il browser scarica comunque ogni singolo pixel.

Ridimensiona alla misura di visualizzazione

Scopri quanto è larga l'immagine quando viene effettivamente mostrata. In un layout desktop con una colonna di contenuto da 1200 pixel, un'immagine a tutta larghezza raramente deve superare circa il doppio di quella misura per restare nitida sugli schermi ad alta densità. Le miniature in una griglia di prodotti ne richiedono molto meno.

Usa srcset e sizes

Le immagini responsive permettono al browser di scegliere il file giusto per ogni schermo:

<img
  src="/images/product-800.jpg"
  srcset="/images/product-400.jpg 400w,
          /images/product-800.jpg 800w,
          /images/product-1600.jpg 1600w"
  sizes="(min-width: 1024px) 50vw, 100vw"
  alt="Blue running shoe, side view"
  width="800" height="800">

srcset elenca le larghezze disponibili e sizes dice al browser quanto sarà larga l'immagine nel layout. Il browser combina queste informazioni con la densità di pixel dello schermo e scarica un solo file. La maggior parte dei CMS, WordPress compreso, genera diverse dimensioni al caricamento e stampa srcset in automatico, a patto che il tema usi le funzioni standard per le immagini.

Comprimi con criterio

Per i formati con perdita, un'impostazione di qualità nella fascia media o medio-alta è di solito indistinguibile dall'originale alle normali dimensioni di visualizzazione. Confronta qualche impostazione affiancata su uno schermo reale invece di fidarti di un unico valore predefinito. Elimina anche i metadati come i dati EXIF della fotocamera, che aggiungono byte e possono rivelare informazioni sulla posizione che non volevi pubblicare.

Carica le immagini al momento giusto

Non tutte le immagini sono ugualmente urgenti. Il browser dovrebbe scaricare subito quella sopra la piega e lasciare le altre a quando il visitatore scorre.

Lazy loading per le immagini sotto la piega

Il lazy loading nativo non richiede JavaScript:

<img src="/images/gallery-3.webp" loading="lazy" alt="..." width="600" height="400">

Mai il lazy loading sull'immagine LCP

È l'errore che vanifica tutto il resto. Se l'immagine hero ha loading="lazy", il browser aspetta di proposito prima di scaricarla e l'LCP peggiora. Alcuni plugin e temi applicano il lazy loading a tutte le immagini per impostazione predefinita, quindi controlla in modo specifico la hero.

Evita gli spostamenti del layout

Assegna sempre alle immagini gli attributi width e height (o un aspect-ratio in CSS). I browser moderni li usano per riservare lo spazio giusto prima che arrivi il file, anche quando il CSS rende l'immagine responsive con width: 100%; height: auto. L'articolo di web.dev sul CLS spiega perché le immagini senza dimensioni sono una delle cause più frequenti di spostamenti del layout.

Lo stesso vale per le immagini inserite in un secondo momento, come caroselli o spazi pubblicitari: riserva il loro spazio nel CSS così il resto della pagina non salta.

Metti in cache le immagini nel modo giusto

Le immagini cambiano di rado, quindi browser e CDN dovrebbero conservarle a lungo. Invia header Cache-Control di lunga durata e cambia il nome del file (o aggiungi un parametro di versione) quando sostituisci un'immagine. Puoi controllare cosa invia il tuo server:

curl -I https://www.example.com/images/hero.webp

Cerca cache-control con un max-age lungo. Se servi formati diversi dallo stesso URL a seconda del browser, la risposta deve anche variare in base all'header Accept, altrimenti una cache potrebbe consegnare un file WebP a un browser che non è in grado di mostrarlo.

Come ti aiuta fast.site

fast.site si mette davanti al tuo hosting attuale, quindi le immagini restano dove sono e il tuo CMS continua a funzionare come prima. Punti i nameserver del dominio su fast.site e da quel momento le richieste passano dalla sua rete edge.

L'ottimizzazione delle immagini converte al volo JPEG e PNG in WebP per i browser che lo supportano, e la conversione in AVIF è disponibile a seconda del tuo piano. I browser che non supportano un formato ricevono l'originale, così non devi mantenere fallback <picture> per ogni immagine. Come gli altri file statici, le immagini vengono messe in cache da Fast Edge Cache™, quindi un cache HIT viene servito dall'edge più vicino al visitatore senza contattare il tuo server.

L'impostazione facoltativa di ottimizzazione HTML precarica l'immagine hero rilevata e aggiunge larghezza e altezza alle immagini per ridurre gli spostamenti del layout.

Cosa fast.site non fa: ridimensionare i caricamenti troppo grandi o decidere quali immagini caricare in lazy loading. Queste scelte restano nel tuo tema e nel tuo flusso di lavoro sui contenuti.

Misura l'effetto sul tuo sito prima e dopo: confronta i byte delle immagini trasferiti nel pannello di rete del browser e controlla l'LCP su corewebvitals.page. Puoi provarlo con una prova gratuita di 7 giorni, senza carta di credito. Nella pagina dei piani trovi cosa include ciascun piano.

Domande frequenti

È meglio WebP o AVIF?

AVIF produce spesso file più piccoli di WebP a qualità simile, soprattutto per le foto, ma richiede più tempo di codifica. WebP è una scelta predefinita sicura con un supporto ampio. Molti siti servono AVIF dove possibile e WebP o l'originale come fallback.

Che dimensioni devono avere le immagini per un sito web?

Adeguale alla misura più grande con cui l'immagine viene mostrata, e prevedi circa il doppio di quella larghezza per gli schermi ad alta densità. Usa srcset così gli schermi più piccoli scaricano file più leggeri. Caricare la risoluzione piena della fotocamera non serve quasi mai.

Il lazy loading danneggia la SEO?

Il lazy loading nativo con loading="lazy" è supportato da Google e non nasconde le immagini alla ricerca. Il vero rischio riguarda le prestazioni: il lazy loading sull'immagine principale sopra la piega ritarda l'LCP. Usalo solo per le immagini più in basso nella pagina.

Come faccio a verificare se le mie immagini sono ottimizzate?

Analizza la pagina con corewebvitals.page e controlla l'LCP su mobile e desktop. Per vedere qual è l'elemento LCP, apri il pannello Performance di Chrome DevTools. Nel pannello di rete del browser filtra per immagini e confronta dimensioni dei file e formati. La nostra guida su come misurare la velocità di un sito mostra come fare un test prima e dopo affidabile.

Mi serve ancora un plugin di ottimizzazione immagini in WordPress?

Dipende dalla tua configurazione. Un plugin che ridimensiona e comprime i caricamenti aiuta comunque, perché la sola conversione di formato non risolve le dimensioni eccessive. Se il tuo CDN gestisce già la conversione in WebP o AVIF, di solito puoi disattivare quella parte del plugin per non fare lo stesso lavoro due volte. Per il quadro completo leggi perché un sito WordPress è lento.