WebP per i siti web: perché dovresti
passare da JPG/PNG

L'elemento Picture con fallback JPG

L'elemento HTML <picture> è il modo più affidabile per servire WebP con un fallback per i browser più vecchi. Permette al browser di scegliere il formato migliore disponibile senza alcun JavaScript:

<picture>
  <source srcset="hero.webp" type="image/webp">
  <source srcset="hero.jpg" type="image/jpeg">
  <img src="hero.jpg" alt="Hero banner" width="1200" height="630"
       loading="lazy" decoding="async">
</picture>

Se il browser supporta WebP, scarica hero.webp. Altrimenti, cade sul hero.jpg. Il tag <img> serve come fallback finale e contiene anche gli attributi alt, width, height e loading.

Per le immagini responsive, combina l'elemento <picture> con srcset e sizes per servire risoluzioni diverse in base alla larghezza del viewport:

<picture>
  <source
    srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1200.webp 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 600px"
    type="image/webp">
  <img
    srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1200.jpg 1200w"
    sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 600px"
    src="photo-800.jpg" alt="Product photo" width="800" height="600"
    loading="lazy" decoding="async">
</picture>

Content Negotiation lato server

La content negotiation controlla l'header Accept del browser e serve WebP in modo trasparente — senza modifiche all'HTML. Quando un browser richiede un'immagine e include image/webp nel suo header Accept, il server risponde con la versione WebP.

Configurazione Nginx

Aggiungi questo al blocco server di Nginx per servire le varianti WebP quando esistono accanto ai file originali:

map $http_accept $webp_suffix {
    default   "";
    "~*webp"  ".webp";
}

server {
    location ~* \.(jpe?g|png)$ {
        add_header Vary Accept;
        try_files $uri$webp_suffix $uri =404;
    }
}

Cerca un file .webp accanto all'originale (es. photo.jpg.webp vicino a photo.jpg). Se il browser supporta WebP e il file esiste, Nginx lo serve. L'header Vary: Accept garantisce che CDN e proxy cache conservino versioni separate per browser con capacità diverse.

Regole Apache .htaccess

Per server Apache, aggiungi queste regole di rewrite al tuo file .htaccess:

RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule ^(.+)\.(jpe?g|png)$ $1.$2.webp [T=image/webp,L]

Header append Vary Accept env=REDIRECT_accept

Lo stesso principio si applica: se il browser accetta WebP e sul disco esiste una variante .webp, Apache la serve in modo trasparente. Nessuna modifica HTML necessaria.

Soluzioni CDN per la conversione automatica

L'approccio più semplice per la maggior parte dei siti è lasciare che il CDN gestisca automaticamente la conversione WebP. Carichi i file originali JPG/PNG e il CDN serve WebP ottimizzato ai browser supportati con zero modifiche al codice.

Le soluzioni basate su CDN gestiscono automaticamente content negotiation, caching e invalidazione della cache. Sono l'approccio consigliato per i siti dinamici dove utenti o redattori caricano immagini — non puoi prevedere quali immagini appariranno, quindi la conversione automatica è essenziale.

Setup WebP su WordPress

WordPress 5.8+ supporta i caricamenti WebP in modo nativo, ma hai bisogno di un plugin per convertire le immagini esistenti e servirle in modo ottimale:

• ShortPixel Image Optimizer: Converte le immagini esistenti in WebP al volo. Serve WebP tramite elemento <picture> o rewrite .htaccess. Piano gratuito: 100 immagini/mese
• Imagify: Conversione in blocco con tre livelli di qualità (normale, aggressivo, ultra). Si integra con WP Rocket per la cache. Piano gratuito: 20 MB/mese
• EWWW Image Optimizer: Genera automaticamente copie WebP al caricamento. Riscrive gli URL delle immagini tramite plugin o CDN. Ottimizzazione locale gratuita e illimitata
• WebP Express: Plugin leggero focalizzato esclusivamente sulla conversione WebP. Configura .htaccess o usa la distribuzione basata su PHP. Gratuito e open source

