Prestazioni del sito web: un approfondimento tecnico su Caching, Gzip, Render Blocking, Minify Images, Ampn e Cdn

Perché guardare sempre alle prestazioni del proprio sito?

Sicuramente per buona creanza nei confronti del lavoro svolto, ma i motivi validi sono differenti.
Iniziamo col dire che un sito web, un blog o un qualunque progetto online, oltre a rispettare parametri visivi dovuti alla esperienza di navigazione, alla qualità dell'impaginato e alla completezza dei contenuti, deve (o dovrebbe) anche avere delle perfomance adatte ad essere fruito su tutti i dispositivi più comuni (specialmente mobile), in tempi relativamente brevi e senza costringere l'utente che vi atterra sopra ad attese ingiustificate, che tutto fanno tranne fidelizzare la visita e trattenere chi naviga sulle proprie pagine.

Spesso e volentieri, infatti, ci capita di dover attendere secondi preziosi prima di riuscire a visualizzare correttamente una risorsa e ancora più spesso siamo tentati di non aspettare quel tempo (che sembra irrisorio ma non lo è), chiudere o tornare indietro con la navigazione e cercare altrove.

Questo perché per una serie di motivi, ci è sembrato di attendere troppo per soddisfare il nostro bisogno momentaneo e nell'estrema fretta di recuperare informazioni, abbiamo deciso di tentare altrove.

Quanto dura la nostra attenzione?

Pochi secondi; siamo sui 2/3 secondi di attesa per la visualizzazione di un primo contenuto ed arriviamo forse ai 6 se siamo convinti delle prime cose che ci compaiono davanti. In questo breve intervallo, il compito di una pagina web è quello di attrarre, spesso sedurre ed infine convincere o convertire la visita in quello che ci è necessario. 

Con l'utilizzo sempre più massiccio dei CMS (Content Management System) come WordPress, Joomla, Prestashop o Magento per la realizzazione di contenuti sui vari generi, è diventato sempre più necessario badare alle performance di quello che mettiamo online, perché se è vero che da una parte questi sistemi sono già abbastanza ottimizzati per rendere al meglio anche sotto questo profilo, è altrettanto vero che a seconda del tipo di utilizzo, al tema installato ed alle capacità di chi se ne serve, spesso questi parametri tendono a peggiorare nei valori e quindi è utile sapere se/come provare ad intervenire per risolvere o almeno mitigare le cose.

Come verificare che le performance siano nella norma?

Esistono ovviamente accorgimenti tecnici, alcune soluzioni rapide che si implementano facilmente ed esiste proprio il fattore umano. Iniziamo dall'ultimo, che è di norma il più facile da controllare.

Partiamo dal principio dicendo che, come accade per la maggior parte dei browser, il contenuto già visualizzato almeno una volta viene memorizzato in quella che comunemente chiamiamo cache del browser.

Che cos'è la cache?

Senza scendere troppo nel tecnicismo, è una sorta di area di memoria temporanea, che raccoglie gli ultimi dati sulla navigazione e li tiene appunto memorizzati, per renderli più velocemente disponibili negli accessi successivi. Quest'area ha una capienza massima, che una volta raggiunta, continua sempre a memorizzare ma cancellando i contenuti esistenti da più tempo e riscrivendo su quelli. 

Se visualizziamo i nostri progetti (o quelli a cui lavoriamo) più volte nello stesso browser senza ripulire prima la cache, probabilmente non vedremo la situazione attuale e veritiera di come vanno realisticamente le cose in termini di velocità di caricamento.

Forse possiamo esserci accorti una prima volta di qualcosa che non ci è sembrato troppo ben fatto da quel punto di vista, ma ci siamo andati leggeri e alla fine la possibile problematica è passata come si suole dire "in cavalleria".

Il controllo umano ad occhio nudo, è il primo passo da percorrere sempre e comunque dopo ogni aggiornamento, modifica, messa in opera e rinnovamento di un progetto web, perché se a noi che ci mettiamo mano sembra già che sia tutto troppo lento e tutto troppo difficile da raggiungere o complesso per come è strutturato, probabilmente lo è davvero, ed è altrettanto probabile che rispecchi esattamente la prima impressione che può avere un utente con un minimo di preparazione o di interesse generale per quello che sta cercando lì da noi.

Tra gli accorgimenti da usare quindi, svuotare sempre la cache del browser (ognuno ha le sue impostazioni) e provare ad accedere al sito avendola pulita, verificando se i tempi di visualizzazione dei contenuti siano quantomeno sopportabili, passando poi alle verifiche e agli aggiustamenti tecnici che andiamo a vedere di seguito.

