Uno sguardo al moderno stack di server WordPress

Ricordi quando potevi eseguire un sito Web WordPress "veloce" solo con un server Apache e PHP? Sì, quelli erano i giorni! Le cose erano molto meno complicate allora.

Ora, tutto deve caricarsi alla velocità della luce! I visitatori non hanno le stesse aspettative sui tempi di caricamento di una volta. Un sito web lento può avere serie implicazioni per te o per il tuo cliente.

Ulteriori letture su SmashingMag:

• Autorizzazioni e proprietà del filesystem WordPress corrette
• Spostare un sito Web WordPress senza problemi
• Come sviluppare WordPress in locale con MAMP
• Metodi di memorizzazione nella cache fai-da-te con WordPress

Di conseguenza, lo stack del server WordPress ha dovuto evolversi nel corso degli anni per stare al passo con questa esigenza di velocità. Come parte di questa evoluzione, è stato necessario aggiungere alcune marce al suo motore. Anche alcune delle marce più vecchie hanno dovuto cambiare.

Il risultato è che lo stack del server di WordPress ha un aspetto molto diverso oggi rispetto a qualche anno fa. Per capirlo meglio, esploreremo in dettaglio questo nuovo stack. Vedrai come i vari pezzi si incastrano per creare un sito Web WordPress veloce.

Panoramica

Prima di immergerci, rimpiccioliamo e osserviamo il quadro generale. Che aspetto ha questo nuovo stack di server WordPress? Bene, ecco la risposta:

Il diagramma sopra offre una buona panoramica di come appare il moderno stack di server WordPress. Ad alto livello, possiamo dividere ciò che sta accadendo in tre aree:

• il ciclo richiesta-risposta tra il browser e WordPress;
• WordPress (che è uno script che esegue il runtime PHP);
• il ciclo del risultato della query tra WordPress e il database MySQL.

Il ruolo del moderno stack di server WordPress è ottimizzare queste tre aree. Queste ottimizzazioni sono ciò che rende tutto più veloce. E la parte migliore è che ci sono diversi modi per farlo. (Sìì!)

Nella maggior parte dei casi, queste ottimizzazioni comportano l'installazione di nuovi servizi sul tuo server. A volte, questi servizi avranno bisogno dell'aiuto di un plugin per interagire con WordPress. Ci saranno anche momenti in cui puoi cavartela semplicemente installando un plug-in. Vedrai molte opzioni diverse in questo articolo.

Il ciclo richiesta-risposta

Tutto inizia con il browser. Supponiamo che tu voglia visualizzare la home page di modern.wordpress-stack.org . Il tuo browser inizierà inviando una richiesta HTTP al server web che lo ospita. All'altra estremità, il server web prenderà la tua richiesta e la trasformerà in una risposta HTTP.

Questa prima risposta dovrebbe essere sempre il contenuto HTML della home page di modern.wordpress-stack.org (a meno che non ci sia un errore). Tuttavia, il lavoro del tuo browser non è terminato. No, quella home page ha ancora bisogno di più file, i più comuni sono CSS, JavaScript e file di immagini.

Quindi, il browser invierà richieste per quei file. Il server web risponderà con i file richiesti (di nuovo, purché non ci siano errori). Questo ciclo continuerà finché il browser non avrà informazioni sufficienti per eseguire il rendering della home page. Più veloce si verifica questo ciclo, più veloce sembrerà il caricamento del sito web.

Ora, questa è un'ovvia semplificazione, ma è così che funzionano le cose per la maggior parte dei siti Web WordPress.

Ottimizzazione del ciclo richiesta-risposta

Va bene, questo ci porta alla domanda ovvia, come possiamo fare in modo che un server web esegua questo ciclo più velocemente? Questa è un'ottima domanda ed è parte del motivo per cui esiste il moderno stack di server WordPress.

Lo stack esiste perché non puoi semplicemente rendere più veloce un server web. Un server web è anche un dispatcher. Può ricevere una richiesta e semplicemente inoltrarla ad altri servizi.

Questi altri servizi sono spesso il collo di bottiglia di questo ciclo di richiesta-risposta. Con WordPress, questo collo di bottiglia è PHP, motivo per cui l'ottimizzazione del ciclo richiesta-risposta si riduce a due cose. Vogliamo che il server web:

