Perché il mio mini carrello WooCommerce smette di comparire quando attivo Remove Unused CSS?

Ottimizza il negozio, il report PageSpeed migliora, e poche ore dopo un cliente scrive: l'icona del carrello non fa nulla. Ci passa sopra col mouse, non si apre nulla. Oppure si apre vuoto, o senza alcuno stile. Non ha mai toccato il carrello. Ha attivato un'ottimizzazione CSS. Cosa è successo?

Il mini carrello è la piccola icona del carrello nell'header, di solito con un conteggio degli articoli, e il pannello che si apre quando ci si passa sopra col mouse o lo si tocca, con l'elenco di ciò che contiene il carrello. È quel pannello la parte che si rompe, e ci sono due motivi per cui si rompe, spesso insieme.

Cos'è davvero un mini carrello (e perché è fragile)

Al caricamento della pagina, il pannello non deve essere visibile. Resta nascosto: display:none, oppure opacity:0 con visibility:hidden, oppure spostato fuori dallo schermo. Non compare nulla finché non si interagisce.

Sono due gli elementi che lo fanno comparire. Il CSS contiene lo stato nascosto e lo stato aperto, le regole che lo rendono visibile e posizionano il pannello. Il JavaScript esegue il cambio di stato: al passaggio del mouse o al tocco aggiunge una classe che attiva il pannello, oppure costruisce e inietta al volo il contenuto del carrello. Su WooCommerce questa costruzione è di solito affidata a wc-cart-fragments.js, lo script che mantiene sincronizzati il mini carrello e il conteggio degli articoli via AJAX.

Tolga il CSS corretto, o impedisca l'esecuzione dello script corretto, e il pannello non comparirà mai. Accade quando si ottimizza senza indicare allo strumento di lasciare in pace il carrello.

Causa 1: il CSS è nascosto, quindi viene rimosso

Un passaggio used-CSS o remove-unused-CSS mantiene gli stili di ciò che è visibile nel momento in cui esegue il rendering della pagina, e scarta il resto. In quel momento il pannello del mini carrello è nascosto, quindi lo strumento ne giudica gli stili superflui e li elimina.

Di conseguenza si rompono due cose. La regola che faceva comparire il pannello all'apertura è sparita, quindi il passaggio del mouse non produce nulla di visibile. Oppure è sparito lo stile del pannello stesso, che si apre senza formattazione: un semplice elenco senza posizionamento e senza sfondo, che si riversa nella pagina.

È lo stesso meccanismo che elimina un menu mobile nascosto o un overlay di ricerca. La spiegazione completa, e la soluzione duratura, si trovano in la nostra guida su come il critical CSS rompe menu e overlay.

Causa 2: il JavaScript non si attiva mai

Anche con gli stili intatti, il pannello ha bisogno del suo script per aprirsi. Se si ritarda o si differisce il JavaScript, lo script che aggiunge la classe di apertura, o quello che costruisce il carrello, potrebbe non essere ancora disponibile quando il visitatore ci passa sopra col mouse.

Su WooCommerce il principale indiziato è wc-cart-fragments.js, più lo script del tema o del carrello laterale (side-cart) che gestisce l'hover, più jQuery alla base di entrambi. Ritardando la catena, il conteggio smette di aggiornarsi, oppure il pannello resta vuoto, oppure l'icona è semplicemente morta.

Differire il JavaScript vale la pena, ma l'interazione del carrello deve continuare a funzionare. Il metodo, escludere l'intera catena di dipendenze tramite frammento di URL con una protezione (guard) che tolleri un caricamento anticipato, è lo stesso che risolve un menu a hamburger a doppio tocco, trattato in la guida sul menu a hamburger.

Un'avvertenza: non disattivi wc-cart-fragments.js per risparmiare la richiesta AJAX. Quella richiesta ha un costo reale su ogni pagina, e se ne può limitare l'esecuzione, ma eliminarla uccide un mini carrello funzionante. Lo escluda dal ritardo, non lo rimuova.

Diagnosi in 30 secondi

