Come abbiamo reso WordPress più veloce dei generatori di siti statici (Caso di studio – Accelerazione di WPBeginner)

In occasione del 10° anniversario di WPBeginner, ho condiviso che l’infrastruttura di hosting di WPBeginner ha ricevuto un enorme aggiornamento grazie al nostro partner di web hosting, HostGator.

Poco dopo, ho iniziato a ricevere e-mail dai lettori che mi chiedevano di condividere i dettagli su come abbiamo reso WPBeginner velocissimo.

Sì, WPBeginner si carica più velocemente della maggior parte dei generatori di siti statici e, in alcuni casi, anche dei siti Google AMP.

In questo articolo vi mostrerò il dietro le quinte di come abbiamo reso WordPress più veloce dei generatori di siti statici e delle piattaforme CMS headless.

Nota: questo articolo è un po’ più tecnico di quelli che pubblichiamo di solito su WPBeginner. Per gli utenti non tecnici, consiglio di seguire la nostra guida definitiva su come velocizzare WordPress.

Aggiornamento: non utilizziamo più la configurazione condivisa in questo articolo. Siamo invece passati interamente alla piattaforma Google Cloud gestita da SiteGround. Abbiamo ottenuto gli stessi risultati in termini di velocità e abbiamo sbloccato prestazioni di back-end ancora più veloci. Leggete perché siamo passati a SiteGround.

Il contesto

Ultimamente WordPress sta ricevendo una cattiva reputazione da parte degli sviluppatori “moderni” che dicono che WordPress è lento.

L’affermazione è solitamente seguita da: dovreste passare a un generatore di siti statici JAMstack come GatsbyJS. Altri, nel mondo delle imprese, dicono che si dovrebbe passare a un CMS headless come Contentful.

Molti dei miei amici imprenditori di successo hanno iniziato a chiedermi se questo fosse vero.

Alcuni hanno addirittura iniziato il processo di migrazione a un CMS headless perché hanno letto casi di studio su come altri hanno ottenuto enormi miglioramenti di velocità passando da WordPress a generatori di siti statici.

Questo è stato molto frustrante per me, perché sapevo che stavano sprecando decine di migliaia di dollari in costi di migrazione. Per non parlare degli infiniti costi di personalizzazione che si accumuleranno in futuro.

Ho quindi accettato la sfida di dimostrare che un sito di contenuti WordPress di grandi dimensioni come WPBeginner può caricarsi altrettanto velocemente, se non più velocemente, della maggior parte dei moderni generatori di siti statici.

Potete chiamarmi vecchia scuola, ma in fin dei conti un sito statico è solo una pagina che si carica dalla cache.

Risultati

Prima di passare all’esatta infrastruttura di hosting WordPress, alle configurazioni del server e ai plugin, credo sia utile condividere i risultati.

Ecco la velocità di caricamento della home page di WPBeginner su Pingdom dal loro server di Washington, DC:

A seconda dell’ora del giorno e del luogo in cui si effettua il controllo, questo risultato varia tra i 400 e i 700 ms, il che è piuttosto veloce per una homepage.

Ecco un test che ho eseguito per una pagina di un singolo post, dato che ha immagini più grandi e più contenuti:

Abbiamo anche ottenuto un punteggio perfetto di “100” nel test di velocità della pagina di Google per desktop. Anche se abbiamo un certo margine di miglioramento nel punteggio per i dispositivi mobili.

I risultati di cui sopra si riferiscono alle pagine memorizzate nella cache, che è ciò che i nostri lettori e i bot dei motori di ricerca ottengono quando visualizzano il nostro sito web. Il tempo di caricamento percepito di WPBeginner è quasi istantaneo (per saperne di più).

A titolo di confronto, ecco i risultati del test di velocità per la homepage di Gatsby. Si tratta di un popolare generatore di siti statici di cui molti sviluppatori vanno matti:

Ecco il risultato del test di velocità della homepage di Netlify, un popolare host di siti statici che molti sviluppatori raccomandano. Si noti che il numero di richieste è dimezzato e la dimensione della pagina è pari al 30% di quella di WPBeginner, ma il caricamento è comunque più lento della nostra homepage.