I fattori principali che contribuiscono al peggioramento delle prestazioni di un sito web

Facciamo un elenco delle casistiche più probabili perché sono quelle che affliggono la maggior parte dei progetti online, per poi andare a vedere più nello specifico come risolverle. Molte delle cause sono fin troppo tecniche ma vediamo di spiegarle nel modo più facile e comprensibile possibile.

Qualità del servizio di Hosting

Il servizio che andiamo ad acquistare ha molta importanza sulle prestazioni del progetto in corso. 
I Mantainer, quindi le società che ci permettono di acquistare ed avere accesso allo spazio web legato al dominio, propongono offerte e pacchetti più o meno adatti, relativamente a budget di spesa ponderati per ogni tipo si necessità.

Dobbiamo dire però che nella norma, se non specificato e se non andiamo noi a cercare soluzioni particolari, quello che si va a comprare è quasi sempre un hosting condiviso (shared hosting), in cui molti siti attingono ad un pool comune di risorse server. In questo caso, lo spazio web, la RAM e la CPU delle macchine fisiche che fungono da base dell'hosting, sono suddivisi tra tutti gli utenti e/o siti in essere su quelle strutture.

L'hosting condiviso è una soluzione particolarmente amata e conveniente soprattutto per i principianti, ma va da sé che essendo un'unica macchina con molti utenti probabilmente al lavoro in contemporanea, non può essere certo una configurazione con delle performance spaziali o adatte a lavori di grandi dimensioni, che forse devono ricevere anche una massiccia dose di traffico.

Per approfondire leggi il post:  Come scegliere il miglior provider di web hosting.

Pagine pesanti da caricare

Ogni pagina che andiamo a realizzare ha un suo peso preciso, proprio in termini di MegaByte. Ogni foto, ogni oggetto speciale, ogni script, ogni contenuto anche testuale pesa e quindi deve essere visualizzato (scaricato) al momento della fruizione da parte del browser di chi accede alla risorsa.

Più pesa una pagina, maggiore è il tempo necessario per la visualizzazione dei suoi contenuti, peggiori sono quindi le performance di quella pagina specifica.

Ovviamente potrebbero esserci diverse ragioni per voler tenere online determinati tipi di pagine, ma è giusto sapere come e quando ottimizzare al meglio le cose.

Eccesso o male utilizzo di plugin e script esterni di terze parti (specialmente con i CMS)

Non tutti sono sviluppatori provetti e non tutti possono essere in grado di mettere mano al codice sorgente di una pagina o di un tema caricato sul CMS di fiducia, quindi si ricorre spesso all'utilizzo di plugin e/o piccoli script esterni per supplire a delle richieste di un cliente o per donare nuove funzionalità al progetto e renderlo più accattivante. 

Quello che dobbiamo sapere è che ogni risorsa che andiamo ad aggiungere aumenta di norma il quantitativo codice, richieste lato server e dati che devono essere scaricati dai browser essendo necessari al funzionamento di "ogni aggiunta", quindi di conseguenza, aumentano i tempi di caricamento generale del nostro sito con tutte le pagine di cui è composto.

Per approfondire leggi il post:  Come ottimizzare WordPress per la SEO: la mia lista di plugin e tool.

Come migliorare le prestazioni di un sito web

Una gestione quasi parsimoniosa delle risorse esterne può aiutare di molto il miglioramento delle performance generali, ma qualora non fosse possibile, dovremo correre ai ripari con le soluzioni tecniche che andiamo a vedere ora.

1. Lavorare sul Caching delle risorse

Permettere una memorizzazione specifica e ponderata delle risorse presenti sul nostro sito è una delle risoluzioni che possiamo adottare per aumentare le performance sui progetti che gestiamo. Come già accennato poco più sopra, è una strategia che funziona ovviamente dalla seconda volta in cui lo stesso utente decide di visitare i contenuti che pubblichiamo, ma su siti/blog/forum realizzati appositamente per generare traffico con un ritorno più o meno ampio di utenti, è una strategia decisamente efficace.

Come possiamo fare?

Parlando di CMS, esistono varie opzioni attraverso l'utilizzo di alcuni plugin, tra cui ad esempio per WordPress (che è tra i sistemi più usati) WP Rocket, WP3 Total Cache o anche Fast Velocity Minify. I plugin sono di facile installazione ed utilizzo, ma la raccomandazione più grande è quella di preparare sempre un backup di tutta la struttura prima di procedere, poiché non possiamo sapere a prescindere e con precisione dove andranno ad impattare i nuovi script e se influiranno in maniera adeguata su tutto.

