Velocizzare WordPress per la SEO e arrivare a 100/100 su PageSpeed Insight. Guida e Riflessioni.

Articolo aggiornato il 17 gennaio 2018

Una guida SEO concreta per velocizzare WordPress fino a raggiungere un punteggio di 100/100 su PageSpeed Insight

Dopo aver effettuato numerosi esperimenti con l’obiettivo di velocizzare WordPress per la SEO, ho trovato un buon equilibrio che mi ha permesso di ottenere il massimo punteggio su PageSpeed Insight. Nel post descriverò gli step per riprodurre il metodo ed aggiornerò costantemente il post indicandone le evoluzioni.

Gli aggiornamenti di dicembre 2017 aggiungono alcuni dettagli e migliorie, relativi all’utilizzo di CloudFlare e di IPS (Instant Page System). Quello di gennaio 2018, aggiunge un approfondimento relativo al TTFB.

 

 

Gli obiettivi della guida

Leggo molti post sull’argomento, i quali, nella nella maggior parte dei casi, si limitano ad una “cozzaglia” di plugin da installare. Quelli un po’ più specifici, presentano soluzioni improponibili, della serie “non usare Google Analytics” (a breve vedremo il motivo).
Il valore aggiunto di questa mini guida è che riguarda la mia esperienza diretta, spiegata nei particolari (teoria, tecniche e motivazioni), e con i giusti compromessi.

Concetti già sentiti? Per chi ha già affrontato questa tematica ed ha già attuato alcune delle pratiche che descrivo, consiglio di spostarsi verso la seconda parte del post, laddove i concetti suno più avanzati ed “impattanti.

 

I risultati raggiunti

Quelli che seguono sono i risultati raggiunti mettendo in pratica i punti della guida.

NOTA: non avendo un hosting dedicato, o comunque particolarmente “corazzato” (questo progetto non lo necessita), è possibile che facendo i test in diversi momenti, con il variare del carico del server, i dati siano leggermente diversi (PageSpeed Insight segnala che il tempo di risposta del server è riducibile, al superamento dei 200 millisecondi).

 

Google PageSpeed Insight

PageSpeed Insight (desktop) / alessiopomaro.com

PageSpeed Insight (desktop) / alessiopomaro.com

 

PageSpeed Insight (mobile) / alessiopomaro.com

PageSpeed Insight (mobile) / alessiopomaro.com

 

Test My Site di Google

Questo tool indica le prestazioni del sito web utilizzando una connessione 3g.

Test my Site / alessiopomaro.com

Test my Site / alessiopomaro.com

 

Test my site: confronto di settore / alessiopomaro.com

Test my site: confronto di settore / alessiopomaro.com

 

TTFB (Time To First Byte)

Nell’immagine che segue, tratta da un test di Pingdom, possiamo vedere la reattività della risposta ed il TTFB (Time To First Byte).

Pingdom: TTFB / alessiopomaro.com

Pingdom: TTFB / alessiopomaro.com

 

Perché la velocità è importante per la SEO?

Vediamolo per punti.

  1. Perché la velocità dei sit web è un fattore di ranking.
  2. Perché la velocità garantisce un’esperienza utente migliore all’utente. Questo, per me, è il Vero motivo per il quale vale le pena considerarla.
  3. Perché ottimizza la gestione del crawl budget, ovvero le risorse che il crawler del motore di ricerca mette a disposizione nella scansione delle nostre pagine.

 

Cosa indica PageSpeed in pratica?

Il coefficiente e i suggerimenti di Google Pagespeed Insight non riguardano strettamente la velocità del sito web: la velocità è una delle conseguenze dell’ottimizzazione richiesta.

Indica rispettivamente:

  1. il rendimento delle pagine che vengono scansionate (sia per dispositivi mobile, sia per desktop)
  2. come sia migliorabile rispetto al caricamento dell’ATF (Above The Fold) e rispetto al caricamento completo.

E’ ovvio che PageSpeed Insight considera solo gli aspetti indipendenti dalla connettività, quindi rappresenta un dato relativo di riferimento. Una pagina web che ottiene 100/100 di coefficiente, richiesta da una connessione a 32 kbps, ad esempio, considerando le aspettative di oggi, risulterà comunque lenta.

 

Ottimizzare WordPress per aumentare il PageaSpeed dà reali vantaggi?

Per rispondere a questa domanda, vorrei utilizzare i diagrammi di Search Console che indicano le statistiche di scansione per dimostrare come migliora il rendimento del crawl budget dopo aver messo in pratica le azioni che vedremo.