La velocità della homepage di Contentful, il CMS headless che è “il modo in cui le aziende offrono esperienze digitali migliori”, non è affatto ottimizzata. È stato il sito web più lento che abbiamo testato.

Condivido queste statistiche non per screditare gli altri framework, ma piuttosto per far capire che non tutte le novità sono così brillanti come possono sembrare.

WordPress, con un’infrastruttura di hosting e ottimizzazioni adeguate, può essere altrettanto veloce di qualsiasi generatore di siti statici. Inoltre, nessun’altra piattaforma si avvicina al livello di flessibilità che WordPress offre agli imprenditori grazie al suo ampio ecosistema di plugin e temi.

Infrastruttura di hosting WPBeginner

Quando si parla di velocità di un sito web, nulla gioca un ruolo più importante dell’infrastruttura di hosting.

Come molti di voi già sanno, sono cliente di HostGator dal 2007. Ho aperto il blog WPBeginner nel 2009 su un piccolo account di hosting condiviso di HostGator.

Man mano che il nostro sito web cresceva, siamo passati al loro hosting VPS e poi ai server dedicati.

Negli ultimi dieci anni ho avuto la possibilità di lavorare a stretto contatto con molti membri del loro team, che sono diventati parte integrante della famiglia WPBeginner.

Così, quando ho accettato la sfida di rendere WPBeginner più veloce dei generatori di siti statici, mi sono rivolto a loro per un aiuto.

Ho condiviso la mia visione con il loro team di leadership e si sono offerti di aiutarmi a creare una configurazione di hosting aziendale unica nel suo genere per WPBeginner.

Hanno messo i migliori ingegneri dei team di Bluehost e HostGator a lavorare a stretto contatto con me per rendere WPBeginner velocissimo.

Ecco una panoramica di come si presenta la configurazione di hosting di WPBeginner:

Come potete vedere, si tratta di una configurazione multi-server distribuita in due regioni geografiche (Texas e Utah). Ci sono in totale 9 server, senza contare il cloud di bilanciamento del carico. Ogni server è una CPU Xeon-D a 8 core (16 thread) con 32 GB di RAM e 2 SSD da 1 TB (configurazione RAID).

Utilizziamo la piattaforma Cloud Load Balancing di Google, in modo da avere un autoscaling e un bilanciamento del carico senza soluzione di continuità, in tutto il mondo.

Una volta configurato l’hardware con la corretta sincronizzazione dei dati, il team di Bluehost e HostGator ha lavorato insieme per ottimizzare le configurazioni del server per WordPress. Spero che alcune di queste ottimizzazioni vengano presto inserite nei futuri piani di hosting WordPress

Riepilogo della configurazione del server

Riassumere le configurazioni del server di questa complessa configurazione in pochi paragrafi è molto difficile, ma farò del mio meglio.

Utilizziamo Apache per il nostro server web perché il team ha maggiore familiarità con esso. Non mi addentrerò nel dibattito tra NGINX e Apache.

Utilizziamo PHP 7.2 e i pool PHP-FPM, in modo da poter gestire carichi elevati di processi e richieste. Se la vostra società di hosting non utilizza PHP 7+, vi state perdendo un’importante ottimizzazione della velocità.

Utilizziamo la cache Opcode con un sistema di cache warmer avanzato per garantire che nessun utente reale possa visualizzare una pagina senza cache.

Utilizziamo anche la Object cache con memcache, in modo da migliorare i tempi di risposta per le visite alle pagine non memorizzate nella cache e altri tempi di risposta delle API nell’area di amministrazione di WordPress per gli utenti loggati (i nostri autori). Ecco una scheda del carico di rete della schermata “Tutti i post” nell’amministrazione di WordPress:

In prospettiva, la nostra esperienza nell’area di amministrazione è ora 2 volte più veloce di quella precedente.

Per il nostro server di database, siamo passati da MySQL a MariaDB, che è un clone di MySQL ma più veloce e migliore. Siamo anche passati da HyperDB a LudicrousDB perché ci aiuta a migliorare la replica del database, il failover e il bilanciamento del carico.