Disattivi per un momento l'opzione used-CSS. Se il mini carrello torna a funzionare, il colpevole è il CSS. La riattivi e passi direttamente alla safelist.

Se gli stili ci sono chiaramente ma il pannello continua a non aprirsi, osservi la scheda Network: passi col mouse sull'icona e verifichi se wc-cart-fragments.js e lo script del tema si caricano ed eseguono. Se si attivano in ritardo, o non si attivano affatto, il colpevole è il ritardo.

E controlli sia su mobile che su desktop. Molti motori mantengono una versione ottimizzata separata per dispositivo, quindi un carrello che funziona su desktop può comunque essere rotto su mobile.

Le eccezioni da aggiungere

Mantenere il CSS (safelist). Protegga i selettori del mini carrello dalla potatura (pruning). Quelli comuni di WooCommerce:

• il widget principale: .widget_shopping_cart, .widget_shopping_cart_content, .woocommerce-mini-cart, .mini_cart_item, .cart_list, .cart-contents
• il carrello a blocchi, se lo utilizza: .wc-block-mini-cart e i suoi elementi figli
• lo stato aperto, il più importante: qualunque classe renda visibile il pannello sul proprio sito (spesso .active, .is-open, .open, .show)
• il wrapper del tema o del plugin di carrello laterale (side-cart), da individuare direttamente sulla pagina

Una safelist dipende dal plugin e dalla configurazione, quindi tende a disallinearsi nel tempo. La versione che sopravvive a una rigenerazione consiste nell'inserire in linea lo stato nascosto e l'intero stile dello stato aperto in un blocco che l'ottimizzatore è istruito a lasciare intatto, posizionato dopo wp_head(). Quel metodo è descritto in la guida sul critical CSS.

Mantenere il JS (esclusioni). Escluda gli script del carrello dal ritardo, come catena unica:

• wc-cart-fragments.js, quello che costruisce e aggiorna il mini carrello
• jQuery e jQuery Migrate, da cui dipende
• lo script del tema o del plugin di carrello laterale che gestisce l'hover o il toggle

Li individui tramite un frammento univoco del loro URL, non tramite l'handle interno, e si assicuri che lo script escluso tolleri un caricamento anticipato. Escluda l'intera catena insieme, altrimenti ottiene il risultato "escluso ma morto": il carrello risulta escluso e continua comunque a non funzionare.

Una nota per chi sviluppa temi e plugin

Se sviluppa il carrello, può trasformare tutto questo in un'eccezione di una sola riga. Dia al componente un'unica classe namespace, ad esempio minicart, e circoscriva ogni regola al suo interno: lo stato nascosto, lo stato aperto e ogni elemento figlio.

.minicart              { opacity: 0; visibility: hidden; }
.minicart.is-open      { opacity: 1; visibility: visible; }
.minicart .item        { /* ... */ }
.minicart .count       { /* ... */ }

Ora l'intero componente è in safelist con un solo token, .minicart, e nessun ottimizzatore può scomporlo. Se invece si disperdono gli stessi stili tra selettori generici come .cart-item o .flyout.open e ciascuno richiede una propria voce in safelist, e il sistema si rompe la prima volta che qualcuno se ne dimentica una. Questo aiuta qualsiasi ottimizzatore, non solo Mantys.

Con Mantys Core

In sintesi

• Il mini carrello resta nascosto finché qualcuno non ci passa sopra col mouse, quindi un passaggio used-CSS ne rimuove gli stili e un ritardo JS ne impedisce l'apertura.
• La prima causa è il CSS: il pannello nascosto viene giudicato inutile e privato dei suoi stili. La seconda causa è il JS: lo script che apre o costruisce il carrello non viene mai eseguito.
• Si risolve il CSS con una safelist, o meglio, con un blocco inline non ottimizzabile per gli stili nascosti e aperti.
• Si risolve il JS escludendo l'intera catena, cart fragments più jQuery più lo script del tema, dal ritardo, e non rimuovendo mai cart fragments.
• Se sviluppa il tema, metta il carrello sotto un'unica classe namespace così l'eccezione diventa una sola riga.