Search-Console: Statistiche di scansione / alessiopomaro.com

Search-Console: Statistiche di scansione / alessiopomaro.com

Il numero delle pagine scansionate ed i dati scaricati dal crawler giornalmente sono saliti in maniera decisa, corrispondentemente ad una discesa drastica del tempo di scaricamento delle pagine.

 

Guida all’ottimizzazione di WordPress

Vediamo tutti gli aspetti che ho considerato e messo in pratica.

 

Abilitazione della compressione

I webserver, configurati opportunamente (per Apache, ad esempio, deve essere installato il modulo “mod_gzip“), possono comprimere le risorse in formato “gzip” prima di inviarle al client. Tale pratica riduce la quantità dei dati scaricati, e di conseguenza aumenta la velocità.
L’attivazione della compressione può avvenire attraverso la gestione del virtualhost all’interno del server web, oppure utilizzando il file htaccess.

Nella mia configurazione ho abilitato la compressione utilizzando un plugin, ovvero W3 Total Cache.
Per farlo, basta entrare nella sezione “Browser cache” e spuntare l’opzione “Enable HTTP (gzip) compression“.

Abilitazione della compressione: WordPress + W3 Total Cache

Abilitazione della compressione: WordPress + W3 Total Cache

Tale impostazione andrà a scrivere la corretta configurazione della compressione all’interno del file .htaccess.

 

Minimizzazione dell’HTML

La minimizzazione delle risorse consiste in una sorta di “compressione” del contenuto dei file (testuali) allo scopo di eliminare i byte che non sono necessari. Gli esempi classici sono gli spazi, le tabulazioni e le interruzioni di riga.

Lo scopo della minimizzazione, è quello di ridurre i tempi di processazione e di download delle risorse.
Esistono numerose librerie che si possono utilizzare in fase di sviluppo per ottenere il markup minimizzato, ma anche estensioni per il browser e servizi online, come il famoso “HTML Minifier“.

Nella mia configurazione, ho minimizzato l’HTML utilizzando W3 Total Cache. Anche in questo caso è davvero semplice: basterà entrare nel menù “Minify” ed applicare le seguenti impostazione nel blocco “HTML minify settings“.

Minify dell'html: WordPress - W3 Total Cache

Minify dell’html: WordPress – W3 Total Cache

 

Minimizzazione e gestione del JavaScript (JS)

Il concetto è il medesimo visto in precedenza, ma, per quanto riguarda il JavaScript ci sono altri aspetti da valutare.

I siti web, soprattutto se vengono realizzati attraverso un tema acquistato ed una serie di plugin installati (quindi con un sistema non sviluppato ed organizzato ad hoc), sono caratterizzati dall’inclusione di molti file Javascript esterni.

In questo caso, l’azione ideale è quella di unificare i file JS e minimizzare tutto il codice. Ma non solo. Uno degli elementi che contano moltissimo nella valutazione di PageSpeed è la presenza o meno di funzionalità JavaScript che bloccano la renderizzazione della pagina nell’area ATB (Above The Fold); la situazione ideale, chiaramente, è che non ci siano “blocchi” e che la pagina possa caricarsi indipendentemente dal JavaScript.

Per questo motivo, è possibile scegliere in che modo includere il JavaScript, e le possibilità sono le seguenti.

  1. In maniera asincrona (async): il download dello script avviene indipendentemente dagli elementi della pagina, e viene eseguito subito dopo il download. La renderizzazione rimane “bloccata” soltanto durante l’esecuzione.
  2. In maniera differita (defer): il download dello script avviene, come per l’asincrono, parallelamente alla pagina. Stavolta, però, l’esecuzione avviene una volta completata la generazione dell’HTML, quindi quando il DOM (Document Object Model) è pronto.
Javascript: async e defer, le differenze

Javascript: async e defer, le differenze

La scelta della tecnica di embedding dipende dalla natura degli script, dalle loro dipendenze e da come interagiscono con il tema.

Nella mia configurazione ho utilizzato W3 Total Cache per minimizzare il JavaScript e ho optato per inserirlo in maniera differita (defer).

Minify del JavaScript: WordPress + W3 Total Cache

Minify del JavaScript: WordPress + W3 Total Cache

Come vediamo dall’immagine, il plugin permette diverse opzioni di minimizzazione, ad esempio è possibile eliminare anche le interruzioni di riga per ottenere la massima compressione.

