21 Ottobre 2022

Come non andare in TV col tuo sito WooCommerce se non opportunamente configurato lato Server ed Hosting.

Birredamanicomio.com ed Hosting Spot televisivo. Un caso di insuccesso annunciato, con un sito offline durante il passaggio su Sky, appena prima dell’inizio di X Factor.

Introduzione

Ci sono delle situazioni difficili da spiegare dal punto di vista tecnico, e ci sono delle sensazioni ancora più difficili da spiegare dal punto di vista prettamente emotivo. Non dovremmo parlare di emozioni su un blog prettamente tecnico in cui si parla di Web Performance ed Hosting WooCommerce, tuttavia è innegabile che sarebbe un vero peccato non far comprendere al lettore quanto possa essere frustrante e insoddisfacente dal punto di vista umano, sentirsi la Giovanna D’Arco di turno.

Giovanna D’Arco fu famosa nell’immaginario popolare per avere visioni e fare profezie a cui abitualmente fu screditata e non creduta, noi di visioni fortunatamente non ne abbiamo e le “profezie” non sono sicuramente frutto del divino o del sovrannaturale ma semplicemente da esperienza maturata nel corso di oltre un decennio che ci ha permesso di fare previsioni in merito a situazioni ad alto rischio in siti ad altro traffico.

Come avremmo dovuto comportarci ad esempio nel leggere di una famosissima e bravissima agenzia di comunicazione, SEO e digital PR del Nord che comunicava la messa in onda di uno spot su Sky Uno in prima serata poco prima del famosissimo talent show X Factor ?

Quanto costa un evento del genere ? Al di la dei costi di produzione dello Spot che va ben oltre la nostra competenza ma che comunque immaginiamo abbia un costo non banale se si considerano attori, trucco, parrucco, macchine da presa, montaggio video, post-produzione, regia e quant’altro, probabilmente i costi più importanti ed impattanti non sono tanto i costi di realizzazione dello spot, quanto i costi di trasmissione su reti importanti come, ad esempio, SKY Uno in prima serata.

Sappiamo che il mondo della pubblicità televisiva sia molto variegato e che in determinate condizionate, media buyer possano vantare di offerte commerciali ad hoc assolutamente conveniente e molto distanti da quelle che sono le offerte “standard” spesso pubblicizzati nei canonici listini che di fatto hanno spesso solo la funzionalità orientativa.

A prescindere dalla contrattazione e dei trattamenti estremamente vantaggiosi che si possono ottenere, comunque bisogna tener presente che parliamo di canali televisivi importanti, con numeri di ascolto impressionanti e con offerte di listino, comunque, davvero molto ma molto esose.

A titolo informativo, infatti, quello sopra sono i costi indicativi per gestire e passare spot durante un evento come quello menzionato, ovvero XFactor 2022.

Senza voler affermare nulla, ma solo a scopo meramente indicativo un passaggio del genere ha un costo molto elevato, motivo per cui avrebbe avuto senso cercare di massimizzare i profitti evitando downtime e situazioni di rallentamenti che sono il timore di ogni campagna pubblicitaria online.

Va detto per completezza di informazione che diversi nostri clienti, (e clienti dei nostri clienti) nel corso degli anni hanno necessitato dei nostri servizi proprio per la messa in TV su reti nazionali (RAI e Mediaset) di spot che avrebbero portato molto traffico.

Campagne come Arquati Tende da Sole hanno trovato in noi la soluzione Hosting ad alte performance, ai downtime e crash, oppure la comparsata di Martina Gold al noto programma Ciao Darwin, lanci per n26 sotto collaborazioni di brand calcistici nostri clienti e via dicendo.

Era dunque normale e forse anche doveroso in coscienza esaminare come era strutturato tecnologicamente il sito che sarebbe stato oggetto di molto traffico, e notando un TTFB decisamente elevato, nonchè la mancanza di cache statiche lato server, la mancanza di formati immagine ottimizzate come Webp e un utilizzo errato dell’header Vary : User-Agent, abbiamo avuto il buon senso di comunicare all’autore del post sopra che il sito sarebbe andato probabilmente offline in quel modo in cui era configurato.

