Velocizzare un sito con prefetch/prerender: dall’analisi ad un plugin WordPress

I SEO sono probabilmente tra i soggetti che conoscono meglio la necessità di ottimizzare la reattività di un sito web. Siti più reattivi soddisfano meglio gli utenti e tale soddisfazione ha benefici anche sulle conversioni.

L’approccio all’ottimizzazione della velocità dei siti, tuttavia, è spesso legato all’implementazione di linee guida suggerite da strumenti quali GTmetrix e WebPageTest.

Se da un lato è vero che per ogni suggerimento ricevuto dagli strumenti viene poi valutato il rapporto costi/benefici della sua implementazione, tali considerazioni di opportunità rimangono spesso circoscritte ad un contesto tecnico, senza essere estese a valutazioni delle abitudini delle diverse tipologie di visitatori del sito.

Scrivo questo articolo per proporre un esempio di un’ottimizzazione della velocità di un sito che si può ottenere attraverso l’implementazione delle relazioni prefetch e prerender, sfruttando una semplice analisi del comportamento degli utenti su un sito.

L’obiettivo dell’articolo è mostrare il filo logico che ho seguito per arrivare al risultato finale. Il sito usato come cavia è, per mia comodità, LowLevel.it

Dalla velocità alla soddisfazione

Il primo passo da fare per individuare nuove opportunità di miglioramento della velocità di un sito è cambiare un po’ il paradigma al quale siamo abituati quando ci limitiamo ad analizzare un sito con i tool sopra citati.

Tendiamo a considerare la velocità un attributo intrinseco del sito, per giunta di tipo tecnico. In realtà non è sempre così: siccome utenti di tipo diverso possono usufruire di un sito in modo diverso, la loro percezione della velocità del sito può variare.

Invece che considerare la velocità un attributo del sito e tentare di migliorare tale caratteristica apparentemente intrinseca, si scoprono più opportunità di miglioramento mettendosi a ragionare sulla qualità della navigazione degli utenti e sulla loro soddisfazione.

La differenza tra i due approcci è tanta e molto pratica. Per esempio, un web server di qualità ospitato in territorio USA può anche essere super-veloce, tuttavia gli utenti geograficamente distanti dagli USA sperimenteranno sempre tempi medi di attesa e di caricamento delle risorse superiori ai tempi medi osservati degli utenti fisicamente più vicini al web server. Questa è la ragione per la quale esistono i CDN: non per migliorare una caratteristica tecnica del sito ma per velocizzare l’esperienza di navigazione degli utenti.

Un secondo esempio è relativo alle diverse tipologie di visitatori di un sito, che vi approdano da canali diversi e per motivazioni diverse. Il presente post fa proprio un’analisi di tali diversità.

Per riassumere, è opportuno fare una distinzione tra velocità di fruizione e velocità del sito, con l’obiettivo di migliorare la prima, che è solo in parte una conseguenza della seconda.

Concetti base: prefetch e prerender

Il link prefetching è una tecnica che consente ad una risorsa, tipicamente una pagina web, di consigliare al browser quali altre risorse pre-caricare in background mentre il browser non ha altro da fare, cosa che per esempio avviene quando l’utente è impegnato a leggere il contenuto di una pagina.

Il browser conserva le risorse pre-caricate nella propria cache. Nel caso in cui l’utente dovesse cliccare un link che porta alla risorsa pre-caricata in cache, non dovrà attendere i suoi tempi di scaricamento, visto che è già stata scaricata durante i “tempi morti”.

Questa convenzione tra sito web e browser funziona bene quando il sito web consiglia al browser di fare il prefetch di risorse che presumibilmente l’utente consulterà successivamente.

Vale la pena di dare qualche dettaglio:

• un sito può consigliare sia il prefetch di risorse interne sia il prefetch di risorse esterne. Per esempio, la pagina di una SERP di un motore di ricerca può suggerire al browser di pre-caricare la risorsa linkata in prima posizione, se il motore è fiducioso che sarà quella presumibilmente più cliccata dagli utenti.
• il suggerimento può avvenire attraverso un’intestazione HTTP oppure attraverso un tag HTML di tipo LINK, con attributo rel contenente il valore “prefetch”.
• una risorsa pre-caricata non corrisponde necessariamente ad una risorsa poi visitata dall’utente e questo aspetto può falsare le statistiche del sito che ospita la risorsa pre-caricata. Per il sito che ospita la risorsa esistono tuttavia modi per distinguere una richiesta fatta a fini di prefetch da una richiesta “normale”.
• il prefetch è solo un consiglio, non un comando che il browser è tenuto ad eseguire: ad avere l’ultima parola su ciò che va effettivamente scaricato è sempre il browser dell’utente.
• il prefetch induce il browser a scaricare una risorsa, non ad interpretarla! Quando viene scaricato un file HTML, esso non viene valutato dal browser ma viene solo salvato in cache. Eventuali ulteriori risorse menzionate dal file HTML (immagini, CSS, ecc.) non vengono quindi caricate. Allo stesso modo, fare il prefetch di un file JavaScript non induce il browser ad eseguire il codice contenuto.