• ricevere il minor numero di richieste possibile,
• inoltra il minor numero possibile di richieste a PHP.

Il moderno stack di server WordPress si concentra su quest'ultimo. Vuole inoltrare il minor numero possibile di richieste a PHP. Questo sarà l'obiettivo principale per ottimizzare lo stack.

Ci concentriamo sul secondo obiettivo perché lo stack non può fare molto per il primo; non ha alcun impatto diretto su di esso. Il secondo è affrontato o dalla configurazione del web server o dalle moderne tecniche di sviluppo.

Stack elementi per il ciclo richiesta-risposta

Quindi, quali sono gli elementi dello stack che ci aiuteranno a ridurre le richieste inoltrate a PHP? Bene, due elementi dello stack in particolare ci aiuteranno a raggiungere questo obiettivo: il server web e la cache HTTP.

Server web

Abbiamo già parlato un po' di server web. Ci sono tre grandi attori nello spazio del server web:

• Apache
• Servizi di informazione Internet (IIS)
• nginx

Insieme, rappresentano oltre il 90% della quota di mercato dei server Web su Internet. Ci concentreremo su Apache e nginx. Sebbene IIS possa essere utilizzato per eseguire WordPress, non è comune perché è disponibile solo per Windows e la maggior parte dei server WordPress utilizza Linux.

Questo ci lascia con Apache e nginx. Per tutta la vita di WordPress, Apache è stato il server web consigliato. Avevamo lo stack LAMP (Linux, Apache, MySQL e PHP), che eseguiva WordPress sia sul computer che sul server.

Ma dietro le quinte, le cose stavano cambiando. C'era un nuovo giocatore in città, e il suo nome era nginx. Automattic e WordPress.com lo utilizzano dal 2008. È il server Web che gestisce la percentuale più alta di siti Web ad alto traffico (molti dei quali eseguono WordPress). Ecco perché molte società di hosting di fascia alta e le migliori agenzie di WordPress lo usano come server web.

Non è che Apache sia un cattivo server web. Ci sono esperti di Apache che possono farlo funzionare alla grande con molto traffico. Semplicemente non funziona altrettanto bene immediatamente o con la configurazione standard di WordPress.

Nel frattempo, l'unico scopo di nginx è gestire molto traffico. Ecco perché Igor Sysoev ha iniziato il progetto quando lavorava in Rambler.

Uno dei motivi per cui nginx gestisce meglio più traffico è che utilizza FastCGI per comunicare con PHP. Cos'è FastCGI? È un protocollo che consente a PHP di funzionare come servizio separato dal server web.

Apache non lo fa per impostazione predefinita. Ogni volta che il server web riceve una richiesta, deve avviare un processo di runtime PHP, anche per immagini, JavaScript e CSS. Ciò riduce il numero di richieste che il server può gestire e la velocità con cui può gestirle.

Questo va contro uno degli obiettivi del moderno stack di server WordPress, che abbiamo visto in precedenza. Lo stack deve mantenere il tempo del ciclo richiesta-risposta il più basso possibile. Caricare PHP per ogni richiesta, anche quando non ne ha bisogno, va contro questo obiettivo. Quindi, se usi Apache, guarda FastCGI.

HTTP/2 è un'altra importante funzionalità del server Web che dovresti conoscere. È la prossima versione di HTTP, il protocollo che alimenta il nostro intero ciclo di richiesta-risposta.

Prima dell'arrivo di HTTP/2, un browser poteva avere solo sei connessioni al server web. E ogni connessione poteva gestire solo una richiesta alla volta. Quindi, in pratica, un ciclo di richiesta-risposta era limitato a sei richieste per ciclo.

Questo è un vero problema. La maggior parte dei siti Web ha dozzine di richieste nel proprio ciclo. Gli sviluppatori e gli amministratori di sistema hanno trovato modi intelligenti per aggirare questa limitazione.

Una delle soluzioni alternative più note è la pratica di combinare file CSS e JavaScript. In uno scenario ideale, ciò ridurrebbe a due il numero totale di richieste di file CSS e JavaScript: una per JavaScript e una per CSS.