Avendo tra la cerchia degli amici (parlare al passato è oggettivamente doveroso) l’autore del post pubblico di cui sopra, non abbiamo avuto nessuna esitazione di comunicare senza troppi giri di parole che il sito sarebbe andato offline, avendo cura e diligenza di comunicare anche le motivazioni (e relativa analisi super partes Google PageSpeed Insight) a chi come Stefano (altro esperto in realizzazione ecommerce e addetto ai lavori) minimizzava con simpatia quello che a nostro avviso era ormai una sentenza inappellabile.

Nello screen in miniatura andavamo ad allegare con cognizione di causa i risultati del Google PageSpeed Insight che mostrava in modo piuttosto chiaro ed eloquente dei valori molto lontani dalle aspettative di Google, che sebbene possano costituire un problema “trascurabile” con poco traffico, diventano problemi di proporzioni epiche qualora il sito debba reggere un alto traffico, come quello che avrebbe ottenuto da un passaggio televisivo prima di X Factor.

PageSpeed Inisight Birredamanicomio

Appare subito evidente che il TTFB elevato significasse basse performance lato server, così come l’utilizzo di formati multimediali non recenti (le vecchie JPG e PNG invece delle nuove webp per intenderci) avrebbero potuto saturare l’uplink (normalmente ad 1Gbit/s nell’attuale fornitore), soprattutto in assenza di una CDN come CloudFlare.

Globalmente i valori riportati sono molto scadenti per un progetto Web che ambisce ad ottenere il dovuto e meritato successo.

Da lì in poi non è stato fatto nulla di significativo a livello di ottimizzazione se non l’aggiunta di un Plugin di ottimizzazione e cache lato applicativo come WP Rocket che, come abbiamo sempre riportato, non sono sufficienti per un sito con veramente molto traffico: Quando i plugin WordPress Cache non sono sufficienti. Reverse Proxy e Object Caching: prestazioni al massimo livello.

Gli effetti reali della messa online senza tuning lato server

Abbiamo pertanto voluto visionare dal vivo quali sarebbero stati i presunti nefasti effetti di portare in TV non sito non sufficientemente ottimizzato per reggere una mole di traffico stimata comunque importante.

Ci siamo pertanto sintonizzati su Sky Uno e abbiamo aspettato con lo smartphone in mano il passaggio dello spot in TV. Appena ha iniziato lo spot ci siamo diretti sulla Home page del sito e abbiamo effettuato dei refresh a cadenza più o meno regolare di uno ogni due secondi.

Dopo già pochi secondi (una decina o poco più), il sito si presentava come potete vedere nel video seguente, con problemi di apertura, una “rotella” in perenne attesa e una barra di avanzamento che non ne voleva sapere di avanzare a fronte di un sito web che non caricava.

Anche andando sul sito .it (un redirect al sito principale .com) ci siamo trovati di fronte alla stessa identica situazione, in alcun modo c’è stato verso di navigarlo e di essere dirottati sul sito principale.

A distanza di diversi minuti in cui probabilmente è diminuita l’affluenza dei visitatori che non sono riusciti a navigare il sito, il tempo di apertura del sito (della Homepage nello specifico) risultava di oltre 16 secondi (SEDICI), utilizzando la utility curl di Linux come ben visibile dall’immagine seguente.

tempo di apertura home page curl birredamanicomio

 

La responsabilità e la colpa sono dell’Hosting? O forse no.

Sarebbe comodo da parte nostra dire con certezza che la colpa sia stata dell’Hosting con delle tecnologie lato server non adeguate a supportare una mole di traffico importante. Tuttavia, questa potrebbe essere un’affermazione non veritiera dato che non sappiamo realmente come siano andate le cose.

Quel che è certo è che il nostro CTO Marco Marcoaldi, parlando con colui che in Fattoretto S.r.l. aveva responsabilità di fare scelte in merito all’Hosting (colui che dice appunto che sta valutando nel messaggio sopra) ha palesato delle problematiche tecniche e tecnologiche che andavano certamente vagliate, ponderate, approfondite ed analizzate col supporto eventualmente dell’attuale fornitore di Hosting.

Fattoretto Agency Sole24Ore

È pacifico che fosse scontato che ci sarebbe stato un picco di traffico molto maggiore rispetto al traffico standard, un traffico a tutti gli effetti non determinabile a priori, evenienza questa che deve essere trattata tenendo conto la peggiore delle situazioni possibili, ovvero trovare online centinaia di migliaia di utenti al minuto.

