Fastest Cache : accelerare il tuo sito con Varnish e NGINX

Procédure

Perché accelerare la velocità di caricamento del vostro sito ? 

È bene sapere che la velocità di caricamento del vostro sito è fondamentale per garantirne il successo. Per un’azienda, ad esempio, questo dà una prima immagine ai suoi visitatori. Inoltre, un caricamento troppo lungo di quest’ultimo può avere un impatto sul posizionamento del vostro sito sui principali motori di ricerca e non consentirà un’esposizione sufficiente per farlo vivere.

Non esiste una soglia da non superare per quanto riguarda il caricamento delle vostre pagine web. Tuttavia, il tempo di caricamento della maggior parte dei siti internet è inferiore a tre secondi.

Che cos’è Fastest Cache e a cosa serve ?

Lo strumento Fastest Cache è un sistema progettato e sviluppato da LWS che consente di ottimizzare le prestazioni di caricamento del vostro sito internet grazie all’utilizzo di meccanismi di cache delle pagine, configurati a livello del server web. Lo strumento combina le tecnologie fornite da NGINX e Varnish.

NGINX è un server web orientato alle prestazioni che consente di gestire molte più richieste rispetto al tradizionale server web Apache HTTPd Server (vedi il nostro articolo del blog intitolato “Apache VS Nginx : Test di prestazioni”). LWS utilizza NGINX per poter ricevere a monte un volume elevato di richieste HTTP senza compromessi in termini di prestazioni. Queste possono poi essere filtrate in modo efficiente ed eliminare le richieste malevole (vedi LWS Protect) e instradare le richieste HTTP al server di cache Varnish o LiteSpeed, a seconda della scelta del cliente dalla propria interfaccia di hosting.

Varnish è un servizio HTTP che implementa un meccanismo di cache delle pagine consentendo di memorizzare in cache il risultato di una richiesta HTTP nella memoria RAM.

Con le giuste configurazioni in atto, NGINX consente di accogliere più richieste sul vostro sito internet, e Varnish permette sia di accelerare il tempo di caricamento della vostra pagina sia di ridurre il consumo di CPU e memoria RAM.

Come funziona il servizio Fastest Cache ?

Funzionamento senza cache

Per comprendere meglio il funzionamento, vedremo innanzitutto come avviene senza un sistema di cache affinché il visitatore possa vedere il vostro sito.

1. Il visitatore richiede la pagina al server web. Esempio: index.php
2. Il server web esegue gli script necessari (PHP, Python, Node.js …)
3. Il server web riceve il risultato dell’esecuzione
4. Il server web invia la pagina HTML risultante dall’esecuzione dello script

Funzionamento con il modulo Fastest Cache

Quando Fastest Cache è attivato, un server di cache viene introdotto tra il visitatore e il server web.

L’obiettivo è ridurre il numero di esecuzioni di script necessarie conservando il risultato dell’esecuzione in memoria per le richieste successive che richiedono la stessa risposta. Ciò consente di non eseguire più volte lo stesso script per ottenere lo stesso risultato.

Così, eliminiamo il tempo di attesa dell’esecuzione dello script sul tempo di caricamento della pagina e, allo stesso tempo, risparmiamo le risorse utilizzate durante l’esecuzione dello script.

11. Il visitatore richiede la pagina al server web. Esempio: index.php
2. Fastest Cache verifica se la risposta può essere ottenuta dalla cache :

• Se sì, la pagina viene restituita direttamente al visitatore senza necessità di accedere al servizio web e senza eseguire lo script
• Se no, la pagina viene generata dal server web, il che comporta l’esecuzione dello script (PHP, Node.js, Perl, Ruby, …). Una volta generata la pagina, Fastest Cache determina se la risposta può essere mantenuta in cache.
  • Se sì, la pagina viene salvata nella memoria cache e restituita al visitatore
  • Se no, la pagina viene restituita al visitatore senza essere salvata nella memoria cache

Si osserva che quando una pagina è memorizzata nella cache, si evitano l’elaborazione da parte del server web e l’esecuzione dello script, riducendo notevolmente il tempo di esecuzione e il consumo di risorse.

Comportamento del sistema di cache

Fastest Cache si basa su molteplici segnali per decidere il comportamento di cache adottato:

• Estensione del file nell'URL
• Presenza e contenuto dei parametri URL (query strings)
• Intestazione di risposta Cache-Control
• Cookie

