Velocizzare WooCommerce e WordPress. Come aumentare la velocità di un sito.

Indice dei contenuti dell'articolo:

Alla fine qualcuno doveva pur farlo, spiegare una volta per tutte in modo chiaro, preciso e conciso il perchè WordPress sia lento, cosa significa aumentarne le performance, come renderlo più veloce sia da un punto di vista di sviluppo, sia da un punto di vista sistemistico e di hosting WordPress.

Ciò vi permetterà di trarne delle corrette conclusioni e potervi districare tra le migliaia di offerte di sedicenti esperti che ogni giorno provano a vendervi servizi di velocità WordPress o servizi di velocizzare WordPress come qualcuno lo chiama.

Attenzione : il seguito dell’articolo è piuttosto tecnico e forse non adatto all’imprenditore che eccelle in tutt’altro nella vita e si ritrova un sito lento e ha come desiderio solo quello di renderlo veloce. Se preferisci non addentrarti in terminologie strane, come cache, TCP BBR, Above the Fold, Critical Css e altro, ti invitiamo a contattarci direttamente nella sezione contatti.

Se invece sei curioso di capire quello che facciamo e le problematiche di lentezza che andiamo a risolvere continua pure questa lettura.

Come dicevamo inizialmente, purtroppo c’è una presa di posizione nel panorama piuttosto disonesta, i sistemisti dicono che basta un hosting e un server veloce per avere un sito veloce, e gli sviluppatori sostengono invece che basti avere un sito sviluppato ad hoc (ovviamente da loro a decine di migliaia di euro l’anno), per non avere nessun problema in termini di performance e velocità.

Ecco cosa scrive ad esempio un noto e preparatissimo sviluppatore WordPress sul suo sito in merito a noi sistemisti.

Quello che ovviamente dimentica di dire questo signore qui sopra, è che l’azienda con cui abbiamo lavorato insieme è passata da un caricamento di pagina di circa 6 secondi a 1,5 secondi SOLO ed esclusivamente grazie ad un tuning sapiente sistemistico lato server e solo successivamente un ulteriore miglioramento nell’ordine di mezzo secondo scarso, grazie ad un costosissimo approccio di sviluppo ad-hoc costato qualcosa come decine e decine di migliaia di euro l’anno come ci ha riportato il CEO di un’azienda che ometteremo per correttezza e privacy di tutte le parti.

Si capisce dunque che molto spesso un approccio ad-hoc sartoriale a livello di sviluppo (come svilupparsi plugin o temi da zero) sia possibile solo dopo che l’azienda sia riuscita ad ottenere dei risultati economici importanti online con un investimento iniziale basso a livello sistemistico che ha permesso di portare il sito ad una velocità quantomeno più che adeguata per avere successo online, e solo in un secondo tempo eventualmente reinvestire una somma comunque importante (di decine e decine di migliaia di euro l’anno) per un tuning ad hoc anche a livello applicativo.

Ciò non significa che un approccio a livello di sviluppo non sia importante, anzi siamo i primi a sostenere l’esatto opposto, motivo per cui spesso quando se ne rileva l’opportunità indirizziamo i clienti che hanno già ricevuto dei brillanti risultati grazie alla nostra consulenza sistemistica, verso sviluppatori con cui collaboriamo in un reciproco equilibrio e rispetto della rispettiva professione e professionalità.

Mai ci sogneremo di dire che lo sviluppo non sia importante in termini di performance, a differenza di chi pur di portare acqua al proprio mulino non ha nessuno scrupolo nel minimizzare l’importanza di un hosting ottimizzato e performante, nonchè la figura professionale del sistemista, improvvisandosi tale con risultati quantomeno discutibili.

Vogliamo solo evidenziare come sia più facile passare da 6 secondi a 1,5 spendendo (investendo) ad esempio 50 o 100€ al mese per un sito in fase embrionale che ancora deve ottenere i giusti successi a livello imprenditoriale e di utili, piuttosto che focalizzarsi sin da subito sullo sviluppo a decine di migliaia di euro l’anno.

A rigor di ciò, proprio per fare un punto fermo della spiacevole situazione che ormai sta prendendo il sopravvento in ambito di ottimizzazione delle performance e della velocità di WordPress, abbiamo voluto scrivere questo post che seppur con un pizzico di genuina e pacifica polemica non vuol far altro che rappresentare la realtà di casi che abbiamo vissuto (anche nostro malgrado) in prima persona.

Vediamo dunque a grosse linee come è impostata un’installazione di WordPress nella sua “complessità”, in cui andremo a elencare le principali componenti come il Server (fisico), il CMS (WordPress) che si basa a sua volta con PHP (interprete server side) e il DBMS (MySQL).

Ci occuperemo pertanto di scomporre il problema in singole compenti : Il Webserver, PHP, MySQL, e l’applicativo WordPress sviluppato sopra ad esso, andando a menzionare le ultime necessità e metriche in ambito PageSpeed e Google Core Web Vitals, indicandovi in ogni caso quale possa essere la soluzione migliore in termini di perfomance e velocità sia per siti lenti già esistenti e dunque già sviluppati, sia per siti che dovranno essere progettati da zero.

Iniziamo dunque.

Cos’è WordPress ?

WordPress è una piattaforma software di “blog” e content management system (CMS) open source ovvero un programma che, girando lato server, consente la creazione e distribuzione di un sito Internet formato da contenuti testuali o multimediali, gestibili ed aggiornabili in maniera dinamica. Inizialmente fu creato da Matt Mullenweg e distribuito con la licenza GNU General Public License. È sviluppato in PHP con appoggio al gestore di database MySQL.

È il CMS più utilizzato al mondo

Secondo W3TECHS https://w3techs.com/technologies/details/cm-wordpress attualmente è utilizzato dal 65,1% di tutti i siti web di cui conosciamo il sistema di gestione dei contenuti. Questo rappresenta di fatto il 42,7% di tutti i siti web online.

Inutile decantarne i punti di forza ormai ben noti in merito alla community, alla facilità di apprendimento, all’utilizzo, alle migliaia di plugin per fare qualsiasi cosa, che lo rende di fatto il CMS più in voga da sempre.

Dovremmo soffermarci sulle noti dolenti, ovvero WordPress non è un sistema performante, leggero e scattante. WordPress è invece un sistema estremamente lento e macchinoso, derivato in primis dalle tecnologie su cui esso è stato sviluppato : PHP e MySQL.

Il primo un linguaggio di programmazione server side ormai vetusto sviluppato dal 1994, l’latro un DBMS relazionale che in quanto ciò dovendo soddisfare alcune importanti proprietà e peculiarità di DBMS ACID compliant sono necessariamente lenti rispetto a soluzioni moderne.