Con questa premessa, la prassi è quella di andare su istanze fisiche dedicate di fascia enterprise con il massimo dei core e dei thread disponibili ed una configurazione di rete e software a puntino con tutte le accortezze del caso.

Cosa si intende con “Fascia Enterprise”? Non stiamo parlando della navicella di Star Trek, ma bensì di una fascia Alta / Altissima che normalmente sono permissibili solo da grandi realtà ed aziende appunto definite di fascia Enterprise.

Spendere 50 – 150 euro di server dedicato al mese è alla portata di tutti, anche privati, fare un investimento di 1000 € al mese di server già inizia ad essere riservato a pochissime realtà.

Ciò avrebbe permesse ad esempio di noleggiare per un mese (o comunque la durata della programmazione dello spot) una macchina molto ben corazzata con almeno 32 core / 64 thread di un processore di ultima generazione e con dischi nVME veloci.

Se questa notizia di potenziali problemi non è stata approfondita col supporto tecnico, palesando preoccupazione, nonchè specificando che si sarebbe andati in onda con lo spot che avrebbe rimandato al sito, in prima serata, appena prima l’inizio di un programma seguitissimo come X Factor, il problema e la responsabilità è imputabile esclusivamente a colui che in possesso di informazioni tecniche che avrebbero dovuto allarmare riguardo ad un probabile downtime, non ha ponderato diligentemente e responsabilmente dati circostanziati proveniente da una fonte fidata.

Non è stato il panettiere, insomma, a dirti che forse andrai offline, ma una figura tecnica che fa questo dal 2005 e ha specificato anche le varie motivazioni misurate con strumenti ufficiali e superpartes come Google PageSpeed Insight, che avrebbe pertanto dovuto farti arrivare la veridicità delle sue esternazioni e la bontà di quanto enunciato.

Se all’Hosting Provider insomma non viene specificata questa situazione straordinaria, in grado di essere gestita straordinariamente con soluzioni hardware e software straordinaria (laddove straordinarie significa extra – ordinarie, ovvero non ordinaria, al di fuori dell’ordinarietà), è ovvio e palese che un Hosting Provider non può pre-occuparsi di allestire la loro migliore soluzione hardware / software per l’evenienza straordinaria, anche perchè richiede del lavoro aggiuntivo dell’Hosting Provider e delle spese vive da parte sua che richiederà necessariamente una rinegoziazione del contratto o la fatturazione a parte del servizio.

Tuttavia, crediamo che anche un investimento extra di 1000 euro, per garantire la migliore esperienza utente, considerando l’investimento economico che uno spot può richiedere sia nella realizzazione che nel passaggio su un canale come Sky Uno, era sicuramente un investimento a tutela dei propri affari.

Qualora invece la problematica fosse già stata segnalata all’Hosting Provider, avendo cura di specificare nel dettaglio e con precisione che lo spot sarebbe passato in prima serata, durante un programma televisivo molto seguito, e l’Hosting Provider abbia minimizzato sull’importanza di un tuning ad-hoc, specifico per l’evenienza, allora a quel punto è scontato che la responsabilità sia imputabile esclusivamente all’hosting provider che non è stato in grado di valutare con scrupolo una situazione che avrebbe comunque richiesto quanto meno l’installazione ed un tuning di una Cache HTML statica come Varnish, LSCache o NGINX FastCGI Cache, di cui non c’è alcuna traccia esaminando gli header della risposta HTML.

Se consideriamo oltretutto la configurazione lato server è rimasta la stessa a distanza di ormai quattro giorni dalla comunicazione della problematica e del relativo downtime, è piuttosto evidente che ancora una volta si tenda a minimizzare l’importanza di quanto già comunicato. Ovvero il sito non è pronto per reggere picchi di traffico ma nonostante tutto è già così.

Conclusione e spunti di riflessione

Come siamo soliti ripetere e ripeterci, in fondo nella vita non si perde mai. O si vince o si impara.

Da questa vicenda abbiamo avuto modo di trarre, documentare e condividere un caso di studio piuttosto eloquente che mostra e dimostra (video e prove alla mano) come a volte anche le migliori realtà di comunicazione italiane ed i migliori progetti possano inciampare rovinosamente su quello che non conoscono sufficientemente.