Questo non è necessario con HTTP/2. HTTP/2 consente un numero illimitato di richieste per connessione. Ciò consente che tutte le richieste extra dopo la risposta HTML iniziale avvengano contemporaneamente.

Questo ha enormi implicazioni sulle prestazioni. Gran parte del lavoro di ottimizzazione dello stack del server è incentrato sul ciclo richiesta-risposta. Riducendo il numero di cicli a una manciata, HTTP/2 ha svolto un'enorme quantità di lavoro per noi.

Cache HTTP

La parte più importante del moderno stack di server WordPress è la cache HTTP. Nel mondo di WordPress, chiamiamo anche questa pagina cache. Lo scopo della cache HTTP è memorizzare nella cache le risposte alle richieste. Cosa significa questo?

Bene, torniamo al nostro esempio precedente. Il browser invia una richiesta per la home page di modern.wordpress-stack.org e il server web riceve quella richiesta e la inoltra a PHP.

Il problema con questo scenario è che il server web è stupido. Inoltrerà sempre tutte le richieste che riceve a PHP, indipendentemente dal fatto che la maggior parte delle richieste genererebbe la stessa risposta.

Questo è esattamente ciò che accade quando i visitatori non hanno effettuato l'accesso. Al server web, sono tutte richieste diverse, ma non importa. Li inoltrerà tutti a PHP, che genererà la stessa risposta per tutti loro.

È terribile! Come abbiamo visto in precedenza, PHP è il vero collo di bottiglia del nostro ciclo richiesta-risposta. Il tuo browser non può inviare le sue richieste di follow-up finché non riceve la risposta iniziale della home page. Non possiamo fare in modo che il server web inoltri tutto a PHP per impostazione predefinita.

È qui che entra in gioco la cache HTTP. Si trova tra il server Web e PHP. Il suo compito è controllare ogni richiesta che il server web riceve e cercare una risposta memorizzata nella cache. Se non ce n'è, inoltrerà la richiesta a PHP e quindi memorizzerà nella cache la risposta generata da PHP.

Ciò riduce drasticamente il tempo del ciclo richiesta-risposta, velocizzando il caricamento del sito web. Consente inoltre al server Web di gestire più richieste simultanee senza esplodere.

I diversi gusti della cache HTTP

A questo punto, dovresti chiederti: "Come posso portare questo bambino sul mio server il prima possibile?!" La buona notizia è che l'installazione di una cache HTTP su un server WordPress è abbastanza semplice. È il componente con la più ampia gamma di opzioni.

Installa un plug-in di cache di pagina

Il modo più semplice è installare un plug-in per la memorizzazione nella cache delle pagine. Hai alcune opzioni tra cui scegliere:

• Bacheca
• Ipercache
• Abilitatore di cache
• WP Rocket
• Supercache WP
• Cache totale W3

Tutti tranne WP Rocket sono disponibili come plugin gratuiti nella directory di WordPress. Quindi, puoi installarne uno e provarlo subito. Detto questo, dei quattro plugin, il migliore è WP Rocket. Sebbene sia un plug-in a pagamento, fa molto di più della semplice creazione di una cache HTTP. Questi altri vantaggi amplificano il lavoro svolto dalla cache HTTP.

Come funziona un plug-in di memorizzazione nella cache delle pagine?

Tutti questi plugin sfruttano un drop-in che WordPress ha reso disponibile per la memorizzazione nella cache. Questo drop-in di memorizzazione nella cache consente ai plugin di creare un sistema di cache HTTP all'interno di WordPress. Il drop-in di memorizzazione nella cache ha bisogno di due cose per funzionare.

Innanzitutto, il file drop-in advanced-cache.php deve trovarsi nella cartella wp-content . Questo è il file vero e proprio. Ma a differenza della maggior parte dei drop-in di WordPress, questo non si attiva per impostazione predefinita. WordPress ha anche bisogno che la costante WP_CACHE sia true per caricare il drop-in. Nella maggior parte dei casi, lo imposteresti in wp-config.php .

Il diagramma sopra mostra cosa succede quando abiliti il ​​drop-in con un plug-in di memorizzazione nella cache. WordPress carica il drop-in in wp-settings.php durante il processo di caricamento. Questo è abbastanza presto nel processo che WordPress non ha ancora fatto nulla di dispendioso in termini di tempo.