Se non abbiamo a disposizione un CMS però, possiamo ricorrere al sistema più sicuro e che funziona con ogni tipo di soluzione con cui è stato realizzato il lavoro, ossia la modifica delle specifiche del file .htaccess (sì, si chiama proprio così) all'interno della root (cartella principale) del nostro spazio web. Parliamo di un file di configurazione relativo al Web Server, che serve (anche) per abilitare o disabilitare funzionalità molto specifiche inerenti alla manipolazione delle risorse generali, tra cui i tempi di rilascio della cache da sfruttare per ogni singolo tipo di contenuto.

NB: il file .htaccess è manipolabile anche sui CMS, se siamo capaci di farlo. Con la modifica di questo tipo di file, possiamo ad esempio comunicare al browser dell'utente di non scaricare nuovamente un determinato tipo di risorsa per un tempo prestabilito, identificando quella interessata in base alla sua estensione. Questo controllo è fondamentale per gestire al meglio la struttura, senza andare a riscaricare tutto quello che può rimanere invariato nel corso del tempo, come per esempio i fogli di stile, i file JavaScript o le immagini.

Ovviamente, per gestire al meglio questi parametri è necessario saper mettere mano al file .htaccess, ma per intervenire ed avervi accesso è sufficiente scaricarlo dal Web Server ed aprirlo con un editor di testo NON VISUALE, tipo il classico blocco note (su PC, text-edit per Mac).

Vediamo due righe di codice, almeno per i metodi più usati.

A) Gestione del processo di Caching con il Cache-Control

Possiamo abilitare questa feature in un colpo solo su ogni aspetto del nostro lavoro solo con una semplice stringa nel file, come questa qui sotto:

Ma potrebbe essere più utile (anche in base alla struttura del sito in oggetto) controllare solo uno specifico tipo di file, quindi: 
 

Sembra difficile, ma possiamo spiegare ogni singola voce che abbiamo usato, quindi: 

1. filesMatch informa il browser di quali estensioni deve rispettare le nuove direttive di caching; 
2. Header set si preoccupa di andare ad impostare una header del documento dove vengono espresse tutte le scadenze delle richieste per i contenuti da mantenere in cache.
3. max-age gestisce la durata della cache, quindi la sua scadenza nel tempo, ed è espressa in secondi. Nel caso specifico (se ben conto), è corrispondente ad un anno.
4. public specifica che questa richiesta è valida per il browser di ogni utente ed anche per una CDN (Content Delivery Network). Se fosse impostata su private, sarebbe valida solo per la prima parte di visitatori.

B) Utilizzo del Modulo Expires

Con questo secondo metodo invece, possiamo risolvere adeguatamente la cosa, impostando un lasso di tempo in cui il browser può utilizzare la risorsa in memoria senza andare ad effettuare controlli sulla disponibilità di una più giovane.

Come per la precedente, vediamo il tipo di istruzioni da utilizzare sempre nel file .htaccess:

Più facilmente intuibile rispetto al primo, esplicita per ogni tipologia di file, l'arco di tempo che deve trascorrere prima che il browser effettui nuovamente la richiesta.

Il modulo viene dichiarato (IfModule mod_expires.c), reso operativo (ExpiresActive On) e poi messo in attività su ogni estensione che in quel momento ci fa comodo controllare. La data di scadenza è in questo caso esplicitata in forma verbale, ed ovviamente, sempre in inglese.

2. Utilizzare la compressione Gzip

La compressione viene attivata sui server web, e riduce notevolmente il peso delle risorse come l'output dell'impaginato in HTML, i file JavaScript e i fogli di stile durante lo scaricamento dei dati da parte del browser. 

NB: Non lavora sulle immagini, che seguono un processo diverso. 

Come funziona?

In soldoni, il browser dell'utente che arriva sulla pagina in questione riceve le risorse compresse e le decomprime istantaneamente, risparmiando di molto (per alcune situazioni fino a quasi l'80%) sul tempo di recupero e quindi di caricamento della pagina stessa.

La compressione Gzip è in uso sulla maggior parte dei browser più conosciuti da moltissimi anni, ma va verificata e va capito se è attiva per il nostro web server. 

Come verificare se la compressione Gzip è attiva

Esiste più di un modo per verificare l'esattezza della cosa, ma il più veloce e semplice, che non richiede conoscenze tecniche approfondite, è quello di utilizzare uno dei tanti servizi gratuiti come gidnetwork oppure websiteplanet in cui basta solo inserire l'URL del sito in questione per verificare che tutto sia già attivo. 

Abilitare la compressione Gzip se non è attiva