Perché tra fare brillantemente, comunicazione, digital PR, marketing e design, e saper fare tuning lato server e sistemistico, specificatamente per siti WooCommerce (come in questo caso), troppo ce ne passa.

Il responsabile era stato messo al corrente delle possibili (e probabili) conseguenze di esporsi in TV con un sito web non adeguatamente ottimizzato per gestire “tutto” il traffico che sarebbe arrivato, ma forse l’eccessivo entusiasmo del momento ha probabilmente messo in secondo piano l’aspetto meramente tecnologico, che sicuramente arginato con mezzi di fortuna come WP Rocket, hanno quanto meno evitato il peggio, riuscendo a gestire almeno in parte il traffico seguente a quello del picco iniziale che abbiamo mostrato e documentato nel video.

E’ pacifico dire ed affermare che anche le migliori iniziative ed i migliori intenti possono essere vani se non ci si circonda di figure estremamente tecniche in grado non solo di comprendere la problematica, ma anche i risvolti futuri, che in questo caso hanno sicuramente impattato economicamente, non consentendo ai visitatori (e dunque potenziali clienti) di visitare un sito che non si apriva e che per un lasso di tempo si è navigato a velocità sicuramente maggiori di quelle consigliate per massimizzare le vendite.

Ancora una volta, dunque, la dimostrazione pratica di come si sarebbe potuto evitare il peggio seguendo i consigli di professionisti specializzati e verticalizzati in ambito web performance, che avrebbero gestito la situazione in modo estremamente diverso, dimensionando un HW sicuramente di fascia enterprise, in modo specifico per l’evento. Un 32 core / 64 thread come minimo, avrebbe impostato correttamente un sistema di caching di fascia Enterprise come Varnish e avrebbe utilizzato formati ottimizzati come webp al posto delle pesantissime jpeg e PNG.

Purtroppo, come successe a Giovanna D’Arco, i nostri moniti non sono stati ascoltati ed è successo l’inevitabile, impattando sia a livello di immagine che in un mancato ritorno economico, un’iniziativa di marketing sicuramente vincente ed encomiabile.

Quando sottovalutate l’importanza di una figura sistemistica, ricordate questo esempio e questo caso di studio per capire quello che non va fatto quando si intende portare in TV un sito web.

Ad esempio, a distanza di ulteriori 10 giorni dal fatto avvenuto, un tempo più che adeguato e sufficiente per correre ai ripari e risolvere le problematiche già comunicate alla proprietà, troviamo ancora il sito con lo stesso stack tecnologico che emerge dall’analisi degli header e di lacune importanti e grossolane come, ad esempio, la mancanza della compressione Brotli.

Brotli Compressione Test

Nonché la mancanza di una importantissima feature ovvero il protocollo HTTP2.

Quando tramite il browser navighiamo un sito web in pratica facciamo una richiesta al server e il server risponde con inviando i dati di quella pagina specifica. I dati però non vengono inviati tutti insieme, ma spacchettati in porzioni più piccole di informazioni. La pagina del sito web, per poter essere caricata nel browser dell’utente, deve aspettare che ogni porzione dell’informazioni sia arrivata.
Questo vale anche per il protocollo HTTP (quello che viene utilizzato praticamente da sempre su Internet).

Il multiplexing, ossia la nuova funzionalità utilizzata dall’HTTP2, permette di “sminuzzare le richieste” in modo che più informazioni possano essere mandate avanti e indietro nello stesso momento. Questo rende la connessione tra browser e server molto più flessibile, efficiente e – come risultato – molto più veloce.

In media è stato calcolato che i siti che utilizzano il protocollo HTTP2 sono in grado di caricare le pagine più velocemente del 50%!

Facciamo un esempio: se per caricare l’homepage del vostro sito su uno smartphone con connessione 3G ci vogliono attualmente circa 8 secondi, con l’Http2 avrete l’home bella e caricata nel giro di 4.

È pacifico affermare senza troppi eufemismi alla luce di questa ultima grave carenza (la mancanza di HTTP/2) che probabilmente ci sia stato un certo disinteresse nell’ottimizzare il sito web e che l’attuale struttura di Hosting che stanno utilizzando, abbia configurazioni piuttosto vetuste non in grado di garantire ed offrire le best practices ai loro clienti.