Il plug-in di memorizzazione nella cache verificherà quindi se ha già memorizzato nella cache la risposta alla richiesta. In tal caso, restituirà quella risposta memorizzata nella cache. In caso contrario, attiverà il buffering dell'output PHP e WordPress continuerà a caricare.

Ora, il buffering dell'output è un sistema interessante. Quello che fa è catturare tutto l'output da uno script PHP in una variabile stringa fino a quando non si verifica una delle due cose:

• dici a PHP di interrompere il buffering del suo output usando una delle funzioni integrate,
• lo script PHP termina e deve restituire una risposta al browser.

Il plug-in di memorizzazione nella cache conta su quest'ultimo scenario. Vuole che WordPress faccia le sue cose e poi metta in cache l'intero output prima che PHP lo rispedisca al browser. Puoi vedere il processo nel diagramma qui sotto.

Chiedi al server web di farlo

L'opzione successiva consiste nell'aggiungere una cache HTTP a livello di server web. Il modo in cui funziona è che il server web memorizzerà nella cache tutte le risposte alle richieste che vengono inoltrate a PHP. Questa soluzione è migliore di un plug-in di memorizzazione nella cache perché non ha bisogno di toccare PHP.

Il diagramma sopra fornisce una panoramica di cosa sta succedendo nel server web. Il server web riceve una richiesta e controlla con la cache HTTP. Se una risposta è già stata memorizzata nella cache, la cache HTTP la rispedirà indietro.

In caso contrario, inoltrerà la richiesta al modulo PHP (solitamente FastCGI). Passerà la richiesta a WordPress in modo che possa generare una risposta. Il modulo della cache HTTP memorizzerà quindi nella cache quella risposta sulla via del ritorno.

Sia Apache che nginx hanno la possibilità di aggiungere un sistema di cache HTTP. Quello di nginx è integrato. Quello di Apache è un modulo separato che devi aggiungere alla tua installazione di Apache.

Non ci sono molte informazioni su come utilizzare il modulo Apache con PHP o WordPress. Ciò potrebbe essere dovuto al fatto che non è popolare tra la folla di Apache, o forse perché ha alcuni problemi. C'è almeno un problema di vecchia data che è ancora aperto.

Nel frattempo, il sistema di cache HTTP di nginx è robusto e ben documentato. Puoi usarlo come una normale cache HTTP o come una micro-cache più piccola ma efficace. È solo un motivo in più per cui nginx è il server web preferito al giorno d'oggi.

Aggiungi vernice alla pila

Cos'è la vernice? È un server cache HTTP dedicato (o, come amano chiamarlo i suoi sviluppatori, acceleratore HTTP). La maggior parte dei siti Web ad alto traffico e delle società di hosting premium lo utilizzano come soluzione di cache HTTP.

Lo usano perché è potente e offre la massima flessibilità. Varnish ha un proprio linguaggio di configurazione, chiamato VCL. Ti consente di controllare ogni elemento del processo di memorizzazione nella cache. Varnish include anche molti strumenti per analizzare cosa sta facendo la cache e come sta funzionando.

Queste sono le principali differenze tra il suo utilizzo e il solo utilizzo della cache HTTP del server Web integrata. La cache HTTP del server Web integrata è super performante ma anche piuttosto semplice. Non hai molto controllo oltre a poche opzioni di configurazione.

Tuttavia, questa potenza e flessibilità hanno un prezzo. Varnish è anche l'opzione cache HTTP più complicata. Non fa altro che memorizzare nella cache le risposte HTTP. Non gestisce la terminazione SSL, cosa che la maggior parte degli sviluppatori di WordPress desidera (o dovrebbe desiderare). Ciò significa che il nostro moderno stack di server WordPress sarà più complesso quando lo utilizzeremo.

Il diagramma sopra illustra questa ulteriore complessità. Ora abbiamo altri due componenti nel nostro stack di server WordPress: vernice e un proxy inverso.

Il proxy inverso è lì per superare la limitazione che Varnish ha con SSL. Si trova di fronte a Varnish e decodifica le richieste che il nostro server riceve. Puoi anche chiamare questo tipo di proxy inverso un proxy di terminazione SSL. Il proxy invia quindi queste richieste decrittografate a Varnish per l'elaborazione.