Possiamo abilitarla sui vari web server seguendo più metodi:

NB: le stringhe qui sotto sono comuni a tutti i tipi di file che andiamo a manipolare e sono facili da reperire online. Ovviamente, per completezza le mettiamo interamente ma è ovvio che possono essere personalizzate in base alle esigenze.

1. Tramite il cPanel

I servizi di hosting più recenti mettono in condizione gli utenti di gestire quello che si chiama cPanel, ossia un pannello di amministrazione piuttosto completo che tra le varie opzioni di configurazione ha anche la possibilità di gestire l'attivazione di questo servizio. Di solito, se il cPanel è presente, vi si può accedere o direttamente dal pannello di amministrazione utente sul sito del Mantainer dove si è registrato l'hosting, oppure direttamente da url, digitando (a seconda di dove abbiamo acquistato il servizio) cpanel.dominio.estensione oppure dominio.estensione/cpanel.

2. Su web server Apache (hosting Linux) e attraverso il file .htaccess

Come accaduto anche per la gestione della cache, se vogliamo ragionare in modo più capillare, dobbiamo mettere mano a questo file, come da esempio qui sotto, esplicitando una volta avviato e messo in operativo il modulo, il comando per ogni tipo estensione che deve essere compresa nella compressione:

3. Su web server NGINX attraverso il file nginx.conf

Idem per il file .htaccess su server Apache, va modificato questo file con:

4. Abilitare Gzip su IIS

Se il web server è IIS (caso più raro ma possibile), ci sono due diversi tipi di compressione: statica e dinamica. La documentazione ufficiale spiega come abilitare la compressione.

Perché raro ma possibile? Perché, di norma, un CMS come i più classici citati sopra è realizzato in PHP, linguaggio di programmazione server-side tipico delle macchine Linux, con WebServer nativo Apache e non IIS, invece proprietario delle soluzioni Windows dove si prediligono il buon vecchio linguaggio ASPX, CSHARP e .NET (si, col punto anche lui). 

Qui la documentazione ufficiale Microsoft.

3. Gestire le risorse per il Render Blocking

Questo è uno dei motivi che più spesso sono alla base di un caricamento fin troppo lento di una pagina web. Normalmente, e specie con i CMS, è difficile impedire l'utilizzo da parte del tema o di plugin aggiunti, di file CSS e JavaScript anche fin troppo complessi e pesanti, quindi è normale ritrovarsi nella situazione di dover gestire al meglio quello che solitamente viene chiamato contenuto Above The Fold, ossia il contenuto visualizzato nella prima schermata che l'utente ha a disposizione nella sua visualizzazione, e che deve essere subito utile, ancor prima che il visitatore stesso effettui lo scroll iniziale. 

Queste risorse di blocco vengono caricate (solitamente) nella prima parte del documento, quindi nella sezione HEAD e richiedono delle frazioni di secondo per essere correttamente gestite dal browser. Frazioni che unite al resto dei contenuti possono allungare di molto la renderizzazione corretta della pagina completa.

Il browser quindi:

1. Scarica l'output della pagina attuale in formato HTML;
2. Prende in carico i file CSS/JavaScript/vari;
3. Passa poi ai contenuti testuali e le immagini contenute nella struttura;
4. Contestualmente, per ognuno verifica in ogni passaggio CSS e JS.

Questo, al fine di assicurarsi che tutto sia in ordine e procedendo solo dopo con la presentazione finale del contenuto completo all'utente. Visto quante cose in pochi attimi? Il problema ora sta nel fatto che mentre in quei pochissimi secondi il browser effettua tutte queste verifiche, gli utenti sono davanti ad un contenuto vuoto o comunque incompleto, in attesa del caricamento effettivo e potrebbero stancarsi, andandosene via.

Come ottimizzare allora?

Nel caso dei fogli di stile è utile ad esempio chiamare il CSS attraverso il metodo <link rel="style.css" href="url_del_file_css">, ma spesso nei temi che si installano è presente la chiamata attraverso un altro metodo che prende il nome di import, espresso nel modo seguente: @import url("url_del_file_css") che costringe il browser a verificare la correttezza dell'importazione prima di capire se va a buon fine o meno, occupando tempo prezioso. 

Un secondo accorgimento è  quello per cui può essere utile non frammentare troppo i fogli di stile ma utilizzarne meno anche se più corposi.

La soluzione risulta esteticamente meno elegante ma riduce i tempi di ricerca da parte del browser e quindi anche di caricamento finale.

