Des pages performantes : le cas de Google Analytics

Comme beaucoup, j’ai recours aux services de Google Analytics pour étudier la fréquentation de mon blog. C’est un outil extrêmement puissant, mais dont le fonctionnement dépend d’un fichier Javascript hébergé sur les serveurs de Google.

Nous allons réfléchir d’une part au problème éthique que cela représente, et d’autre part au problème que cela implique du point de vue des performances.

Servir un contenu étranger

Si l’on veut maîtriser un système, il faut en maîtriser les composantes, or le fichier ga.js dont nous avons besoin pour le tracking est hébergé sur les serveurs de Google, et nous n’avons aucun contrôle sur ceux-ci.

Google pourrait très bien, du jour au lendemain, décider de remplacer le contenu de ce fichier par un script nuisible, lequel ferait crasher le navigateur du visiteur ou lui présenterait une photo du drapeau nazi. Nous savons que Google ne le fera pas. Cependant, on peut imaginer que les serveurs de Google soit hackés, ou encore qu’ils tombent en panne.

Si on veut être maître du contenu que l’on sert à ses visiteurs, on ne peut pas relayer certaines fonctions à des sites externes sans mesures de contrôle.

Du point de vue des performances

On sait bien que le Javascript est un facteur important de ralentissement car en plus d’être chargé, il doit être exécuté et ralentit tout le reste. C’est encore pire ici puisque l’on demande au visiteur de récupérer un fichier sur un autre domaine : on ajoute un DNS Lookup, on perd entre 20 et 120 ms en plus du ralentissement provoqué par le tracking.

J’évoquais tout à l’heure le fait que les serveurs de Google puissent être inaccessibles : même si c’est très rare, cela arrive ; on se retrouve alors avec une réponse 404. Une réponse 404 sur un script externe ? Aïe !

J’ai simulé le phénomène en ajoutant un appel vers un script.js sur un site fictif, et j’ai pris une capture d’écran du résultat.

Le script.js prend d’une part près d’une seconde de téléchargement, et d’autre part il bloque une connection avec le serveur, parasitant le téléchargement en parallèle. Plus grave encore, certains navigateurs interprètent la réponse 404 comme du Javascript — après tout, on annonçait un .js — et là on peut carrément faire planter les autres fonctionnalités Javascript de sa page.

Quelles solutions ?

Fort heureusement, je ne suis pas le seul humain sur Terre à avoir soulevé ces problèmes. On peut classer les solutions employées par les utilisateurs d’Analytics en trois catégories.

On intègre le code en suivant les instructions de Google

On accepte ainsi le ralentissement du au script ga.js, et on croise les doigts pour que les serveurs qui distribuent le fichier soient fiables.

Allons, on peut faire mieux que ça !

On sert le Javascript nous-mêmes

C’est une solution intéressante mais relativement complexe. Elle implique de récupérer le fichier régulièrement sur les serveurs de Google, car ga.js est mis à jour régulièrement pour ajouter de nouvelles fonctionnalités au tracking. L’avantage par contre, c’est qu’on va pouvoir servir le script nous même, gzippé, avec un entête expire et compagnie.

Il existe un plugin Wordpress qui fait cela : Local Analytics. Cependant, le résultat n’est pas très pointu, et il est plus intéressant à mon avis de faire le travail soit même¹.

On charge tout le Javascript d’Analytics onload

C’est la solution que j’ai adopté sur ce blog. On garde le confort d’aller chercher un Javascript à jour chez Google, en évitant les problèmes tels que les 404 et les pertes de performances.

En effet, la page se charge entièrement, puis le Javascript de Google est chargé et exécuté. On n’a aucun ralentissement du au calcul du script pendant le chargement, et si le serveur retourne une 404, on ne bloque pas les autres téléchargements en parallèle.

Le seul inconvénient que je voie à cette technique, c’est que le comportement des visiteurs sera tracké avec moins de fidélité puisque leurs actions ne seront enregistrées qu’à partir de quelques millisecondes (le temps de charger le script) après le chargement de la page.

Si quelqu’un a une réflexion à faire sur ce point, j’aurais beaucoup de plaisir à en débattre avec lui. Le formulaire est en bas de page.

Charger et exécuter ga.js onload

J’ai traité le problème avec la fonction Asset de Mootools. On pourrait charger le script sans Mootools, mais puisque je l’utilise déjà abondamment sur ce blog, je m’en sers ici. Ceux qui aimeraient le faire sans librairie Js, voici quelques pistes pour le onload et pour le chargement du script. Pour les bienheureux qui utilisent Mootools, voici le code à placer juste avant la fin du body.

<script type="text/javascript">
window.addEvent('load', function() {
	setTimeout( function() {
		new Asset.javascript('http://www.google-analytics.com/ga.js', {
			onload: function() {
				var pageTracker = _gat._getTracker("XX-XXXXXX-X");
				pageTracker._initData();
				pageTracker._trackPageview();
			}
		});
	}, 10);
});
</script>

Le script est chargé par Asset, et une fois le chargement complet, les fonctions d’Analytics sont invoquées. J’ai décalé de 10ms avec setTimeout tout le processus car j’ai l’impression que certains navigateurs considèrent le contenu onload comme faisant partie du chargement de la page : la roue continue à tourner quelques instants après que la page soit chargée.

Bien entendu, remplacez XX-XXXXXX-X par votre code de tracking, et l’url de ga.js par l’url sécurisée si vous utilisez SSL.

1. L’auteur du plugin propose un script PHP qui peut servir de base de travail. ↩