Indice dei contenuti dell'articolo:
L’oggetto di questo articolo nasce a puntino, dopo diverse settimane di “mancanza di ispirazione” su argomenti inerenti alle web performance. Vuoi perché il Black Friday ha assorbito le energie per lo scaling degli e-commerce dei clienti, vuoi perché stiamo mettendo molta carne sul fuoco con lo sviluppo di plugin per Prestashop e Magento, nonché la nostra soluzione dedicata di CDN per immagine adattive, ma soprattutto perché abbiamo parlato molto delle tecnologie in ballo ed in uso nel nostro stack software specifico per WordPress.
Chi ha letto e seguito gli articoli ed i post pubblicati nel corso del tempo, ha sicuramente notato come ci siano delle ricorrenze abituali sugli articoli tecnici quando si parla di Hosting WordPress o Hosting Linux in modo più generico.
Si finisce sempre di parlare di NGINX e Varnish come combo definitiva quando si parla di performance e velocità, dimenticando spesso quanto sia importante un tuning certosino per ottenere valori adeguati come un TTFB il migliore possibile.
Abbiamo parlato a lungo dell’importanza di un TTFB il più basso possibile, e di quanto sia importante ottenere una bassa latenza; tuttavia, non ci è mai capitato di poter documentare con un’analisi differenziale due siti identici con lo stesso stack ed un’ottimizzazione ulteriore dello stack software ed un tuning specifico per NGINX Web server.
Il caso specifico nato per caso.
La scorsa sera abbiamo postato sulla bacheca Facebook privata un post in cui si misurava il TTFB tramite la utility SpeedVitals.com, un servizio online che permette di misurare il TTFB da più location sparse per il mondo.
Da quello che era inizialmente un post “sterile”, scritto in una domenica uggiosa e senza troppi fini, se non quello di esternare una piccola Vanity Metrics e “farci belli”, ne sono scaturiti da li fino a tarda serata diversi commenti in cui molti hanno risposto postando i loro punteggi e le valutazioni che questo Tool online restituiva.
Tra i 26 commenti che potete visionare in basso a destra dell’immagine sopra, ci ha particolarmente colpito il commento di un nostro cliente che mostrava un TTFB particolarmente elevato se messo a confronto con quello postato nello screen sopra.
In particolar modo si evidenziava come la valutazione restituita fosse di grado B e che il tempo di scansione degli spider Google fosse non proprio bassissimo, arrivando a 141ms.
Considerando che lo stack software alla base era praticamente lo stesso, bisognava andare a rivedere sicuramente quale fossero le problematiche specifiche delle configurazioni dei servizi Varnish e NGINX per cercare di migliorare ed ottimizzare al meglio il tutto.
Analisi delle metriche del sito in oggetto.
Il caso ha voluto che la problematica sollevata fosse sotto il nostro più totale controllo e dunque seppur di domenica, abbiamo voluto addentrarci in un “lavoro di lima” consapevoli che sarebbe stato un’occasione ghiotta ed irripetibile per mostrare e dimostrare come un tuning sopraffino avrebbe potuto apportare dei vantaggi tangibili e finire col documentare il tutto con questo post che altro non è che un’analisi differenziale tra la situazione pre e post tuning.
Abbiamo pertanto deciso di utilizzare una utility che si chiama ByteCheck (bytecheck.com) che ci permette di misurare il Time To First Byte e scomporre il tempo totale nei vari step che compongono il TTFB totale.
A partire dalla risoluzione DNS, al tempo di connessione, al tempo di instaurazione della connessione crittografata, fino ai tempi di attesa e della delivery dei contenuti, come possiamo vedere nell’immagine seguente, in cui si evince in modo piuttosto evidente ed inopinabile che ci sia un waiting time particolarmente elevato di ben 240ms.
Viene oggettivamente da chiedersi cosa faccia il webserver (o l’intero stack) in quei 240ms, un tempo troppo basso per ipotizzare che la cache statica Varnish non stia funzionando correttamente, ed allo stesso tempo, un valore troppo elevato per ipotizzare che lo stack software stia funzionando normalmente al meglio delle possibilità.
Abbiamo pertanto voluto testare che la cache statica stesse funzionando correttamente, utilizzando la utility Linux CURL, ed esaminando la risposta degli header HTTP.
[root@lawebstar ~]# curl -I https://www.ilmiocaneleggenda.it HTTP/1.1 200 OK Server: nginx Date: Mon, 28 Nov 2022 00:26:46 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Vary: Accept-Encoding Vary: Accept-Encoding Strict-Transport-Security: max-age=86400; includeSubDomains X-Content-Type-Options: nosniff X-Frame-Options: DENY X-XSS-Protection: 1; mode=block Link: <https://www.ilmiocaneleggenda.it/wp-content/themes/parker/dist/js/main.js?ver=2.2.0v12>; rel=preload; as=script Link: <https://www.google-analytics.com/analytics.js>; rel=preload; as=script Link: <https://cdn.iubenda.com/cs/tcf/stub-v2.js>; rel=preload; as=script Link: <https://cdn.iubenda.com/cs/iubenda_cs.js>; rel=preload; as=script Link: <https://www.iubenda.com/cookie-solution/confs/js/32853419.js>; rel=preload; as=script Link: <https://www.ilmiocaneleggenda.it/wp-json/>; rel="https://api.w.org/" Referrer-Policy: no-referrer-when-downgrade X-Cacheable: YES X-Varnish: 1727731347 1727662746 Age: 4656 Via: 1.1 varnish X-Cache: HIT
La risposta in esame non lasciava dubbi al fatto che la Cache Statica Varnish stesse lavorando correttamente, avendo in cache la risposta da ben 4656 secondi e che la cache statica restituiva una HIT e non una MISS e pertanto trovava (e consegnava) la risposta già memorizzata nella cache.
Il problema, dunque, doveva essere a monte, secondo la logica “a panino” in cui NGINX è sia il webserver su cui gira il sito web, che il terminatore in reverse proxy della connessione HTTPS, considerando che Varnish non supporta HTTPS e che necessita di un terminatore HTTPS secondo lo schema seguente.
Abbiamo pertanto rivisto completamente la configurazione NGINX sia a livello globale che dei singoli Virtual Host, e aggiustando minuziosamente parametri come buffer, nonché abilitando alcune features ben documentate nelle ultime versioni di NGINX a partire dalla 1.22 in poi, abbiamo ottenuto un valore decisamente ottimale, portando il waiting time da 247ms a 124ms, ovvero di fatto dimezzando il TTFB finale.
Ovviamente, essendo un’azienda di hosting ci scusiamo anticipatamente se non mostriamo i file di configurazione specifici ne documentiamo le modifiche apportate nel dettaglio essendo di fatto del know how che tendiamo a non divulgare per ovvi motivi imprenditoriali.
L’importanza di un TTFB basso ed i vantaggi che si otterrà da questo tuning.
Dell’importanza del TTFB come accennavamo inizialmente ne abbiamo già parlato in questo articolo: Cos’è il TTFB? Come migliorare il Time To First Byte, tuttavia è bene evidenziare come Google con i suoi parametri Core Web Vitals, abbia decretato come un TTFB inferiore ai 200ms possa considerarsi buono, ed un TTFB superiore che necessita di miglioramenti.
Qualcuno potrebbe obiettare o chiedersi quali possano essere i vantaggi reali di un TTFB che sia compliant alle aspettative di Google, e se sia veramente così importante avere un TTFB al di sotto dei 200ms.
Quello che è certo e a cui dovrai prestare molta attenzione, è che la frequenza di scansione degli spider Google ed il TTFB sono direttamente correlati.
Puoi vederlo da uno storico come sopra di Search Console.
Puoi comprendere dalle due linee blu e arancio, che, come aumenta il tempo di risposta, (TTFB linea arancio), diminuiscono le richieste di scansione da parte di Google (linea Blu).
Viceversa, come il tempo di risposta TTFB diminuisce, aumentano invece le richieste di scansione di Google.
Se stai cercando di conoscere le statistiche di scansione di Google, in Search Console, vai su “Impostazioni” in basso nella colonna di sinistra. Nella sezione Scansione, troverai il pulsante “Apri rapporto” per le statistiche di scansione. Quando il rapporto è aperto, puoi selezionare la casella di controllo “Tempo medio di risposta (ms)” per aggiungere la metrica al grafico.
Google utilizza 200 ms come valore di soglia in altri test e rapporti, prima che visualizzino un avviso che indica che il tempo di risposta è elevato. Il tempo di risposta varia a seconda del tuo hosting, della qualità del sito e della configurazione generale della cache, della CDN, ed in questo caso del tuning del webserver.
Conclusioni ed osservazioni
Da questo caso reale e ben documentato, possiamo osservare come l’utilizzo dei giusti strumenti, possa non essere sufficiente per ottenere i migliori risultati, ottenibili invece dall’uso dei giusti strumenti, ma anche e soprattutto dall’utilizzo delle giuste configurazioni.
È altresì utile comprendere come le giuste configurazioni di mesi o anni fa, possano d’un tratto essere ritenute non più adeguate o addirittura sorpassate, da nuove metriche e nuovi requisiti che richiede un ciclo continuo di adattamenti ai nuovi requisiti.
Terremo in osservazione questo caso di studio per valutare anche a livello di indicizzazione con la utility SeoZoom, come questa ottimizzazione possa aver impattato sul posizionamento ed indicizzazione, valutando il grafico prima e dopo il 28 Novembre, data in cui abbiamo operato al miglioramento del tempo di risposta dei due siti in oggetto sullo stesso server (ilmiocaneleggenda.it ed ilmiogattoeleggenda.it) e valutando rispettivamente il trend dei due siti in una futura analisi differenziale.
