CDN per immagini in Magento 2: media cache, performance e SEO tecnica

CDN tradizionale e CDN immagini non fanno lo stesso lavoro

Una CDN tradizionale conserva nei propri nodi copie di file già prodotti. Riduce la distanza tra utente e risorsa, assorbe parte delle richieste e può diminuire il carico sul server di origine. Se Magento continua a creare dieci varianti locali, però, quelle dieci varianti restano nella media cache: vengono semplicemente distribuite attraverso la CDN.

Una CDN per immagini aggiunge un livello di trasformazione. A partire da un file sorgente può generare una larghezza, una qualità o un formato specifici e conservare il risultato all’edge. In questo modello il browser riceve una versione adatta al contesto senza obbligare necessariamente Magento a preparare in anticipo ogni combinazione.

Questa distinzione evita una promessa troppo ampia: non basta avere una CDN per ridurre la media cache. Occorre verificare dove avviene il ridimensionamento e se il frontend continua a richiamare gli URL derivati prodotti dall’applicazione.

CDN per immagini: un tema che seguo da anni

Sono passati alcuni anni da quando, in Tun2U, iniziai a parlare dell’importanza della CDN per le immagini di un eCommerce. Tun2U è il partner tecnico di ForzaSEO per lo sviluppo di eCommerce Magento.

Come cresce la media cache di Magento 2

Nel tema Magento, le proprietà delle immagini di prodotto sono configurate nel file view.xml. Ogni identificatore può specificare ruolo, larghezza, altezza, rapporto, trasparenza e comportamento di ridimensionamento. Quando una variante viene generata, la copia viene archiviata in pub/media/catalog/product/cache e utilizzata dal frontend.

Adobe documenta sia la configurazione in view.xml sia il comando bin/magento catalog:images:resize, che può produrre le copie previste dal tema. Questo meccanismo è corretto; diventa oneroso quando temi, moduli e personalizzazioni definiscono molte dimensioni sovrapposte o non più utilizzate. La documentazione Adobe sulle immagini del tema è il punto da cui partire per ricostruire le varianti attese.

In un catalogo ampio, il costo non riguarda soltanto i gigabyte. Contano anche il numero di file e inode, i tempi di backup, la rigenerazione dopo un deploy, le operazioni di pulizia e la coerenza tra ambienti. Prima di introdurre un nuovo servizio conviene quindi separare tre valori:

• numero e peso delle immagini sorgenti;
• numero e peso dei file presenti nella cache del catalogo;
• numero di varianti effettivamente richieste da PLP, PDP, gallerie, widget e viewport differenti.

Una sorgente non significa una sola immagine per tutti

Ridurre le duplicazioni all’origine non significa servire lo stesso file sovradimensionato in ogni punto del sito. Una miniatura di categoria, una fotografia nella pagina prodotto e un’immagine da zoom hanno requisiti diversi. Riutilizzare ovunque un originale da 1600 o 2400 pixel trasferisce e decodifica dati inutili, soprattutto su mobile.

Il modello più equilibrato prevede una sorgente di buona qualità e un insieme finito di trasformazioni controllate. Il browser deve ricevere una variante vicina alla dimensione di rendering, attraverso srcset e sizes coerenti con il layout. L’obiettivo non è produrre il minor numero possibile di file a qualunque costo, ma evitare varianti ridondanti senza penalizzare qualità e prestazioni.

Dove eseguire il resize: applicazione, server o edge

Il ridimensionamento può avvenire in punti diversi, ciascuno con conseguenze operative.

Dentro Magento

È il modello standard: Magento conosce i ruoli definiti dal tema, genera le copie e le conserva nella cache. È semplice da comprendere, ma CPU, spazio e inode restano a carico dell’infrastruttura applicativa.

Sul server o sullo storage remoto

Adobe prevede anche il ridimensionamento lato server per configurazioni con remote storage. I parametri di altezza e larghezza vengono passati nell’URL e il server produce la variante. È un modo per spostare lavoro fuori dall’applicazione senza adottare necessariamente un servizio esterno completo. La configurazione dipende però dall’architettura di hosting e va progettata con il team che gestisce l’infrastruttura.

All’edge tramite CDN immagini

Il servizio riceve l’originale, applica una trasformazione ammessa e memorizza il risultato vicino agli utenti. Può alleggerire l’origine e semplificare la gestione dei formati, ma richiede regole precise per parametri, cache key, qualità, fallback e invalidazione. Non esiste un punto di esecuzione migliore in assoluto: la scelta dipende dal deployment e dal problema misurato.

Adobe Commerce Cloud, Magento Open Source e Fastly

“Magento 2” può indicare installazioni molto diverse. Adobe Commerce on Cloud utilizza Fastly come CDN predefinita; Adobe Commerce as a Cloud Service usa una CDN gestita da Adobe. Un progetto Magento Open Source o on-premise non eredita automaticamente la stessa architettura e può richiedere una soluzione esterna, un modulo o un’integrazione personalizzata. La documentazione Adobe sulla CDN di Commerce distingue questi scenari.

Su Adobe Commerce Cloud, Fastly Image Optimization può trasformare le immagini in tempo reale. La modalità Deep Image Optimization disattiva il ridimensionamento integrato di Commerce e lo sposta su Fastly, ma riguarda le immagini di prodotto, non quelle CMS. Adobe segnala inoltre effetti da verificare su formati lossless, trasparenze e colore di sfondo. Sono dettagli che impediscono di trattare l’attivazione come un interruttore senza conseguenze. Vanno letti nella guida ufficiale a Fastly Image Optimization.