Cos’è WooCommerce ?

WooCommerce è un plugin scaricabile all’interno di WordPress, che consente di trasformare il tuo sito in un vero e proprio negozio virtuale. Lanciato nel settembre 2011, WooCommerce è una piattaforma in costante miglioramento e aggiornamento, sia in termini di funzionalità che di caratteristiche. Vene utilizzato da commercianti, principianti o esperti, per avviare un’attività di vendita online di prodotti o servizi altamente professionale.

WordPress è lento, perchè è basato su PHP

Lo sviluppo di questo linguaggio di programmazione ebbe inizio nel 1994, quando Rasmus Lerdorf era alle prese con la creazione di script Common Gateway Interface (“Interfaccia comune per gateway” in italiano) in Perl da utilizzare per gli aggiornamenti periodici del suo sito web. Questi piccoli tool svolgevano compiti tutto sommato semplici e ripetitivi come mostrare il suo curriculum vitae e registrare il numero di visitatori alla sua pagina personale.

Inizialmente il PHP non era pensato – né tantomeno realizzato – per essere un linguaggio di programmazione a sé stante. Con il passare del tempo, e al crescere della comunità di sviluppatori web che lo utilizzava, si decise di dare una sistematizzazione al corpus di funzioni e script realizzati. Da questo lavoro nacque la seconda release di PHP/FI, lanciata nel novembre 1997.

PHP non è il linguaggio più veloce in cui potremmo scrivere applicazioni web, eppure continuiamo a farlo per molte altre ragioni. La pura velocità di un linguaggio è raramente il principale fattore decisivo per molti progetti. La produttività degli sviluppatori, per prima cosa, di solito è più importante. E in molte applicazioni i colli di bottiglia non saranno nel codice dell’applicazione; invece è dove avviene l’interazione con altri sistemi. Ad esempio, la comunicazione con database, API e code di messaggi richiede tempo.

Allora perché PHP è lento rispetto ad altri linguaggi? PHP è un linguaggio dinamico e interpretato. Ciò significa che non è compilato in linguaggio macchina ma piuttosto letto in fase di esecuzione. PHP ha anche un’architettura share-nothing, quindi su ogni richiesta interpreta tutto da zero. La conseguenza di ciò è che le prestazioni non sono buone come per i linguaggi compilati, ma consentono anche funzionalità che i linguaggi compilabili non hanno.

Non aver bisogno di compilare PHP può aiutare con la produttività degli sviluppatori in alcuni modi. Consente cicli di feedback più brevi durante lo sviluppo: i risultati delle modifiche al codice possono essere visualizzati immediatamente senza che sia necessario eseguire prima alcuna fase di compilazione. C’è meno bisogno di preoccuparsi della garbage collection e dell’uso della memoria. Il debug degli errori di runtime è più semplice, perché è possibile identificare direttamente dove si verificano nel codice sorgente. Consente anche codice dinamico come variabili variabili, tipi dinamici e così via, anche se è necessario prestare attenzione con questi per evitare di rendere difficile il test dell’applicazione.

Tutto ciò però fa di PHP un linguaggio pesante e lento se lo volessimo confrontare ai più moderni linguaggi asincroni come GO o Node.js che a differenza di PHP sono linguaggi asincroni e non bloccanti e di fatto più performanti come vediamo facilmente dall’immagine seguente.

MySQL è lento, perchè è un vero DBMS relazionale con proprietà ACID.

Un altro componente fondamentale su cui gira WordPress è il database server, nella totalità di casi un server MySQL o un suo fork e derivato come MariaDB o Percona Server.

MySQL soddisfa pienamente i requisiti ACID per un RDBMS sicuro per le transazioni, come segue:

L’atomicità viene gestita memorizzando i risultati delle istruzioni transazionali (le righe modificate) in un buffer di memoria e scrivendo questi risultati su disco e nel log binario dal buffer solo una volta che la transazione è stata confermata. Ciò garantisce che le dichiarazioni in una transazione operino come un’unità indivisibile e che i loro effetti siano visti collettivamente o per niente.
La coerenza è principalmente gestita dai meccanismi di registrazione di MySQL, che registrano tutte le modifiche al database e forniscono una traccia di controllo per il ripristino delle transazioni. Oltre al processo di registrazione, MySQL fornisce meccanismi di blocco che assicurano che tutte le tabelle, le righe e gli indici che compongono la transazione siano bloccati dal processo di avvio abbastanza a lungo da eseguire il commit della transazione o il rollback.
Le variabili del semaforo lato server e i meccanismi di blocco fungono da gestori del traffico per aiutare i programmi a gestire i propri meccanismi di isolamento . Ad esempio, il motore InnoDB di MySQL utilizza il blocco a livello di riga a grana fine per questo scopo.
MySQL implementa la durabilità mantenendo un file di registro delle transazioni binario che tiene traccia delle modifiche al sistema nel corso di una transazione. In caso di guasto hardware o arresto improvviso del sistema, il ripristino dei dati persi è un’attività relativamente semplice utilizzando l’ultimo backup in combinazione con il registro al riavvio del sistema. Per impostazione predefinita, le tabelle InnoDB sono durevoli al 100% (in altre parole, tutte le transazioni impegnate nel sistema prima dell’arresto anomalo possono essere ripristinate durante il processo di ripristino), mentre le tabelle MyISAM offrono una durata parziale.

Questo paradigma risale al 1970, formalizzato parzialmente (ACD, l’isolamento giunse successivamente) in uno storico articolo del 1981 intitolato The Transaction Concept: Virtues and Limitations da Jim Grey e divenendo maturo nel 1983 in un secondo documento intitolato Principles of Transaction-Oriented Database Recovery, scritto da Andreas Reuter e Theo Härder.

I database relazionali ad uso OLTP – citiamo ad esempio i motori di database relazionale prodotti da Oracle e Microsoft – sono stati progettati mettendo quindi al centro affidabilità e coerenza dei dati gestiti, secondo questo paradigma.

Ciò ne fa un DBMS davvero potente e stabile in grado di mantenere uno stato di coerenza dei dati, non perderli o di generare errori in fase di scrittura o lettura.

I database conformi alle regole ACID sono spesso utilizzati dalle istituzioni finanziarie come banche oppure casinò e sistemi mission critical in cui i dati debbono essere integri e coerenti.