Ci sono anche molte altre configurazioni che ci aiutano con le prestazioni e la scalabilità, come HTTP/2 e HSTS per una connessione più veloce e la crittografia, la possibilità di attivare server aggiuntivi in nuove regioni in caso di interruzione del datacenter, ecc.

Mi sembra di non rendere giustizia all’incredibile configurazione che il team ha costruito, ma sappiate che il mio punto di forza è il marketing. Sì, sono un blogger che scrive su WordPress, ma molte delle ottimizzazioni tecniche sono molto al di sopra del mio livello.

Sono state realizzate da ingegneri super intelligenti del team Endurance, tra cui David Collins (architetto capo di Endurance / CTO di HostGator), Mike Hansen (sviluppatore principale di WordPress) e altri che ringrazierò nella sezione dei crediti qui sotto.

CDN, WAF e DNS

Oltre all’hosting web, le altre aree che giocano un ruolo significativo nella velocità del vostro sito web sono il vostro provider DNS, la vostra rete di distribuzione dei contenuti (aka CDN) e il vostro firewall per applicazioni web (WAF).

Sebbene le abbia elencate come tre cose separate, molte aziende offrono ora queste soluzioni in un unico piano, come Sucuri, Cloudflare, MaxCDN (StackPath), ecc.

Poiché voglio avere il massimo controllo e distribuire il rischio, sto usando tre aziende separate per gestire ogni parte in modo efficiente.

Il DNS di WPBeginner è gestito da DNS Made Easy (la stessa società di Constellix). Sono costantemente classificati come i fornitori di DNS più veloci al mondo. Il vantaggio di DNS Made Easy è che posso dirigere il traffico a livello globale quando un centro dati specifico del mio CDN o WAF non funziona correttamente per garantire il massimo uptime.

Il nostro CDN è gestito da MaxCDN (StackPath). In pratica ci permette di servire le nostre risorse statiche (immagini, file CSS e JavaScript) dalla loro vasta rete di server in tutto il mondo.

Utilizziamo Sucuri come firewall per le applicazioni web. Oltre a bloccare gli attacchi, agisce anche come un altro livello di CDN e le sue prestazioni complessive sono semplicemente sorprendenti. Credo che abbiano la migliore soluzione firewall per WordPress sul mercato.

Quando si lavora sull’ottimizzazione della velocità dei siti web, è importante ridurre ogni millisecondo. Ecco perché l’utilizzo di questi fornitori di soluzioni in combinazione con la nostra nuova infrastruttura di web hosting fa un’enorme differenza.

A titolo di esempio, ecco la ripartizione a cascata di WPBeginner.com vs GatsbyJS.org vs CloudFlare.com:

Si noti che il tempo DNS, il tempo SSL, il tempo di connessione e il tempo di attesa di WPBeginner sono tutti al top rispetto a questi altri siti web popolari. Ognuno di questi miglioramenti è in grado di fornire i migliori risultati.

Instant.page, immagini ottimizzate e altre buone pratiche

Una delle cose che avrete notato è il tempo di caricamento quasi istantaneo quando sfogliate i post e le pagine di WPBeginner.

Oltre a tutte le cose che ho menzionato sopra, stiamo anche ingannando la latenza utilizzando uno script chiamato instant.page che utilizza il precaricamento just-in-time.

In pratica, prima che un utente clicchi su un link, deve passare il mouse su quel link. Quando l’utente ci passa sopra per 65 ms (un periodo di tempo molto breve), uno su due clicca effettivamente sul link.

Lo scriptInstant.page inizia a precaricare la pagina in quel momento, quindi quando l’utente fa effettivamente clic sul link gran parte del lavoro pesante è già stato fatto. In questo modo il cervello umano percepisce il tempo di caricamento del sito web come quasi istantaneo.

Per abilitare Instant.page sul vostro sito, potete semplicemente installare e attivare il plugin Instant Page WordPress.

Questo script è molto interessante. Consiglio vivamente di visitare il loro sito web e di fare clic sul pulsante “prova la tua velocità di clic” per vedere come inganna il cervello.