Una volta che una richiesta raggiunge Varnish, i file di configurazione VCL entrano in azione. Sono il cervello di Varnish. Ad esempio, gli dicono come:

• analizzare, ripulire e modificare le richieste in arrivo;
• cercare una risposta memorizzata nella cache;
• analizzare, ripulire e modificare le risposte di ritorno da WordPress;
• memorizzare nella cache queste risposte di ritorno;
• gestire una richiesta di rimozione di una o più risposte dalla cache.

Quest'ultimo è particolarmente importante. Lasciato a se stesso, Varnish non ha modo di sapere quando WordPress vuole rimuovere una pagina dalla cache. Quindi, per impostazione predefinita, se apporti modifiche a un post e lo aggiorni, i visitatori continueranno a vedere la stessa pagina memorizzata nella cache. Fortunatamente per noi, esiste un plugin che rimuove le pagine dalla cache di Varnish.

WordPress

Va bene, la nostra richiesta per la home page di modern.wordpress-stack.org ha colpito WordPress. Ha attraversato il ciclo di richiesta-risposta che abbiamo appena trattato. La cache HTTP ha fatto tutto il possibile per trovare una risposta HTTP da inviare indietro.

Ma non c'era una risposta HTTP memorizzata nella cache da inviare al browser. A quel punto, la cache HTTP non aveva altra scelta. Doveva inoltrare la richiesta HTTP a WordPress.

Ora è tutto nelle mani di WordPress. WordPress deve trasformare la nostra richiesta HTTP in una risposta HTTP e rispedirla alla cache HTTP. Come abbiamo visto in precedenza, questo è il collo di bottiglia principale del nostro intero stack di server WordPress moderno.

La causa di questo collo di bottiglia è duplice. WordPress ha molto codice PHP da eseguire. Questo richiede molto tempo e più PHP è lento a farlo, più tempo impiega.

L'altro collo di bottiglia sono le query al database che WordPress deve eseguire. Le query al database sono operazioni costose. Più ce ne sono, più WordPress diventa lento. Questo sarà il fulcro dell'ultima sezione sul ciclo dei risultati della query.

Ottimizzazione del runtime di PHP

Torniamo a PHP. Al momento, WordPress ha un requisito minimo di PHP 5.2. Questa versione di PHP ha quasi 10 anni! (Il team PHP ha smesso di supportarlo nel 2011.)

Il team PHP non è rimasto inattivo per tutti questi anni. Sono stati apportati numerosi miglioramenti alle prestazioni, soprattutto negli ultimi anni. Diamo un'occhiata a cosa puoi fare per ottimizzarlo al giorno d'oggi.

Usa l'ultima versione di PHP

La cosa più semplice che puoi fare è aggiornare la tua versione di PHP. Le versioni 5.4, 5.5 e 5.6 hanno tutte visto miglioramenti delle prestazioni. Il più grande miglioramento è stato da 5,3 a 5,4. Passare ad esso ha aumentato le prestazioni di WordPress di una quantità decente.

Installa Opcode Caching

La memorizzazione nella cache di Opcode è un altro modo per velocizzare PHP. Come linguaggio di scripting lato server, PHP ha un grosso difetto: ha bisogno di compilare uno script PHP ogni volta che lo esegue.

La soluzione a questo problema è memorizzare nella cache il codice PHP compilato. In questo modo, PHP non deve compilarlo ogni volta che lo esegue. Questo è il lavoro della cache del codice operativo.

Prima di PHP 5.5, PHP non veniva fornito in bundle con una cache di codice operativo. Dovevi installarlo tu stesso sul server. Questo è un altro motivo per cui è meglio usare una versione più recente di PHP.

Passa a un compilatore di nuova generazione

L'ultima cosa che puoi fare è passare a uno dei due compilatori di nuova generazione: HHVM di Facebook o PHP 7, l'ultima versione di PHP. (Perché PHP 7? È una lunga storia.)

Facebook e il team PHP hanno creato questi due compilatori da zero. Volevano sfruttare strategie di compilazione più moderne. HHVM utilizza la compilazione just-in-time, mentre PHP 7 utilizza la compilazione anticipata. Entrambi offrono incredibili miglioramenti delle prestazioni rispetto al buon vecchio PHP 5.

