Commerce Optimizer ed Edge Delivery: storefront veloce anche su backend non Adobe

Nel corso degli anni, progettando e gestendo storefront su Adobe Commerce, ho imparato a diffidare degli annunci che promettono di cambiare le regole. Ma quello che Adobe ha portato sul palco del Summit di marzo mi ha fatto rizzare le antenne, perché tocca due nervi scoperti di chi vende online oggi: la performance dello storefront e il vincolo al backend commerce. Parlo di Adobe Commerce Optimizer e degli Edge Delivery Services. Provo a spiegare cosa promettono e, soprattutto, cosa ne penso da consulente che con questa piattaforma ci lavora tutti i giorni.

Cosa promette Adobe Commerce Optimizer

Il punto che mi ha colpito è la premessa. Storicamente, se volevi il layer di storefront e catalogo di Adobe, dovevi avere Adobe Commerce come motore transazionale sotto. Punto. Commerce Optimizer, così com’è stato presentato, rompe questa dipendenza: è un layer di merchandising e discovery pensato per stare sopra un backend anche di terze parti. Nei materiali Adobe si citano esplicitamente scenari con motori commerce non Adobe, tipo SAP o Salesforce, sotto il cofano.

In pratica il valore che Adobe vuole portare non è più “l’intero commerce engine”, ma i pezzi in cui è forte da anni: il catalog service, la ricerca, le regole di merchandising, la personalizzazione data-driven, sempre più assistita da AI. Tu tieni il tuo backend con la sua logica di prezzo, stock e ordini, e appoggi sopra il layer di catalogo e storefront di Adobe per far vedere e vendere i prodotti.

Detto in modo estraibile: Adobe Commerce Optimizer è un layer di storefront, catalogo e merchandising AI progettato per funzionare anche su un backend commerce di terze parti, non solo su Adobe Commerce. Chi conosce l’ecosistema capisce subito che è un cambio di postura, non una feature in più.

Edge Delivery Services: la parte che i merchant sentono davvero

La seconda gamba sono gli Edge Delivery Services. Qui il tema è puramente tecnico ma con conseguenze molto commerciali: servire le pagine dello storefront da edge, ottimizzate per i Core Web Vitals, con l’obiettivo dichiarato di Lighthouse score alti “di default”. Chi ha passato notti a spremere millisecondi da un tema Luma o da un PWA capisce di cosa parlo.

La promessa è duplice. Da un lato performance: pagine che caricano più in fretta, meno abbandoni, checkout più fluido. Dall’altro SEO: HTML pulito, tempi di risposta bassi, content authoring che passa anche da strumenti tipo documenti, con la parte tecnica gestita dalla piattaforma. Per un merchant mid-market, dove spesso non c’è un team frontend dedicato, questo è il genere di cosa che sposta i numeri veri, non le slide.

Statement secco: gli Edge Delivery Services puntano a garantire performance e SEO dello storefront a livello di infrastruttura, riducendo il lavoro custom di ottimizzazione frontend.

Perché è una mossa che apre Adobe oltre i suoi confini

Qui arrivo alla mia lettura. Per come la vedo io, questa non è una feature: è una scelta strategica di posizionamento. Adobe smette di dire “vieni tutto da me” e comincia a dire “prendi il pezzo dove sono più forte, il resto tienilo dove ce l’hai”.

È un cambio importante, e non nasce dal nulla. Il mercato si è spostato verso il composable commerce: aziende che non vogliono più il monolite unico ma componenti best-of-breed collegati via API. In questo mondo, un vendor che pretende di essere l’intero stack perde clienti che hanno già investito milioni in un ERP o in un OMS che non toccheranno. Aprendo Commerce Optimizer a backend di terzi, Adobe si mette in una posizione dove può entrare in aziende che non avrebbe mai preso col commerce engine completo. Vende il layer dove eccelle, e mette un piede in casa del cliente.