Aggiornamento: per ora ho disabilitato instant.page e nel prossimo futuro testerò il plugin FlyingPages. Gijo Varghese ha condiviso con me il suo nuovo plugin nel gruppo Facebook WPBeginner Engage e sembra combinare il meglio di instant.page e dello script quicklink.

Ottimizzare le immagini per il web

Sebbene siano in fase di sviluppo nuovi formati di immagine, come il webp, non li stiamo ancora utilizzando. Chiediamo invece a tutti i nostri autori di ottimizzare ogni immagine utilizzando lo strumento TinyPNG.

È anche possibile automatizzare la compressione delle immagini utilizzando plugin come Optimole o EWWW Image Optimizer.

Tuttavia, personalmente preferisco che il team lo faccia manualmente, in modo da non caricare file di grandi dimensioni sul server.

Al momento non effettuiamo il caricamento pigro delle immagini, ma ho intenzione di aggiungerlo nel prossimo futuro, ora che Google ha integrato il supporto per il caricamento pigro in Chrome 76.

C’è anche un ticket nel core di WordPress per aggiungere questa funzione a tutti i siti (spero davvero che ciò avvenga presto), così non dovrò scrivere un plugin personalizzato.

Aggiornamento: Poche ore dopo aver pubblicato il post, Google ha rilasciato il plugin Native Lazy Load per WordPress.

Limitare le query HTTP e le migliori pratiche

A seconda dei plugin di WordPress utilizzati, alcuni aggiungono file CSS e JavaScript a ogni caricamento di pagina. Queste richieste HTTP aggiuntive possono andare fuori controllo se avete molti plugin sul vostro sito web.

Per maggiori dettagli, vedere come i plugin di WordPress possono influire sul tempo di caricamento del sito.

Ora, prima che saltiate alla conclusione sbagliata che troppi plugin di WordPress sono negativi, voglio farvi sapere che ci sono 62 plugin attivi sul sito WPBeginner.

Quello che dovete fare è combinare i file CSS e JavaScript dove possibile per ridurre le richieste HTTP. Alcuni plugin per la cache di WordPress, come WP Rocket, possono farlo automaticamente grazie alla loro funzione di minificazione.

Potete anche seguire le istruzioni di questo articolo per farlo manualmente, come ha fatto il nostro team di WPBeginner.

Oltre alle richieste HTTP che i plugin e i temi aggiungono, dovete anche prestare attenzione agli script di terze parti che aggiungete al vostro sito web, perché ogni script avrà un impatto sulla velocità del vostro sito.

Ad esempio, se si eseguono molti script pubblicitari o di retargeting, questi rallenteranno il sito. Si consiglia di utilizzare uno strumento come Google Tag Manager per caricare in modo condizionato gli script solo quando sono necessari.

Se si tratta di un sito web supportato da annunci pubblicitari, come TechCrunch o TheNextWeb, c’è ben poco da fare, poiché la rimozione degli annunci non è un’opzione.

Fortunatamente, WPBeginner non si affida a script pubblicitari di terze parti per guadagnare. Volete vedere come WPBeginner guadagna? Consultate il mio post sul reddito di WPBeginner.

Lezioni apprese (finora) + Pensieri finali

Si tratta di un’infrastruttura di hosting nuova di zecca e sono sicuro che ci sono tonnellate di lezioni che imparerò nel corso del tempo.

Finora ho apprezzato i miglioramenti in termini di velocità, perché ci hanno aiutato a incrementare le classifiche SEO e l’area di amministrazione è molto più veloce.

Con la nuova configurazione multi-server, abbiamo introdotto un nuovo flusso di distribuzione per portare WPBeginner alla pari con gli altri siti di Awesome Motive.

Ciò significa che ora abbiamo un controllo delle versioni adeguato e che sono state adottate misure per impedirmi di essere sconsiderato (ad esempio, aggiungere plugin senza averli testati correttamente, aggiornare plugin dalla dashboard senza averli testati, ecc.)

Queste modifiche hanno anche permesso a me di uscire dallo sviluppo e di passare le redini del sito WPBeginner al nostro team di sviluppatori.

Ho resistito per anni, ma credo che il momento stia arrivando e devo solo accettarlo.