Inoltre è stata aggiunta una funzionalità per i server che supportano il protocollo HTTP/2; in pratica aiuta a migliorare le performance aggiungendo degli header specifici per il precaricamento delle risorse utilizzando l’HTTP/2, il quale garantisce delle prestazioni nettamente superiori.

Tuttavia, consiglio di fare dei test per trovare il giusto equilibrio tra minimizzazione e assenza di errori.

 

Minimizzazione e gestione del CSS

Ancora una volta ci troviamo difronte alla compressione di un file testuale. Anche in questo caso, il concetto non cambia, tuttavia ho utilizzato un plugin diverso, ma altrettanto noto: Autoptimize.
La scelta deriva dal fatto che Autoptimize consente di ottimizzare e differire i fogli di stile incorporando il CSS critico per l’ATF (Above The Fold) che gli viene indicato.
Nota importante: anche la versione Pro di W3 Total Cache possiede questa funzionalità, ma non credo abbia senso l’acquisto esclusivamente per questa caratteristica.

 

Come si definisce il CSS critico per l’Above The Fold (ATF)

Il CSS “critico comprende le regole necessarie alla corretta visualizzazione della porzione ATF per garantire un’esperienza utente corretta durante il completamento della renderizzazione della pagina e del successivo caricamento dell’intero foglio di stile.
La determinazione delle regole è semplice se siamo noi a creare il tema; è meno immediata se utilizziamo un tema acquistato, e quindi sviluppato da altri.

Above The Fold (ATF): cos'è?

Above The Fold (ATF): cos’è?

Nel mio caso ho fatto diversi esperimenti, e i punti che seguono identificano, se non la soluzione definitiva, un buon punto di partenza.

  1. Configuriamo Autoptimize in modo che crei un unico CSS complessivo (vedere l’immagine che segue).
  2. Utilizziamo uno strumento online (e gratuito) per generare l’Above The Fold CSS: Critical Path CSS Generator. Come parametri, indichiamo l’URL del sito interessato e il link al CSS unico generato da Autoptimize. Per trovarlo, basterà aprire lo strumento per sviluppatori del browser (nei browser più noti premendo F12) e copiare l’URL dell’unico file CSS che vedermo (all’interno della tab “rete” o “network“), il quale sarà contenuto nella directory /wp-content/cache/autoptimize/css/.
  3. Inseriamo le regole CSS generate all’interno dell’apposita area di testo nelle impostazioni di Autoptimize come segue.
Autoptimize: impostazioni per la compressione del CSS

Autoptimize: impostazioni per la compressione del CSS

Il risultato dell’operazione, se tutto viene impostato nella giusta maniera, sarà la corretta visualizzazione dell’area ATF durante il caricamento di tutta la pagina web.

Per chi fosse interessato ad approfondire l’argomento, consiglio la lettura della seguente guida messa a disposizione da Google per i web developer: “Percorso di rendering critico“.

 

Impostazioni avanzate di Minificazione

W3 Total Cache si integra nativamente con diversi sistemi di cache, come:

  1. Memcached (sistema di caching distribuito in RAM per oggetti) e
  2. APC (cache open-source per PHP).
Opzioni avanzate di minimizzazione di W3 total cache

Opzioni avanzate di minimizzazione di W3 total cache

Nella mia configurazione ho impostatol’interfacciamento con Memcached, disponibile nel mio piano hosting. Negli approfondimenti della parte finale del post, descriverò in maniera un po’ più dettagliata il sistema di cache di Siteground.

 

Ottimizzazione delle immagini

L’ottimizzazione delle immagini è uno dei punti di base delle verifiche di PageSpeed Insight, ma anche uno dei meno ostici da gestire.

Consiglio la lettura del post “Google Immagini: suggerimenti SEO per migliorare il ranking” per comprendere quanto è importante l’ottimizzazione delle immagini in ottica SEO.

L’analisi della pagina, rileva le immagini che possono essere ridotte mantenendo una qualità adeguata; basterà quindi utilizzare un tool di compressione per andare a ridurne il “peso” facendole rientrare nel range ottimizzato.

Un esempio di ottimizzazione di un'immagine

Un esempio di ottimizzazione di un’immagine

Ho realizzato un articolo dove spiego nei minimi particolari come ottimizzare le immagini per la SEO, il quale contiene sia una lista dei migliori tool di compressione, sia una mini recensione dei migliori plugin per WordPress indicati per questo scopo.
Ecco il link al post: Immagini SEO: come ottimizzare le immagini. Guida e strumenti.