Un Database ACID compliant avendo la necessità di offrire queste garanzie dovrà necessariamente avere dei controlli a livello di business logic (logica interna dell’applicazione) che lo renderà necessariamente più lento rispetto ai nuovi DB NOSQL di nuova generazione che a differenza di un DBMS SQL Acid compliant sono appena sufficienti per leggere e scrivere informazioni senza troppi fronzoli.

D’altro canto, i database non relazionali in genere garantiscono atomicità sulla singola istruzione, indipendentemente da quanto questa sia complessa. Tale Eric Brewer ha coniato il termine BASE che i database NoSQL devono rispettare:

Basic Availability: è garantita una risposta ad ogni richiesta, sia che sia conlusa con successo che con fallimento.
Soft state: lo stato del sistema può cambiare nel corso del tempo, anche senza intervento dell’utente.
Eventual consistency: dal momento che si ha soft state, possono verificarsi casi di mancata consistenza, la quale va gestita manualmente dallo sviluppatore.

Tutto ciò rende evidente che ogni tal volta sia necessario rappresentare su un database un concetto del mondo reale che contiene la parola transazione, a meno di essere pazzi suicidi che vogliono implementare un loro meccanismo di gestione delle transazioni a mano, la scelta ricade necessariamente sui database relazionali.

Tralasciando il linguaggio SQL standard ANSI, la normalizzazione dei dati e altri argomenti estremamente tecnici e accademici (ricordando il Buon Prof. Montesi del corso di basi di dati dell’università di Camerino), possiamo affermare con serenità che un CMS sviluppato BENE con una base di dati progettata BENE su un sistema NOSQL sarà sicuramente più veloce della rispettiva soluzione sviluppata BENE su un DBMS relazionale.

WordPress è lento perchè alcuni plugin sono lenti.

Una delle casistiche standard in cui ogni sviluppatore WordPress si sarà imbattuto nel corso della propria carriera è quella di avere un sito tutto sommato sufficientemente prestante e veloce fino a quando non è stato installato un plugin che ha rovinosamente rallentato le performance del sito WordPress.

Questo scenario è molto frequente quando si intende aggiungere nuove feature e funzionalità al sito, come magari l’aggiunta di un banalissimo contatore di visite come Post View Counts, un semplice sistema multilingua come WPML, oppure un sistema di e-Commerce come WooCommerce o anche un sistema di backup come Updraft Update e Restore ad esempio.

In realtà la lista dei plugin problematici è molta lunga e non basterebbe un’enciclopedia nel volerli trattare correttamente tutti.

Basti dunque pensare che molti Hosting ad alte performance internazionali, tra cui noi ovviamente abbiamo stilato una lista di plugin che andrebbero scoraggiati o addirittura vietati, pena un rallentamento importante del sito e delle relative performance.

Non stiamo in alcun modo suggerendo che uno di questi plugin non consentiti sia un plugin “cattivo”. Alcuni di essi, come i plug-in di post correlati, possono essere ottimi per la rilevabilità dei contenuti. Tuttavia, in qualità di host WordPress gestito, la nostra preoccupazione principale è fornire l’esperienza di hosting WordPress più veloce e sicura possibile. Questi plugin hanno dimostrato di avere un impatto negativo sulle prestazioni o sulla sicurezza sulla nostra piattaforma e abbiamo deciso di impedirne l’uso.

Per quanto riguarda i plugin non sicuri, proviamo a collaborare con lo sviluppatore del plugin per farli correggere. Durante quel periodo il plugin potrebbe essere temporaneamente aggiunto al nostro elenco di utenti non consentiti e saremo lieti di consentirlo nuovamente una volta che il problema sarà stato risolto.

Plugin di memorizzazione nella cache

I plug-in di memorizzazione nella cache possono entrare in conflitto con la struttura di memorizzazione nella cache integrata della nostra piattaforma. È noto che questi plug-in causano conflitti diretti e, se utilizzati, avrebbero un impatto sulla capacità di caricamento del tuo sito:

WP Super Cache
WP Fast Cache

Molte delle funzionalità di memorizzazione nella cache offerte da questi plug-in sono integrate nei nostri server per impostazione predefinita come parte della tua esperienza di hosting WordPress gestito. Abbiamo le spalle, non preoccuparti!

Plugin di backup

Sconsigliamo l’uso di plug-in di backup poiché gonfiano inutilmente il tuo sito e possono archiviare i file in modo non sicuro. Molti di questi plugin eseguono anche i loro processi di backup in momenti inopportuni, rallentando le query MySQL e persino causando timeout sul tuo sito.

Le seguenti soluzioni di backup sono plug-in non consentiti:

WP DB Backup : gonfia inutilmente la memoria locale del tuo sito.
WP DB Manager : si consiglia la protezione .htaccess, ma l’utilizzo dell’archiviazione locale è la preoccupazione principale in quanto offre solo un’opzione di archiviazione locale.
BackupWordPress — Duplica un gran numero di file nella memoria locale già presenti nei nostri backup.
VersionPress — Per funzionare, questo plugin ha bisogno dell’accesso a funzioni a livello di server che non consentiamo per motivi di sicurezza.

Effettuiamo backup notturni di tutti i siti Web WordPress ospitati con noi . Questi vengono eseguiti in modo efficiente e automatizzato e i dati vengono conservati in modo sicuro su un server separato dalla tua installazione di WordPress. I nostri backup automatici non contano per i limiti di archiviazione locale del piano e rendiamo disponibili questi backup per ripristinarli, copiarli o scaricarli quando necessario.

Se ti senti più sicuro con un backup secondario fuori sede, permettiamo ad esempio VaultPress sui nostri server.

Plugin per server e MySQL Thrashing

Questi plugin non sono consentiti perché causano un carico elevato sul server o creano un numero eccessivo di query di database. Influiranno direttamente sul carico del server e in definitiva ostacoleranno le prestazioni del tuo sito.

Broken Link Checker : travolge il server con una quantità molto grande di richieste HTTP
MyReviewPlugin — Blocca il database con una quantità significativa di scritture.
LinkMan — Proprio come MyReviewPlugin sopra, LinkMan utilizza una quantità non scalabile di scritture di database.
Fuzzy SEO Booster : causa problemi con MySQL man mano che un sito si espande.
WP PostViews : scrive in modo inefficiente nel database a ogni caricamento di pagina.
Tweet Blender — Non interagisce bene con la memorizzazione nella cache e può causare un aumento del carico del server.

Per tenere traccia del traffico in modo più scalabile, sia il modulo statistiche nel plug-in Jetpack di Automattic che Google Analytics funzionano alla grande.

