28 Novembre 2022

NGINX Tuning e Time To First Byte: Un caso di studio reale sul TTFB

Un caso di studio reale sui vantaggi in termini di TTFB dopo il tuning del web server NGINX

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.

SpeedVitals.com

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.

Post Facebook Marco Marcoaldi SpeedVitals

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.

Byte Check

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.

ilmiocaneleggenda TTFB Migliorato

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.

google-search-console-crawl-stats-response-time

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.

 

Hai dei dubbi? Non sai da dove iniziare? Contattaci !

Abbiamo tutte le risposte alle tue domande per aiutarti nella giusta scelta.

Chatta con noi

Chatta direttamente con il nostro supporto prevendita.

0256569681

Contattaci telefonicamente negli orari d’ufficio 9:30 – 19:30

Contattaci online

Apri una richiesta direttamente nell’area dei contatti.

INFORMAZIONI

Managed Server S.r.l. è un player italiano di riferimento nel fornire soluzioni avanzate di sistemistica GNU/Linux orientate all’alta performance. Con un modello di sottoscrizione dai costi contenuti e prevedibili, ci assicuriamo che i nostri clienti abbiano accesso a tecnologie avanzate nel campo dell’hosting, server dedicati e servizi cloud. Oltre a questo, offriamo consulenza sistemistica su sistemi Linux e manutenzione specializzata in DBMS, IT Security, Cloud e molto altro. Ci distinguiamo per l’expertise in hosting di primari CMS Open Source come WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart e Magento, affiancato da un servizio di supporto e consulenza di alto livello adatto per la Pubblica Amministrazione, PMI, ed aziende di qualsiasi dimensione.

Red Hat, Inc. detiene i diritti su Red Hat®, RHEL®, RedHat Linux®, e CentOS®; AlmaLinux™ è un marchio di AlmaLinux OS Foundation; Rocky Linux® è un marchio registrato di Rocky Linux Foundation; SUSE® è un marchio registrato di SUSE LLC; Canonical Ltd. detiene i diritti su Ubuntu®; Software in the Public Interest, Inc. detiene i diritti su Debian®; Linus Torvalds detiene i diritti su Linux®; FreeBSD® è un marchio registrato di The FreeBSD Foundation; NetBSD® è un marchio registrato di The NetBSD Foundation; OpenBSD® è un marchio registrato di Theo de Raadt. Oracle Corporation detiene i diritti su Oracle®, MySQL®, e MyRocks®; Percona® è un marchio registrato di Percona LLC; MariaDB® è un marchio registrato di MariaDB Corporation Ab; REDIS® è un marchio registrato di Redis Labs Ltd. F5 Networks, Inc. detiene i diritti su NGINX® e NGINX Plus®; Varnish® è un marchio registrato di Varnish Software AB. Adobe Inc. detiene i diritti su Magento®; PrestaShop® è un marchio registrato di PrestaShop SA; OpenCart® è un marchio registrato di OpenCart Limited. Automattic Inc. detiene i diritti su WordPress®, WooCommerce®, e JetPack®; Open Source Matters, Inc. detiene i diritti su Joomla®; Dries Buytaert detiene i diritti su Drupal®. Amazon Web Services, Inc. detiene i diritti su AWS®; Google LLC detiene i diritti su Google Cloud™ e Chrome™; Microsoft Corporation detiene i diritti su Microsoft®, Azure®, e Internet Explorer®; Mozilla Foundation detiene i diritti su Firefox®. Apache® è un marchio registrato di The Apache Software Foundation; PHP® è un marchio registrato del PHP Group. CloudFlare® è un marchio registrato di Cloudflare, Inc.; NETSCOUT® è un marchio registrato di NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, e Kibana® sono marchi registrati di Elastic N.V. Hetzner Online GmbH detiene i diritti su Hetzner®; OVHcloud è un marchio registrato di OVH Groupe SAS; cPanel®, L.L.C. detiene i diritti su cPanel®; Plesk® è un marchio registrato di Plesk International GmbH; Facebook, Inc. detiene i diritti su Facebook®. Questo sito non è affiliato, sponsorizzato o altrimenti associato a nessuna delle entità sopra menzionate e non rappresenta nessuna di queste entità in alcun modo. Tutti i diritti sui marchi e sui nomi di prodotto menzionati sono di proprietà dei rispettivi detentori di copyright. Ogni altro marchio citato appartiene ai propri registranti. MANAGED SERVER® è un marchio registrato a livello europeo da MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italia.

SOLO UN ATTIMO !

Vorresti vedere come gira il tuo WooCommerce sui nostri sistemi senza dover migrare nulla ? 

Inserisci l'indirizzo del tuo sito WooCommerce e otterrai una dimostrazione navigabile, senza dover fare assolutamente nulla e completamente gratis.

No grazie, i miei clienti preferiscono il sito lento.
Torna in alto