Core Web Vitals per l'Ecommerce: Perché i visitatori con alto intento di acquisto ottengono le prestazioni peggiori

Il problema invisibile delle prestazioni negli ecommerce

Molti dei miei clienti tengono molto a superare i Core Web Vitals. Superarli significa che il 75% di tutto il traffico dovrebbe avere una buona user experience. Un obiettivo ammirevole. Ma nell'ottimizzare per quel 75%, un piccolo ma critico gruppo di circa il 5% viene trascurato: i visitatori che si convertiranno in clienti.

L'ironia? Questi visitatori con alto intento di acquisto spesso ottengono le prestazioni peggiori sul tuo sito. Non perché ti sei dimenticato di ottimizzare. Perché il tuo sistema di caching li esclude attivamente.

Ultima revisione a cura di Arjen Karel a Marzo 2026

Perché i tuoi dati CrUX nascondono il problema

L'ottimizzazione dei Core Web Vitals, principalmente per via del bonus di ranking su Google, tende a concentrarsi sull'ottimizzare per il visitatore leggermente sotto la media. Negli ecommerce, ha molto senso andare oltre questo aspetto e aggiungere un'attenzione extra ai visitatori con un alto intento di acquisto. Quelli sono i visitatori che si convertono in clienti.

Secondo una ricerca di Deloitte e Google, un miglioramento di 0,1 secondi nella velocità della pagina porta ad un aumento del 9,1% nelle azioni di aggiunta al carrello per i siti di vendita al dettaglio. Questo è anche l'esatto momento in cui il caching smette di funzionare per loro.

Tipicamente, possiamo identificare questi utenti dal numero di articoli nel loro carrello.

C'è un altro punto cieco. CrUX (il Chrome User Experience Report) traccia solo gli utenti Chrome che hanno la sincronizzazione abilitata. Molti acquirenti di ecommerce utilizzano Safari su mobile o browser senza sincronizzazione. La tua dashboard CrUX potrebbe mostrare punteggi verdi mentre i tuoi veri acquirenti sperimentano qualcosa di molto diverso. Questo è il motivo per cui un punteggio CrUX positivo non racconta tutta la storia.

Il crollo del caching: cosa succede quando un utente aggiunge al carrello

Ecco il problema: aggiungere articoli a un carrello della spesa distrugge il tuo caching. E il caching è ciò che rende veloce il tuo sito.

I plugin di caching disabilitano la cache a pagina intera per gli utenti con contenuti dinamici. Qualcosa di così semplice come "articoli in un carrello della spesa" forza il server a ricostruire l'intera pagina ad ogni richiesta. Questo aumenta significativamente il tuo Time to First Byte, il quale rallenta direttamente il Largest Contentful Paint e il First Contentful Paint.

I numeri sono drammatici. Su un tipico sito WooCommerce, il TTFB passa da circa 100ms (con cache) a 1.600ms o più (senza cache). Si tratta di un aumento di 16 volte nel tempo di risposta del server nel momento in cui qualcuno aggiunge un prodotto al proprio carrello. Ho visto casi in cui gli utenti loggati di WooCommerce aspettano dai 5 ai 9 secondi per una pagina che si carica in meno di un secondo per i visitatori anonimi.

Come ogni piattaforma gestisce il problema

WooCommerce imposta diversi cookie quando un utente aggiunge al carrello: woocommerce_cart_hash, woocommerce_items_in_cart, e wp_woocommerce_session. Nel momento in cui qualsiasi plugin di caching (WP Rocket, LiteSpeed Cache, WP Super Cache) rileva questi cookie, bypassa la cache per ogni pagina. Non solo la pagina del carrello. La tua homepage, le pagine dei tuoi prodotti, le pagine delle tue categorie: tutte non in cache. Oltre a questo, WooCommerce lancia una richiesta AJAX a /?wc-ajax=get_refreshed_fragments al caricamento di ogni pagina per mantenere aggiornato il widget del mini-carrello. Questa singola richiesta può richiedere dai 2 ai 3 secondi su un hosting condiviso.

Questa è una delle ragioni per cui WooCommerce ha il tasso di superamento dei Core Web Vitals più basso tra tutte le principali piattaforme di ecommerce. Secondo il 2025 Web Almanac, solo il 33% dei siti WooCommerce supera tutti e tre i Core Web Vitals su desktop, in confronto al 76% di Shopify.

Shopify gestisce questo aspetto in modo migliore grazie alla sua infrastruttura CDN gestita, ma persino Shopify non può mettere in cache pagine che contengono gli oggetti customer o cart. La differenza è che il TTFB di base di Shopify (circa 0,51 secondi) è già sufficientemente veloce da rendere la penalità dell'assenza di cache più ridotta.