Ti consigliamo di utilizzare uno dei seguenti strumenti per verificare la presenza di collegamenti interrotti sul tuo sito. Poiché non sono plugin, non avranno un effetto negativo sulle prestazioni del tuo sito.

Post correlati Plugin

Quasi tutti i plug-in “Post correlati” soffrono degli stessi problemi di MySQL, indicizzazione e ricerca. Questi problemi rendono i plugin estremamente intensivi per il database.

Quelli che abbiamo bandito a titolo definitivo sono:

Dynamic Related Posts
SEO Auto Links & Related Posts
Yet Another Related Posts Plugin
Similar Posts
Contextual Related Posts

Esistono servizi dedicati che ti consentono di scaricare le funzionalità di post correlate ai loro server. Ti consigliamo invece di esaminare uno dei servizi di posta correlati:

Plugin di posta elettronica

Solo perché sei in grado di inviare e-mail con WordPress, ciò non significa sempre che dovresti. Vogliamo che i nostri clienti sperimentino la stessa esperienza migliore con la posta elettronica come forniamo con l’hosting web, quindi consigliamo di utilizzare un servizio di terze parti. Servizi specializzati come MailChimp , Constant Contact , AWeber e innumerevoli altri offrono soluzioni di posta elettronica complete per la tua azienda e ti forniranno risultati ottimali.

Se il provider di posta elettronica del tuo dominio offre il proprio server SMTP, puoi configurarlo come server in uscita. Assicurati di verificare con il tuo provider di posta elettronica la loro posta in blocco, la posta opt-in e le politiche anti-spam prima di farlo.

Plugin vari

Altri plugin che abbiamo deciso di rimuovere in modo proattivo includono:

Ciao Dolly!
WP phpMyAdmin — Non consentito a causa di un problema di sicurezza piuttosto grave . Offriamo anche l’accesso a phpMyAdmin senza plug-in dal tuo Portale utente .
Sweet Captcha — Dopo che i nostri partner di Sucuri hanno rivelato che il servizio Sweet Captcha è stato utilizzato per distribuire adware, abbiamo deciso di seguire l’esempio di WordPress Plugin Repo e vietare completamente il plug-in.
Digital Access Pass (DAP) — Sebbene non lo rimuoviamo attivamente dai siti, tieni presente che non funzionerà correttamente sulla nostra piattaforma a causa dell’utilizzo di sessioni PHP e cron a livello di sistema. Invece, ti consigliamo di utilizzare uno degli altri plug-in di abbonamento di alto livello come Paid Memberships Pro , Restrict Content o S2Member .

Script aggiuntivi

È noto che alcuni script utilizzati di frequente contengono vulnerabilità di sicurezza. La nostra piattaforma esegue periodicamente la scansione del file system per identificare e correggere o rimuovere questi script.

TimThumb : è noto che le versioni precedenti di TimThumb contengono vulnerabilità. Quando la nostra scansione del sistema identifica una versione precedente, aggiornerà automaticamente lo script. Dopo che l’aggiornamento è stato completato, il sistema ti avviserà tramite e-mail.
Uploadify : l’accesso a questo script è bloccato a causa di note minacce alla sicurezza. Il ragionamento alla base di ciò è stato ampiamente informato da questo post sul blog dei nostri partner di Sucuri.

Ovviamente la lista non è esaustiva ma serve solo a render conto di come basti un plugin per mettere in ginocchio un sito WordPress. Bisogna sempre fare attenzione dunque quando si installa un plugin chiedendosi se effettivamente abbiamo bisogno di quella funzionalità e se stiamo installando il migliore plugin disponibile per implementare quella determinata funzione.

Potremmo aver bisogno di usare un sistema multilingua, quale scegliere dunque tra WPML, PolyLang e MultilingualPress ? Quali pro, quali contro, quale andremmo ad installare ?

Questo è il giusto approccio che dovremmo usare ogni volta che vogliamo aggiungere una funzione tramite plugin.

WordPress è lento, perchè i temi sono lenti.

Allo stesso modo di come possono essere lenti i plugin sopra menzionati, anche un tema può essere più o meno veloce in base al tema e alla configurazione dello stesso. Esistono temi estremamente veloci con poche query verso il database e codice PHP molto veloce, ed altri estremamente macchinosi con molteplici query verso il database (magari per creare un menù) che rende il tutto molto complesso, ridondante e dunque lento.

Non ci addentreremo troppo nella discussione inerente i Temi WordPress dato che c’è poco da dire, se non che un sistema sviluppato ad-hoc risulterà sicuramente più veloce di uno di quei tanti temi General Purpose con mille funzionalità non necessarie che potrete trovare su siti come ThemeForest.

Se avete già un sito in produzione con un tema già impostato e non volete spendere diverse migliaia di euro per lo sviluppo di un tema ad-hoc (preventivate almeno circa 5000 – 10000 euro per almeno un paio di mesi di lavoro da parte di uno sviluppatore WordPress competente), evitate pure di scervellarvi su come ottimizzare l’attuale tema in uso intervenendo a livello applicativo e cercate di risolvere il peso e la lentezza del sito intervenendo su altri punti trattati in questo post, soprattutto quelli lato server.

WordPress lento. Ma cosa significa ?

Spiegare cosa significa WordPress lento può avere molteplici interpretazioni. Dipende ovviamente dal metro di misura che si utilizza e che per brevità possiamo rappresentare con due entità distinte : l’utente e Google.

L’utente che ha la necessità di avere un sito reattivo e veloce per godere di un’esperienza utente (o user experience) soddisfacente che migliori la permanenza sul sito, riduca i tassi di rimbalzo, gli abbandoni del carrello e dunque migliori le conversioni e le vendite per la gioia dell’imprenditore che vede un aumento del fatturato e presumibilmente anche degli utili.

Google che misurando il sito tramite dei test automatizzati, nonchè tramite dei dati reali sul campo che vengono inviati a Google dai browser Chrome (e solo loro) ci pesa e ci valuta tramite i moderni Core Web Vitals simulando una connessione 3G lenta che oggi come oggi riguarda una minima parte delle connessioni reali.

Google Page Speed Insights mostra i risultati in base a due dispositivi. La tua versione desktop del tuo sito web e una versione mobile.

Il test eseguito sulla versione desktop mostra più o meno come verrà visto il tuo sito da un utente che visita dal proprio laptop o computer desktop con velocità Internet generalmente buone.

I test eseguiti su un dispositivo mobile mostreranno come si comporta il tuo sito quando accedi da uno smartphone o un tablet, di solito con velocità più basse e meno risorse.