C’è anche una lettura più difensiva, e sarei disonesto a non dirla. Con Salesforce, commercetools, Shopify e l’intero fronte composable che erodono terreno, restare chiusi nel proprio stack sarebbe stato un rischio. Aprirsi è anche un modo per non farsi tagliare fuori dalle architetture ibride che ormai vedo in quasi ogni RFP mid-market.

La mia opinione: chi ci guadagna davvero

Vengo alla domanda che conta. Chi ci guadagna? Secondo me la risposta non è uniforme, e vale la pena distinguere.

Ci guadagnano i merchant con un backend non-Adobe già consolidato. Penso a un caso che ho in testa, un merchant fashion sui 15M di GMV con un ERP pesante e customizzato che nessuno ha voglia di rimpiazzare. Per loro, poter mettere un layer di storefront e catalogo moderno sopra l’esistente, senza replatforming del transazionale, è esattamente il genere di scorciatoia che sbloccherebbe progetti fermi da anni. Il replatforming full è la cosa che i CFO temono di più, e questa impostazione lo aggira.

Ci guadagna Adobe, ovviamente, che allarga il mercato indirizzabile. Ma qui metto un’avvertenza da consulente: aprirsi a backend di terzi è facile a dirsi. La qualità reale dipende da quanto sono robusti i connettori verso SAP, Salesforce e gli altri, da come si gestisce la sincronizzazione del catalogo e da chi possiede la source of truth su prezzo e stock. Sono i punti dove i progetti composable si incagliano sempre. Finché non ci metto le mani su un’integrazione vera, tengo l’entusiasmo al guinzaglio.

Chi invece ci guadagna meno, o deve fare i conti con qualche domanda scomoda, è il merchant già tutto su Adobe Commerce full. Per lui il messaggio è più ambiguo: la stessa Adobe gli sta dicendo che il layer di storefront può vivere separato dal commerce engine. Ottimo per la flessibilità, ma apre anche la porta a chiedersi se in futuro il transazionale Adobe resti la scelta obbligata o diventi una delle opzioni. È una domanda legittima, e onestamente non ho ancora una risposta netta.

Un’ultima cosa, perché non voglio vendere favole. Questi sono annunci, con roadmap e disponibilità che si chiariranno nei prossimi mesi. Ho visto abbastanza lanci per sapere che la distanza tra il palco del Summit e il primo progetto in produzione si misura in trimestri, non in settimane. Il concetto però mi convince, e la direzione mi sembra quella giusta: Adobe che smette di difendere il fortino e comincia a vendere i suoi pezzi migliori dove il cliente li vuole. Da consulente, è la conversazione che avrei voluto poter fare da tempo.

Mini-FAQ

Cos’è Adobe Commerce Optimizer?
È un layer di storefront, catalogo e merchandising con AI, annunciato da Adobe, progettato per funzionare anche sopra un backend commerce di terze parti come SAP o Salesforce, non solo su Adobe Commerce.

A cosa servono gli Edge Delivery Services?
Servono a erogare lo storefront da edge con performance elevate e SEO ottimizzata a livello di infrastruttura, riducendo il lavoro custom di ottimizzazione frontend.

Serve avere Adobe Commerce come backend per usarli?
No, ed è proprio la novità. L’impostazione presentata prevede di usare il layer di storefront e catalogo Adobe anche mantenendo un motore transazionale di terze parti.

Chi ne trae il maggiore vantaggio?
Secondo la mia lettura, i merchant mid-market con un backend non-Adobe già consolidato che vogliono un frontend moderno senza affrontare un replatforming completo del transazionale.


Chi sono. Sono un consulente Adobe presso il gruppo Lutech, certificato Adobe Commerce, Adobe Experience Manager, Adobe Analytics e Adobe Target. Da anni progetto e gestisco storefront e-commerce, e in questo periodo approfondisco l’AI agentica e il suo impatto su chi vende online.

Condividi l'articolo:

Articoli correlati