Nel caso di file Javascript, invece, la situazione è un po' più complessa perché bisogna conoscere davvero l'esatta ubicazione di ogni file, come interviene ognuno nella renderizzazione della pagina e come si possono spostare o manipolare. Fortunatamente, attraverso uno strumento di casa Google, possiamo provare a mandare avanti un'analisi (di ampio respiro) sul nostro sito, per avere un report rapido sulla situazione e sapere se/dove/come intervenire per spostare anche a mano le risorse. Parliamo del Google Page Speed Insights, che in pochi passi ci fa vedere ogni singola risorsa che bisognerebbe andare ad ottimizzare.

PS: esistono parecchi strumenti che possono darci informazioni più o meno complete su quello che facciamo (GT Metrix e WebPagetest ad esempio), ma prendiamo in esame quello di casa Google visto che la maggioranza degli utenti ci cercano con lui e che si presuppone lavori pro (e non contro) i suoi fruitori.

Tutti questi cambiamenti dobbiamo farli a mano?

Potremmo, sì; sarebbe il metodo più pulito in assoluto, ma non tutti siamo in grado di farlo e il lavoro potrebbe essere più complesso del previsto. Parlando sempre di WordPress (visto che è il CMS più usato) potremmo ovviare con un plugin come W3 Total Cache che già abbiamo nominato in precedenza, ma provando stavolta a selezionare gli aspetti che più ci interessano relativi a CSS e JavaScript (sempre facendo attenzione ad avere a portata di mano un backup della situazione precedente per evitare disastri indesiderati).

NB: Prima di toccare tutte le altre feature (non è un corso sul plugin) passiamo da qui, tentiamo di capire se o quanto migliora la situazione e poi, in caso andiamo a sistemare altrove. L'importante è sempre svuotare la cache del browser e provare con ad esempio Chrome, Firefox e Edge (Ex I.E.) a navigare, perché può accadere, specie con i CMS (non sapendo bene come sono strutturati i temi), che le modifiche possano giovare magari su Chrome o non funzionare affatto sugli altri.

In ogni caso, come? Una volta installato, nella dashboard di WordPress, basta portarsi su Prestazioni > minimizza, scorrere verso il basso e cercare le sezioni relative.

Selezionare la casella abilitare, salvare svuotando la cache e provare con gli strumenti per controllare la page speed se qualcosa migliora.

Dallo screen notiamo nella figura di destra le "Operations in areas", nella sezione dedicata a JavaScript. Il valore di default può essere cambiato a seconda del tipo di script che abbiamo sul nostro sito e anche a seconda delle indicazioni che ci vengono date dal Page Speed Control.

NB: Sì, non tutti sono in grado di scegliere tra le opzioni, ma il plugin in questo caso non applica soluzioni definitive e possiamo comunque andare a cambiare per verificare che tutto sia ok, provando sempre a cache vuota e con più browser.

Una nota importante invece va data alle sezioni sottostanti, dove si può specificare tutto quello che non deve essere "minificato", perché proprio per la struttura del sito/blog che avete, potrebbero esserci problemi di compatibilità con quello che si va a fare. 

Con pochi click, probabilmente possiamo già notare parecchia differenza dalle indicazioni del tool Page Speed Insight, ma una buona parte del lavoro, meno tecnico e forse anche più facile per tutti, consiste proprio in quello che sta nel paragrafo qui sotto. 

4. Ottimizzare le immagini

Il reparto foto occupa nella media tra il 15 ed il 30 percento delle risorse di caricamento di una pagina web, quindi è ovvio che migliorarlo incide in modo importante sulle performance finali.

Immagini di dimensioni più contenute utilizzano meno larghezza di banda per essere scaricate dal browser, quindi verranno visualizzate in tempi più rapidi, contribuendo alla velocità finale del caricamento effettivo di tutta la pagina.

Bisogna anche dire poi, che essendo ad oggi la maggior parte dei servizi di hosting più decenti impostati con uno spazio totale (nei casi più standard) tra i 4 ed i 5 GigaByte, ottimizzare il peso delle fotografie ci permette anche di sfruttare in modo più oculato tutto l'hosting, senza dover ricorrere ad un ampliamento quasi ingiustificato delle risorse.

Come possiamo ottimizzare le immagini per il Web?

Dobbiamo tenere bene a mente che bisogna trovare il giusto compromesso tra qualità e velocità, durante il nostro tentativo di ottimizzazione. 

Possiamo sacrificare l'aspetto per le performance?

Quanto devono impattare le foto nell'esperienza di navigazione dei nostri utenti? In base allo scopo del nostro contenuto, l'opzione che scegliamo può essere fin troppo determinante, ma è palese che se scegliamo di usare una fotografia di qualità troppo bassa, ad esempio su uno slider in full-size nella home, rischiamo di cacciare i visitatori con una immagine sfocata, poco chiara e che non esprime al massimo le potenzialità di quello che stiamo raccontando.

