Est-il normal que le suivi de la vitesse des sites de Google Analytics présente d'énormes anomalies?
J'ai récemment commencé à utiliser la nouvelle fonction _trackPageLoadTime de Google Analytics pour mesurer les temps de chargement des pages. Cependant, j'ai remarqué que quelques pages apparaissent avec un énorme "temps de chargement moyen". Une page montre un temps de 556.22 secondes! Plusieurs autres pages indiquent des temps moyens de plus de 30 secondes.
Le fait de cliquer sur le détail de la page montre que les temps moyens les plus élevés sont le résultat d'un temps de chargement très long de plus de 100 secondes (et la plupart des meilleurs temps ne disposent que d'un "échantillon de chargement de page" de 1 ou 2 personnes).
S'agit-il uniquement d'anomalies où l'utilisateur a perdu la connexion ou quelque chose? Existe-t-il un moyen de visualiser les données sans ces anomalies?
Le suivi de vitesse du site Google Analytics utilise l’API HTML5 Navigation Timing. J'ai écrit un réponse assez détaillée sur StackOverflow.
Plus précisément, il utilise ces 2 attributs sur les navigateurs ayant l'objet performance.timing:
Si la nouvelle ressource doit être extraite à l'aide de HTTP GET ou équivalent, fetchStart doit renvoyer l'heure immédiatement avant que l'agent d'utilisateur ne commence à vérifier les caches d'application pertinents. Sinon, il doit renvoyer l'heure à laquelle l'agent d'utilisateur commence à extraire la ressource.
Cet attribut doit renvoyer l'heure immédiatement avant le déclenchement de l'événement de chargement du document actuel. Il doit renvoyer zéro lorsque l'événement load n'est pas encore déclenché.
Ce dernier événement correspond à l'événement de chargement de la fenêtre (window.onload). Bien qu'il s'agisse d'un événement important, ce n'est pas la même chose que lorsque votre page devient utilisable. Ainsi, votre page pourrait très bien fonctionner, mais l'événement onload pourrait être retardé par une ressource particulièrement lente sur votre page.
Votre site contient-il des actifs externes? La publicité? Beaucoup de plugins sociaux? Il est possible que son événement de chargement de fenêtre soit retardé.
Il est important de garder à l'esprit que le taux d'échantillonnage de cette fonction est par défaut très faible. Il est configuré pour essayer d'échantillonner 10% des visites, mais en pratique, selon votre niveau d'assistance, il peut représenter entre 2% et 4% du trafic. Ainsi, des valeurs aberrantes uniques peuvent avoir des effets très importants sur la qualité des données.
Vous pouvez avoir une meilleure idée de la fiabilité de la distribution des données en explorant en détail les données d'échantillonnage de la page vue pour obtenir la distribution.
Si vous souhaitez un point de données différent pour vos performances, vous pouvez utiliser des événements pour créer un suivi des performances personnalisé. (Cela ruinerait toutefois votre taux de rebond, car un événement compterait comme une interaction.) Par exemple, l’événement DOM Ready est peut-être un meilleur baromètre du moment où votre site devient utilisable.
if(window.performance && performance.timing)
{
var ms = performance.timing.domContentLoadedEventStart - performance.timing.fetchStart;
_gaq.Push(["_trackEvent", "Performance", "Time to DOM Ready","",ms]);
}
(Anecodetally, oui, c'est très commun. Découvrez certains de ces moments de l'un de mes comptes):
Il peut s'agir d'une personne connectée qui a pris beaucoup de temps pour charger votre page ou d'une personne dont la connexion est encombrée.
Si vous pouvez savoir quand ils se sont rendus, vous pouvez exclure ce jour de vos chiffres. Ou, si vous pouvez repérer d'autres caractéristiques, telles que leur pays ou leur réseau, vous pouvez créer un segment personnalisé qui exclut ces visiteurs.