Vediamo ad esempio la diffusione di HTTP/2 ad ottobre 2022 aiutandoci con i dati di https://w3techs.com/technologies/details/ce-http2

Ben il 42% dei siti Web mondiali fanno uso di HTTP/2, un protocollo molto importante in grado di aumentare ALMENO del doppio la velocità di trasferimento dati e rendering della pagina web come facilmente visibile dalla dimostrazione animata sotto.

HTTP2 Demo Animated Gif

Aggiornamento in data 3 Novembre 2022.

Sembra che il nostro lavoro di monitoraggio e comunicazione delle problematiche ad uno dei soci abbiamo prodotto l’effetto sperato, ovvero che si dedicasse attenzione alla problematica delle performance e dell’ottimizzazione dell’installazione lato server per poter ospitare correttamente WooCommerce.

Controllando su SecurityTrails.com, un servizio online in grado di mostrare le variazioni IP e DNS, abbiamo notato come dall’immagine seguente che in data 31 Ottobre 2022 l’IP che risponde al dominio birredamanicomio.com è diventato 77.39.211.105, invece del vecchio 185.81.1.17 che era in uso da quasi 5 anni.

Historical Data DNS Birredamanicomio.com SecurityTrails

La motivazione non è data sapere, ma crediamo sia pacifico che abbiano voluto evolvere il loro stack tecnologico optando per migliorie lato hardware (che ci è dato solo supporre) e sicuramente lato Software.

Se infatti fino al 30 Ottobre usavano un server web Apache, dal 31 Ottobre le cose sono cambiate come possiamo vedere dagli header nello screenshot seguente prodotto da curl -I

Possiamo vedere come il Web Server sia ora diventato NGINX, notoriamente più performante di Apache , il tutto su un server gestito tramite il pannello di controllo Plesk.

Non troviamo però alcuna traccia negli header di sistemi di caching lato server e Full Page Cache come Varnish Cache che avrebbe sicuramente potuto migliorare in modo assolutamente determinante le prestazioni del sito soprattutto a fronte di picchi di traffico.

Il Pagespeed è migliorato ? E le performance ?

Ad oggi (3 Novembre alle ore 13:48) il risultato dell’analisi Google PageSpeed Inside, porta i seguenti risultati che in termini di prestazioni sono a dir poco scarsi per un progetto che ambisce a presentarsi al grande pubblico con campagne di advertising televisive di un certo livello.

A voler dirla tutta, il punteggio PageSpeed sembra addirittura peggiorato, mostrando un indecoroso 16, rispetto all’altrettanto indecoroso 20 che mostrava nell’analisi precedente che potete trovare sopra.

Non ci addentreremo troppo nell’analisi delle varie voci del report di Google PageSpeed Insight, basti solo pensare che già utilizzare la compressione Brotli, HTTP/2 e le immagini webp avrebbero fatto sicuramente molto con il minimo sforzo.

Sembra assurdo e paradossale che alle soglie del 2023 ancora esistano siti Web che non hanno abilitato HTTP/2 o compressione Brotli.

La nuova configurazione è andata in TV il 2 Novembre ed è andata nuovamente offline.

Lo spot è andato nuovamente in onda il 2 Novembre alle 21:30 circa, in concomitanza con i Live di X Factor su TV8 il canale del digitale terreste facente capo al gruppo Sky.

 

 

Ed ecco cosa ci segnala il nostro sistema di Uptime.

Alle ore 21:34 (le prime avvisaglie iniziano già alle 21:33) il sito arriva ad impiegare 16,2 secondi (sedici secondi) per riuscire ad aprire la Home Page. Il problema persiste con questo tenore fino alle 21:37 con un buco di circa 4 minuti, in cui il sito è stato di fatto inusabile (chi aspetterebbe 16 secondi per aprire una singola pagina web ?).

Praticamente lo stesso identico problema e gli stessi identici valori che avevamo diagnosticato la volta precedente con tanto di curl -I e il comando time per misurare la lentezza di apertura.

tempo di apertura home page curl birredamanicomio

I dati parlano chiaro, stesso identico problema : 16,277 secondi contro gli scorsi 16,275 secondi che potete vedere nello screen qui sopra.

Non ci siamo. Non ci siamo.

Hai dei dubbi? Non sai da dove iniziare? Contattaci !