Questo test mobile viene volutamente eseguito simulando una rete 3G con limitazioni, raramente utilizzata nel mondo digitale moderno. La maggior parte utilizza il test di Google per controllare rapidamente il proprio sito Web e non ha idea del perché i propri siti Web sembrino funzionare così male sui dispositivi mobili.

Se fino a qualche tempo fa era prassi giustificarsi dicendo al cliente finale di non preoccuparsi troppo di quello che dice il test mobile di Google PageSpeed Insight dato che a livello di navigazione reale anche un sito con un punteggio mobile gravemente insufficiente poteva essere realmente veloce nella realtà e caricarsi in meno di due secondi, è anche vero che con l’annuncio di Google che il punteggio Core Web Vitals non sia più una vanity metrics (come qualche sviluppatore troppo orgoglioso quanto ignorante ancora vuol far credere) ma un fattore di ranking e posizionamento, oggi bisogna anche soddisfare questa necessità.

Partiamo da un concetto però, come avviene la visualizzazione di una pagina Web nel momento in cui noi scriviamo ad esempio https://www.wikipedia.org ?

Ecco tutti gli step che farà il nostro Browser dalla richiesta alla visualizzazione del contenuto utilizzabile per essere letto e anche cliccato :

Richiesta del sito tramite inserimento nella barra di navigazione del Browser.
Richiesta DNS al nameserver del nostro fornitore di connettività che chiederà al DNS autoritativo l’IP corrispondente del nome a dominio wikipedia.org
Richiesta del vhost all’IP che ci è stato restituito al punto 2
Il Webserver accetta la richiesta e scopre che il browser richiede la navigazione in modalità sicura HTTPS
Il Webserver negozia col client l’handshake SSL per instaurare la connessione in modalità sicura
Il Webserver inoltra la richiesta all’handler per il sito in questione, in questo caso un pool PHP che dovrà creare dei processi (qualora non siano già avviati e in attesa di richieste) per iniziare a interpretare i file PHP.
L’interprete PHP leggerà i file producendo un bytecode che richiamerà i vari file di WordPress, i temi, i plugin e le relative query verso il Database MySQL
Il database riceverà le centinaia di Query che eseguirà in modo più o meno efficiente restituendo un record set di dati più o meno grande che verrà poi elaborato da PHP.
PHP che ha ricevuto i dati produrrà un layout HTML e CSS che verrà restituito al browser dell’utente comprensivo di immagini e multimedia.
Il browser dell’utente scaricherà i relativi contenuti statici impiegando un tempo variabile che dipende dal peso dei dati da scaricare e della relativa velocità di download.
Il browser prenderà il layout html e i fogli di stile per ricomporre il tutto, disegnando la pagina nella struttura che andremo a visualizzare (rendering).

Come abbiamo visto dunque, dietro ad una banalissima visita ad un sito web si instaurano una serie di inevitabili operazioni che possono però essere fatte bene o male.

Prendiamo l’elenco di prima e iniziamo a farci delle dovute domande se quello che stiamo facendo lo stiamo facendo nel migliore dei modi.

Richiesta del sito tramite inserimento nella barra di navigazione del Browser.
Stiamo usando un browser moderno di ultima generazione ? La connessione è buona ? Se siamo da smartphone godiamo di una buona copertura ? Siamo in 5G, 4G o 3G ? Abbiamo dei limiti di velocità in download da parte del nostro fornitore di telefonia mobile ? Abbiamo utilizzato nel nostro server Web il protocollo TCP-BBR per le connessioni lente 3G permettendo di utilizzare comunque il loro massimo della velocità possibile nonostante la loro lentezza ?
Richiesta DNS al nameserver del nostro fornitore di connettività che chiederà al DNS autoritativo l’IP corrispondente del nome a dominio del nostrosito.it
Il nameserver che utilizziamo come nameserver autoritativo per nostrosito.it è veloce ? Quanti millisecondi impiega a restituire l’IP corretto al nostro sistema operativo del nostro smartphone ? Perchè non utilizziamo un DNS Anycast magari su un fornitore terzo specializzato come può essere Amazon Route 53 o CloudFlare DNS ?
Richiesta del vhost all’IP che ci è stato restituito al punto 2
Il Webserver accetta la richiesta e scopre che il browser richiede la navigazione in modalità sicura HTTPS
Che webserver stiamo utilizzando ? Quanto è veloce nell’accettare una connessione ? Come si comporta di fronte ad oltre 10 mila connessioni al secondo ? Quanto impatta sulla CPU e sulla memoria ? Lavora a processi ? A Thread ? Usiamo il velocissimo NGINX o il vecchio e lentissimo Apache ?
Il Webserver negozia col client l’handshake SSL per instaurare la connessione in modalità sicura
Che protocolli SSL utilizziamo e quale tipo di crittografia vogliamo utilizzare per instaurare le connessione ? Che tipo di certificato SSL utilizziamo ? Vogliamo rivolgerci anche ai vecchi sistemi operativi con Windows Vista, Windows XP, Android 7 e versioni precedenti di MacOS El Captain ? Forse Let’s Encrypt non va bene e dobbiamo adottare un certificato commerciale DV per soddisfare tutti e non ricevere errori di connessione.
Il Webserver inoltra la richiesta all’handler per il sito in questione, in questo caso un pool PHP che dovrà creare dei processi (qualora non siano già avviati e in attesa di richieste) per iniziare a interpretare i file PHP.