Per la maggior parte dei siti WordPress, ShortPixel o EWWW sono le scelte più sicure. Gestiscono l'intera pipeline: conversione al caricamento, generazione varianti WebP, riscrittura HTML per servire WebP e fallback a JPG/PNG per i browser non supportati.

Integrazione con i build tool

Per i siti statici e i framework JavaScript (React, Vue, Next.js, Nuxt), integra la generazione WebP nella tua pipeline di build così le immagini vengono convertite automaticamente al momento del build.

Webpack (image-minimizer-webpack-plugin)

const ImageMinimizerPlugin = require("image-minimizer-webpack-plugin");

module.exports = {
  optimization: {
    minimizer: [
      new ImageMinimizerPlugin({
        generator: [{
          preset: "webp",
          implementation: ImageMinimizerPlugin.sharpGenerate,
          options: { encodeOptions: { webp: { quality: 80 } } }
        }]
      })
    ]
  }
};

Vite (vite-plugin-imagemin)

import viteImagemin from "vite-plugin-imagemin";

export default defineConfig({
  plugins: [
    viteImagemin({
      webp: { quality: 80 }
    })
  ]
});

La conversione in fase di build funziona bene per i siti con un insieme noto di immagini (pagine marketing, documentazione, blog). Per i contenuti caricati dagli utenti, preferisci soluzioni basate su CDN che elaborano le immagini dinamicamente.

Impostazioni di qualità ottimali

Scegliere la giusta impostazione di qualità WebP è fondamentale. Troppo bassa e compaiono artefatti visibili; troppo alta e si perdono i vantaggi in termini di dimensioni. Ecco le impostazioni consigliate per tipo di contenuto:

Misurare l'impatto

Dopo aver implementato WebP, misura il reale miglioramento delle performance con questi strumenti:

• Google Lighthouse: Esegui audit prima e dopo il passaggio. Controlla la diagnostica "Serve images in next-gen formats" — dovrebbe scomparire. Confronta il punteggio Performance, LCP e Total Blocking Time
• PageSpeed Insights: Testa su mobile e desktop dai server di Google. La sezione "Opportunità" non dovrebbe più elencare l'ottimizzazione delle immagini come raccomandazione
• WebPageTest: Fornisce waterfall chart dettagliate con i tempi di caricamento delle singole immagini. Confronta le viste filmstrip prima e dopo per vedere le differenze di velocità di rendering visivo
• Tab Network di Chrome DevTools: Filtra per tipo "Img" e confronta la dimensione totale del trasferimento. Verifica che l'header Content-Type mostri image/webp per le immagini convertite
• Search Console Core Web Vitals: Monitora i dati sul campo per 2–4 settimane dopo il passaggio. Cerca miglioramenti in LCP e nella percentuale complessiva di "URL buoni"

Considerazioni sul lazy loading

WebP e lazy loading lavorano insieme per massimizzare le performance, ma ci sono importanti dettagli implementativi:

• Immagini above-the-fold: NON applicare il lazy loading all'hero image o a qualsiasi immagine visibile al caricamento iniziale della pagina. Usa loading="eager" (il default) e aggiungi fetchpriority="high" per l'immagine LCP
• Immagini below-the-fold: Usa loading="lazy" su tutte le altre immagini. Il browser ne differisce il caricamento finché l'utente non scorre nelle vicinanze
• Imposta sempre le dimensioni: Includi attributi espliciti width e height su ogni tag <img> per prevenire il Cumulative Layout Shift (CLS)
• Decodifica asincrona: Aggiungi decoding="async" per permettere al browser di decodificare le immagini fuori dal thread principale

<!-- Hero image: eager loading, high priority -->
<img src="hero.webp" alt="..." width="1200" height="630"
     fetchpriority="high" decoding="async">

<!-- Below-the-fold: lazy loading -->
<img src="product.webp" alt="..." width="600" height="400"
     loading="lazy" decoding="async">