Abbiamo tutte le risposte alle tue domande per aiutarti nella giusta scelta.

Chatta con noi

Chatta direttamente con il nostro supporto prevendita.

0256569681

Contattaci telefonicamente negli orari d’ufficio 9:30 – 19:30

Contattaci online

Apri una richiesta direttamente nell’area dei contatti.

INFORMAZIONI

Managed Server S.r.l. è un player italiano di riferimento nel fornire soluzioni avanzate di sistemistica GNU/Linux orientate all’alta performance. Con un modello di sottoscrizione dai costi contenuti e prevedibili, ci assicuriamo che i nostri clienti abbiano accesso a tecnologie avanzate nel campo dell’hosting, server dedicati e servizi cloud. Oltre a questo, offriamo consulenza sistemistica su sistemi Linux e manutenzione specializzata in DBMS, IT Security, Cloud e molto altro. Ci distinguiamo per l’expertise in hosting di primari CMS Open Source come WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart e Magento, affiancato da un servizio di supporto e consulenza di alto livello adatto per la Pubblica Amministrazione, PMI, ed aziende di qualsiasi dimensione.

Red Hat, Inc. detiene i diritti su Red Hat®, RHEL®, RedHat Linux®, e CentOS®; AlmaLinux™ è un marchio di AlmaLinux OS Foundation; Rocky Linux® è un marchio registrato di Rocky Linux Foundation; SUSE® è un marchio registrato di SUSE LLC; Canonical Ltd. detiene i diritti su Ubuntu®; Software in the Public Interest, Inc. detiene i diritti su Debian®; Linus Torvalds detiene i diritti su Linux®; FreeBSD® è un marchio registrato di The FreeBSD Foundation; NetBSD® è un marchio registrato di The NetBSD Foundation; OpenBSD® è un marchio registrato di Theo de Raadt. Oracle Corporation detiene i diritti su Oracle®, MySQL®, e MyRocks®; Percona® è un marchio registrato di Percona LLC; MariaDB® è un marchio registrato di MariaDB Corporation Ab; REDIS® è un marchio registrato di Redis Labs Ltd. F5 Networks, Inc. detiene i diritti su NGINX® e NGINX Plus®; Varnish® è un marchio registrato di Varnish Software AB. Adobe Inc. detiene i diritti su Magento®; PrestaShop® è un marchio registrato di PrestaShop SA; OpenCart® è un marchio registrato di OpenCart Limited. Automattic Inc. detiene i diritti su WordPress®, WooCommerce®, e JetPack®; Open Source Matters, Inc. detiene i diritti su Joomla®; Dries Buytaert detiene i diritti su Drupal®. Amazon Web Services, Inc. detiene i diritti su AWS®; Google LLC detiene i diritti su Google Cloud™ e Chrome™; Microsoft Corporation detiene i diritti su Microsoft®, Azure®, e Internet Explorer®; Mozilla Foundation detiene i diritti su Firefox®. Apache® è un marchio registrato di The Apache Software Foundation; PHP® è un marchio registrato del PHP Group. CloudFlare® è un marchio registrato di Cloudflare, Inc.; NETSCOUT® è un marchio registrato di NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, e Kibana® sono marchi registrati di Elastic N.V. Hetzner Online GmbH detiene i diritti su Hetzner®; OVHcloud è un marchio registrato di OVH Groupe SAS; cPanel®, L.L.C. detiene i diritti su cPanel®; Plesk® è un marchio registrato di Plesk International GmbH; Facebook, Inc. detiene i diritti su Facebook®. Questo sito non è affiliato, sponsorizzato o altrimenti associato a nessuna delle entità sopra menzionate e non rappresenta nessuna di queste entità in alcun modo. Tutti i diritti sui marchi e sui nomi di prodotto menzionati sono di proprietà dei rispettivi detentori di copyright. Ogni altro marchio citato appartiene ai propri registranti. MANAGED SERVER® è un marchio registrato a livello europeo da MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italia.

SOLO UN ATTIMO !

Vorresti vedere come gira il tuo WooCommerce sui nostri sistemi senza dover migrare nulla ? 

Inserisci l'indirizzo del tuo sito WooCommerce e otterrai una dimostrazione navigabile, senza dover fare assolutamente nulla e completamente gratis.

No grazie, i miei clienti preferiscono il sito lento.
Torna in alto