Nella mia configurazione, oltre ad ottimizzare la qualità, utilizzo un plugin che carica le immagini in maniera asincrona: a3 Lazy Load.
Il vantaggio di questa pratica si riflette nella velocità di apertura delle pagine, le quali si caricano completamente senza attendere il download delle imamgini che avverrà in un secondo momento, man mano che l’utente “scrolla” in basso.
Una nota interessante sul plugin è che carica in maniera asincrona anche i video “embeddati” nelle pagine web.

 

L’utilizzo di CloudFlare come Caching Reverse Proxy

Nel’articolo relativo all’ottimizzazione delle immagini per la SEO (link nel punto precedente) viene ampiamente presentato anche l’aspetto relativo all’utilizzo delle CDN ed ai vantaggi che introducono.
Nella mia esperienza di velocizzazione di WordPress per la SEO ho utilizzato CloudFlare come sistema di “caching reverse proxy, ovvero un sistema che interviene tra il server web ed il client allo scopo di ottimizzare al massimo le risposte alle richieste.

Come funziona CloudFlare? Velocizzare WordPress per la SEO

Come funziona CloudFlare? Velocizzare WordPress per la SEO

Vediamo, in uno schema, i PRO e i CONTRO di questo servizio per capirne le potenzialità.

I PRO di CloudFlare
  • Velocizza il sito web (di molto).
  • Riduce circa del 60% la banda utilizzata e circa il 65% il numero delle richiesta al server web. Ne consegue che quest’ultimo subirà molto meno carico e, nel caso di utilizzo di cloud “a consumo“, i costi da affrontare saranno inferiori.
  • Grazie a server dislocati in tutto il mondo, i contenuti verranno serviti da quello più vicino al client, riducendo notevolmente i tempi di risposta. Nel mio caso, ho fatto dei test utilizzando Pingdom ed i tempi di caricamento risultano di poco diversi facendo richieste dall’Italia, dalla Svezia, dalgi Stati Uniti, ecc..
  • Garantisce un livello di sicurezza molto elevato, facendo da filtro delle richieste (firewall) e proteggendo il sito web anche da noti attacchi informatici.
  • E’ gratuito (esiste anche la versione a pagamento, la quale introduce ulteriori ottimizzazioni).

 

I CONTRO di CloudFlare
  • Nella versione gratuita, per i siti web HTTPS, il certificato SSL non offre una compatibilità per i browser obsoleti.
  • L’utilizzo di Rocket Loader (vedremo a breve di cosa si tratta), in alcuni casi, può determinare errori JavaScript (non nel mio caso).
  • Può essere utilizzato soltanto se il piano hosting permette la gestione dei record DNS.

 

Come attivare CloudFlare

L’attivazione del servizio gratuito avviene in maniera semplicissima, seguendo gli step che seguono.

  1. Accedere al sito web e creare un account.
  2. Inserire il dominio di riferimento. Il sistema procederà a verificarne tutti i record DNS associati mappando già quelli che andranno ad utilizzare il proxy e quelli, invece, che lo bypasseranno.
  3. Una volta ultimata la configurazione, basterà sostituire i name server del provider che utilizziamo con quelli forniti da CloudFlare, che sarà attivo una volta ultimata la propagazione.

Nel caso in cui il nostro hosting sia gestito su SiteGround, l’attivazione di CloudFlare può avvenire direttamente dall’apposita sezione di cPanel con pochi clic (in questo caso la gestione dei record DNS avverrà in automatico).

 

Come configurare CloudFlare

Non è mia intenzione fare una guida specifica, ma vediamo alcuni punti interessanti che possiamo gestire dal pannello di CloudFlare.

  • Possiamo attivare e gestire l’HTTP Strict Transport Security (HSTS). Per approfondire, ecco un post interessante: “Cos’è il 307 / HSTS Policy? Panico nel mondo SEO“.
  • Possiamo gestire le regole del Firewall e attivare la protezione contro attacchi DDoS.
  • Possiamo usufruire del servizio Rocket Loader, ovvero un sistema di ottimizzazione ulteriore del JavaScript che utilizza anche il “local storage” del browser per salvare le risorse in locale.
  • Possiamo usare Railgun (solo se l’hosting lo consente), ovvero un sistema molto complesso di velocizzazione dei contenuti dinamici.

  • Possiamo utilizzare il generatore di contenuti AMP (Accelerated Mobile Pages).
  • Possiamo impostare CloudFlare in modalità “Always Online, la quale garantisce il funzionamento del sito web anche se il server ha dei malfunzionamenti.
  • Possiamo integrare CloudFlare con W3 Total Cache, attraverso l’apposita estensione gratuita, in modo da poter gestirne le impostazioni e la cache dal pannello di WordPress.

 