Dobbiamo imparare a scegliere i formati più adatti e saperli gestire a seconda dello scopo dei nostri contenuti, oltre che al layout in cui sono contestualizzati.

Esistono diversi tipi di file immagine che è possibile utilizzare ma vediamo quelli più comuni:

• PNG – Un formato con una perdita di dati davvero esigua e che mantiene alti gli standard anche sui gradienti di colore complessi e le trasparenze. 
• JPEG – Il più usato e quello con il maggior numero di settaggi per raggiungere un equilibrio decoroso tra peso/qualità, ma non gestisce le trasparenze, riempiendo in bianco le zone che dovrebbero averne.
• GIF – Utilizza palette con pochi colori ed è perfetto per immagini piatte, grafiche semplici ed icone, senza eccessive sfumature. Supporta la trasparenza ma tende a pesare molto di più di un JPEG se la usiamo per foto complesse, poiché deve usare molteplici combinazioni di colori per riprodurre il più possibile quello che non arriva a gestire, data la piccola campionatura di colore di cui dispone.
• SVG – Elementi vettoriali scalabili che possono essere visualizzati dai browser. Nessuna perdita di qualità e trasparenze gestite, ma non tutti i browser (specialmente quelli su mobile di qualche anno fa) riescono a visualizzare correttamente queste immagini, quindi da usare con un po' più di parsimonia.

Ovviamente, sapendo utilizzare con profitto un software di ritocco fotografico è possibile gestire le immagini in maniera più che adatta, ma se non siamo in grado di farlo o non possiamo, servizi online come tinypng o anche resizeyourimage offrono un supporto degno e facile per i principianti.

Con l'esperienza impareremo ad usare diversi tipi di foto e cromie relativamente al loro utilizzo, ma di norma, a meno di voler osare molto con la qualità e considerando che molti utenti navigano ancora con connessioni 3G, non andrei per uno slider oltre i 300KB per una gran bella foto ed oltre i 100/120 per formati medi, scalando considerevolmente per le miniature e tutto il resto (Io sul sito aziendale sbaglio volutamente ma come dicevo, sono scelte :D).

NB: Non usiamo plugin automatici per la riduzione della qualità delle foto, perché in primis non tutti gli scatti possono necessitare dello stesso trattamento massivo e poi perché, come già accennato sopra, non facciamo che aggiungere script e risorse al caricamento totale delle pagine, quindi se da una parte togliamo, dall'altra re-inseriamo qualcosa.

Per approfondire leggi il post:  Immagini e SEO: come ottimizzare le immagini per Google.

5. Gestire il formato AMP (Accelerated Mobile Page)

Basicamente, il formato AMP aiuta al miglioramento delle performance dei siti web nella navigazione da dispositivi mobile. La particolarità di questa soluzione è data dai formati nell'output della visualizzazione delle pagine, poiché si basa sempre sui classici HTML, CSS e JavaScript, in cui però vengono ripresi ed utilizzati (in parte) tag, funzioni o regole differenti, protesi tutti all'eliminazione degli elementi più pesanti da caricare senza rinunciare in ogni caso alle personalizzazioni grafiche, alle animazioni o anche ad annunci sponsorizzati, quindi offrendo nel complesso un'esperienza completa ma molto più rapida per chi accede alle risorse. 

Un esempio sono le librerie JavaScript proprietarie, che massimizzano il rendering delle pagine utilizzando una tecnica di caricamento asincrono, disabilitano i selettori CSS che risultano troppo pesanti ed utilizzano anche una gestione della cache ottimizzata che permette di dare un boost alla velocità totale di caricamento fino a quasi 3 o 4 volte quella originale.

Le pagine AMP allora sono migliori?

Comportano sicuramente una serie di vantaggi, ma passare un sito web o un blog (anche) su AMP non è un lavoro da fare senza preparazione e cognizione di causa, perché se è pur vero che le velocità di caricamento sono eccezionali, dall'altra parte potremmo dover rinunciare a funzionalità che invece possono comunque esserci comode, quindi la decisione va presa con calma e tentando di lavorare per riuscire (anche se difficile) ad avere la famosa capra insieme ai famosi cavoli, nella stessa soluzione.