Quanto impiega il webserver ad accettare la connessione ? Quanto impiega il webserver ad azionare il processo PHP corrispondente alle richiesta ? Il processo PHP va avviato da zero o il processo PHP è già in modalità di attesa e possiamo risparmiare il tempo di avviamento del processo ? Se usiamo PHP-FPM dunque che tipo di modalità utilizziamo ? ondemand, static, dynamic ? Con quali limiti e in quali contesti ?
L’interprete PHP leggerà i file producendo un bytecode che richiamerà i vari file di WordPress, i temi, i plugin e le relative query verso il Database MySQL
Dobbiamo leggere il file accedendo al disco. Quanto è veloce il disco ? Dobbiamo scrivere sul disco che abbiamo fatto un’operazione di lettura del file o possiamo ignorarlo dato che è un dato superfluo che ci comporterebbe solo di sprecare tempi di scrittura sul disco ? Dobbiamo necessariamente ogni volta che chiamiamo index.php rileggere ed eseguire il codice interpretato o possiamo utilizzare un bytecode precompilato da mettere in una cache per aumentare le performance tramite OpCache ? Ogni quanto dobbiamo controllare se i file sono cambiati e rigenerare il nuovo bytecode aggiornato ?
Il database riceverà le centinaia di Query che eseguirà in modo più o meno efficiente restituendo un record set di dati più o meno grande che verrà poi elaborato da PHP.
Stiamo utilizzando Cache a livello di DBMS ? Le tabelle hanno gli indici ? Ci sono cron attivi a livello di WordPress ? Ci sono transient scaduti o inutili ? Abbiamo recordset giganti restituiti da plugin / temi non ottimizzati ?
PHP che ha ricevuto i dati produrrà un layout HTML e CSS che verrà restituito al browser dell’utente comprensivo di immagini e multimedia.
Quanto è veloce il webserver ? Utilizziamo comprimiamo i contenuti JS e CSS con compressione gzip o meglio brotli ?
Il browser dell’utente scaricherà i relativi contenuti statici impiegando un tempo variabile che dipende dal peso dei dati da scaricare e della relativa velocità di download.
I contenuti statici come le immagini usano sistemi di compressione come le immagini webp invece delle pesanti png,jpg,jpeg ? In caso stessimo utilizzando una Cache Statica come Varnish, le immagini vanno cachate in RAM o servite direttamente dal disco ? Riusciamo ad utilizzare HTTP/2 o HTTP/3 per migliorare il parallelismo dei download senza usare il vetusto damain sharding ? Il contenuto del nostro sito è di interesse nazionale ? Possiamo e conviene utilizzare una CDN come Cloudflare ? Con quali pro ? Con quali contro ? Possiamo utilizzare le immagini webp condizionalmente con CloudFlare a seconda del browser compatibile o meno, senza dover usare il loro piano Business da ben 200 dollari al mese per singolo sito ?
Il browser prenderà il layout html e i fogli di stile per ricomporre il tutto, disegnando la pagina nella struttura che andremo a visualizzare (rendering).
Una pagina di 2000 elementi è più lenta da renderizzare rispetto ad una pagina di 100 elementi, così come un puzzle da 2000 pezzi è più complesso da terminare rispetto ad un puzzle da 100 pezzi.
Siamo sicuri di utilizzare un numero di elementi non troppo grandi? Siamo sicuri di non dover scaricare degli stili CSS che poi non vengono utilizzati nella pagina che stiamo vedendo? Siamo sicuri di aver impostato dei tempi di cache lato browser in modo intelligente per evitare di dover riscaricare ad ogni visita degli elementi non modificati come magari il logo della pagina? Ha senso aspettare di aver caricato tutte le risorse come immagini, font, fogli di stile e javascript e poi iniziare a fare il rendering della pagina o possiamo iniziare nel più breve tempo possibile e proseguire successivamente mentre l’utente sta visualizzando già qualcosa nel sito? Possiamo evitare di evitare lo “sfarfallamento” del layout, quel flickering e cercare di non ricomporlo in una modalità fastidiosa sotto gli occhi dell’utente?

Per ogni punto che abbiamo elencato (ben 12) abbiamo dei problemi (più o meno importanti e gravi) e delle relative soluzioni ad esse.

Rendere veloce un sito WooCommerce insomma significa analizzare tutti questi aseptti (o quanto meno quelli più importanti) ed effettuare delle operazioni che possano risolvere o migliorare sensibilmente il tempo perso per ogni operazione.

Le operazioni si differenziano principalmente in due macrocategorie, le ottimizzazioni lato server e le ottimizzazioni lato applicativo.

Vediamo insieme come si dividono le due branche e come a volte possono in parte sovrapporsi.

Ottimizzazione lato server.

Per Ottimizzazione delle performance Lato Server di intendono tutte quelle operazioni e caratteristiche che riguardano l’aspetto hardware e software lato sistemistico, di cui si dovrebbe occupare un sistemista Linux verticalizzato e specializzato sulle performance.

Ottimizzazione e dimensionamento Hardware

Ad esempio, un sistemista Linux specializzato sulle performance di WooCommerce avrà il buon senso di saper dimensionare le risorse hardware ed il server in base ad un ottimo compromesso tra costi / performance e le possibilità reali di investimento e spesa del cliente.

Certamente opterà per il giusto dimensionamento della CPU, il numero dei core, il numero dei thread, il giusto quantitativo di memoria RAM, la tecnologia dei dischi SSD o meglio ancora nVME per massimizzare la velocità di I/O sui dischi, e dunque anche sul Database MySQL ad esempio.

Avrà cura anche oltre di implementare le giuste componenti software lato server affinchè l’hardware venga utilizzato al meglio e/o che le problematiche conosciute di WooCommerce piuttosto che di altri CMS possano essere risolte con dei workaround e dei fix che richiedono magari l’installazione e la configurazione di ulteriori software per scopi ben specifici.

Normalmente le opzioni e le operazioni ricadono sempre nella scelta del giusto servizio, la giusta configurazione e la giusta integrazione con WooCommerce.

Ottimizzazione rete e kernel

Si assicurerà di aver implementato e configurato correttamente TCP BBR per migliorare le connessioni lente o quelle ad alta perdita di pacchetti come le connessioni 3G come potrai leggere in questo articolo BBR TCP: la formula magica per le prestazioni della rete.

Installazione di un Web Server leggero e veloce

Si preoccuperà di installare un server web leggero in memoria ed estremamente performante come NGINX Webserver piuttosto che il più diffuso Apache.

Ormai il mercato è maturo e la supremazia di NGINX è stata finalmente riconosciuta vedendo una tendenza estremamente crescente e una diffusione sempre maggiore.

In merito alle performance ed ai benchmark nonchè altre interessanti feature e comparazioni ti rimandiamo a questo articolo : Apache VS NGINX. Qual è il miglior server web?

Di fatto, volendo andare al sodo si ricade sempre sull’utilizzo di sistemi di software e di Cache per le diverse componenti.

Tuning Cache di MySQL o comunque del Database come InnoDB Buffer Pool Cache

InnoDB (il motore più performante di MySQL rispetto a MyISAM) mantiene un’area di archiviazione chiamata Buffer Pool per la memorizzazione nella cache di dati e indici in memoria. Sapere come funziona il Buffer Pool e sfruttarlo per mantenere in memoria i dati a cui si accede di frequente è un aspetto importante dell’ottimizzazione di MySQL.

L’ottimizzazione del database MySQL è tra i tuning più importanti in tema di performance web. Quando ci si trova ad ottimizzare MySQL ci si imbatte irreparabilmente su InnoDB.

InnoDB è senza dubbio l’engine MySQL più performante quando si tratta di gestire query di tipo SELECT. La sua configurazione prevede diversi parametri, tra cui innodb_buffer_pool_size.

