Filtro prodotto AJAX: comodo catalogo senza ricaricare la pagina

Tre anni fa, il proprietario di un negozio online di ricambi per auto mi chiamò e mi disse una frase che da allora sento regolarmente: "Abbiamo un catalogo di quindicimila articoli e la gente se ne va senza raggiungere il prodotto giusto". Sono andato sul suo sito web, ho selezionato la marca dell'auto nel filtro e la pagina si è ricaricata. Selezionato il tipo di pezzo di ricambio: riavviare nuovamente. Ho provato a specificare la fascia di prezzo: un altro riavvio e tutti i filtri precedenti sono stati ripristinati. Tre clic: quindici secondi di attesa e completa perdita di contesto. Ho chiuso la scheda. E sono una persona che si occupa professionalmente di negozi online. Cosa fa l'acquirente medio? Esatto, va a Wildberries, dove il filtraggio funziona immediatamente.

Questa non è la storia di un negozio. Questo è un problema sistemico con WooCommerce, che vedo in quasi tutti i progetti in cui non è stato ancora installato un normale filtro AJAX. Il meccanismo di filtro standard in WooCommerce è estremamente semplice: selezioni un parametro, il browser invia una richiesta GET con i nuovi parametri, il server elabora l'intera richiesta - dall'analisi dell'URL al rendering dell'intera pagina HTML - e restituisce il risultato. Per ogni clic sul filtro, avviene un ciclo completo: interrogare il database, assemblare il modello, inviare nuovamente tutto l'HTML al browser. E se hai diecimila prodotti, ciascuno con una dozzina di attributi e, inoltre, il server non è tra i migliori, ciascuno di questi riavvii può richiedere due o tre secondi. Moltiplicalo per i cinque o sei clic necessari per restringere la selezione ai prodotti desiderati e otterrai dai quindici ai venti secondi di puro tempo di attesa. Durante questo periodo, l'acquirente ha il tempo di cambiare idea, distrarsi o semplicemente andarsene.

Ho studiato questo problema per molto tempo, non come sviluppatore, ma come operatore di marketing. Perché per un marketer il filtraggio del catalogo non è un dettaglio tecnico, ma un elemento critico del funnel di vendita. Tra “andato al catalogo” e “aggiunto al carrello” c'è un filtro e, se funziona male, l'imbuto scorre qui. Secondo il Baymard Institute, il 42% dei grandi rivenditori online perde clienti a causa di filtri scomodi. Non a causa dei prezzi, non a causa dell'assortimento, perché una persona non riesce a trovare rapidamente ciò di cui ha bisogno. E quando ho iniziato a progettare il modulo di filtraggio per il nostro plugin, mi sono posto un compito: assicurarmi che l'acquirente non si accorgesse nemmeno che il filtro funziona. Nessun riavvio, nessun ritardo, nessuna sensazione di "sto aspettando che il computer pensi".

Ecco cosa ne è venuto fuori e perché dietro le quinte si è rivelato molto più complicato di quanto sembri a prima vista.

Perché il filtraggio standard di WooCommerce è una seccatura

Per capire perché un filtro AJAX non è solo una caratteristica interessante, ma una necessità, diamo un'occhiata a cosa succede quando un acquirente filtra i prodotti in WooCommerce standard. Supponiamo che tu abbia un negozio di oli industriali. Un acquirente entra in un catalogo, vede ottocento prodotti e vuole scegliere un olio motore 5W-30 di una determinata marca. Fa clic sul widget "Filtra per attributo", seleziona "Oli motore" e la pagina viene completamente ricaricata. Il browser invia una richiesta GET del tipo “?filter_tip-masla=motornoe”, il server la elabora, WooCommerce lancia WP_Query con meta query, MySQL scorre wp_postmeta - una tabella che può pesare fino a un gigabyte su un progetto con sedicimila prodotti - e restituisce il risultato in un paio di secondi. L'acquirente vede, diciamo, trecento prodotti. Ora vuole selezionare la viscosità. Un altro clic: un altro riavvio, altri due secondi. Quindi il marchio: il terzo riavvio. Ed ecco la cosa più fastidiosa: su alcuni temi e configurazioni, i filtri precedenti vengono reimpostati al successivo riavvio. L'acquirente ricomincia da capo.

L'ho visto decine di volte su progetti reali. Il proprietario del negozio investe denaro in pubblicità, paga per ogni clic in Yandex.Direct, porta una persona sul sito e la perde nella fase di filtraggio. E non perché non ci sia il prodotto, ma perché il prodotto c'è, ma è impossibile trovarlo normalmente. È come un negozio in cui tutte le merci sono ammucchiate in una pila e il venditore risponde a ogni domanda con un ritardo di tre secondi. Te ne andresti? Me ne sarei andato.

C'è un altro problema di cui non si parla molto: il filtro predefinito di WooCommerce è pessimo per la SEO. Ogni opzione di filtro genera un URL univoco con parametri GET e se un bot di ricerca inizia a indicizzare tutte queste combinazioni (e possono esserci combinazioni da dieci alla decima potenza con dieci attributi con dieci valori ciascuno) ti ritroverai con un indice gonfiato, contenuti duplicati e un budget di scansione diluito. Per un piccolo negozio con centinaia di prodotti questo non è fondamentale, ma per un catalogo serio è un vero problema.