Piccola nota: Nelle prime release ufficiali di Google (ad oggi ancora se ne parla e si sperimenta parecchio) si parlava di una esposizione migliorata nelle ricerche mobile, specie dopo il rilascio del famoso Mobile First Index. Ovviamente, tutti i maggiori produttori di contenuti come i grandi portali informativi hanno subito accolto la notizia e si sono messi all'opera per implementare al massimo le nuove introduzioni.

Ma cosa ci danno in sostanza le pagine AMP? Vediamo i vantaggi principali:

1. Esecuzione solo di script asincroni

Durante il render delle pagine, non si avvertirà nessun rallentamento e nessuno scatto nella navigazione, perché tutto il caricamento sarà simultaneo ed il primo script che attingerà alle risorse, le renderà disponibili nella cache per tutti quelli successivi.

2. Riduzione statica delle risorse nel caricamento

Tutto quello che rimane esterno al nostro progetto deve necessariamente esplicitare le proprie dimensioni nel sorgente HTML in modo che AMP possa già avere tutto a disposizione (prima che ognuna venga scaricata durante la navigazione) e preparare il giusto layout. 

3. Tutti i CSS devono essere "in linea" e legati alle dimensioni

Incorporare i fogli di stile nelle pagine elimina le chiamate ai file esterni e diminuisce i tempi di visualizzazione. Nei CSS le dimensioni degli elementi vanno dichiarate e vanno rimossi tutti i selettori che sappiamo già "pretendere" troppo tempo per il caricamento.

4. Priorità al caricamento delle risorse

AMP prevede, nello scarico delle risorse, di dare priorità a quelle che ritiene più importanti, includendole prima nella lista del TO-DO se ad esempio risultano presenti tra i contenuti Above the Fold accennati in precedenza o se l'utente può avervi subito un rapido e facile accesso.

E dopo le belle notizie, gli svantaggi… Almeno quelli più visibili

Il primo e più evidente per gli addetti ai lavori è quello legato alla monetizzazione attraverso i banner pubblicitari. Molti portali ad esempio, tendono ad avere accordi con concessionarie di pubblicità per la visualizzazione, in spazi più o meno visibili, di banner sponsorizzati di diverso formato e caratteristiche.
Questi banner sono (di norma) gestiti da file JavaScript proprietari di terzi domini, che fanno riferimento alle risorse esterne di chi li fornisce per essere manipolati e controllati. 

AMP, per sua natura, ha bisogno di caricare gli script in maniera asincrona e quindi, avendo a che fare con risorse esterne che possono intervenire nel caricamento pulito e nelle policy generali della struttura stessa delle pagine "accellerate", non è possibile garantire il risultato corretto nella visualizzazione di queste pubblicità. 

Ricordiamo poi, come nella nota messa ad inizio capitolo, che le tipologie di risorse che rischiano di trarre più giovamento dalle funzionalità di AMP sarebbero proprio quelle relative ai siti di news, avendo un ricambio rapido e continuo di notizie e quindi dovendo supportare come struttura hardware un traffico non indifferente e come esperienza umana una leggibilità quasi assoluta.

Questa sorta di problematica che impedisce proprio (forse) ai maggiori fruitori di questo servizio di approfittare di certe comodità deve essere ricercata nella ferma e immutata vecchia forma degli script di tanti troppi anni fa. Società vecchie, con sviluppatori vecchi (dentro) che non aggiornano le loro offerte tecniche per pigrizia o piuttosto incapacità, negando spesso a chi si rivolge loro (non sempre un tecnico capace) la possibilità di migliorare il proprio appeal nei confronti degli utenti finali.

Passiamo poi agli elementi grafici.

Come ancora accennato poco sopra, una visualizzazione sempre minimale degli aspetti "colorati" della situazione può non essere sempre una soluzione super azzeccata.

Il potere di conversione di un bello scatto qualitativamente decoroso o di un pop-up generato da un plugin, o anche un carosello di notizie o fotografie, può venire a mancare se gli script non sono compatibili con AMP e non si è in grado di rimediare, portando potenzialmente anche meno conversioni, se in origine invece la soluzione adottata ne accalappiava anche con delle call to action su misura. AMP quindi è una soluzione decisamente efficace se sappiamo dove mettere le mani, ma non è di certo la pietra filosofale delle performance su un sito e aiuterà poco se pur essendo il sito/blog stesso molto veloce, comunque ci saranno pecche strutturali o contenuti inadatti a generare anche "solo" dei lead. 

Per approfondire leggi il post:  Mobile SEO: come essere competitivi nell'epoca del Mobile-friendly.

6. Ricorrere ad una CDN 