Fastest Cache rileva inoltre alcuni CMS ed estensioni / moduli e implementa comportamenti di cache specifici legati a questi strumenti.

Comportamento alla ricezione della richiesta

Fastest Cache mette in cache solo i metodi HTTP GET e HEAD.

Quando un visitatore visita un URL, Fastest Cache normalizza la richiesta rimuovendo i cookie e i parametri URL che non influiscono sul rendering finale dello script lato server (parametri URL di Google Analytics, cookie legati a script Javascript ...).

Una volta normalizzata, la richiesta viene verificata per vedere se contiene un’autenticazione HTTP (intestazione di richiesta HTTP Authorization) o se restano dei cookie (intestazione di richiesta HTTP Cookie). Se sì, allora la richiesta verrà rinviata al server web senza passare attraverso il sistema di cache.

Comportamento all’invio della risposta

Se la richiesta non ha bypassato la cache al momento della ricezione, Fastest Cache analizza nuovamente la risposta HTTP fornita dal server web e verifica se è possibile memorizzare in cache la risposta per un uso futuro.

Se la risposta HTTP fornisce un intestazione di risposta HTTP Cdn-Cache-Control, Fastest Cache rispetta immediatamente quanto ivi definito :

• Se vi è definito no-store, no-cache o private, Fastest Cache restituisce la risposta al visitatore senza conservarla nella cache.
• Se vi è definito s-maxage o max-age, Fastest Cache utilizza immediatamente questo valore come durata di permanenza della pagina nella cache.

Se Cdn-Cache-Control è definito insieme a Set-Cookie, Cdn-Cache-Control verrà ignorato e la risposta non sarà conservata nella cache.

I file statici corrispondenti a temi, plugin, upload e core WordPress vengono automaticamente conservati nella cache per 30 giorni.

Se la risposta HTTP proviene dal sistema di cache delle pagine LWS Optimize, WP Fastest Cache, Airlift, W3 Total Cache, WP Rocket, WP Optimize o FastPixel, essa viene conservata nella cache per 7 giorni. Questi plugin WordPress provvederanno essi stessi alla purga della cache Varnish quando rimuovono la cache delle pagine.

Se la risposta HTTP proviene dalla cartella /_next/static, questa viene anch’essa conservata nella cache per 7 giorni.

Se la risposta HTTP restituisce un codice HTTP 404, questa viene conservata nella cache per 900 secondi. Ciò permette di evitare ulteriori richieste inutili al database MySQL, in particolare per WordPress.

Se la risposta HTTP restituisce un codice HTTP 500, la risposta non viene mai conservata nella cache.

Se la risposta HTTP contiene un cookie (intestazione di risposta HTTP Set-Cookie), la risposta non viene mai conservata nella cache.

Se la risposta HTTP fornisce un intestazione di risposta HTTP Cache-Control o Surrogate-Control, Fastest Cache segue il comportamento di cache atteso per i browser. Se queste intestazioni sono fornite con Cdn-Cache-Control, Fastest Cache ignora Cache-Control e Surrogate-Control a favore di Cdn-Cache-Control. Ciò consente, ad esempio, di obbligare il browser a fare una richiesta HTTP per consultare un elenco di articoli a ogni visita, senza che l’elenco di articoli sia assente dalla cache del server.

Presentazione dell’interfaccia e attivazione del servizio

Fastest Cache si presenta sotto forma di un’icona in cPanel nella sezione “Performance”.

Una volta nell’interfaccia, il dominio principale, i domini aggiuntivi e i sottodomini sono visualizzati nell’elenco.

• La colonna “Stato della cache” mostra lo stato di attivazione della cache. Se è su “Attivato” allora la cache è attiva.
• Il pulsante “Svuotare la cache” consente di eliminare tutti i dati in cache per questo nome di dominio in particolare.
• Il pulsante “Disattivare la cache” consente di disattivare la cache.
• Il pulsante “Attivare la cache” consente di attivare la cache.
• Il pulsante “Cambiare la modalità di funzionamento” consente di modificare il comportamento del sistema di cache. Queste modalità saranno spiegate subito dopo.

Le diverse modalità di cache

Per impostazione predefinita, il sistema di cache adotta la modalità « Utilizzo generale » che si adatta agli utilizzi generali. Esistono tuttavia altre modalità :