InnoDB Buffer Pool indica la dimensione di RAM da dedicare per la memorizzazione di indici, cache, strutture dati e tutto ciò che ruota attorno InnoDB.

È uno dei parametri più importanti della configurazione di MySQL ed il suo valore va impostato in funzione del quantitativo di memoria RAM disponibile e dei servizi che operano sul server.

Cache di bytecode PHP come Zend OpCache

Una delle maggiori criticità riguardo i siti web è il tempo di caricamento. Uno dei modi migliori per ridurre il tempo di caricamento è abilitare sistemi di cache. Non esiste solo la cache di file HTML, OpCache infatti è una cache di opcode, che aumenta la velocità dei siti Web PHP memorizzando script precompilati bytecode nella memoria condivisa.

Mettere in cache gli script PHP significa che, la prima volta che lo script viene eseguito viene anche precompilato e salvato in memoria. Tutte le volte successive che lo script verrà richiamato non sarà necessario eseguirlo di nuovo dato che opcache ha memorizzato il codice risultante nella memoria RAM. Questo risparmio ti tempo porta miglioramenti delle prestazioni, soprattutto su siti web costantemente sotto stress.

La definizione ufficiale dice:

OPCache migliora le performance PHP immagazzinando uno script bytecode precompilato nella memoria condivisa, eliminando così la necessità per il PHP di caricare e analizzare gli script per ogni richiesta.

In altre parole, quando uno script PHP viene eseguito, è compilato in opcode, un codice comprensibile dalla macchina. OPCache immagazzina questo codice in memoria durante la prima esecuzione in modo che sia riutilizzato in seguito. La cache PHP porta così a incrementi di performance. OPCache rimpiazza APC ed è un’alternativa a XCache, un acceleratore PHP. A differenza di Memcached che lavora sul database, Opcache lavora sugli script PHP.

Questa estensione è in bundle con PHP 5.5.0 e versioni successive, ed è disponibile in PECL per le versioni di PHP 5.2, 5.3 e 5.4.

Fondamentalmente quando il sistema compila del codice in PHP, il codice leggibile dall’uomo viene convertito in linguaggio macchina e ci vuole tempo per compilare tutti gli script. Quindi se l’applicazione fa molte richieste ciclicamente, le prestazioni potrebbero essere migliorate mettendo in cache i vari script. Abilitando PHP OPcache, il processo verrà eseguito una volta e memorizzerà nella cache tutti gli script. Gli script verranno archiviati in memoria e solo gli aggiornamenti verranno compilati e continueranno a essere archiviati.

OPCACHE può darti un notevole incremento delle prestazioni e può ridurre significativamente il tempo di caricamento del sito web. PHP7 OPcache utilizza 64 MB di memoria per impostazione predefinita. Non sono necessarie librerie esterne per abilitare questa estensione.

Object Cache di WordPress

La cache ad oggetti di WP (object cache) è un meccanismo lato codice utilizzato per ridurre le hit sul database e migliorare i tempi di caricamento e le prestazioni del nostro sito. Sono definiti all’interno del file del core wp-includes/cache.php, e si possono utilizzare mediante un insieme predefinito di funzioni – simile a quelle messe a disposizione per i transient, da cui si distaccano per il fatto di essere un sistema di data storage anche per la cache, che però non è disponibile su tutti gli hosting e soprattutto richiede un plugin di cache per poter funzionare.

Si tratta di una feature avanzata che pochi programmatori conoscono, e che ancora di meno usano in modo attivo: ma molti plugin di cache e di ottimizzazione, del resto, si basano su di esso. Di default, WP Object Cache non è una forma di dato persistente, e tende a durare esclusivamente per la brevissima durata della richiesta HTTP in esame. Non vengono, quindi, memorizzati per il futuro a meno che non si installi un apposito plugin (consigliato: W3 Total Cache). Parliamo di cache lato server, e non lato client ovviamente, per cui non facciamo confusione su questo fin dall’inizio.

Il principale vantaggio dell’uso della cache ad oggi è legato al miglioramento delle prestazioni dei tempi di caricamento del sito, qualora non si riesca ad intervenire diversamente.

Lo scopo della memorizzazione nella cache degli oggetti è memorizzare nella cache i risultati delle query dal database.

Un database efficiente è uno dei fattori cruciali per un sito web veloce: WordPress è un sistema di gestione dei contenuti che dipende naturalmente dal suo database MySQL.

Ogni volta che gli utenti (o i crawler) effettuano una richiesta sul tuo sito Web, generano query di database. Se il tuo sito riceve un numero elevato di richieste al database, le query possono accumularsi rapidamente, sovraccaricando il tuo server MySQL e rallentando il tuo sito web.

La buona notizia è che WordPress ha introdotto la sua classe di caching degli oggetti molto tempo fa: era il 2005 quando la classe denominata WP_Object_Cache fu implementata nel core di WordPress.

Normalmente si può utilizzare Memcached o REDIS.IO come backend per fare lo storage dei dati della Cache ad oggetti.

Page Cache, ovvero cache di pagina di WordPress.

Memcached è uno dei meccanismi di memorizzazione nella cache che risiedono sul tuo server di hosting. Si occupa principalmente delle query del database che aiutano a ridurre il carico del database risultando in una pagina Web a caricamento rapido. Se il tuo sito Web/negozio fa molto affidamento sulle query del database, l’utilizzo di Memcached per il sito Web WordPress migliorerebbe significativamente le prestazioni e ridurrebbe il tempo di caricamento della pagina.

I giganti di Internet tra cui YouTube, Reddit, Facebook, Twitter e Wikipedia utilizzano Memcached per aumentare il tempo di caricamento della pagina. Anche Google App Engine, Microsoft Azure, IBM Bluemix e Amazon Web Services offrono il servizio Memcached tramite un’API.

Considerando la sua importanza nel migliorare e diminuire il tempo di caricamento della pagina, noi offriamo Memcached preinstallato sui nostri server di hosting WordPress gestiti. Tuttavia, a volte potrebbe essere necessario configurare la propria applicazione (WordPress) per sfruttare appieno Memcached.

Memcached viene utilizzato per velocizzare applicazioni web dinamiche come negozi di e-commerce, siti web di registrazione/accesso, ecc. riducendo il carico del database. Memorizza il risultato elaborato in modo che ogni volta che un visitatore richiede nuovamente la stessa query, Memcached può rispondere a quella invece di elaborare la query e rispondere. Mantenendo il server meno occupato, i tuoi visitatori sperimenteranno un tempo di caricamento più rapido e una migliore esperienza utente.