URL, cache key e invalidazione: i rischi da progettare

Una CDN per immagini può ridurre il lavoro sull’origine e, nello stesso tempo, introdurre nuove complessità. Prima dell’implementazione vanno definite almeno queste regole:

• un insieme limitato di larghezze e qualità ammesse, invece di combinazioni arbitrarie;
• URL stabili e accessibili senza cookie o autorizzazioni temporanee;
• parametri normalizzati, così che due trasformazioni equivalenti non creino cache key diverse;
• una strategia di purge o versionamento quando cambia l’immagine sorgente;
• fallback compatibili per formato e trasparenza;
• coerenza tra URL usati nell’HTML, nelle sitemap e nei dati strutturati.

URL firmati o parametrizzati non sono automaticamente un problema SEO. Lo diventano quando scadono, impediscono l’accesso a Googlebot o generano un numero incontrollato di combinazioni. Il controllo degli URL è quindi parte del progetto, non una rifinitura successiva.

Impatto SEO: indiretto ma misurabile

Una CDN non rende un’immagine più rilevante e non sostituisce contenuto, alt text o contesto della pagina. Può però migliorare il modo in cui il file viene distribuito: meno byte, dimensioni più appropriate e una risorsa LCP disponibile prima. Le indicazioni di web.dev sull’ottimizzazione del LCP raccomandano di non applicare il lazy loading all’immagine LCP e di usare fetchpriority="high" soltanto per una reale risorsa prioritaria. Il beneficio va verificato sulla pagina, non presunto dalla presenza della CDN.

Per la scoperta, Google raccomanda immagini in veri elementi <img>, URL accessibili e una variante di fallback nel src. Le sitemap immagini possono includere file ospitati su un dominio CDN; in quel caso Google suggerisce di verificare anche quel dominio in Search Console. Sono requisiti più concreti della semplice ripetizione di keyword. La guida ufficiale di Google alla SEO delle immagini copre questi controlli.

Alt text, filename e contenuto vicino all’immagine restano importanti, ma sono temi trasversali e non specifici della CDN. Li approfondiamo nella guida su come ottimizzare le immagini per la SEO; qui il punto è assicurarsi che l’architettura di distribuzione non renda le immagini instabili o difficili da scansionare.

Audit prima di scegliere una CDN per immagini

Prima di confrontare provider o moduli serve una baseline. Su un ambiente in cui l’operazione è sostenibile, i primi controlli possono includere:

du -sh pub/media/catalog/product
du -sh pub/media/catalog/product/cache
find pub/media/catalog/product/cache -type f | wc -l

Su cache con milioni di file, una scansione completa può essere costosa: va eseguita fuori dai picchi o sostituita con metriche dello storage. Il numero isolato non basta. Deve essere confrontato con immagini sorgenti, SKU attivi, ruoli definiti in view.xml e richieste osservate nel frontend.

Su un campione di pagine categoria e prodotto conviene poi registrare:

• dimensione intrinseca e dimensione di rendering di ogni immagine;
• variante scelta dal browser tramite srcset e sizes;
• peso trasferito, formato e intestazioni di cache;
• risposta HIT o MISS della CDN, quando disponibile;
• immagine LCP e relativo tempo di caricamento;
• URL restituiti a Googlebot e codice HTTP senza sessione.

Questa baseline permette di distinguere un problema di rete da un problema di template, storage o generazione delle varianti. Senza questa distinzione si rischia di acquistare una CDN per correggere dimensioni sbagliate richieste dal frontend.

Quando conviene e quando può essere superflua

Una CDN per immagini merita una valutazione quando il catalogo è ampio, ogni prodotto ha molte fotografie, la cache cresce in modo sproporzionato, la rigenerazione pesa sui deploy o il browser riceve spesso file più grandi del necessario. È particolarmente utile quando il servizio può sostituire una parte reale del lavoro svolto all’origine.

Può invece essere superflua se il catalogo è piccolo, le poche varianti sono già corrette, l’origine non ha problemi di CPU o storage e le immagini vengono distribuite nella dimensione adeguata. Anche in quel caso una CDN tradizionale può aiutare la latenza per un pubblico geograficamente distribuito, ma è un beneficio diverso dalla riduzione della media cache.

Come verificare il risultato dopo l’attivazione

Il confronto va svolto sulle stesse pagine, viewport e condizioni di rete usate per la baseline. Dopo l’attivazione vanno controllati almeno:

• crescita della cache locale e numero di nuovi derivati;
• richieste di resize e consumo di risorse sull’origine;
• peso delle immagini trasferite su mobile e desktop;
• cache hit ratio e comportamento dopo un aggiornamento del prodotto;
• LCP e stabilità del layout, in laboratorio e nei dati reali quando disponibili;
• accessibilità e indicizzazione degli URL immagine principali.

Una diminuzione del peso trasferito non dimostra, da sola, che la media cache sia stata risolta. Allo stesso modo, meno file all’origine non compensano URL instabili o immagini sovradimensionate. Il risultato va letto sull’intero flusso.

Conclusione

Una CDN per le immagini di Magento 2 è una scelta di architettura prima che una tecnica SEO. Può ridurre latenza, trasformazioni sull’origine e crescita della media cache, ma soltanto se sostituisce consapevolmente una parte del flusso esistente.

Il lavoro corretto parte da view.xml, cache, template e richieste del browser; prosegue con la scelta del punto in cui eseguire le trasformazioni; termina con misurazioni tecniche e controlli di scansione. È questo il livello di analisi che colleghiamo alla nostra attività di SEO per Magento.