Railgun o HTML statico per ottimizzare le prestazioni?

Railgun è un sistema che è stato messo a punto per salvare in cache i contenuti dinamici. In realtà è un’affermazione imprecisa allo scopo di semplificare il concetto; in pratica, attraverso un sistema molto complesso ed articolato, Railgun verifica se i contenuti sono variati e se lo sono, aggiorna la cache con trasferimenti dati minimali e velocissimi.

Railgun, quindi, è comodo per i siti web che hanno pagine che si aggiornano con una frequenza elevata, oppure per chi ha un sito web dinamico e desidera non gestirne la cache.

Per rispondere alla domanda del titolo del paragrafo:

  • il metodo che garantisce le prestazioni più elevate, di certo è la cache totale da parte di CloudFlare, la quale riduce al minimo l’interazione con il server web;
  • il metodo più “intelligente“, ma che comunque garantisce buone prestazioni è Railgun.

Quello che segue è un esempio dell eprestazioni che si possono raggiungere utilizzando la modalità “cache everithing” di CloudFlare con le dovute attenzioni.

Test di Load Time usando la cache di CloudFlare

Test di Load Time usando la cache di CloudFlare

Nel periodo successivo alla prima stesura del post, inoltre, sempre utilizzando questa modadalità di caching, il tempo di download medio delle pagine segnalato da Search Console si è abbassato ulteriormente.

 

Caching del browser

La memorizzazione delle risorse statiche (file JS, CSS, immagini, PDF, ecc.) all’interno della cache del browser è una pratica che aumenta la velocità di navigazione degli utenti che visitano più volte le pagine di un sito web, poiché dopo la prima visualizzazione, per un certo tempo, non verranno più scaricate.

Google PagaSpeed Insight verifica se la pagina analizata include delle risorse per le quali non sono state specificate le intestazioni (headers) per la memorizzazione nella cache del browser, oppure se il periodo di memorizzazione specificato risulta essere troppo breve.

La gestione degli headers per la gestione della cache del browser può essere gestita manualmente utilizzando le seguenti regole all’interno del file .htaccess.

<IfModule mod_expires.c>
 ExpiresActive on
 ExpiresByType text/css "access plus 14 days"
 ExpiresByType text/xml "access plus 0 seconds"
 ExpiresByType text/javascript "access plus 14 days"
 ExpiresByType application/x-javascript "access plus 14 days"
 ExpiresByType image/ico "access plus 14 days"
 ExpiresByType image/jpg "access plus 14 days"
 ExpiresByType image/jpeg "access plus 14 days"
 ExpiresByType image/gif "access plus 14 days"
 ExpiresByType image/png "access plus 14 days"
 ExpiresByType image/svg+xml "access plus 1 month"
 ExpiresByType text/html "access plus 14 days"
 ExpiresByType video/ogg "access plus 1 month"
 ExpiresByType audio/ogg "access plus 1 month"
 ExpiresByType video/mp4 "access plus 1 month"
 ExpiresByType video/webm "access plus 1 month"
 ExpiresByType application/x-font-woff "access plus 1 month"
 ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
 ExpiresByType application/xml "access plus 0 seconds"
 ExpiresByType application/json "access plus 0 seconds"
 ExpiresByType application/rss+xml "access plus 1 hour"
 ExpiresByType application/atom+xml "access plus 1 hour"
 </IfModule>

In alternativa, è gestibile da W3 Total Cache (sezione Browser Cache) attraverso una semplice configurazione.

Gestione della cache del browser: WordPress + W3 total cache

Gestione della cache del browser: WordPress + W3 total cache

L’immagina indica le impostazioni generali. Dal pannello le regole possono essere specificate per singola tipologia di file.

 

Come risolvere il problema del caching del browser per le risorse esterne