Magento 2 ha trovato una soluzione intelligente: la pagina intera è sempre in cache, persino per gli utenti con il carrello. I contenuti dinamici (mini-carrello, saluto all'utente, stato del magazzino) vengono recuperati lato client tramite AJAX su /customer/section/load/ e archiviati nel localStorage del browser. La pagina in sé rimane nella cache a pagina intera. Questo è il problema del "lento by design" risolto a livello architetturale.

I tuoi migliori clienti ottengono le tue pagine peggiori

I numeri rendono questo aspetto doloroso. Farfetch ha misurato un calo dell'1,3% nel tasso di conversione per ogni 100ms di aumento dell'LCP. Blue Triangle ha rilevato un declino dal 40 al 50% del tasso di conversione quando l'LCP passa da 2 secondi a 4 o 5 secondi.

Un visitatore naviga il tuo sito veloce e in cache. Trova un prodotto che gli piace. Clicca su "aggiungi al carrello". In quell'esatto momento, il caching si interrompe e il suo TTFB salta da 100ms a 1.600ms. Da qui in poi, ogni pagina che visita (confrontare prodotti, controllare la spedizione, dirigersi al checkout) non è in cache. Le persone più propense ad acquistare stanno ora navigando la versione più lenta del tuo sito.

Nei siti monitorati da CoreDash, vediamo gli utenti con il carrello subire un TTFB dalle 3 alle 5 volte peggiore rispetto ai visitatori anonimi su piattaforme ecommerce self-hosted. Su piattaforme gestite come Shopify il divario è più piccolo (da 1,5 a 2x) ma comunque misurabile.

Come rilevare questo nei tuoi dati RUM

Non puoi vedere questo problema in Lighthouse o in PageSpeed Insights. Quegli strumenti eseguono i test come visitatori anonimi senza alcun cookie. I tuoi punteggi di laboratorio sembreranno fantastici mentre i tuoi veri acquirenti faranno fatica.

Per trovare questo problema, hai bisogno di un Real User Monitoring. Segmenta i tuoi dati RUM in base al fatto che l'utente abbia un cookie del carrello impostato. Confronta il TTFB, l'FCP e l'LCP tra questi due segmenti. Se vedi un divario di 2x o più, il bypass della cache è il tuo problema.

Nella maggior parte delle piattaforme di analytics puoi segmentare anche per tipo di pagina. Confronta le tue pagine di listing dei prodotti (di solito in cache) con le tue pagine del carrello e del checkout (mai in cache). Una differenza di TTFB di oltre 500ms tra queste tipologie di pagina è un campanello d'allarme che indica che la tua server waiting duration ha bisogno di attenzione.

Come correggere le prestazioni per i visitatori con alto intento di acquisto

Sistema il backend prima di affidarti al caching. Non fare affidamento esclusivamente sui plugin di caching. Analizza il codice del tuo backend, ottimizza le query al database e metti a punto il tuo server per assicurare un TTFB veloce persino senza caching. Un sito che è lento senza cache sarà catastroficamente lento per gli utenti con il carrello. La sub-parte cache duration del TTFB non dovrebbe fare tutto il lavoro pesante.

Utilizza il caching parziale (fragment caching). Metti in cache le parti costose della tua pagina separatamente. Le descrizioni dei prodotti, i menu di navigazione e i contenuti del footer cambiano raramente e possono essere messi in cache su Memcached o Redis persino quando la cache a pagina intera è disabilitata. Quando un utente con il carrello richiede una pagina, il tuo CMS la assembla dai frammenti in cache invece di rigenerare tutto da zero. Questo può tagliare il TTFB senza cache dal 60 all'80%.

Rendi i componenti dinamici lato client. Questo è l'approccio di Magento 2 e funziona. Servi la maggior parte della pagina come HTML in cache (server-side rendered). Poi utilizza JavaScript e una piccola chiamata API per recuperare le parti dinamiche (conteggio del carrello, saluto all'utente, raccomandazioni personalizzate) dopo che la pagina si è caricata. Il browser ottiene l'HTML veloce e in cache immediatamente. I bit dinamici si riempiono un istante dopo. Il tuo LCP e il tuo FCP rimangono veloci perché sono guidati dalla shell in cache, non dal contenuto dinamico.

Il framework headless di Shopify (Hydrogen) fa esattamente questo: i dati del prodotto sono aggressivamente messi in cache con TTL lunghi, mentre i dati del carrello e dei clienti usano CacheNone() e vengono recuperati lato client dopo il caricamento. Questo pattern evita anche problemi di INP poiché il recupero dinamico avviene in modo asincrono invece di bloccare l'interazione dell'utente.

Implementa una gestione efficace delle cache key. Usa chiavi semplici per gli elementi statici (l'URL spesso è sufficiente come cache key) e chiavi complesse per i contenuti dinamici che includono l'ID utente, gli ID dei prodotti e i timestamp. Questo ti permette di mettere in cache a livello di singolo utente invece di dover scegliere tra "tutto in cache" e "niente in cache".

Disabilita i frammenti del carrello sulle pagine che non sono del carrello. Se utilizzi WooCommerce, disabilita la chiamata wc-ajax=get_refreshed_fragments sulle pagine che non mostrano un mini-carrello. Diversi plugin di ottimizzazione delle prestazioni (Perfmatters, FlyingPress) offrono un interruttore per farlo. Questo elimina una chiamata AJAX di 2 o 3 secondi ad ogni caricamento di pagina per gli utenti con il carrello.

Considera la edge-side composition. Se utilizzi Cloudflare, i Worker possono assemblare le pagine all'edge: servire il corpo della pagina in cache dalla CDN e iniettare frammenti dinamici (carrello, informazioni dell'utente) tramite sotto-richieste separate. Cloudflare ha pubblicato un'implementazione Edge Side Includes per i Worker che fa esattamente questo, mantenendo veloce il tuo TTFB pur continuando a servire contenuti personalizzati.