In realtà, questo è il motivo per cui tutti i principali mercati - Ozon, Wildberries, Yandex.Market - sono passati da tempo al filtraggio AJAX. Quando un cliente seleziona un'opzione, il browser invia una richiesta asincrona al server, riceve solo i dati (nessuna intestazione, piè di pagina o barra laterale) e aggiorna solo la parte della pagina in cui vengono mostrati i prodotti. Nessuno sfarfallio dello schermo, nessun riavvio, nessuna perdita di scorrimento. Fai clic e i prodotti cambiano immediatamente. Questo è uno standard del settore e se il tuo negozio non lo fornisce, stai già perdendo a livello di esperienza utente.

Ma, ed è qui che le cose si fanno interessanti, il semplice passaggio del filtraggio ad AJAX non è sufficiente. Se la stessa WP_Query con wp_postmeta join rimane sotto il cofano, rimuoverai semplicemente la ricarica, ma la velocità di risposta rimarrà la stessa: la stessa da uno e mezzo a due secondi per ogni richiesta. L'acquirente non vedrà la pagina ricaricarsi, ma vedrà uno spinner al posto dell'elenco dei prodotti. E la differenza tra “la pagina si ricarica” e “i prodotti non vengono visualizzati” in termini di pazienza del cliente è circa zero. Pertanto, durante la progettazione del nostro modulo di filtraggio, ho immediatamente adottato un approccio radicalmente diverso per archiviare e recuperare i dati.

FilterIndex: quando cinquanta millisecondi non è marketing, ma realtà

L'idea principale che distingue il nostro filtro AJAX dalla maggior parte delle soluzioni sul mercato è l'indice precalcolato. Si chiama FilterIndex e funziona secondo il principio utilizzato dai motori di ricerca: invece di passare in rassegna tutti i prodotti e i loro attributi ogni volta che un utente lo richiede, costruiamo in anticipo una tabella ottimizzata che ha già tutti i collegamenti necessari “prodotto - attributo - valore - prezzo - disponibilità”.

Come funziona tecnicamente? Quando un amministratore configura i filtri, ad esempio aggiungendo filtri per marca, viscosità e tipo di olio, il sistema avvia un'attività in background tramite lo strumento di pianificazione delle azioni. Questa attività esamina tutti i prodotti nel catalogo e per ciascun prodotto registra una serie di righe in una tabella wpaic_filter_index separata: prodotto tale e tale, l'attributo “Brand”, il valore “Shell”; prodotto tale e tale, attributo “Viscosità”, valore “5W-30”; e così via. Inoltre, a ciascuna riga vengono aggiunti il ​​prezzo del prodotto, lo stato di disponibilità, la categoria e altre informazioni che potrebbero essere necessarie per il filtraggio. In sostanza, prendiamo i dati sparsi su dozzine di tabelle WordPress - wp_posts, wp_postmeta, wp_terms, wp_term_relationships, wp_wc_product_meta_lookup - e li inseriamo in un'unica tabella piatta con gli indici corretti.

Risultato? Una query che, nel filtraggio standard di WooCommerce, richiedeva da quattro a cinque operazioni JOIN sulla tabella wp_postmeta di dimensioni gigabyte ed era stata completata in un secondo e mezzo o due, viene ora completata in trenta-cinquanta millisecondi. Questa non è una cifra teorica: si tratta di misurazioni reali su un catalogo di sedicimila prodotti con novantanove attributi. La differenza di velocità è da trenta a quaranta volte. E l'acquirente sente letteralmente questa differenza: fa clic sul filtro e la merce appare immediatamente, senza alcuna attesa.

Ma un indice precalcolato presenta una domanda ovvia: cosa succede se i dati cambiano? Aggiunto un nuovo prodotto, modificato il prezzo, aggiornato il saldo da 1C? È qui che entra in gioco il sistema di aggancio. Quando modifichi qualsiasi prodotto - tramite la modifica standard in WordPress, tramite l'API REST, tramite l'importazione da 1C - viene attivato un hook che aggiorna le righe corrispondenti nell'indice. Inoltre non aggiorna l'intero indice, ma solo le righe di un prodotto specifico. Una ricostruzione completa dell'indice viene avviata solo su comando dell'amministratore o in base a una pianificazione, ad esempio una volta al giorno per garantire la coerenza. Nella modalità normale, l'indice viene aggiornato in modo incrementale, quasi in tempo reale.

Ricordo che un cliente, proprietario di un negozio con ventimila prodotti, mi chiese: "Sei sicuro che l'indice non perderà la sincronizzazione?" Questa è una domanda giusta: me lo sono posto io stesso in fase di progettazione. E la risposta è: sì, in determinate circostanze, ad esempio quando si modifica direttamente il database oltre WordPress, l'indice può ritardare. Ecco perché nel pannello di controllo è presente un pulsante per ricostruire manualmente l'indice e impostare la ricostruzione automatica tramite cron. Ma in modalità normale, quando i prodotti vengono modificati tramite WooCommerce o tramite il nostro connettore 1C, la desincronizzazione è esclusa.

Un altro punto che ritengo importante: l'indice memorizza non solo i valori degli attributi, ma anche il numero di prodotti per ciascun valore. Questo è ciò che viene chiamato "contatori sfaccettati": accanto a ciascun valore del filtro viene mostrato il numero di prodotti che corrispondono ad esso. Nel filtro WooCommerce standard, questi contatori non vengono visualizzati o richiedono una query aggiuntiva al database. Nel nostro caso i contatori vengono calcolati direttamente al momento della richiesta, praticamente senza costi aggiuntivi, perché l'indice contiene già tutte le informazioni necessarie. E quando l'acquirente seleziona "Shell" nel filtro per marca, vede immediatamente che ci sono dodici oli motore Shell con una viscosità di 5W-30 e otto con una viscosità di 10W-40. Ciò elimina la situazione del "parametro selezionato - ottenuto zero risultati", che irrita selvaggiamente gli acquirenti.

A proposito di zero risultati. Uno dei problemi con il filtraggio standard sono le cosiddette “combinazioni morte”. L'acquirente seleziona la marca, poi il tipo di olio, poi la viscosità - e riceve una pagina bianca, perché non esistono prodotti con questa combinazione di parametri. Nel nostro filtro, le combinazioni morte vengono bloccate automaticamente: dopo ogni selezione di parametri, i contatori per tutti gli altri valori vengono ricalcolati e i valori con zero prodotti vengono nascosti o mostrati inattivi. L'acquirente non può fisicamente arrivare ad una selezione vuota: il sistema lo guida mostrando solo le opzioni pertinenti.

Filtri visivi e campioni: quando l'interfaccia vende

Onestamente la velocità di filtrazione è fondamentale, ma non è ciò che l'acquirente nota per primo. La prima cosa che attira la tua attenzione è l'aspetto dei filtri. E qui con WooCommerce standard tutto è completamente triste: elenchi a discesa con valori di testo. "Rosso", "Blu", "Verde" - scritto nel testo. Ora immagina di vendere vernici, tessuti, mobili o vestiti. L'acquirente deve vedere il colore, non leggerne il nome. Vuole fare clic sul cerchio rosso e vedere tutti i prodotti rossi. Oppure fai clic sul logo Bosch e vedi tutto di Bosch, senza ricordare come si scrive il nome: Bosch, BOSCH o Bosch.

Abbiamo implementato tre tipi di filtri visivi. Il primo sono i campioni di colore. Ad ogni valore dell'attributo “Colore” può essere assegnato un codice colore HEX e nel filtro, invece di un elenco di testo, l'acquirente vede una serie di cerchi colorati. Ho cliccato sul rosso e ho ricevuto la merce rossa. Inoltre, i cerchi non sono solo statici: il colore selezionato è evidenziato da una cornice e, quando ci si passa sopra, viene mostrato un suggerimento con il nome. Il secondo tipo sono i pulsanti. Funziona bene per le taglie (S, M, L, XL, XXL) o per taglie discrete (500 ml, 1 L, 5 L, 20 L). Invece di un elenco a discesa, c'è una serie di pulsanti ordinati che possono essere cliccati e combinati. Il terzo tipo sono i loghi. Per l'attributo Brand, ogni valore può essere caricato con un'immagine del logo e l'acquirente sceglie il brand in base all'immagine visiva anziché al testo. Ciò è particolarmente importante per i negozi con marchi internazionali, dove il cliente può avere una memoria visiva migliore per il logo che per l'ortografia del nome.

E qui voglio concentrarmi specificamente sui campioni non nel filtro, ma nella scheda prodotto. Perché è un compito correlato ma separato. Quando l'acquirente trova un prodotto attraverso il filtro e accede alla scheda, deve selezionare un'opzione specifica. Colore, dimensione, volume: in WooCommerce tutto questo viene implementato attraverso prodotti variabili ed elenchi a discesa standard. E questi elenchi sono una delle maggiori opportunità mancate da WooCommerce in termini di conversione.

Il nostro modulo campioni sostituisce gli elenchi a discesa con elementi visivi direttamente sulla scheda prodotto. Per il colore: cerchi con colori reali. Per dimensioni: pulsanti. Per il marchio: miniature del logo. Ma la cosa più importante è che quando selezioni un'opzione, l'immagine del prodotto cambia automaticamente. L'acquirente fa clic sul cerchio blu e la versione blu appare sulla foto principale del prodotto. Se fa clic sul rosso, vede il rosso. Questa è una piccola cosa dal punto di vista tecnico, ma dal punto di vista del marketing è una leva enorme. Un acquirente che vede un prodotto nel colore che desidera è molto più vicino all’acquisto rispetto a qualcuno che vede solo il testo “Blu” e deve immaginare come appare.

Ho condotto una ricerca informale su tre progetti in cui abbiamo implementato i campioni. Prima dell'implementazione, la conversione dalla scheda prodotto al carrello era in media dell'8%. Dopo l'introduzione dei campioni visivi con cambio automatico dell'immagine: dall'11 al 12%. Un aumento dal trenta al cinquanta per cento. È chiaro che questo non è un puro test A/B e c’erano altri fattori, ma la tendenza è chiara. Le persone comprano quello che vedono, non quello che leggono.

Un'altra sfumatura che mi sembra importante: i campioni e i filtri visivi dovrebbero essere un unico sistema. Se nel filtro del catalogo “rosso” è un cerchio con il colore #FF0000, e sulla scheda prodotto “rosso” è il testo nell'elenco a discesa, l'acquirente si sente disconnesso. Nel nostro plugin, le impostazioni dei campioni sono globali: una volta assegni il tipo di visualizzazione "Campione colore" all'attributo "Colore" e imposti i codici HEX per ciascun valore - e poi questi campioni vengono utilizzati ovunque: nel filtro, sulla scheda prodotto, nei widget, nei risultati di ricerca. Un'unica ambientazione: un unico linguaggio visivo in tutto il negozio.

Ma parliamo di cosa succede sotto l'elenco dei prodotti: l'impaginazione. Perché anche un filtro ideale non aiuta se dopo il filtraggio rimangono duecento prodotti e l'acquirente deve cambiare pagina per vederli tutti.

“Mostra altro” invece dell'impaginazione: pulsante piccolo, grande effetto

Sai cosa mi ha sempre sorpreso di WooCommerce? L'impaginazione standard - "1, 2, 3, ... 15, Successivo" - è stata inventata in un'epoca in cui ogni pagina era completamente caricata e l'utente era seduto al desktop con il mouse. Oggi, oltre il sessanta per cento dei clienti proviene da dispositivi mobili e per loro cambiare pagina è una seccatura. Piccoli collegamenti che devi toccare con il dito, inoltre ogni transizione significa un ricaricamento della pagina, oltre alla perdita della posizione di scorrimento. Ozon e Wildberries lo hanno sostituito molto tempo fa con un pulsante "Mostra altro" e un caricamento infinito, e non è una coincidenza: è semplicemente più conveniente.

Nel nostro plugin abbiamo implementato il modulo Carica altro, che sostituisce l'impaginazione standard di WooCommerce con un pulsante “Mostra altro”. L'acquirente ha fatto scorrere fino alla fine della porzione corrente di merce, ha premuto un pulsante grande e la porzione successiva viene aggiunta senza problemi a quelle già caricate. Nessuna ricarica, nessuna perdita di scorrimento, nessuna necessità di puntare a piccoli numeri di paginazione. E funziona benissimo insieme al filtro AJAX: l'acquirente ha selezionato i parametri, ha visto i primi venti prodotti, ha fatto clic su "Mostra altro" e ne ha visti altri venti. Tutto su una pagina, tutto senza sfarfallio.

Tecnicamente funziona così: quando si fa clic su un pulsante, JavaScript invia una richiesta AJAX con le opzioni di filtro correnti e il numero di "pagina" successivo. Il server restituisce il markup HTML per il successivo lotto di prodotti e lo script lo inserisce nel DOM dopo l'ultimo prodotto. L'URL nella barra degli indirizzi non cambia, lo scorrimento viene mantenuto e i filtri selezionati rimangono al loro posto. Per l'acquirente, sembra che gli articoli semplicemente “appariscano” in fondo all'elenco.

Ma c'è una sottigliezza di cui voglio parlare, perché molti sviluppatori si imbattono in essa. Quando utilizzi il caricamento infinito su WooCommerce, devi gestire correttamente la situazione quando esaurisci i prodotti. Se l'acquirente ha raggiunto l'ultima porzione, il pulsante "Mostra altro" dovrebbe scomparire ed è consigliabile mostrare un messaggio discreto "Tutti i prodotti sono caricati". Sembra banale, ma ho visto implementazioni in cui il pulsante continuava a essere visualizzato e restituiva una risposta vuota quando veniva cliccato, lasciando il cliente confuso. Oppure, al contrario, il pulsante è scomparso, ma quando si cambiano i filtri non è ricomparso e l'acquirente ha visto solo i primi venti prodotti su duecento. Nel nostro modulo, il pulsante è controllato dallo stato: sa quanti prodotti sono rimasti e lo mostra all'acquirente - "Mostra altro (45 rimasti)". Quando si cambiano i filtri, il contatore viene azzerato e ricalcolato automaticamente.

C'è un'altra cosa che ritengo fondamentale per gli utenti di dispositivi mobili: la dimensione e il posizionamento dei pulsanti. I collegamenti di impaginazione standard di WooCommerce sono piccoli numeri difficili da raggiungere con il dito su un telefono. Il nostro pulsante Mostra altro è un pulsante a larghezza intera con testo di grandi dimensioni da non perdere. È stilizzato per adattarsi al design complessivo del negozio tramite variabili CSS e l'amministratore può personalizzarne il colore, gli arrotondamenti e le rientranze, ma per impostazione predefinita ha già un bell'aspetto e, soprattutto, è facile da cliccare da qualsiasi dispositivo.

E questo fa sorgere una domanda che mi viene posta regolarmente: che dire della SEO? Se tutti i prodotti vengono caricati tramite AJAX, come faranno i robot di ricerca a visualizzare il catalogo completo? Questa è una domanda davvero importante e la risposta sta nell’architettura. Il nostro modulo Carica altro non sostituisce l'impaginazione lato server, ma la integra. Il codice HTML della pagina contiene collegamenti standard alle seguenti pagine: rel="next" e rel="prev". Un bot di ricerca che non esegue JavaScript segue questi collegamenti e indicizza normalmente tutte le pagine della directory. E l'acquirente, il cui JavaScript è in esecuzione, vede un pulsante "Mostra altro" invece dei collegamenti di impaginazione e carica i prodotti tramite AJAX. In questo modo, otteniamo il meglio da entrambi i mondi: una comoda UX per l'acquirente e un'indicizzazione completa per il bot di ricerca.