Questo problema è un tallone d’achille per moltissimi siti web che si avvicinano al massimo punteggio. Di fatto, essendo le risorse esterne, non è possibile gestirne le intestazioni, e di conseguenza anche quelle relative alla cache.
Propongo due metodologie per risolvere il problema, suddividendo le risorse in altrettante categorie.

  1. File che non necessitano un aggiornamento e che non sono “vitali”
    Un esempio di file di questa categoria sono i JS relativi alle inclusioni dei post dei social. In questo caso, possiamo anche scaricarli ed utilizzarli attraverso l’URL del nostro sito web. Una volta fatto questo, i file saranno, di fatto, risorse locali che verranno memorizzate dal browser seguendo le regole definite in precedenza.
  2. File “vitali”, che devono essere sempre aggiornati
    Gli esempi classici sono i file JS caricati dagli snippet di Google Analytics o Google Tag Manager (il quale, al suo interno, richiama comunque analytics.js).
    In questo caso possiamo agire come nel punto precedente, ma dobbiamo anche creare un’automazione che mantiene costantemente aggiornati i file locali. La soluzione che sto utilizzando in questo momento è costituita da un semplice script PHP che, eseguito periodicamente (attraverso un cronjob), va a leggere i file gtm.js e analytics.js remoti, andando a sovrascrivere i corrispondenti locali.

Indico la porzione di codice relativa all’aggiornamento dello script di Google Analytics.

<?php
$ch = curl_init(); // Inizializzazione di CURL
$headers = array('HTTP_ACCEPT: Something', 'HTTP_CONNECTION: Something');

curl_setopt($ch, CURLOPT_URL, "https://www.google-analytics.com/analytics.js"); // URL del file remoto
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1 );
curl_setopt($ch, CURLOPT_HTTPHEADER, $header );
$result = curl_exec( $ch ); // Esecuzione
curl_close($ch);

//scrittura nel file locale
if (!$handle = fopen('/path-del-file-locale/analytics.js', 'w')) {
 exit;
}

if (fwrite($handle, $result) === FALSE) {
 exit;
}

fclose($handle); // Chiusura
?>

Per il file di Google Tag Manager la situazione è la medesima, ma con una piccola complicazione. L’inclusione del file analytics.js, avviene, infatti all’interno del file gtm.js. Quindi, attraverso un “replace“, sostituisco l’URL remoto di analytics.js con la path del file locale all’interno del file gtm.js prima di scrivere la stringa letta con CURL nel file locale.

Attraverso questo escamotage, tutti i file statici saranno locali e il problema della gestione della cache del browser sarà risolto.

 

Page Cache, Database Cache e Object Cache

Concludo la questione “cache” con una rapida carrellata in merito a queste importanti tipologie di memorizzazione.
La page cache memorizza una versione statica delle pagine che compongono il sito web, riducendo di molto i tempi di risposta del server. Nel mio caso, l’ho abilitata attraverso W3 Total Cache (attraverso semplici impostazioni nella sezione “Page Cache“) con Memcached.

W3 Total Cache permette di attivare anche la funzione di creazione automatica delle pagine statiche (10 per ciclo, per impostazione predefinita – più pagine vengono inserite, e più aumenta il carico del server), le quali si rigenerano periodicamente, con periodo gestibile dalle opzioni.

La cache automatica delle pagine: W3 total cache

La cache automatica delle pagine: W3 total cache

Per le altre tipologie di cache ho utilizzato Supercacher di SiteGround, configurabile attraverso il plugin per WordPress “SG Optimizer“.
SiteGround, grazie all’utilizzo delle tecnologie più veloci (come dischi SSD, nginX, CDN, HTTP/2, PHP7) ha creato un sistema basato su 3 livelli di cache.

  1. Cache statica. Memorizza tutti i dati statici delle pagine (immagini, CSS, JS, ecc.) per restituirli ai visitatori in maniera velocissima.
  2. Cache Dinamica. Crea copie delle parti dinamiche del sito web all’interno della RAM del web server. Lo scopo, come per il primo livello, è quello di “servire” i contenuti dinamici velocemente.
  3. Memcached. Una tecnologia che velocizza le chiamate verso il database e le API. Riducendo le query al database, si ottiene la velocizzazione e la riduzione del carico del server.

In alternativa, la gestione della Database Cache e della Object Cache è disponibile anche su W3 Total Cache.

 

Ottimizzazione del Database di WordPress

Il database di WordPress, se non viene monitorato, cresce di dimensioni molto velocemente principalmente perché il sistema conserva:

  1. un grande numero di revisioni automatiche dei contenuti;
  2. le opzioni anche di componenti che non vengono più utilizzati;
  3. i commenti eliminati e quelli contrassegnati come spam.

Per la pulizia e l’ottimizzazione del database utilizzo un noto plugin: “WP Optimize“.
Effettuo delle pulizie periodiche comprendendo tutte le opzioni permesse. Prima di avviare il processo, consiglio sempre di fare una copia di backup del database.

Mantenere il database “pulito” può velocizzare di molto le query, e di conseguenza le pagine in cui vengono eseguite.

 

Ottimizzazione di WordPress