CDN è l'acronimo di Content Delivery Network e letteralmente è una rete di distribuzione dei contenuti. 
Ogni singolo utente che accede alle tue pagine web non fa altro che interrogare i server per la visualizzazione di contenuto e questi lavorano incessantemente per rispondere ad ogni singola richiesta, producendo un output con la pagina di destinazione che poi il browser dell'utente va a visualizzare in tempi più o meno brevi. 

È fin troppo facile capire che in questo modo, specialmente su progetti a grosso traffico, il singolo server si carica di tutto il lavoro e, per quanto possa essere potente o ottimizzato il progetto (anche sfruttando tutti gli accorgimenti di cui sopra), è sempre possibile fare di meglio utilizzando un servizio come questo.

Con la CDN infatti, tutte le richieste in arrivo vengono ridistribuite direttamente al nodo CDN installato geograficamente più vicino all'utente che fa la richiesta, con un notevole risparmio sui tempi e quindi maggiori performance.

Che vuol dire? 

I nodi CDN sono distribuzioni fisiche di una grande struttura di server ubicata in diverse località, per poter servire (appunto) in tempi molto brevi gli utenti che si collegano da quelle aree specifiche, proprio per una questione di distanza. Ne consegue che i vari Mantainer che decidono di proporre una soluzione del genere hanno già predisposto strutture più o meno proprietarie, a cui si appoggiano per lo scopo. 

Un vantaggio molto grande risiede poi sicuramente nella possibilità di lasciare in cache (ve la ricordate, no?!) i contenuti per un tempo stabilito, modificabile relativamente alla profondità del contratto con chi offre la rete di distribuzione. In questo modo, l'utente che ri-accede alla pagina entro quel limite di tempo potrà usufruire con latenze ancora minori della risorsa richiesta.

La CDN è adatta specialmente per siti/blog/forum che ricevono traffico internazionale, quindi con utenze collegate da varie parti del globo.

Ovviamente, più nodi CDN sono disponibili nelle ubicazioni utili, più è facile rispettare gli standard di velocità richiesti anche verso chi è molto distante da dove fisicamente risiede il nostro spazio web.

PS: Va detto infine che sì, le CDN sono utilissime per migliorare le performance dei siti web, ma sono utilizzate anche ad esempio per la trasmissione più rapida di contenuti audio-visivi di qualità, download di grandi software e applicativi e anche per grandi basi di dati ad esempio per enti internazionali o aziende di enormi proporzioni.

Per ogni cosa un plugin: ma anche no!

Nel corso del post ho accennato ad alcuni plugin e se ne porrebbero consigliare anche per le cose più tecniche, ma non è corretto farlo, o almeno non è coerente con il tipo di implementazione che andrebbe fatta.

Ottimizzare le performance di un progetto online non può passare solo per dei click su un pulsante che comanda delle istruzioni di cui, probabilmente, molti non saprebbero nulla.

Un lavoro tecnico deve essere fatto e supportato da una figura tecnica, che sa mettere mano al codice sorgente ed ottimizzare davvero quanto più possibile un lavoro che tutto è tranne che semplice. Ho spesso accennato alla necessità di avere sempre a portata di mano un backup della situazione precedente ed è una nota a margine che chiunque potrà trovare su quasi tutte le risorse online che parlano di performance ed ottimizzazione.

Questo perché non possiamo essere sempre dentro agli script di quello che stiamo per applicare sul nostro sito/blog e non possiamo prevedere (se non ci giriamo a mano tutte le pagine di programmazione di cui è composto) cosa farà esattamente questo plugin aggiunto. 

Funzionerà? Romperà tutto? Sarà utile o non sortirà effetto?
Certi tipi di implementazioni devono essere commisurati alla risorsa dove si vanno ad applicare e vanno tenuti d'occhio nel corso del tempo, provando e riprovando, cambiando o spostando una cosa anziché l'altra e via discorrendo.

Certo, per soluzioni più semplici un plugin di riferimento molto usato e molto sicuro possiamo sempre provare a cercarlo e per lavori molto contenuti sono implementazioni utili, ma mettere in mano una roba "one-click" a qualcuno che non è così esperto e spiegargli che con pochi attimi può ottimizzare un sito web non è corretto e non è giusto. Specialmente se ci siamo parati prima il di dietro con la nota sul backup.

Non tutto "l'internet" è facile e non tutto deve essere preso alla stregua di un free-to-play senza condizioni e senza prerequisiti. 

Ma questo è solo un approfondimento tecnico, non ci fate caso! ;)

Vi è rimasto qualche dubbio sulla questione "prestazioni dei siti web"?

Usate pure la sezione dei commenti per chiedere chiarimenti o per verificare insieme il modo migliore per offrire una buona esperienza utente sulle vostre pagine.