A proposito, riguardo alla combinazione di filtro e caricamento. Quando l'acquirente modifica i parametri del filtro, il modulo Carica altro viene automaticamente azzerato: viene mostrata la prima porzione di prodotti secondo i nuovi criteri, il contatore viene azzerato e il pulsante aggiorna il numero di prodotti rimanenti. Ciò sembra ovvio, ma in pratica l'integrazione dei due moduli AJAX, filtraggio e caricamento, richiede un attento coordinamento. Devono utilizzare uno stato comune e abbiamo dedicato molto tempo a rendere questa connessione perfetta.

Ora parliamo di come funziona tutto questo sui dispositivi mobili. Perché il filtraggio mobile è una storia diversa, con i suoi problemi e soluzioni.

Su desktop, i filtri si trovano solitamente nella barra laterale a sinistra dell'elenco dei prodotti. Lo schermo è grande, c'è abbastanza spazio, il pannello dei filtri è sempre visibile: fai clic e seleziona. Non esiste un lusso del genere sui dispositivi mobili. La barra laterale semplicemente non si adatta ai prodotti su uno schermo largo trecentonovanta pixel. E qui ci sono due soluzioni tipiche, entrambe infruttuose. Il primo è mostrare i filtri sopra i prodotti, un lungo elenco. L'acquirente vede una schermata piena di filtri e deve scorrerli per vedere almeno un prodotto. Il secondo è nascondere i filtri in un elemento a fisarmonica standard o in un blocco a discesa. L'acquirente fa clic: i filtri si aprono, ma allo stesso tempo spostano i prodotti verso il basso e tutto salta sullo schermo.

Abbiamo preso la terza strada: un pannello filtro pieghevole sotto forma di sovrapposizione. Su un dispositivo mobile, l'acquirente vede un pulsante "Filtri", solitamente nella parte superiore del catalogo, accanto all'ordinamento e alla quantità dei prodotti. Quando fai clic su questo pulsante, il pannello del filtro scorre lateralmente, come un menu su molti siti mobili, e occupa circa l'ottanta per cento dello schermo. L'acquirente seleziona i parametri necessari, fa clic su "Mostra": il pannello si chiude e i prodotti vengono aggiornati. È importante che in questo caso i prodotti vengano aggiornati in tempo reale, proprio mentre il pannello è aperto: l'acquirente vede il contatore “Trovato: 42 prodotti” sul pulsante “Mostra”, e questo contatore viene aggiornato ogni volta che si cambia il filtro. Ciò fornisce all'acquirente un feedback immediato sul fatto che stia restringendo troppo la sua selezione o meno.

Un altro trucco che utilizziamo sui dispositivi mobili sono i "chip" dei filtri selezionati. Dopo aver chiuso il pannello dei filtri, sopra l'elenco dei prodotti compaiono dei "chip" compatti: piccole barre con i valori selezionati: "Shell", "5W-30", "Disponibile". Ogni chip può essere rimosso con un solo tocco rimuovendo il filtro corrispondente. Questo è molto più comodo che aprire nuovamente il pannello per rimuovere un parametro. E questo fa risparmiare tempo all'acquirente, e il tempo sui dispositivi mobili è doppiamente prezioso, perché le sessioni mobili sono generalmente più brevi di quelle desktop.

Una cosa interessante che ho notato è che sui dispositivi mobili, i consumatori utilizzano in media meno filtri contemporaneamente, di solito uno o due, tre al massimo. Ma li usano più spesso e più velocemente. Pertanto, la velocità di risposta è fondamentale: cinquanta millisecondi di risposta dell'indice giocano un ruolo ancora maggiore qui che sul desktop. Se un cliente mobile fa clic su un filtro e attende più di un secondo, molto probabilmente deciderà che qualcosa non è rotto e ricomincerà a fare clic. E fare doppio clic su un filtro di solito significa selezionarlo e annullarlo immediatamente - e l'acquirente resta al punto di partenza, solo infastidito.

Parliamo ora di una situazione che molti proprietari di negozi si trovano ad affrontare: la migrazione da una soluzione esistente. Poiché la maggior parte dei negozi WooCommerce non sono costruiti da zero, hanno già una sorta di filtro, solitamente YITH Ajax Product Filter o WooCommerce Product Filter di un altro sviluppatore.

Migrazione da YITH e altri filtri: come non perdere dati e nervi

Ho riscontrato ripetutamente una situazione in cui un negozio utilizza YITH Ajax Product Filter da anni e il proprietario desidera passare a qualcos'altro. Ci sono diversi motivi: YITH ha smesso di aggiornarsi, ha iniziato a entrare in conflitto con il tema, lavora troppo lentamente su un catalogo di grandi dimensioni o semplicemente si è stancato di pagare separatamente per un filtro, separatamente per i campioni, separatamente per l'impaginazione. E la prima domanda che il proprietario pone: "Le impostazioni del filtro verranno salvate?"

