WordPress conserva diverse copie di ogni immagine e non ne ottimizza nessuna

Carica una foto su WordPress e non ottieni un file. Ottieni una miniatura, una media, una media-grande, una grande, la dimensione piena e tutte le dimensioni extra che il tuo tema e il tuo page builder hanno registrato. Sei o otto file da un solo caricamento è la norma. Ognuno viene ricodificato alla qualità JPEG predefinita di WordPress e poi non viene più toccato.

Moltiplicalo su qualche anno di pubblicazioni e la cartella degli upload è di solito la cosa più pesante nel tuo backup, e la parte più lenta delle tue pagine. Gran parte di questo peso è evitabile.

Dov’è davvero il peso

Sono i JPEG. Le foto dominano una libreria tipica, e WordPress le codifica a una qualità fissa (82 per impostazione predefinita) con un vecchio encoder. È un valore predefinito prudente e ragionevole, non un file piccolo. Screenshot e loghi salvati come PNG aggiungono altro, perché il PNG è il contenitore sbagliato per molti di loro.

Ci sono due modi onesti per ridurlo, e i compromessi sono diversi.

1. Ricodificare sul posto

Prendi ogni dimensione generata e ricodificala in una versione più leggera dello stesso formato: il JPEG resta JPEG, il WebP resta WebP. Un encoder moderno toglie da circa un quinto a un quarto da un JPEG predefinito di WordPress senza cambiamento visibile.

Il bello è che nient’altro sul tuo sito se ne accorge. Il nome del file, le dimensioni e l’estensione sono identici, quindi ogni URL continua a funzionare, in ogni tema, in ogni pagina in cache, in ogni <img> scritto a mano. È l’opzione noiosa e sicura, e per molti siti è quella giusta.

Ciò che non farà: cambiare formato. Un JPEG resta un JPEG, quindi non ottieni i guadagni maggiori che ti darebbe un formato più recente.

2. Servire formati di nuova generazione

Genera un AVIF (e un WebP) accanto a ogni originale e servilo tramite un tag <picture>, mantenendo il JPEG o il PNG originale come ripiego per i browser più vecchi. È qui che stanno i risparmi veri: a parità di qualità, l’AVIF ha bisogno di molti meno byte del JPEG, e finalmente copre anche i tuoi PNG. Abbiamo misurato il divario su circa 1.900 foto se vuoi i numeri.

Le riserve oneste, perché ce ne sono:

• Riscrive l’HTML della pagina, il che la rende indipendente dal tema, ma tocca solo i tag <img>. Un background-image in CSS non verrà sostituito.
• Un lazy-loader JavaScript che riscrive src a runtime può non accorgersene. Il loading="lazy" nativo va bene.
• Il GIF non è ancora coperto.

Gli originali restano esattamente dove sono, quindi non si perde niente, e i browser che non sanno leggere l’AVIF ripiegano sul file che già capivano.

La parte che preoccupa davvero le persone

Entrambi gli approcci conservano un backup di ogni originale, quindi qualsiasi immagine si ripristina ai suoi byte esatti con un clic. Un file viene sostituito solo quando il nuovo è strettamente più piccolo, quindi niente diventa più grande. E se un’ottimizzazione fallisce, viene saltata, non è fatale: il tuo caricamento non si blocca mai e un’immagine non resta mai scritta a metà.

Farlo

È questo che fa Patu Optimizer. I nuovi caricamenti si ottimizzano automaticamente, un unico passaggio in blocco gestisce tutto ciò che è già nella libreria, e scegli sul posto o nuova generazione per ogni sito. Gira sull’API Patu, quindi la codifica avviene fuori dal tuo server. Una chiave gratuita basta per iniziare.

Inizia con sul posto se vuoi zero sorprese. Passa alla nuova generazione quando vuoi i byte e le tue pagine usano tag <img> normali. In ogni caso, l’obiettivo è lo stesso: smettere di consegnare una libreria multimediale due o tre volte più pesante del necessario.