Il leverage browser caching (o sfrutta il caching del browser) rappresenta uno dei problemi più frequenti di chi cerca di ottimizzare il pagespeed di un sito.

In questo articolo tratterò delle linee guida da seguire per trattare gli script di terze parti, come analytics.jsgtm.jsfbevents.js e più in generale ogni exernal js.

Nello specifico, seguirò con attenzione l’ottimizzazione di analytics perché rappresenta uno scoglio comune nell’ottimizzazione del pagespeed.

In molti forum si dice che il “centesimo punto” della scala ottimizzazione di Pagespeed Insight sia proprio il file di cui parleremo.

Leverage browser caching per Analytics.js

Come funziona il leverage browser caching

Quando un device chiede al server una risorsa (immagine, pdf, ect.), la richiesta viene intercettata dalla web cache, che controlla se ha una copia di quel file.

Se non lo possiede, lo preleva dal server, altrimenti propone all’utente una copia presente in cache.

Sfruttare il caching del browser significa aumentare il tempo di permanenza in cache delle risorse. 

Se non sappiamo se le nostre risorse sono interne o esterne, il modo migliore di operare è iniziare dal problema più semplice:

Caching risorse interne

Per una questione di maggiore diffusione inizio con la risoluzione del problema su server Apache.

Il classico esempio è l’ottimizzazione di un sito WordPress, durante la quale andremo a inserire i seguenti codici sul file .htaccess:

#Customize expires cache start - adjust the period according to your needs
<IfModule mod_expires.c>
FileETag MTime Size
AddOutputFilterByType DEFLATE text/plain text/html text/xml text/css application/xml application/xhtml+xml application/rss+xml application/javascript application/x-javascript
ExpiresActive On
ExpiresByType text/html "access 600 seconds"
ExpiresByType application/xhtml+xml "access 600 seconds"
ExpiresByType text/css "access 1 month"
ExpiresByType text/javascript "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresDefault "access 1 month"
</IfModule>#Expires cache end

Come potete notare il tempo di accesso varia a seconda della risorsa richiesta.

Per far funzionare al meglio il caching bisogna aggiungere al codice già scritto delle indicazioni per l’headers.

# BEGIN Cache-Control Headers
<IfModule mod_expires.c>
    <IfModule mod_headers.c>
          <filesMatch "\.(ico|jpe?g|png|gif|swf)$">
              Header append Cache-Control "public"
          </filesMatch>
          <filesMatch "\.(css)$">
              Header append Cache-Control "public"
          </filesMatch>
          <filesMatch "\.(js)$"> 
              Header append Cache-Control "private"
          </filesMatch>
          <filesMatch "\.(x?html?|php)$">
              Header append Cache-Control "private, must-revalidate"
          </filesMatch>
    </IfModule>
</IfModule>

Nel caso usufruite di una CDN dovete spegnere l’ETag, quella parte del protocollo HTTP che si occupa della verifica del web cache.

Se utilizzate un CDN non è garantito che utilizziate sempre uno stesso server, di conseguenza l’ETag perde di efficacia.

Per spegnerlo basta inserire il codice:

 #Disable ETags
<IfModule mod_headers.c>
Header unset ETag
</IfModule>
FileETag None

Per quanto riguarda altri tipi di server vi segnalo questa guida pratica per Nginx.

Finita questa operazione, le indicazioni presenti su Pagespeed Insight indicheranno solo script di terze parti.

Analytics.js

Prima di iniziare vi metto in guardia sulle soluzioni deprecate da Google.

Evitare di implementare script per MOSTRARE il problema risolto tramite l’utilizzo di script. Il punto non è la visualizzazione del punteggio, ma il beneficio pratico.

Il secondo punto è hostare localmente i file. Esiste una pagina dell’help di Analytics che lo sconsiglia.

La soluzione che ho trovato pur non essendo ufficiale utilizza le API di Google, un CDN e uno script molto semplice che riporto qui sotto:

<script>
  (function(e,t,n,i,s,a,c){e[n]=e[n]||function(){(e[n].q=e[n].q||[]).push(arguments)}
;a=t.createElement(i);c=t.getElementsByTagName(i)[0];a.async=true;a.src=s
;c.parentNode.insertBefore(a,c)
})(window,document,"galite","script","https://cdn.jsdelivr.net/npm/[email protected]/dist/ga-lite.min.js");

galite('create', 'UA-XXXXXXXX-X', 'auto');
galite('send', 'pageview')
;</script>

Potete trovare maggiori spiegazioni sulla pagina github di ga-lite.


Gli altri script di terze parti

Ho cercato a lungo di risolvere i problemi degli altri script, ma le soluzioni che si trovano riguardano sempre l’upload di un file sull’host e l’aggiornamento dei dati tramite sistemi integrati, come Cron di CPanel.

I file in questione vengono aggiornati costantemente, e andare contro le linee guida più che un problema di ottimizzazione diventa un problema di gestione delle proprie risorse.

Se siete i possessori di un sito che offre una buona velocità di fruizione di contenuti agli utenti, sentitevi realizzati.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.