HHVM è stato il primo ad arrivare sulla scena alcuni anni fa. Molti host di alto livello hanno avuto molto successo con esso, offrendolo come compilatore PHP principale.

Vale la pena sottolineare, tuttavia, che HHVM non è un compilatore PHP ufficiale. Non è compatibile al 100% con PHP. Il motivo è che HHVM non è progettato solo per supportare PHP; è anche un compilatore per il linguaggio di programmazione Hack di Facebook.

PHP 7 è un compilatore PHP ufficiale. Non esiste da molto tempo. Il team PHP lo ha rilasciato a dicembre del 2015. Ciò non ha impedito ad alcune società di hosting WordPress di supportarlo già.

La buona notizia è che WordPress stesso è compatibile al 100% con entrambi i compilatori! La cattiva notizia è che non tutti i plugin e i temi lo sono, perché la versione minima di PHP per WordPress è ancora 5.2.

Niente obbliga gli autori a far funzionare i loro plugin o temi con questi compilatori. Quindi, non puoi andare all in con uno di loro. Il tuo stack dovrebbe sempre ricadere su PHP 5.

Ciclo Query-Risultato

A questo punto, il runtime PHP esamina tutti i file PHP di WordPress e li esegue. Tuttavia, questi file PHP di WordPress non contengono dati. Contengono solo il codice WordPress.

Il problema è che WordPress memorizza tutti i suoi dati in un database MySQL. Quindi, per arrivarci, il runtime PHP deve interrogare quel database. Il server MySQL restituisce il risultato di quella query e il runtime PHP continua quindi a eseguire i file PHP di WordPress... beh, fino a quando non avrà bisogno di nuovo di dati.