Per quanti strumenti possiamo utilizzare con l’obiettivo di velocizzare WordPress per la SEO, è fondamentale partire dalla radice, ovvero dall’ottimizzazione del tema e dall’utilizzo moderato di plugin.

 

Ottimizzazione del tema di WordPress

Non sempre è possibile farlo, ma è una pratica che consiglio se si hanno delle basi di PHP ed HTML. Per ottimizzazione intendo togliere dal tema tutto ciò che è dinamico di cui non necessitiamo, e quindi generato da una funzione/ciclo PHP. Un esempio su tutti può essere il nome del sito.

E’ chiaro che va valutato di progetto in progetto quanto “spingersi” in termini di alleggerimento. Nel mio tema, ad esempio, carico anche la sidebar ed il footer in maniera asincrona, ma si tratta di operazioni abbastanza evolute.

Consiglio, inoltre, di verificare quali operazioni vengono effettuate all’interno del file functions.php e di snellirlo il più possibile; nel mio caso, ad esempio, ho eliminato le funzioni di WordPress che richiamano le path e gli URL del tema e del CSS, quindi

  • get_template_directory
  • get_template_directory_uri
  • get_stylesheet_directory
  • get_stylesheet_directory_uri

sostituendole con la stringa corrispondente.

 

Utilizzo moderato dei plugin

Ogni volta che richiediamo una pagina di un sito web di WordPress, vengono caricate prima tutte le funzionalità del “core“, e successivamente tutti i plugin. Proprio per questo motivo, leggiamo ovunque il consiglio di utilizzare il minor numero di plugin per snellire il sistema.

 

Come disattivare i plugin di WordPress nelle pagine in cui non servono

Quella che sto per descrivere è una funzionalità poco conosciuta, ma che secondo me offre grandi potenzialità, se utilizzata nel modo corretto.
Esiste, infatti la possibilità di creare una tipologia di plugin avente 2 caratteristiche particolari:

  1. vengono eseguiti prima di tutti gli altri, potendone controllare l’attivazione;
  2. non possono essere disattivati dal pannello di amministrazione di WordPress.