Siamo onesti: non esiste una migrazione automatica al 100% delle impostazioni tra diversi plugin di filtraggio. Architetture troppo diverse, modi troppo diversi di archiviare la configurazione. YITH memorizza i suoi preset nelle opzioni di WordPress e postmeta, altri plugin utilizzano tabelle personalizzate e altri utilizzano file JSON. Ma non è nemmeno necessario eseguire la migrazione manualmente: il nostro modulo dispone di uno strumento di migrazione che analizza i plug-in di filtro installati e offre la mappatura delle impostazioni.

Come funziona in pratica? Quando attivi per la prima volta il nostro modulo di filtraggio, il sistema controlla se YITH Ajax Product Filter (o YITH WooCommerce Ajax Product Filter Premium) è installato. Se sì, nell'interfaccia delle impostazioni viene visualizzata la scheda "Migrazione" con informazioni sui preset YITH trovati, sui filtri configurati e sui loro tipi. L'amministratore vede quali attributi sono stati configurati in YITH, quali tipi di visualizzazione sono stati utilizzati (casella di controllo, elenco a discesa, campione di colore, cursore del prezzo) e può avviare la migrazione con un pulsante. Il sistema crea filtri simili nel nostro modulo, mappa i tipi di visualizzazione (YITH “colore” → il nostro “campione”, YITH “etichetta” → il nostro “pulsante” e così via) e crea un indice.

Ma voglio avvisarti: dopo la migrazione, dovrai assolutamente controllare manualmente il risultato. Non perché la migrazione sia inaffidabile, ma perché è un ottimo motivo per riconsiderare la struttura dei filtri. Accade spesso che i filtri in YITH siano stati configurati due o tre anni fa, da allora l'intervallo è cambiato, sono comparsi nuovi attributi, alcuni valori sono obsoleti e la migrazione copia ciecamente tutto così com'è, comprese le impostazioni che non sono più rilevanti. Incoraggio i clienti a utilizzare la migrazione come punto di partenza, quindi a esaminare ciascun filtro e a chiedersi: "Il cliente ne ha davvero bisogno?"

A proposito, una delle domande più comuni durante la migrazione è "cosa accadrà all'URL?" YITH ha il proprio formato per filtrare gli URL (solitamente con hash o parametri personalizzati), mentre il nostro modulo ha il proprio. Se hai utilizzato attivamente il filtro degli URL nella pubblicità o nei link interni, questi URL non funzioneranno più durante la migrazione. In questi casi, ti consiglio di impostare i reindirizzamenti tramite il nostro modulo di reindirizzamento SEO, che supporta i modelli regex. Un paio di regole e i vecchi collegamenti di filtraggio verranno reindirizzati correttamente a quelli nuovi.

Un altro consiglio pratico tratto dall'esperienza di migrazione: non disattivare il vecchio filtro prima di aver configurato completamente quello nuovo. Sembra ovvio, ma ho visto persone disattivare YITH, attivare il nostro modulo e iniziare a configurare, mentre il negozio live funziona senza alcun filtro. L'operazione potrebbe richiedere un'ora o due e durante questo periodo perderai alcune vendite. È meglio impostare un nuovo filtro in parallelo (non entrerà in conflitto finché il suo shortcode non verrà inserito nella pagina), assicurarsi che tutto funzioni e cambiare allo stesso tempo.

Voglio sottolineare ancora una volta un'idea su cui torno costantemente: il filtraggio del catalogo non è una caratteristica tecnica, ma un elemento di vendita. Ogni negozio che è migrato dal filtro standard o dal plug-in legacy di WooCommerce al nostro filtro pre-indice AJAX ha riscontrato un miglioramento nelle metriche comportamentali. Riduzione della frequenza di rimbalzo sulla pagina del catalogo, aumento della profondità di navigazione, aumento del tempo sul sito. E, soprattutto, un aumento delle conversioni dalla visualizzazione del catalogo all'aggiunta al carrello. Perché quando un cliente trova rapidamente ciò di cui ha bisogno, è più probabile che lo acquisti.

Parliamo ora di come tutto questo confluisce in un unico sistema e perché l'approccio “un plugin per tutto” è qui di fondamentale importanza.

Sapete qual è secondo me il problema principale con l'approccio "filtro da uno sviluppatore, campioni da un altro, impaginazione da un terzo"? Questi non sono conflitti di plugin, anche se possono verificarsi. Questo è il divario nell’esperienza dell’utente. L'acquirente seleziona un colore nel filtro e vede un bellissimo cerchio. Va alla scheda prodotto e c'è un elenco a discesa di testo. Fa clic su "Mostra altro" e i filtri vengono reimpostati, perché il plug-in di impaginazione non riconosce il plug-in di filtro. Ognuno di questi plugin funziona benissimo da solo, ma insieme creano la sensazione di Frankenstein: cuciti insieme da pezzi diversi, irregolari, con cuciture sporgenti.

Quando il filtro, i campioni, il caricamento del prodotto e l'indicizzazione fanno parte dello stesso modulo, condividono uno stato comune. Il codice JavaScript di filtraggio riconosce il modulo di caricamento e interagisce correttamente con esso. Le impostazioni dei campioni vengono applicate allo stesso modo nel filtro e nella scheda prodotto. L'indice di filtraggio tiene conto dei dati aggiornati tramite altri moduli plug-in: sincronizzazione 1C, modifica in blocco, importazione. Questa non è solo comodità per lo sviluppatore: è un livello di esperienza utente fondamentalmente diverso per l'acquirente.

