Velocizzare un e-commerce Shopify con un servizio esterno: cosa può andare storto

Un banner che non spariva e foto prodotto che non si vedevano: due incidenti reali, con la stessa radice, causati da un servizio esterno che riscrive il sito al volo.

Davide Ruggeri

Davide Ruggeri

A fine agosto un mio cliente, un e-commerce di moda su Shopify, ha riaperto dopo la pausa estiva. Una settimana più tardi chi apriva la home leggeva ancora l’avviso di chiusura, con la promessa che gli ordini sarebbero partiti al rientro. Il banner era stato tolto dal pannello di Shopify da giorni, ma per i visitatori non era mai sparito.

Shopify non c’entrava. Il negozio passava da un servizio esterno di ottimizzazione della velocità, di quelli che si attivano senza toccare il tema e promettono Core Web Vitals in verde. In poche settimane ho trovato due problemi diversi con la stessa radice, e il cliente ha deciso di staccarlo.

Non faccio il nome del servizio: lo stesso modello lo usano diversi prodotti della categoria, e i rischi che racconto valgono per tutti.

Come funzionano i servizi che velocizzano il sito al volo

Si mettono tra il negozio e il visitatore. Il dominio non punta più alla piattaforma ma a un proxy, quasi sempre costruito su Cloudflare, che riceve la pagina dall’origine, la riscrive e la consegna al browser. Nel passaggio comprime le immagini, ritarda gli script, tiene in cache l’HTML, aggiunge il lazy loading e a volte genera meta tag e dati strutturati.

Sulla carta è comodo. Il codice che arriva ai clienti però non è più quello del tema, e nessuno del team lo legge a meno di andarlo a cercare apposta.

Su Shopify c’è un’aggravante. La piattaforma gira già su Cloudflare, con la sua CDN e la sua cache, e nel centro assistenza dichiara che i proxy davanti al dominio non sono supportati e possono interferire con il sito. Se qualcosa si rompe, il supporto di Shopify ti rimanda al fornitore del proxy.

Primo incidente: una cache che non scadeva mai

Ho fatto dieci richieste consecutive alla home e tutte e dieci hanno restituito la stessa copia, salvata una settimana prima. Gli header di risposta erano chiari: la pagina arrivava dalla cache, aveva sette giorni di età e la regola impostata permetteva di tenerla per 24 giorni.

La presentazione commerciale del servizio parlava di una cache dinamica aggiornata ogni pochi secondi. La configurazione reale era decine di migliaia di volte più lunga.

Le poche richieste che sfuggivano alla cache mostravano la pagina corretta, quindi l’origine funzionava e il blocco stava tutto a valle. Il problema toccava la home e le pagine statiche, mentre collezioni e carrello erano a posto. Per questo nessuno se n’era accorto: chi lavora sul negozio guarda i prodotti, non la home.

Un banner sbagliato è il caso fortunato, perché almeno si vede. Con la stessa regola restano ferme per settimane anche variazioni di prezzo, disponibilità e testi delle promozioni. Il cliente modifica, controlla dal pannello e trova tutto giusto, mentre i visitatori vedono la versione vecchia.

Secondo incidente: le foto prodotto che sparivano

Qualche settimana dopo il cliente mi scrive che aprendo una scheda prodotto le immagini non si vedono. Le foto c’erano tutte e il server le restituiva senza errori. Il guasto stava nel modo in cui arrivavano al browser.

Il servizio riscriveva l’HTML: al posto di ogni foto metteva un segnaposto vuoto e spostava l’indirizzo vero in un attributo. A rimettere la foto al suo posto ci pensava una libreria JavaScript scaricata da un CDN pubblico esterno, e la pagina non aveva nessun fallback.

L’ho verificato aprendo la scheda in un browser automatico con quel CDN bloccato. Su desktop e su mobile la galleria era fatta di riquadri vuoti. Con la libreria caricata, invece, la pagina si vedeva perfettamente.

Basta poco perché lo script non arrivi: un adblock, i filtri di contenuto di Safari o di Brave, una rete aziendale che blocca i CDN, una connessione lenta che va in timeout. A quel punto la scheda prodotto di un negozio di abbigliamento è una pagina senza vestiti.

C’è anche un paradosso. I browser gestiscono il lazy loading da soli dal 2019 con un semplice attributo HTML, e il tema del cliente lo usava già. Rifarlo in JavaScript aggiunge una dipendenza e non porta nessun vantaggio. Applicarlo all’immagine principale, poi, peggiora proprio la metrica che questi servizi promettono di migliorare: un’analisi pubblicata da Google su web.dev ha trovato che i siti con lazy loading tendono ad avere un LCP peggiore, e che il problema sparisce caricando subito le immagini visibili all’apertura.

Due livelli che fanno lo stesso lavoro

I due incidenti hanno la stessa origine. Shopify ha già una CDN, una cache e un tema con il suo lazy loading. Il servizio esterno ci aggiunge sopra un secondo livello che rifà le stesse cose senza conoscere il negozio: quali pagine devono restare aggiornate, quali immagini servono subito, cosa non va toccato.

Intanto chi gestisce il sito perde la visibilità su quello che succede. Con il banner il cliente aveva fatto tutto bene e non aveva modo di saperlo. Con le foto il guasto compariva solo su alcuni dispositivi, quindi chi controllava dal proprio non lo vedeva mai.

Questi servizi vendono un punteggio, e il punteggio si misura in laboratorio: una pagina caricata una volta, da un browser pulito, su una rete veloce. Chi compra arriva con l’adblock attivo, dal telefono in metropolitana, e torna sulla stessa pagina dopo una settimana. È lì che i due livelli si pestano i piedi.

Come capire se il tuo e-commerce ha lo stesso problema

Non serve uno sviluppatore per i primi controlli.

  • Negli strumenti per sviluppatori del browser, scheda Rete, guarda gli header della home. Un’età della cache di giorni e un s-maxage molto alto vogliono dire che le modifiche non arrivano.
  • Confronta la pagina servita dal tuo dominio con quella all’indirizzo .myshopify.com. Se l’HTML è diverso, qualcuno lo sta riscrivendo.
  • Apri qualche scheda prodotto con un adblock attivo e da una rete diversa dalla tua.
  • Prima di giudicare la velocità, guarda i Core Web Vitals reali in Search Console e non solo il punteggio di PageSpeed.

Se trovi un livello in mezzo che non sapevi di avere, chiedi a chi l’ha installato quali regole applica e chi le controlla.

Dove si recupera davvero la velocità

Il cliente ha deciso di servire il sito direttamente da Shopify. Il lavoro sulla velocità resta dove è sempre stato: nel tema, nelle app installate che caricano script su ogni pagina, nel peso delle immagini caricate. È meno comodo di un servizio che si attiva con un click, ma il codice che arriva ai clienti è quello che puoi leggere e correggere.

Se vuoi un parere sul tuo sito, raccontami il tuo progetto.

Fonti