Il prerendering è una tecnica diversa dal prefetch, perché ha l’obiettivo di scaricare una risorsa e di disegnarla (rendering) in background in modo completo, esattamente come se l’utente l’avesse effettivamente visitata.

Quando l’utente clicca un link di una risorsa che è stata pre-renderizzata, la sua visualizzazione è immediata, perché tutte le fasi di scaricamento e di disegno sono già state interamente eseguite durante i già citati tempi morti.

Nel momento in cui scrivo, Chrome è l’unico dei principali browser ad aver implementato il prerender. Il più semplice prefetch è invece attualmente supportato da Firefox e da alcune versioni di Chrome.

Anche il prerendering, come il prefetching, può produrre problemi con l’analisi del traffico, in quanto non è detto che le risorse pre-scaricate vengano poi effettivamente visitate dall’utente.

Le due tecniche hanno inoltre un costo per il sito che ospita le risorse scaricate, quello della banda consumata. Se l’utente non visita la risorsa pre-scaricata, il server che la ospita ha consumato inutilmente la propria banda. Il problema è maggiormente sentito col prerendering, perché può indurre il browser a scaricare maggiori quantità di file rispetto al prefetching.

Questa ultima considerazione evidenzia il punto chiave sull’uso corretto di prefetching e prerendering: è importante scegliere bene che cosa consigliare al browser di scaricare e tale decisione non è generalizzabile, perché dipende dalle abitudini di navigazione degli utenti dello specifico sito web.

Descrizione del sito da ottimizzare

Il sito usato come cavia è LowLevel.it

Si tratta di un blog che fa uso del CMS WordPress e di un hosting americano. Le sue caratteristiche tecniche che influiscono sulla velocità di fruizione delle pagine sono già state ottimizzate abbastanza, attraverso le pratiche consuete che i SEO conoscono bene. Rimane comunque un sito nel complesso lento per il target italiano, in futuro beneficerà di un server italiano.

Il blog ha scopi divulgativi, pubblica articoli prevalentemente dedicati al search marketing o al web marketing, viene letto da un pubbico italiano e riceve dall’Italia la stragrande maggioranza delle visite. La frequenza di pubblicazione di nuovi post è bassa e non raggiunge i tre post al mese. Non viene inoltre seguita alcuna periodicità fissa: gli articoli vengono scritti quando ispirazione e tempo conciliano. Il sito non vende servizi o prodotti e l’unica azione considerabile “conversione” è l’iscrizione al feed.

Gli articoli pubblicati vengono spesso segnalati su Facebook, Twitter e Google+. E’ da questi canali che arriva la fetta di traffico maggiore, a seconda di quanto ciascun post incontra gli interessi del target o a seconda di quanto esso diventa virale oltre ai confini ristretti di markettolandia.

La piattaforma di web analytics usata è Google Analytics, che è in grado di gestire correttamente le richieste nate a seguito di prefetching o prerendering. Tanto per dare un’idea approssimata delle dimensioni, le visite ricevute in un giorno di pubblicazione di un nuovo post sono diverse centinaia e superano a volte il migliaio, il picco massimo registrato in un singolo giorno è stato di 2.900 visite.

Come per tutti i blog, è possibile dividere la natura delle visite tra due principali fenomeni:

• le visite conseguenti la pubblicazione di un nuovo post e la sua diffusione sui social network
• le visite distanti dalla pubblicazione dei post, provenienti prevalentemente da referral, traffico di bassa qualità da SERP organiche e accessi diretti generati da utenti che vogliono visitare il sito per consultarlo o in cerca di novità.

Definizione di obiettivi e KPI

L’obiettivo finale è quello di migliorare l’esperienza utente.

Per far ciò, è necessario analizzare quali pagine vengono visitate dalle diverse tipologie di utenti e, in base ad esse, decidere quali pagine successive suggerire ai browser di pre-caricare.

Una volta ottenuta una maggiore reattività del sito alle richieste degli utenti, aumenta la probabilità che questi ultimi siano indotti a consultare il sito in modo un po’ più approfondito. Per questa ragione, l’indicatore principale (KPI) che ho deciso di usare per valutare gli effetti dell’ottimizzazione è il rapporto Pagine/Visita.

Come indicatori secondari potrebbero essere presi in considerazione anche il tempo di permanenza dell’utente sul sito ed i tempi di caricamento delle pagine.

Quando si definiscono dei KPI è indispensabile scendere in dettagli maggiori riguardo la loro definizione e l’esatto modo in cui devono essere calcolati. Alla faccia dell’indispensabilità, nel caso di questo articolo non lo farò perché so già in partenza che LowLevel.it è troppo poco trafficato per rendere significativo qualsiasi KPI scelto. Tuttavia voi sappiate che la definizione degli indicatori dovrebbe essere accurata e che sebbene in questo specifico contesto mi limito a definire volutamente un becero “Pagine/Visita”, l’argomento è talmente importante che meriterebbe un post a sé.

Analisi della navigazione degli utenti

Per decidere quale pagina successiva consigliare ai browser degli utenti è necessario sapere da quale pagina del sito l’utente inizia la propria visita.

Ho quindi usato Google Analytics per dividere le visite in due grandi categorie: quelle che approdano al sito (landing page) dalla home page e quelle che atterrano sulla pagina di un post.

Home page

Ogni visita ricevuta nel 2012 già trascorso e che ha avuto inizio dalla home page di LowLevel.it ha generato in media 1,89 pagine. Questo significa che, prescindendo dal canale di provenienza degli utenti, la maggior parte di coloro che hanno iniziato la visita dalla home page sono stati poi indotti a visualizzare una seconda pagina.

Bisogna adesso comprendere quali altre pagine sono state visitate dopo la home page e per ottenere la risposta giusta non sarebbe opportuno analizzare un periodo di tempo durante il quale i contenuti della home page sono cambiati.

Ho quindi preso in esame una finestra temporale che non ha visto la pubblicazione di nuovi post ed ho avuto conferma che la pagina successiva più richiesta dai visitatori è stata quella che all’epoca corrispondeva all’ultimo post pubblicato. Al secondo posto ma già abbastanza distanziata, c’è la pagina degli articoli precedenti a quelli pubblicati in home page.

Ho effettuato la stessa valutazione prendendo in esame altri periodi di tempo successivi alla pubblicazione di un nuovo post ed è stato confermato che il fenomeno si ripete sempre. Voi direte: “era palese” ed io rispondo: sì, ma va sempre dimostrato, perché non tutti i siti hanno la stessa struttura e spesso le nostre intuizioni non corrispondono a quanto avviene realmente.

Le visite che iniziano dalla home page ammontano al 36% del totale e, di queste, quelle che poi proseguono sulla pagina del post più recente ammontano al 27%.

Apparentemente si potrebbe credere che le visite che beneficerebbero di un eventuale prefetch/prerender della pagina del post più recente ammontino solo al 27% del 36% tuttavia bisogna ricordare che la navigazione degli utenti non è mai lineare e che non si può escludere che la visualizzazione del post più recente sia avvenuta come terzo o quarto step di tali visite. A prescindere da quando la visualizzazione avviene, il visitatore ne beneficia se il browser se la ritrova già in cache.

Al di là del “quanto”, rimane comunque indubbio che suggerendo di pre-caricare la pagina del post più recente ai browser di quegli utenti che atterrano sulla home page si riuscirebbe a coprire una buona fetta di traffico.

Pagina di un post

Prendendo in esame tutto il 2012 già trascorso, ho usato le stesse statistiche di Google Analytics indicate nella sezione precedente per determinare che le visite che iniziano dalla pagina di un post proseguono molto spesso con la visita della home page.

Si noti che, quantitativamente, il fenomeno è ridotto perché la maggior parte delle visite che iniziano dalla pagina di uno specifico post avvengono a seguito della diffusione dell’articolo sul web e pertanto l’effetto registrato è quello tipico dei blog: l’utente legge l’articolo e poi esce dal sito, cliccando al massimo qualche pulsante di “like”. Il bounce rate è alto anche perché LowLevel.it non fa nulla per incentivare la lettura di articoli aggiuntivi.

Anche in questo caso voi potrete dire: “era palese che la pagina successiva più probabile fosse la home” ed anche in questo caso io rispondo: sì, ma va sempre dimostrato.

Decisione degli interventi

La decisione di quali interventi tecnici effettuare sul sito è logica: per velocizzare l’esperienza di navigazione delle due tipologie di visite/utenti sopra descritte, è opportuno:

1. consigliare ai browser che stanno visualizzando la home page di pre-caricare la pagina del post più recente
2. consigliare ai browser che stanno visualizzando la pagina di un articolo di pre-caricare la home page

Implementazione dell’ottimizzazione

Detto, fatto! Essendo questo un blog WordPress ho ritenuto opportuno effettuare l’implementazione scrivendo un semplicissimo e piccolo plugin che ho chiamato, in un delirio estatico di lapalissiana creatività “Browser Prefetch”. Il plugin è già in funzione su questo sito.

Aggiunto: mi è venuto il dubbio che chi mastica poco di browser potesse credere che questo articolo sia dedicato a velocizzare i siti WordPress. Ovviamente prefetching e prerendering servono a velocizzare qualsiasi genere di sito web. Parlo di WordPress solo perché in questo specifico esempio il prefetching va implementato in un sito che usa WordPress come CMS. 🙂

Il plugin implementa esattamente quanto descritto nella sezione precedente: viene creato un tag di tipo LINK con relazioni di tipo prefetch e prerender ed un URL di cui si consiglia il pre-caricamento che varia a seconda della pagina in cui il tag esiste: i post consigliano la home page e la home page consiglia la pagina dell’ultimo post pubblicato.

Sia inteso: questo plugin non va bene per voi, va bene per LowLevel.it! E’ stato tagliato su misura delle esigenze di questo sito e questa è la ragione per la quale non è pensato per il pubblico e non ha pagine di opzioni di alcun genere.

Il plugin potrebbe essere pieno di bug. Usarlo vi produrrà orticaria e non riuscirete più a pronunciare la consonante “z”. Il gatto vi vomiterà sulla moquette.

Ne mostro di seguito il codice solo per completezza e, ovviamente, non fornirò alcun file né indicazione di che cosa farci perché di vostri eventuali utilizzi e adattamenti non ne voglio sapere nulla.

<?php
/*
Plugin Name: Browser Prefetch
Description: Inserts prefetch and prerender link tags in posts and home page
Version: 1.0
Author: Enrico Altavilla
Author URI: http://www.lowlevel.it/
License: GPL2
*/
?>
<?php
/*  Copyright 2012  Enrico Altavilla  (email : enrico.altavilla@gmail.com)

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License, version 2, as 
    published by the Free Software Foundation.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
*/
?>
<?php

function bpre_link_output() {
	
	$url = "";
	
	if (is_home()) {
		$args = array ('numberposts' => 1);
		$lastposts = wp_get_recent_posts($args);
		if ($lastposts) {
			$lastpost = $lastposts[0]['ID'];
			$url = get_permalink ($lastpost);
		}
	}
	elseif (is_single()) {
		$url = home_url('/');
	}
		if ($url) {
		echo '<link rel="prerender prefetch" url="' . $url . '" />' . "\n";
	}
}

add_action('wp_head', 'bpre_link_output');
?>

Monitoraggio dei risultati

Come già accennato nella sezione dedicata alla definizione dei KPI, nel corso del tempo terrò monitorati gli indicatori scelti per valutare i benefici ricavati.

Sono convinto che siti con maggior traffico e con un’infrastruttura decente (cosa che LowLevel.it non possiede ancora) potrebbero beneficiare di prefetching e prerendering in modo più consistente e chiaro di quanto emergerà su questo sito. Si vedrà.

Conclusioni

L’obiettivo di questo post era quello di mostrarvi un metodo: dall’analisi di un’opportunità all’implementazione di quanto serviva per coglierla.

Non ho la pretesa di presentare le valutazioni fatte e le soluzioni scelte come quanto di meglio era possibile fare, perché io stesso avrei svolto analisi più approfondite qualora avessi lavorato su un caso reale. Considerate questo post solo come un esercizio.

Presentarvi questo metodo è stato anche un modo per fare un esempio di tipi di ottimizzazioni che possono nascere solo su misura, al di là dell’applicazione di semplici linee guida tecniche che ogni buon SEO già conosce.

Spero che l’articolo vi sia di spunto per le vostre attività. 🙂

P.S.
Pensavo che sarebbe interessante parlare di argomenti simili in qualche evento. Giusto per dire.