Questo avanti e indietro può accadere da poche dozzine di volte a poche centinaia di volte. (Potresti parlare con il tuo sviluppatore se è quest'ultimo!) Ecco perché è un grosso collo di bottiglia.

Ottimizzazione del ciclo Query-Risultato

L'obiettivo di ottimizzazione qui è accelerare il tempo di esecuzione dei file WordPress da PHP. È qui che le query del database sono problematiche. Tendono a richiedere più tempo rispetto alla semplice esecuzione di codice PHP (a meno che il tuo codice non stia facendo qualcosa di scandaloso).

Il modo più ovvio per risolvere questo problema è ridurre il numero di query che WordPress deve eseguire. E ne vale sempre la pena! Ma non è qualcosa con cui il moderno stack di server WordPress può aiutare.

Potremmo non essere in grado di ridurre il numero di query che WordPress fa, ma non siamo nemmeno a corto di opzioni. Ci sono ancora due modi in cui lo stack può aiutarci a ottimizzare il ciclo dei risultati della query. In primo luogo, può ridurre il numero di query fatte al database. E per quelle query che arrivano al database, può ridurre il tempo necessario per eseguirle.

Queste due opzioni hanno entrambe lo scopo di fare la stessa cosa: fare in modo che PHP aspetti il ​​meno possibile i risultati dal database, il che renderà WordPress stesso più veloce.

Stack elementi per il ciclo query-risultato

Diamo un'occhiata ai diversi elementi dello stack coinvolti nel ciclo dei risultati della query. Questa parte della pila è meno complessa. Ma coinvolge ancora più di un componente, vale a dire il server del database MySQL e la cache degli oggetti.

Server di database MySQL

Alcuni anni fa, un server di database MySQL avrebbe significato la stessa cosa per tutti. Era un server con installato il server MySQL. Ma le cose sono cambiate molto negli ultimi anni.

Vari gruppi non erano contenti di come Oracle stesse gestendo il progetto MySQL. Quindi, ogni gruppo lo ha biforcato e ha creato la propria versione che potresti invece "inserire". Il risultato è che ora ci sono diversi server di database MySQL.

Il nuovo server MySQL "ufficiale" è il server MariaDB. È la versione del server MySQL sviluppata dalla comunità. La comunità prevede di mantenere la piena compatibilità con il progetto del server MySQL.

Un'altra popolare alternativa a MySQL è il server Percona. A differenza di MariaDB, Percona è più un ramo di MySQL. I suoi sviluppatori non sono contrari al progetto MySQL stesso; vogliono solo concentrarsi sul miglioramento delle prestazioni di MySQL. Il team di MariaDB ha successivamente unito alcuni di questi miglioramenti delle prestazioni nel progetto MariaDB.

Alla fine della giornata, puoi scegliere quello che preferisci. Non c'è differenza di prestazioni tra un server Percona e un server MariaDB (per la maggior parte di noi comunque). Entrambi funzionano meglio di MySQL. Percona, tuttavia, mantiene una maggiore compatibilità con il progetto Oracle.

Ciò che influisce sulle prestazioni è il motore di archiviazione utilizzato dal database di WordPress. Il motore di archiviazione controlla il modo in cui il server di database gestisce i dati archiviati. È inoltre possibile impostare un motore di archiviazione diverso per la tabella del database; non è necessario utilizzare lo stesso per l'intero database.

Un server di database ha diversi motori di archiviazione. Non li esamineremo tutti. Solo due ci interessano: InnoDB e MyISAM.

Per impostazione predefinita, WordPress utilizza il motore di database MySQL predefinito. Prima di MySQL 5.5, quel motore era MyISAM. Se gestisci un piccolo sito Web WordPress, MyISAM va bene. MyISAM incontra problemi di prestazioni una volta che le dimensioni di un sito Web aumentano. A quel punto, InnoDB è l'unica scelta per un motore di database.

L'unico problema con InnoDB è che richiede un po' di messa a punto per funzionare al meglio. Se stai eseguendo un server di database di grandi dimensioni, potrebbe essere necessario modificare le cose. Fortunatamente per noi, c'è uno strumento per aiutarci.

MySQLTuner è un piccolo script che analizza il tuo server di database. Genererà un rapporto e ti fornirà consigli per l'ottimizzazione.

Cache oggetti

Il peso maggiore del lavoro di ottimizzazione del ciclo dei risultati della query risiede nella cache degli oggetti. Il compito della cache degli oggetti è archiviare i dati che richiedono molto tempo per ottenere o generare. Come puoi immaginare, le query di database sono un candidato perfetto.

WordPress utilizza molto la cache degli oggetti. Diciamo che usi get_option per ottenere un'opzione dal database. WordPress interrogherà il database per quell'opzione solo una volta. Non lo interrogherà di nuovo la prossima volta che qualcuno ne avrà bisogno.

Invece, WordPress recupererà il risultato della query dalla cache degli oggetti. Questo è un passo proattivo che WordPress compie per ridurre il numero di query al database che deve fare. Ma non è una soluzione infallibile.

Mentre WordPress farà del suo meglio per sfruttare la cache degli oggetti, un plug-in o un tema non è necessario. Se un plug-in o un tema esegue molte query sul database e non memorizza nella cache i risultati, lo stack non può fare nulla al riguardo.

In questi casi, la maggior parte delle query al database proverrà dallo stesso WordPress. Quindi, otterrai un grande vantaggio dall'uso integrato di WordPress della cache degli oggetti. Ecco perché è un elemento importante del moderno stack di server WordPress.

Ora, un problema con la cache degli oggetti è che non mantiene i dati che archivia per impostazione predefinita. Memorizza solo i dati in memoria mentre PHP esegue tutti i file di WordPress. Ma una volta terminato il processo PHP, tutti i dati archiviati in memoria vengono cancellati.

Questo non è affatto l'ideale. Una cache degli oggetti potrebbe rimanere valida per molto tempo, quindi non vuoi limitarla a una singola richiesta. La soluzione consiste nell'utilizzare una cache di oggetti persistente .

Una cache di oggetti persistente spesso si presenta sotto forma di plug-in. Quel plugin utilizzerebbe il drop-in object-cache.php per fare il suo lavoro. Questo drop-in consente agli autori di plugin di modificare il comportamento predefinito della cache degli oggetti.

I plug-in collegano quindi la cache degli oggetti a un archivio dati persistente. Lo fanno sostituendo la funzionalità di recupero e salvataggio della cache degli oggetti predefinita. Invece di salvare e recuperare i dati in memoria, la cache degli oggetti lo fa da quell'archivio.

Plugin cache oggetti persistenti

Al giorno d'oggi, ci sono due popolari opzioni di archiviazione dati per la memorizzazione nella cache di oggetti persistente:

• Memcached (plugin)
• Redis (plugin)

Entrambi questi archivi di dati utilizzano la RAM per l'archiviazione, il che li rende velocissimi. In effetti, le loro prestazioni sono paragonabili a quelle della cache degli oggetti predefinita.

L'unico problema è che non vengono preinstallati sui server. E nemmeno la loro estensione PHP (che è facoltativa con Redis). È necessario installarne uno prima di poter utilizzare il plug-in WordPress corrispondente.

Quale dovresti installare? In pratica, non c'è molta differenza tra i due per la memorizzazione nella cache degli oggetti. In passato, l'opzione popolare era Memcached. Questo è cambiato negli ultimi anni. Redis ha aggiunto molte funzionalità che l'hanno resa l'opzione ideale per la memorizzazione nella cache degli oggetti.

Ottenere il tuo moderno server WordPress

Quindi, come si ottiene il proprio server? Il modo più ovvio è ottenerne uno da società di hosting WordPress di alto livello. Queste aziende vogliono rimanere in prima linea nel business dell'hosting WordPress, il che le motiva ad adottare le ultime innovazioni e tecnologie.

Ma cosa succede se ne vuoi uno senza spendere troppo? Un paio di strumenti sono disponibili per chiunque preferisca farlo da solo e pagare meno per l'hosting. Diamo un'occhiata a loro.

DebOps per WordPress

DebOps per WordPress è uno strumento che ho creato per aiutare chiunque a creare un moderno server WordPress. La sua missione è rendere il moderno stack di server WordPress disponibile a chiunque nella comunità. Ecco perché sto cercando di renderlo il più facile possibile da usare. Non hai bisogno di alcuna conoscenza di amministrazione del sistema per usarlo.

DebOps per WordPress configura un server con quanto segue:

• HHVM (fino a quando PHP 7 non diventa un repository Linux ufficiale)
• MariaDB
• nginx
• Redis
• Vernice

Lo strumento fa molto di più che configurare un server con le ultime tecnologie. Si occupa anche di proteggere il server per te. Questo è qualcosa che le persone spesso trascurano quando gestiscono il proprio server.

Easy Engine

EasyEngine è uno strumento da riga di comando progettato per aiutarti a configurare un sito Web WordPress su un server. La cosa grandiosa di EasyEngine è la sua flessibilità: puoi usarlo per configurare quasi tutte le combinazioni di tecnologie server che abbiamo visto finora.

Ad esempio, ti consente di configurare un server con HHVM o PHP 7. Ti consente di scegliere tra Memcached e Redis per il tuo archivio dati persistente. E ti consente di installare strumenti di amministrazione come phpMyAdmin.

Offre anche un gran numero di opzioni quando crea un sito Web WordPress. Puoi dirgli di configurare un sito Web con una cache HTTP utilizzando un plug-in o nginx. Tutta questa flessibilità è il motivo per cui EasyEngine è uno strumento così popolare.

Traliccio

Trellis è uno strumento sviluppato da Roots. Come DebOps, configura il server con un insieme specifico di tecnologie server:

• MariaDB
• Memcached
• nginx
• cache HTTP nginx (opzionale)
• PHP 7

Una cosa da sapere su Trellis è la sua relazione con Bedrock, un altro strumento costruito da Roots. Bedrock è una base per la strutturazione di un sito Web WordPress attorno ai principi dell'app a dodici fattori.

Il team di Roots ha creato Trellis per consentire alle persone di configurare un server che utilizza i siti Web WordPress strutturati in Bedrock. Non puoi usarlo con una normale installazione di WordPress, quindi tienilo a mente.

I tempi sono cambiati

Come puoi vedere, oggi un server WordPress ha molte più parti mobili! Ma questo non deve essere motivo di disperazione. Non è così male come sembra perché non è sempre necessario utilizzare tutte le parti.

Ecco perché gran parte di questo articolo discute come queste parti funzionano insieme. Il punto è darti la possibilità di prendere le tue decisioni. Usa questa conoscenza per decidere quali parti devi usare e quando. In questo modo anche tu avrai un sito WordPress veloce.