Modalità sviluppatore : identica alla disattivazione della cache, consente di bypassare il sistema di cache durante i periodi di sviluppo.
WordPress : una modalità di cache più adatta a WordPress in cui la gestione delle cartelle (wp-content, wp-admin, …) e dei cookie specifici di WordPress è migliorata.
Prestashop : una modalità di cache più adatta a Prestashop in cui la gestione delle cartelle e dei cookie è migliorata.

Purga della cache

Oltre all’interfaccia cPanel che consente di svuotare la cache, è possibile svuotare manualmente la cache dal terminale SSH dell’account cPanel o da uno script ospitato sul server.

Lanciate dal vostro hosting (script PHP del vostro sito, attività Cron o terminale SSH), queste procedure non richiedono né token API né credenziali : Fastest Cache accetta direttamente i metodi HTTP PURGE.

Purga della cache con cURL

Svuotare la cache di una pagina :

curl -X PURGE https://mon-site-web.com/mapage.php

Questo consentirà di svuotare la cache dell’URL https://mon-site-web.com/mapage.php.

Svuotare la cache di una cartella :

curl -X PURGE 'https://mon-site-web.com/wp-content/uploads/.*'

Questo consentirà di svuotare tutte le cache degli URL che iniziano con 'https://mon-site-web.com/wp-content/uploads/'

Svuotare la cache di un sito

curl -X PURGE https://mon-site-web.com/.*

Per l’insieme di questi tre comandi, sono possibili tre risposte :

Codice HTTP 200 : la purga è andata a buon fine senza errori.

Codice HTTP 4xx : la purga non è autorizzata.

Codice HTTP 5xx : si è verificato un errore.

Purga automatica con uno script PHP (attività Cron)

Lo script seguente svuota la cache di tutto il sito, o di alcune pagine soltanto. Copiatelo in un file purge-cache.php del vostro hosting, poi indicate il vostro dominio in $site. Per svuotare solo alcune pagine, elencatele in $pages.

 'PURGE',
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CONNECTTIMEOUT => 5,
        CURLOPT_TIMEOUT        => 20,
    ]);
    curl_exec($ch);
    $code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);
    return $code;
}

if (empty($pages)) {
    echo date('Y-m-d H:i:s') . ' purga completa : HTTP ' . purger($site . '/.*') . PHP_EOL;
}
else {
    foreach ($pages as $page) {
        echo date('Y-m-d H:i:s') . ' ' . $page . ' : HTTP ' . purger($site . $page) . PHP_EOL;
    }
}

Per avviarlo automaticamente, ad esempio ogni notte, create un’attività Cron che esegua questo file con PHP. Se volete semplicemente svuotare tutta la cache, l’attività Cron può anche eseguire direttamente :

curl -s -o /dev/null -X PURGE 'https://mon-site-web.com/.*'

Purga con un plugin o modulo

La maggior parte dei plugin/moduli che hanno un’integrazione Varnish è compatibile con il meccanismo di purga interno di Fastest Cache.

Ecco alcuni plugin testati e verificati compatibili :

• LWS Optimize
• WP Fastest Cache
• WP Rocket
• Proxy Cache Purge

Rilevamento HTTPS e reindirizzamenti

Lo stato HTTPS e le porte indicate su Apache vengono iniettati nell’ambiente e generalmente non richiedono alcuna modifica aggiuntiva.

Tuttavia, se il rilevamento HTTPS non è funzionante con Fastest Cache, ciò può causare cicli di reindirizzamento infiniti. Pertanto, sarà necessario modificare i dati di rilevamento.

Le intestazioni HTTP di fiducia per il rilevamento sono :

• X-Forwarded-Proto
• X-Forwarded-Port

Quindi, se utilizzate il seguente reindirizzamento HTTPS con un .htaccess :

RewriteEngine On 
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

e se ciò non funziona, potete sostituire la variabile SERVER_PORT con X-Forwarded-Proto :

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !on
RewriteRule ^(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R]

CloudFlare e altri CDN

I CDN di tipo CloudFlare possono filtrare le richieste HTTP che potrebbero bloccare le richieste “PURGE” e utilizzate da Fastest Cache per svuotare la cache. Vi si consiglia quindi di specificare l’indirizzo IP del server durante la vostra purga con curl così da bypassare i CDN durante le azioni di purga :

curl -X PURGE --resolve mon-site-web.com:443:IP_DU_SERVEUR 'https://mon-site-web.com/.*'

I CDN possono inoltre contenere un livello di cache supplementare che dovete gestire indipendentemente dalla cache fornita da Fastest Cache.