Uso spesso l'analogia dell'auto. Puoi assemblare un'auto con parti di diversi produttori: il motore di uno, le sospensioni di un altro, l'elettronica di un terzo. Tecnicamente questo è possibile, e ogni dettaglio può essere di ottima qualità. Ma un'auto progettata nel suo insieme si guiderà meglio, perché gli ingegneri hanno ottimizzato l'interazione di tutti i componenti, anziché di ciascun componente singolarmente. Con un negozio online è lo stesso: l’acquirente non ha bisogno del miglior filtro del mondo, dei migliori campioni e della migliore impaginazione. Ha bisogno di un catalogo che funzioni nel suo insieme: in modo rapido, bello e prevedibile.

E qui voglio tornare all'argomento da cui ho iniziato: la velocità. Perché l'indice precalcolato non è l'unica ottimizzazione che abbiamo apportato. Ci sono molte altre cose che influenzano la velocità di filtraggio percepita. Innanzitutto, un aggiornamento ottimista: quando un acquirente fa clic su un filtro, la griglia del prodotto riceve immediatamente un effetto di “caricamento” CSS – un leggero attenuamento o sfocatura – e contemporaneamente viene inviata una richiesta AJAX. Quando arriva la risposta (dopo trenta-cinquanta millisecondi - te lo ricordo), i prodotti vengono aggiornati e l'effetto di caricamento viene rimosso. Per l'acquirente, questa sembra una reazione immediata: ha cliccato - la griglia ha "lampeggiato" - i nuovi beni sono a posto. Inoltre, ha “lampeggiato” così rapidamente che l'acquirente lo percepisce non come un'aspettativa, ma come una conferma visiva dell'azione.

In secondo luogo, la memorizzazione nella cache lato client. Se l'acquirente ha selezionato "Shell, 5W-30" e ha ricevuto dodici prodotti, quindi ha rimosso "5W-30" e ha esaminato tutti gli oli Shell, quindi ha inserito nuovamente "5W-30", la seconda volta la stessa richiesta non verrà inviata al server, ma verrà inviata dalla cache del browser. Ciò consente di risparmiare traffico e velocizzare la navigazione durante il filtraggio di "ritorno" quando l'acquirente prova diverse combinazioni avanti e indietro.

In terzo luogo - e questa è forse l'ottimizzazione meno evidente - inviamo dal server non l'HTML completo delle schede prodotto, ma il minimo richiesto. Un modello standard di scheda prodotto WooCommerce in un catalogo può contenere dozzine di hook, ognuno dei quali aggiunge HTML: un pulsante di confronto da un plugin, un'icona dei preferiti da un altro, una valutazione da un terzo. Su una pagina con venti prodotti, potrebbero essere due o trecento kilobyte di HTML. Abbiamo ottimizzato il rendering del server in modo che la risposta AJAX contenga solo il minimo richiesto e che gli elementi aggiuntivi (confronta pulsanti, campioni, icone) siano stati inizializzati sul client dopo aver inserito le carte nel DOM. Il risultato è che la risposta del server è tre o quattro volte più semplice e con una connessione Internet mobile lenta questa differenza è notevole.

Infine, l'ultima cosa di cui voglio parlare è il filtraggio dell'analisi. Abbiamo integrato una raccolta di statistiche nel modulo di filtraggio: quali filtri vengono utilizzati più spesso, quali combinazioni vengono selezionate, quali valori non vengono mai cliccati, quante volte gli acquirenti arrivano a un risultato pari a zero. Questi dati sono disponibili nel pannello di controllo e aiutano il proprietario del negozio a ottimizzare il catalogo. Se vedi che il filtro "Paese di produzione" viene utilizzato nello zero virgola due per cento del filtraggio, potrebbe valere la pena rimuoverlo per non ingombrare il pannello. Se vedi che i clienti spesso filtrano per marca e immediatamente per viscosità, ha senso mettere prima questi due filtri. Se vedi che sui dispositivi mobili i clienti utilizzano solo il dispositivo di scorrimento del prezzo e il marchio, puoi nascondere i filtri rimanenti per la versione mobile, mostrandoli solo con un tocco separato "Tutti i filtri".

Il punto è questo: il filtraggio delle directory non è "impostalo e dimenticalo". Questo è uno strumento vivente che deve essere personalizzato per adattarsi alla tua gamma di prodotti e ai tuoi clienti. E più dati raccogli sul filtraggio degli acquirenti, più preciso sarà il livello di personalizzazione. Cerchiamo di dare al proprietario del negozio non solo un filtro, ma uno strumento per capire come i clienti cercano i prodotti.

Quando ho iniziato a progettare questo modulo, mi sono posto un obiettivo semplice: fare in modo che un acquirente in un negozio online su WooCommerce potesse trovare un prodotto in modo rapido e conveniente come su Ozon o Wildberries. Non “quasi lo stesso” e non “con alcune restrizioni”, ma proprio lo stesso. Filtraggio istantaneo senza ricaricare, campioni visivi invece di elenchi di testo, caricamento infinito invece di pagine numerate, comodo pannello di filtro mobile. E in modo che tutto ciò funzioni rapidamente, non in secondi, ma in decine di millisecondi.