La nuova configurazione non ha cPanel o WHM, quindi questo mi rende praticamente inutile in ogni caso, dato che non sono più molto abile con la riga di comando.

Finora abbiamo imparato due grandi lezioni:

La prima è che l’aggiornamento di WordPress non è così semplice a causa della sincronizzazione/replicazione del server. Quando abbiamo aggiornato il mio blog personale(SyedBalkhi.com) a WordPress 5.2, i file di aggiornamento non si sono sincronizzati correttamente su uno dei nodi web e il debugging ha richiesto molto più tempo del previsto. Stiamo lavorando per creare un processo di compilazione e test migliore.

In secondo luogo, dobbiamo migliorare la comunicazione tra i team, perché abbiamo avuto una piccola crisi con una configurazione errata del bilanciatore di carico che ha provocato alcuni tempi di inattività. Come se non bastasse, ero su un volo transatlantico della Turkish Airlines e il WiFi non funzionava.

Fortunatamente tutto si è risolto grazie alla rapidità di risposta del team di hosting, ma questo ci ha aiutato a creare diverse nuove procedure operative standard (SOP) per gestire meglio gli incidenti in futuro.

Nel complesso sono molto soddisfatto della configurazione e so che alcune delle configurazioni/ottimizzazioni della cache realizzate per WPBeginner diventeranno parte integrante dei piani di hosting WordPress di HostGator Cloud e Bluehost.

Penso che non ci sia bisogno di dire che se state iniziando un sito web, un blog o un negozio online, NON avete bisogno di questa sofisticata configurazione aziendale.

Consiglio sempre di iniziare in piccolo con i piani condivisi di HostGator o Bluehost, come ho fatto io, e poi di aggiornare l’infrastruttura di hosting man mano che la vostra attività cresce.

Potete applicare molte delle ottimizzazioni che ho condiviso sopra ai vostri attuali piani di hosting WordPress.

Ad esempio, il piano standard di Bluehost è già dotato di un plugin di caching integrato che potete utilizzare e offre anche PHP 7 di default.

Potete combinarlo con un CDN + WAF come Sucuri per velocizzare in modo significativo il vostro sito web.

Se siete un’azienda di medie dimensioni/imprese che desidera una configurazione di hosting simile, contattatemi tramite il nostro modulo di contatto. Posso aiutarvi a orientarvi nella giusta direzione.

Ringraziamenti speciali e crediti

Anche se nell’articolo precedente ho dato un sacco di grida ai marchi HostGator e Bluehost, voglio prendermi un momento per riconoscere e apprezzare le singole persone che hanno lavorato dietro le quinte per renderlo possibile.

Innanzitutto, voglio ringraziare il team di leadership di Endurance, Suhaib, Mitch, John Orlando, Mike Lillie e Brady Nord, per aver accettato di aiutarmi in questa sfida.

Voglio anche ringraziare Mike Hansen, David Collins, Rick Radinger, Chris Miles, David Ryan, Jesse Cook, David Foster, Micah Wood, William Earnhardt, Robin Mendieta, Rod Johnson, Alfred Najem e altri membri del team del centro dati per aver fatto il lavoro duro e per averlo realizzato.

Vorrei fare un ringraziamento speciale a Steven Job (fondatore di DNSMadeEasy) per aver risposto rapidamente alle mie domande e per avermi aiutato a capire meglio alcune impostazioni. Voglio anche ringraziare Tony Perez e Daniel Cid di Sucuri per avermi sempre sostenuto.

Infine, ma non meno importante, voglio dare un riconoscimento speciale a Chris Christoff. È il co-fondatore di MonsterInsights ed è stato così gentile da aiutarmi con molti dei test e della distribuzione.

Spero davvero che questo caso di studio sul dietro le quinte dell’infrastruttura di hosting di WPBeginner vi sia stato utile. Potreste anche voler consultare la nostra guida definitiva su come velocizzare WordPress, molto più adatta ai principianti.

Bonus: ecco i migliori plugin e strumenti per WordPress che consiglio per tutti i siti WordPress.

Se vi è piaciuto questo articolo, iscrivetevi al nostro canale YouTube per i video tutorial su WordPress. Potete trovarci anche su Twitter e Facebook.