Indice dei contenuti dell'articolo:
Oggi parleremo di qualcosa che, a quanto pare, viene spesso trascurato nel mondo dell’hosting, sia dagli sviluppatori che dai sistemisti: gli Header HTTP.
Immagina di guidare una Ferrari da F1, una macchina potente e veloce, ma con la condizione di non conoscere bene come si guida una vettura da Gran Premio al massimo del suo potenziale. Cosa pensi che ne verrà fuori? Vinci la gara o fuori pista assicurato entro il primo giro?
Ma facciamo una piccola premessa, o forse uno sfogo. Il mondo dell’hosting al giorno d’oggi è, purtroppo, un disastro. Con la guerra dei prezzi lanciata da anni da Hosting Provider che vendono piani hosting a 100 euro l’anno (ma ne abbiamo visti anche a 30€), l’industria dell’Hosting è diventata una macchina da soldi che scala brillantemente la vendita dei propri servizi, ma non scala affatto l’applicativo ed i siti dei loro clienti. Insomma, si tratta di un business molto lucrativo ma con pochissima attenzione alle reali esigenze del cliente e problematiche intrinseche che ogni progetto realizzato “assemblando” plugin come WordPress normalmente nasconde.
Quando il webmaster dell’azienda che ha commissionato un e-commerce (su WooCommerce, Prestashop o Magento, poco ha importanza) entra in gioco comprando un piano hosting e pagandolo con la carta di credito, ecco che gli vengono rilasciate automaticamente le credenziali al pannello di controllo, FTP e database e, al limite, configurate le impostazioni di qualche cache più o meno valida.
Oltretutto, bisogna tener conto ad esempio che gran parte degli sviluppatori di plugin WordPress, abituati allo “spaghetti code”, sono perfettamente ignoranti riguardo agli header HTTP e al loro funzionamento, il che porta a siti con cache lato server che funzionano quasi come se non avessero affatto la cache. Di conseguenza, il cliente si ritrova con un sito lento, che genera frustrazione negli utenti finali, causando abbandoni, meno vendite, meno fatturato e meno utile.
La quasi totalità dei problemi di velocità su server che hanno comunque i giusti requisiti per essere veloci, nascono appunto dagli header HTTP, come il Cache-Control. Questo header ha lo scopo di gestire la cache sia lato browser che lato server o reverse proxy. Un utilizzo errato dell’header HTTP Cache-Control può portare ad una scadenza della cache lato server troppo prematura, rendendo un sito lento anche in presenza di cache lato server.
Spesso, è buona prassi e molto più conveniente affiancare la messa in produzione del sito del cliente ed ignorare a livello server gli header HTTP Cache-control che potrebbero essere errati o provenire da plugin installati con pseudo funzionalità di Cache applicativa che invaliderebbero la cache lato server.
Ecco nuovamente il paragone con la Ferrari: un buon hosting orientato alle performance è potenzialmente una macchina da Formula 1, ma il cliente o lo sviluppatore, non esperto di come si guida una F1 al massimo del suo potenziale, deve essere necessariamente limitato da alcuni accorgimenti, come il controllo elettronico della trazione e della frenata, al fine di evitare fuori pista. Nel nostro caso, ad esempio, una volta verificata che l’applicazione invia header HTTP errati, ci limitiamo ad ignorare alcuni header qualora vediamo che essi producano dei problemi di persistenza della cache, rendendola di fatto inutile o quasi.
L’Header Cache Control ed il bypass della Cache
Varnish Cache e FastCGI Cache sono due popolari strumenti di caching utilizzati per velocizzare i siti web e ridurre il carico sui server back-end. Tuttavia, sia Varnish Cache che FastCGI Cache rispettano gli headers Cache-Control.
Varnish Cache
Varnish Cache è un acceleratore HTTP estremamente veloce, flessibile e performante. Utilizza la cache in memoria per memorizzare le copie delle risposte HTTP e servirle più rapidamente alle successive richieste.
Supponiamo che il tuo server invii la seguente risposta:
HTTP/1.1 200 OK Cache-Control: no-cache Content-Type: text/html <p>Hello, world!</p>
In questo caso, anche se la risposta viene memorizzata nella cache Varnish, per ogni richiesta successiva, Varnish invierà una richiesta di convalida al server originale prima di servire la risorsa memorizzata nella cache. Se la risorsa non è cambiata, il server originale risponderà con uno stato HTTP 304 (Not Modified) e Varnish servirà la risorsa dalla cache. Se la risorsa è cambiata, il server invierà la nuova risorsa, che Varnish memorizzerà nella cache e servirà al client.
FastCGI Cache
Analogamente, FastCGI Cache è un metodo di caching basato su Nginx e FastCGI che può essere utilizzato per memorizzare nella cache intere pagine HTML o altri tipi di contenuti. Funziona allo stesso modo rispetto a Varnish per quanto riguarda la direttiva Cache-Control: no-cache.
Se si utilizza Cache-Control: no-cache, FastCGI Cache invierà una richiesta di convalida al server back-end prima di servire la risorsa dalla cache. Se la risorsa è stata modificata, il server back-end risponderà con la nuova risorsa, che FastCGI Cache memorizzerà nella cache e servirà al client.
In conclusione, l’uso dell’header Cache-Control: no-cache può essere una soluzione efficace quando si vuole avere un controllo granulare sul comportamento della cache per specifiche risorse. Tuttavia, è importante ricordare che ogni richiesta di convalida comporta una certa latenza, quindi l’uso eccessivo di no-cache può influenzare negativamente le prestazioni del sito web.
Il problema dell’uso inconsapevole di un Cache Control Errato.
La gestione della cache web, pur essendo un aspetto cruciale per le prestazioni di un sito, è spesso sottovalutata o mal compresa sia da sviluppatori che da committenti. Il committente, nella maggior parte dei casi, non ha le competenze tecniche per identificare un uso errato dell’header Cache-Control o per verificare il corretto funzionamento della cache. Questo diventa un problema quando si tratta di ottimizzare l’esperienza del visitatore o la scalabilità del sito.
Dall’altro lato, alcuni sviluppatori, in particolare quelli che lavorano su piattaforme come WordPress, spesso adottano un approccio noto come “spaghetti code”. Questo termine si riferisce a una struttura di codice disorganizzata, intricata e difficile da seguire o mantenere. È un modo di scrivere codice che può portare a una serie di problemi, tra cui inefficienze, errori difficili da rintracciare e, nel contesto della nostra discussione, un uso improprio degli headers Cache-Control.
In alcuni casi, gli sviluppatori di plugin WordPress possono utilizzare l’header Cache-Control: no-cache senza capire appieno le sue implicazioni. Potrebbero pensare che “no-cache” sia un modo sicuro per evitare problemi di coerenza dei dati, quando in realtà sta inibendo l’uso efficace della cache, che può essere disastroso in un ambiente di hosting ad alte prestazioni in cui si desidera cachare il più possibile.
Questo problema è aggravato dal fatto che anche molti sistemisti non comprendono completamente il ruolo dell’header Cache-Control. Si potrebbe facilmente installare uno stack software con full-page caching integrato, senza mai chiedersi se quella particolare configurazione è appropriata per il sito in questione. Non si chiedono se stiano effettivamente riducendo la latenza e migliorando il Time to First Byte (TTFB), o se stiano solo aggiungendo un “effetto cosmetico”, cioè mostrando headers HTTP di risposta che indicano l’uso di un sistema di caching che, a causa dell’uso improprio di Cache-Control, viene bypassato.
Ad esempio, si potrebbero vedere sempre dei risultati “MISS” o dei valori “Age 0”, che indicano che la risorsa non è stata servita dalla cache come previsto. Il risultato è un ambiente che sembra ottimizzato per le prestazioni, ma che in realtà non sta sfruttando appieno i vantaggi della cache.
Cache Control errati e CDN come CloudFlare ad esempio.
Le Content Delivery Networks (CDN) come CloudFlare sono progettate per migliorare le prestazioni di un sito web distribuendo il suo contenuto attraverso una rete globale di server. Queste CDN, seguendo gli standard e le best practices del settore, sono configurate automaticamente per rispettare gli headers Cache-Control che ricevono. Ad esempio, se un header arriva con Cache-Control: no-cache, CloudFlare bypasserà automaticamente la sua cache, proprio come ci si aspetterebbe.
Tuttavia, questo comportamento può diventare problematico in presenza di header Cache-Control mal configurati. CloudFlare, come altre CDN, opera come un reverse proxy, funzionando su versioni personalizzate di NGINX (prima di adottare la propria soluzione proprietaria, Pingora). Quindi, se un plugin o un’altra parte del sito invia un header Cache-Control: no-cache non necessario o improprio, CloudFlare onorerà quell’header, bypassando la cache e inoltrando la richiesta GET all’origin server. Questo comportamento può compromettere gravemente le prestazioni del sito, specialmente se si stanno utilizzando piani di servizio premium come i piani business di CloudFlare o estensioni come CloudFlare’s Automatic Platform Optimization (APO).
Automatic Platform Optimization (APO) di CloudFlare è un servizio che migliora ulteriormente le prestazioni del sito attraverso l’ottimizzazione del caching e la minificazione dei file. Ma anche con APO, se un plugin invia un header Cache-Control: no-cache, la CDN rispetterà quell’header e bypasserà la cache, compromettendo le prestazioni.
La situazione è ulteriormente complicata dal fatto che molti sviluppatori e sistemisti non sono abbastanza esperti o attenti per rilevare quando qualcosa non sta funzionando come dovrebbe. La chiave per evitare queste problematiche è un’attenta gestione degli header Cache-Control, assicurandosi che vengano utilizzati correttamente e solo quando necessario. Se non viene prestata la dovuta attenzione a questo aspetto, si rischia di sabotare involontariamente l’efficacia di una CDN come CloudFlare, annullando gli investimenti fatti in piani e servizi premium.
Il nostro approccio sistemistico sartoriale.
Uno dei motivi per cui preferiamo avere un piccolo colloquio in ogni richiesta di preventivo è comprendere la preparazione di chi abbiamo davanti. Non c’è nulla di male a non conoscere alcuni aspetti sistemistici in fondo. Nella quasi totalità dei casi, eccetto un paio di gruppi editoriali di punta, molto importanti sul panorama italiano, tutti i restanti non prestano minimamente attenzione alla responsabilità che si ha nell’usare correttamente gli header HTTP, ma lasciano che i vari plugin installati li inviino a loro piacimento senza nemmeno comprenderne il perchè.
Seguire un cliente nella messa in opera di un sito e prestare attenzione agli header potenzialmente sbagliati, è uno sforzo di tempo e risorse che non possono essere vendute al costo di hosting low cost, che si vantano con slogan e payoff alquanto pittoreschi, autocelebrandosi tutti come siano i migliori hosting. Che poi se tutti sono i migliori, qualcosa non torna, giusto?
Tuttavia, questo sforzo iniziale, che comporta necessariamente un costo molto più elevato dei piani low cost che si trovano abitualmente sul mercato, tende a dare al cliente la soluzione definitiva ai suoi reali problemi di velocità. Così, garantiamo un’esperienza utente fluida e veloce, un TTFB inferiore ai 50 millisecondi, ed una percentuale di HIT Ratio superiore al 95%. In altre parole, la quasi totalità delle pagine vengono servite immediatamente dalla cache lato server.
Rivendica le prestazioni che meriti. Assicura che il tuo sito web funzioni al massimo delle sue potenzialità!
Sei stanco di vedere le prestazioni del tuo sito web rallentate a causa di un cattivo utilizzo degli headers HTTP? Sei preoccupato che la tua cache possa non funzionare correttamente, compromettendo l’esperienza dei tuoi utenti e il tuo posizionamento SEO?
Non sei solo. Troppi siti web sono vittime di una cattiva gestione della cache, spesso senza che ne siano consapevoli. Ma non deve essere così. Con la giusta consulenza, puoi massimizzare le prestazioni del tuo sito web, garantendo un’esperienza utente fluida e veloce e un Time to First Byte (TTFB) inferiore ai 50 millisecondi.
Noi possiamo aiutarti. Siamo esperti nell’ottimizzare le performance dei siti web e abbiamo l’esperienza per identificare e correggere gli headers HTTP mal configurati che possono sabotare la tua cache. Siamo qui per aiutarti a ottenere il massimo dalla tua CDN, assicurandoci che ogni pagina del tuo sito web venga servita quasi istantaneamente dalla cache del server.
È tempo di agire.
Contattaci oggi stesso per una consulenza e scopri come possiamo aiutarti a migliorare le prestazioni del tuo sito web. Non lasciare che un cattivo utilizzo degli headers HTTP limiti il tuo successo online. Assicura il tuo futuro digitale con la nostra consulenza esperta.
Non aspettare.