Ha funzionato? Penso di sì, ma non perché abbiamo scritto un codice brillante, ma perché abbiamo impostato correttamente le nostre priorità. Abbiamo iniziato non con una bella interfaccia, ma con le prestazioni, con un indice precalcolato. Perché un bel filtro che rallenta è pur sempre un cattivo filtro. E poi hanno creato un'interfaccia comoda sopra il nucleo veloce: campioni, chip, un overlay mobile, un pulsante di download. E lo hanno collegato in un unico sistema, dove ogni elemento conosce tutti gli altri.

Se stai attualmente guardando il tuo negozio WooCommerce e vedi elenchi a discesa standard nei filtri, impaginazione numerata nella parte inferiore del catalogo e ricaricamenti di pagina ad ogni clic, pensa a quanti clienti stai perdendo ogni giorno. Non per i prezzi, non per l'assortimento, ma perché è semplicemente scomodo per loro cercare. Il modulo di filtraggio AJAX in COS WP Woo risolve questo problema in modo completo: filtraggio, visualizzazione, caricamento, adattamento mobile, indicizzazione e analisi - tutto in un unico plugin, senza la necessità di acquistare e configurare cinque diverse soluzioni. Provalo e osserva i tuoi parametri tra una settimana. Sono sicuro che i numeri ti sorprenderanno.

E ora: una conversazione onesta sulle insidie. Perché non mi piacciono gli articoli in cui tutto è perfetto e non c'è un solo svantaggio. Qualsiasi tecnologia ha i suoi limiti e il filtraggio AJAX non fa eccezione.

Il primo problema è la memorizzazione nella cache a livello di server. Se disponi di cache LiteSpeed, Varnish, nginx FastCGI o qualsiasi altra cache del server, le richieste di filtro AJAX dovrebbero ignorarla. Sembra semplice, ma in pratica richiede una configurazione adeguata. Le richieste AJAX vanno allo stesso wp-admin/admin-ajax.php o a un endpoint REST personalizzato e la cache del server può iniziare a memorizzare nella cache i risultati del filtraggio. Di conseguenza, l'acquirente seleziona "Shell", ma vede i risultati per Lukoil, perché la cache restituisce la risposta dalla richiesta precedente di un altro acquirente. Risolviamo questo problema in due modi: in primo luogo, utilizziamo le richieste POST per il filtraggio (le cache del server di solito non memorizzano nella cache POST) e in secondo luogo, aggiungiamo intestazioni no-cache alle risposte. Ma se imposti tu stesso la memorizzazione nella cache del server, tienilo a mente, perché un filtro AJAX memorizzato nella cache non è solo un bug, è un bug che mostra all'acquirente i risultati di qualcun altro.

La seconda pietra è l'accessibilità. Quando tutto il contenuto viene aggiornato tramite JavaScript senza ricaricare la pagina, gli screen reader e altre tecnologie assistive potrebbero non notare la modifica. Aggiungiamo gli attributi ARIA all'area del prodotto (aria-live="polite") e annunciamo modifiche per le tecnologie assistive con ogni aggiornamento. Ciò non è evidente per il consumatore medio, ma è fondamentale per le persone che utilizzano gli screen reader. E, tra l’altro, ciò influisce sul punteggio di accessibilità in Lighthouse, che sta diventando sempre più un fattore di ranking.

Il terzo punto sono i cataloghi pesanti con campi personalizzati. Se i tuoi prodotti non utilizzano attributi WooCommerce standard, ma campi personalizzati (ACF, il nostro modulo CF o semplicemente wp_postmeta), l'indicizzazione di questi campi richiede una configurazione aggiuntiva. Gli attributi standard di WooCommerce (pa_color, pa_size e così via) vengono indicizzati automaticamente, ma i meta campi personalizzati devono essere specificati esplicitamente nelle impostazioni del filtro: quale campo indicizzare e come visualizzarlo. Abbiamo reso l'interfaccia il più semplice possibile: seleziona la meta chiave dall'elenco a discesa, specifica il tipo di visualizzazione (casella di controllo, cursore, campione) e il sistema include questo campo nell'indice durante la successiva ricostruzione. Ma devi saperlo in anticipo per non sorprenderti del fatto che il nuovo filtro "Punto di scorrimento" non mostra alcun valore, perché ti sei dimenticato di includerlo nell'indice.

E l'ultima cosa sono le prestazioni con un numero molto elevato di filtri simultanei. Il nostro indice funziona benissimo con da cinque a dieci filtri attivi contemporaneamente, ma se hai un catalogo con trenta attributi e l'acquirente ha attivato venti filtri contemporaneamente, il tempo di risposta può aumentare da cento a centocinquanta millisecondi. Questo è ancora molto veloce rispetto a WooCommerce standard (dove una richiesta del genere richiederebbe dai cinque ai dieci secondi), ma notevolmente più lento di cinquanta millisecondi per un semplice filtraggio. In pratica, tali situazioni si verificano raramente - gli acquirenti di solito utilizzano da tre a cinque filtri alla volta - ma se si dispone di un catalogo specifico con molte caratteristiche tecniche, vale la pena tenerne conto durante la progettazione dell'interfaccia. Puoi, ad esempio, dividere i filtri in “principali” (visibili subito) e “aggiuntivi” (apribili cliccando) per ridurre la probabilità di utilizzare venti parametri contemporaneamente.