Sto parlando dei “Must Use Plugins“, detti anche “mu-plugins” (link alla documentazione: https://codex.wordpress.org/Must_Use_Plugins).

Creare un plugin di questo tipo è molto semplice. E’ sufficiente:

  1. creare la directory/wp-contents/mu-plugins” (nella documentazione viene anche indicato come sia possibile personalizzarne la posizione),
  2. posizionarvi all’interno il file PHP contenente il codice che vedremo.

Nel flusso dell’esecuzione di WordPress, i Must Use Plugins vengono inizializzati prima della “main query“, ed è proprio questo il motivo per il quale, per lo sviluppo, non si hanno a disposizione i tag condizionali (link alla documentazione: https://codex.wordpress.org/Conditional_Tags) per identificare in quale pagina sta avvenendo l’esecuzione.
Come vedremo, infatti, utilizzo dei controlli sull’URL per individuare la pagina in uso.

Nel mio plugin, ho creato una serie di casistiche per lediverse pagine, ma per facilitare la comprensione, vediamo una versione semplificata, la quale va a disabilitare il plugin Contact Form 7 in tutto il sito web, ad eccezione della pagina “Contatti.

<?php
/*
Plugin Name: AP plugin - Componenti selettive
Plugin URI: https://www.alessiopomaro.com
Description: Rimuove i plugin selettivamente nelle pagine
Author: Alessio Pomaro
Version: 1.0
Author URI: https://www.alessiopomaro.com
*/

add_filter( 'option_active_plugins', 'ap_disable_plugins' );

function ap_disable_plugins($plugins){

if((strpos($_SERVER['REQUEST_URI'], '/contatti/') === FALSE) && (strpos($_SERVER['REQUEST_URI'], '/wp-admin/') === FALSE)){ //se non è la pagina Contatti e non è l'admin
 $key = array_search( 'contact-form-7/wp-contact-form-7.php' , $plugins );
 if ( false !== $key ) {
 unset( $plugins[$key] );
 }
 }

return $plugins;
}
?>

Una volta caricato il file PHP nella directory, comparirà una nuova voce di filtro nell’area plugins, con nome “Obbligatorio” (nel senso che vengono sempre eseguiti e non sono disattivabili), all’interno della quale troveremo il nostro mu-plugin.

mu-plugin per l'abilitazione selettiva dei plugins all'interno delle pagine

mu-plugin per l’abilitazione selettiva dei plugins all’interno delle pagine

I vantaggi che ne derivano sono misurabili in termini di velocita, perché evitando di caricare i plugin che non servono,

  • vengono effettuate meno query,
  • si evitano elaborazioni inutili che possono essere dispendiose in termini di risorse,
  • si evita di caricare script non necessari nel frontend.

 

Redirect 301

Aggiungo, infine, un ultimo consiglio relativo ai plugin. Evitiamo di fare i redirect 301 lato software, cioè di farli attraverso un plugin di WordPress, perché sono controlli pesanti che vengono eseguiti ad ogni caricamento di pagina.

E’ molto meglio farli lato server usando i tool messi a disposizione dal provider (cPanel, ad esempio, ha un’apposita sezione), dal proxy, oppure usando il file .htaccess (o il file di configurazione di nginx).
A questo proposito, consiglio la lettura del seguente post: “Come ottimizzare il file .htaccess in ottica SEO. Guida pratica“.

 

Conclusioni e presentazione di Instant Page System

Come dimostrano le statistiche di scansione di Google Search Console, fare tutto ciò che è in nostro potere per rendere le pagine web più veloci e più confortevoli per i nostri utenti, e quindi aumentare il più possibile il coefficiente di PageSpeed Insight dà effettivamente dei vantaggi.

Ma ricordiamoci che si tratta di uno strumento, il quale ha lo scopo di aiutarci a comprendere lo stato delle pagine web.. ma non deve sostituirsi alla nostra capacità di valutare la situazione!

Se le nostre pagine web sono veloci e garantiscono un’esperienza utente importante, il nostro scopo sarà raggiunto.

 

Instant Page System (IPS)

Concludo condividendo un piccolo progetto che sto sviluppando e migliorando costantemente.
Si tratta di un nuovo concetto di navigazione ultraveloce nato da un’idea dell’amico Eduard Zabara (anche il suo sito web utilizza un sistema simile), dopo centinaia di chiacchierate notturne, che ho nominato “Instant Page System“, il quale, nella sua terza versione beta, è in test in questo sito e in pochi altri.

Instant Page System (IPS) - by alessiopomaro.com

Se navighi le pagine del menù (sia in versione desktop che mobile) ti accorgerai che la navigazione avviene in moda particolare e molto veloce.

L’ultimo aggiornamento del sistema, già in uso in questo sito web, ha introdotto un miglioramento della tecnica di prerendering e un’ottimizzazione della selezione dei contenuti da velocizzare, per otttenere prestazioni ancora superiori.

Questo metodo, per alcuni parametri di valutazione, non mi fa ottenere il massimo punteggio usando, ad esempio, lo strumento GTMetrix, tuttavia, secondo il mio punto di vista, l’esperienza utente viene migliorata di molto. Tu cosa ne pensi?

 

Aggiungo un tweet di Ilya Grigorik (web performance engineer di Google) del 17 gennaio in cui, linkando un post del Webmaster Central Blog dal titolo “Using page speed in mobile search ranking“, afferma che la velocità del sito web diventerà fattore di ranking per le ricerche mobile.

Ilya Grigorik su Twitter: Google userà il "page speed" come fattore di ranking per il mobile

Ilya Grigorik su Twitter: Google userà il “page speed” come fattore di ranking per il mobile

 

6 commenti per “Velocizzare WordPress per la SEO e arrivare a 100/100 su PageSpeed Insight. Guida e Riflessioni.

  1. Michele

    Ciao Alessio, ottima guida!
    Ho solo una domanda: ho installato Autoptimize ma la mia unica opzione all’interno del plugin è “Opzioni CSS
    Ottimizzare il codice CSS?”

    Non c’è traccia della altre configurazioni anche dopo averlo attivato.
    Come mai?

  2. Piero

    Ciao Alessio. Complimenti, una guida molto ricca di dettagli e utile :) Ti volevo chiedere un’informazione: tra i vari servizi di CDN disponibili quale (o quali) ti sentiresti di consigliare? Grazie.

    1. Alessio Pomaro Post author

      Io mi sono sempre trovato benissimo con CloudFlare. Di alternative ce ne sono, ad esempio “Incapsula”, “CloudFront”, “Sucuri”.
      Il fattore vincente di CloudFlare è che da un servizio free molto performante.

  3. Antonino

    Interessantissimo! Complimenti per l’articolo. Per quanto riguarda il prerender era ora che arrivasse anche su wp. Ho visto web in SPA con prerenderizzato che si aprono veramente in nanosecondi :)

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *