Il dibattito su dove inserire il codice di tracciamento di Google Analytics è sempre stato molto acceso, fin dal rilascio del software.
Inizialmente, quando Urchin era appena stato ribrandizzato in Google Analytics ed il prodotto era poco più che un cambio di nome, ricordo che la documentazione suggeriva di inserire il codice di tracciamento all’interno del tag <head> della pagina. Non ho mai verificato direttamente, ma la motivazione ufficiale era che alcune caratteristiche richiedevano di essere inserite all’interno delle intestazioni per funzionare correttamente.
Poi è arrivato il nuovo codice di tracciamento di Google Analytics, per intenderci quello definito dal file ga.js. La documentazione ufficiale di Google Analytics indica di inserire il codice di tracciamento immediatamente prima la chiusura del tag <body>, ovvero la chiusura della pagina HTML.
Prendendo a campione un centinaio di siti, soprattutto quelli che utilizzando Google Anaytics dai primi tempi, è facile notare come la posizione in cui è inserito il codice di tracciamento è assolutamente arbitraria. Alcuni la tengono a chiusura pagina, altri nell’header.
Le motivazioni sono essenzialmente due. Nel caso in cui il codice di tracciamento sia inserito ad inizio pagina, la probabilità di perdersi per strada dei dati è decisamente inferiore. Con il codice di tracciamento al fondo, infatti, l’utente potrebbe chiudere il browser prima che il tracciamento sia inizializzato.
Viceversa, l’inserimento di un javascript nell’head forza il browser ad attendere il suo caricamento prima di proseguire il rendering completo della pagina. Nel caso in cui Google ritardi a fornire il codice di tracciamento, la nostra pagina cadrà in uno stato di sospensione apparente ed il browser continuerà a mostrare l’avviso di caricamento in corso fino ad un eventuale timeout o ad una risposta del javascript esterno.
Lo screenshot seguente è emblematico: 357ms per restituire la pagina al browser, 35 secondi per eseguire il codice di tracciamento di Google Analytics.
Purtroppo il fenomeno non è così raro. Limitato, certo, ma spesso mi capita di imbattermi in comportamenti simili.
Il dilemma resta. Top della pagina per tutti i visitatori ma rischi al caricamento, fondo della pagina per dati potenzialmente incompleti ma utente felice?
Io preferisco tenere tutto in fondo, meglio statistiche falzate che un sito non funzionante. Ritengo che lo scopo del sito è quello di essere visto, le statistiche di utilizzo servono a migliorarlo ma è una cosa accessoria. Se questo aspetto potrebbe andare a minare la stabilità del sistema a che serve avere le statistiche se tanto il sito non funziona bene?
La domanda posta così non esiste, il sito è fatto per google o per l’utente?
Io dico utente felice, sempre!
Essendo tutto client side il rendering della pagina è progressivo. Bisogna appunto studiare quando fare caricare e cosa. A mio avviso le js vanno (quando possibile) caricate all’interno dell’header, loro posto naturale soprattutto se si trattano di funzioni, quindi non routine che si avviano automaticamente.
Quindi le funzioni le richiamiamo quando necessario. Il fatto se richiamare il track della pagina all’inizio o alla fine del caricamento diciamo che va a gusti. Se il trackPage() lo mettiamo in header contiamo tutti gli accessi o quasi, se lo mettiamo nel footer, specie per siti con molto html, potremo rischiare di non contare utenti fuggitivi frettolosi.
Io ho sempre preferito nel footer da quando ho notato che a volte il caricamento è molto lento. Preferisco perdere qualche hit che non un possibile utente.
a complicare il tutto ci sono almeno due fattori:
il primo è che alcune documentazioni sulle funzioni richiedono esplicitamente che il codice sia richiamato PRIMA di invocare la funzione nella pagina.
il secondo è che il browser dovrebbe controllare prima in cache se ha già lo script, e di solito lo ha. 35 secondi mi sembrano decisamente troppi!
In linea di massima mi sembra di notare che siamo tutti sulla linea utente.
Curiosamente, osservando il comportamento del plugin di WordPress utilizzato su questo blog noto che l’inserimento del codice avviene nell’head!
@ Marco
Speravo in un tuo intervento! ;)
In realtà, il caching del file in questo caso potrebbe non risolvere il problema. Per sapere se utilizzare la versione in cache il browser deve comunque connettersi e leggere lo status code del server. Se 304 allora utilizza la versione in cache.
La connessione al server è quello che può causare rallentamenti. Se Google non risponde, comunque il browser attende fino ad un timeout.
Prima di leggere i commenti ero pronto a sostenere il posizionamento in header. Ora ho qualche dubbio in più.
Faccio una proposta:
Partendo da un layout standard a due colonne (content e navgation), una soluzione potrebbe essere quella di inserire lo script all’inizio della colonna di navigazione in modo da permettere il corretto caricamento dei contenuti che sono il cuore del sito. Certo il risparmio non è molto rispetto alla soluzione nel footer ma per progetti molto elaborati e con più colonne di navigazione potrebbe comunque essere utile.
Secondo voi si può andare incontro a qualche inconveniente?
I signori di analytics consigliano di piazzare tutto nel footer.
Io ribadisco che secondo me le chiamate dei js esterni vanno sopra. Le funzioni dove volete.
Anche perchè se fate tracking dei alcuni link e la gente ci clicca prima che voi carichiate il .js di analytics, ne perdete il tracciamento.
@David Terni
non sono d’accordo con te. Casomai se le metti all’inizio le statistiche rischi di comprometterti il sito.
@All
Per la medesima risposta che ho dato sopra, mettendo il codice alla fine hai la possibilità di avere anche dei dati migliori e più veritieri che non la visita “fugace” che sempre nulla a che vedere con la hit (che non conta nulla) e che spesso molti ancora pensano sia il numero di visitatori.
@Merlinox
Se tu metti il codice di attivazione nell’head, ma la chiamata del tracking nel footer non hai risolto nulla. O tutto o nulla.
@SEO in Abruzzo (nome???): Non è proprio così. Nel senso che nel footer puoi mettere il trackPage, mentre nella pagina puoi usare il trackEvent (http://tinyurl.com/ddn2kr).
Secondo me la cosa migliore è fare il tutto con una chiamata asincrona javascript nell’head cosi hai sia botte piena che la moglie ubriaca
:)