C’è una storia del mondo reale interessante e divertente su GitHub, dai una lettura per capire il tipico caso d’uso di Memcached.

Full Page Cache statica come Varnish Cache, NGINX FastCGI Cache, LsCache o CloudFlare Cache

Sicuramente la full page statica lato server è la componente più apprezzabile in termini di performance per i contenuti che sono “uguali per tutti”, ovvero quelli di un blog, di una testata giornalistica o di un ecommerce come WooCommerce se non si è loggati.

Infatti, una full page cache statica permette di memorizzare il contenuto di una page statica e riproporla a chi la richiese senza andare ad azionare PHP e le query verso il database MySQL, risparmiando importanti cicli macchina e dunque permettendo come abbiamo visto in alcuni casi un tempo di caricamento da 12 secondi a 1 secondo semplicemente cachando correttamente con Varnish o NGINX FastCGI Cache.

Ovviamente non è la panacea di tutti i mali, perchè se il sito è lento, una volta che l’utente decide di loggarsi magari per avere un listino prezzi riservato, ecco qui che il sito inizia ad andare alla reale velocità di come sarebbe andato senza Cache.

Ma già poter ottenere una velocità eccellente da non loggati, cosa che avviene nella maggior parte degli ecommerce dove ci si logga solo al checkout, significa fare la differenza tra un ecommerce che a fine anno ha fatturato centinaia di migliaia di euro e un ecommerce che chiude il bilancio con pochi spiccioli.

Le soluzioni attualmente presenti sul mercato maggiormente diffuse sono: Varnish Cache di cui abbiamo ampiamente parlato qui Varnish Hosting, NGINX FastCGI Cache che a nostro avviso è un modo rapido e veloce per usare una Full Page Cache se non si hanno gli attributi per usare Varnish in modo corretto e il suo linguaggio di configurazione VCL, LsCache che è una cache piuttosto nuova che ben si adatta al webserver LiteSpeed o la versione free Open LiteSpeed e CloudFlare Cache.

LsCache

In merito a LsCache possiamo dire che è un prodotto limitato e limitante che va bene solo su WebServer commerciale LiteSpeed, non ha un linguaggio di programmazione interno per poter lavorare con regole molto elaborate e dunque va bene se non si hanno esigenze particolari come quelle di separare cache in base al cookie, allo user agent, e tanta altra roba molto interessante che LSCache non fa.

NGINX FastCGI Cache

NGINX FastCGI Cache sarebbe anche promettente se non fosse che alcune delle funzionalità (vedi ad esempio la possibilità di fare PURGE ALL per pulire tutta la cache) sono presenti solo nella versione commerciale Nginx Plus o NGINX+ che non è sicuramente appetibile a livello di costi per la sottoscrizione commerciale annuale.

Come già accennato per LSCache anche NGINX FastCGI Cache non dispone di un linguaggio di configurazione che permette di effettuare virtuosismi tecnici ed esercizi di stile per raggiungere gli obiettivi di caching più complessi ed ambiti.

CloudFlare Cache

CloudFlare Cache è un servizio commerciale Software as a Service che comporta diversi piani sottoscrivibili che vanno dal piano Free, al piano Enterprise da 200 dollari al mese per singolo sito.

Di default CloudFlare non offre una full page Cache, ovvero di fatto non cacha l’HTML come pagine, post, prodotti, ma si limita a cachare le risorse multimediali come immagini, JS e CSS. Per ottenere le funzioni di caching HTML bisogna necessariamente avere la possibilità di fare esclusione dei Cookie e lavorare con la sottoscrizione di 200 dollari al mese per singolo sito.

Come già detto in fase introduttiva, il costo può essere sicuramente abbordabile ed addirittura economico per aziende che sono già consolidate e riescono a fare un utile proporzionato all’investimento su questo servizio ormai leader del mercato che include numerose opzioni come ad esempio la protezione dei DDOS.

Tuttavia abbiamo notato che spesso si fa confusione e la fanno anche gli hosting provider ed esperti del settore, credendo che il piano free faccia da Full Page Cache, e dunque ecco il fiorire di aziende di hosting che reclamizzano una CDN lasciando intendere una full page cache e vi invitano a comprare la loro soluzione di hosting più costosa reclamizzando la disponibilità di CloudFlare che loro installano in versione Free e che non avendo funzionalità di Full Page Cache non vi migliora minimamente la velocità.

Se volete capirne di più in merito a questo errore madornale leggete pure questo articolo : CloudFlare CDN cache HTML ?

Varnish Cache

Una Cache statica lato Server direbbe qualcuno, sarebbe più corretto dire LA cache statica. Utilizzata dai siti più trafficati e gettonati dal mondo è anche l’unica Cache statica lato server che anche nella versione Free include praticamente tutte le funzioni necessarie per realizzare complesse regole di caching nel mondo reale.

Alcune mancanze che invece si trovano esclusivamente nella versione commerciale Varnish Plus possono essere sapientemente colmate utilizzando sapientemente in “combo” configurazioni ad-hoc di NGINX Webserver.

Probabilmente senza centinaia di ore passate a sviluppare le migliori configurazioni Varnish e Combo, oggi saremmo uno dei tanti hosting e non avremmo ottenuto i numeri ed i successi che ci hanno permesso di arrivare a reggere centinaia di milioni di pagine viste al mese e picchi di centinaia di migliaia di utenti al minuto senza crash.

Se volete conoscere qualcosa in merito a Varnish vi consigliamo questa lettura : Hosting WordPress per testate giornalistiche ed editoria online.

A prescindere dalla soluzione che vogliate adottare (noi consigliamo SEMPRE Varnish) o CloudFlare per traffico intercontinentale, queste soluzioni vanno sempre opportunamente configurate ad hoc per la vostra installazione WooCommerce. Bisogna infatti poter gestire ed escludere i cookie di sessione, alcune pagine specifiche come quelle riservate all’utente, il carrello, il checkout, la wishlist onde evitare imbarazzanti collisioni di pagine, ovvero l’utente A arriva al carrello e vede i prodotti messi nel carrello dell’utente B e allo stesso modo gli altri visitatori iniziano a vedere contenuti non loro.

Il tutto ovviamente si traduce in un abbandono del carrello e una perdita di vendite e fatturato.

Vanno gestiti i file XML, le sitemap, i feed di Google, i timeout se lavoriamo con software di importazione di magazzino e tante tante tante altre cose.

Verrebbe da dire all’utente novizio, “installo Varnish e lo configuro” ma poi si finisce sempre per creare danni di proporzioni mastodontiche, per cui è sempre meglio affidarsi a chi come noi vive solo di questo.

BLOG