Google Analytics a-t-il un surcoût en termes de performances?
Dans quelle mesure Google Analytics a-t-il un impact sur les performances?
Je cherche ce qui suit:
- Points de repère (y compris temps de réponse/temps de chargement des pages et autres)
- Liens ou résultats vers des points de repère similaires
Une méthode (possible) de test de Google Analytics (GA) sur votre site:
- Servez ga.js (le fichier JavaScript de Google Analytics) à partir de votre propre serveur.
- Mise à jour à partir de Google Daily (test 1) et Hebdomadaire (test 2).
Je serais intéressé de voir comment cela réduit la communication entre le serveur Web du client et le serveur GA.
Quelqu'un a-t-il effectué l'un de ces tests? Si oui, pouvez-vous fournir vos résultats? Sinon, est-ce que quelqu'un a une meilleure méthode pour tester l'impact sur la performance (ou son absence) d'utilisation de GA?
Mise à jour 2018 : Où et comment vous montez Analytics a changé maintes et maintes fois. Le code actuel de gtag.js fait quelques choses:
- Chargez le script gtag mais en mode asynchrone (non bloquant). Cela signifie que votre page ne ralentira pas autrement que par la bande passante et le traitement.
- Créez un tableau sur la page appelée
window.datalayer - Définissez une petite fonction
gtag()qui pousse tout ce que vous lui lancez dans ce tableau. - Appelle cela avec un événement pageload.
Une fois le script gtag principal chargé, il synchronise ce tableau avec Google et le surveille en conséquence. C'est un bon système et contrairement aux systèmes précédents (par exemple, insérer du code juste avant </body>), cela signifie que vous pouvez appeler des événements avant le rendu du DOM, et l'ordre des scripts n'a pas vraiment d'importance, tant que vous définissez d'abord gtag().
Cela ne veut pas dire qu'il n'y a pas de frais généraux de performance ici. Nous utilisons toujours la bande passante lors du chargement du script (il est mis en cache localement pendant 15 minutes) et il ne s’agit pas d’un petit tas de scripts qu’ils vous lancent. Il faut donc un peu de temps CPU pour le traiter.
Mais tout cela est négligeable comparé aux (par exemple) les frameworks frontend modernes.
Si vous optez pour le site Web absolu, le plus réduit possible, évitez-le complètement. Si vous essayez de protéger la vie privée de vos utilisateurs, n'utilisez pas de scripts tiers ... Mais si nous parlons d'un site Web moderne moyen, il y a beaucoup de fruits moins précieux que gtag.js si vous rencontrez des problèmes de performance.
Il y a quelques superbes diapositives par Steve Souders (expert en performance côté client) sur:
- Différentes techniques pour charger des fichiers JavaScript externes en parallèle
- leur effet sur le temps de chargement et le rendu de la page
- type d'indicateurs "en cours" affichés par le navigateur (par exemple, "chargement" dans la barre d'état, curseur de souris en sablier).
Je n'ai pas fait de tests automatisés sophistiqués ni de calculs programmatiques, mais en utilisant le bon vieux Firefox avec le plugin Firebug et une paire de variables JS pour indiquer la différence de temps avant et après l'exécution de tout le code GA, voici ce que J'ai trouvé.
Deux choses sont téléchargées:
ga.js est le fichier JavaScript contenant le code. Il s'agit de 9 Ko, de sorte que le téléchargement initial est négligeable et que le nom de fichier n'est pas dynamique. Il est donc mis en cache après la première demande.
un fichier gif de 35 octets avec une URL dynamique (via une chaîne de requête args), c'est donc demandé à chaque fois. 35 octets est également un téléchargement négligeable (firebug dit qu'il m'a fallu 70 ms pour le dl).
En ce qui concerne le temps d'exécution, ma première demande avec un cache de navigateur vierge était en moyenne d'environ 330 ms à chaque fois et les demandes suivantes, entre 35 et 130 ms.
D'après mon expérience personnelle, l'ajout de Google-Analytics n'a pas modifié les temps de chargement.
Selon FireBug, il se charge en moins d’une seconde (648 MS avg), et selon certains de mes autres tests, environ 60% - 80% du temps a été consacré au transfert des données du serveur, ce qui, bien entendu, variera d’un utilisateur à l’autre à l'utilisateur.
Je ne pense pas, à priori, que la mise en cache locale du code d'analyse modifie beaucoup le temps de chargement, pour les raisons susmentionnées.
J'utilise Google-Analytics sur plus de 40 sites Web sans que cela ne soit la cause d'un quelconque ralentissement, même minime, car la plupart du temps est consacré à l'obtention des images, ce qui, du fait de leur taille typique, est compréhensible.
Vous pouvez héberger le fichier ga.js sur vos serveurs sans aucun problème, mais l’idée est que vos utilisateurs auront le fichier ga.js mis en cache à partir de certains autres sites qu’ils auront visités. Ainsi, le téléchargement de ga.js, du fait de sa popularité, ajoute très peu de temps système (c’est-à-dire qu’il a déjà été mis en cache).
De plus, les recherches DNS ne coûtent pas la même chose à différents endroits en raison de la topologie du réseau. Le comportement de la mise en cache changerait selon que les utilisateurs utilisent ou non d'autres sites incluant ga.js.
Une fois le javascript chargé, le fichier ga.js communique avec les serveurs de Google, mais il s’agit d’un processus asynchrone.
J'espère que cela t'aides.
Il n'y a pas de surcharge de site/minimale du côté serveur.
Le code HTML pour Google Analytics est constitué de trois lignes de code javascript que vous placez au bas de votre page Web. Ce n'est rien vraiment, et ne consomme pas plus de ressources du serveur qu'un avis de droit d'auteur.
Du côté client, la page peut prendre un peu de temps (jusqu'à quelques secondes) pour finir d'afficher une page. Cependant - D'après mon expérience, le seul élément de la page qui n'a pas été chargé est le contenu de Google, afin que les utilisateurs puissent voir votre page parfaitement. Vous obtenez juste le throbber en haut de la page palpitant un peu plus longtemps.
(Remarque: pour que ce soit le cas, vous devez placer votre bloc de code Google Analytics dans le bas de l'une des pages servies. Je ne sais pas ce qui se passe si le bloc de code est placé en haut de votre code HTML.)
Les instructions traditionnelles de Google expliquant comment inclure ga.js utilisent document.write(). Ainsi, même si un navigateur chargeait de manière asynchrone des bibliothèques JavaScript externes jusqu'à ce que du code soit réellement exécuté, la document.write() bloquait toujours le chargement de la page. Les dernières instructions asynchrones ne pas utiliser document.write() directement, mais peut-être insertBefore bloque-t-il également le chargement de page?
Cependant, Google définit le max-age du cache sur 86 400 secondes (1 jour, et même sur public , aussi applicable aux mandataires ). Ainsi, comme de nombreux sites chargent le même script Google, le code JavaScript est souvent extrait du cache. Néanmoins, même lorsque ga.js est mis en cache, un simple clic sur le bouton de rechargement obligera souvent un navigateur à demander à Google toute modification . Et puis, tout comme lorsque ga.js n'était pas encore mis en cache, le navigateur doit attendre la réponse avant de continuer:
GET /ga.js HTTP/1.1 Hôte: www.google-analytics.com ... Si-Modifié-Depuis: lun. 22 juin 2009 20:00: 33 GMT Cache-Control: max-age = 0 HTTP/1.x 304 Non modifié Dernière modification: lun., 22 juin 2009 20: 00:33 GMT Date: dim. 26 juil. 2009 12:08:27 GMT Cache-Control: max-age = 604800, public Serveur: Golfe
Notez que de nombreux utilisateurs cliquent sur recharger pour les sites d'actualités, les forums et les blogs qu'ils ont déjà ouverts dans une fenêtre de navigateur. Ainsi, de nombreux navigateurs sont bloqués jusqu'à ce qu'une réponse de Google soit reçue . À quelle fréquence rechargez-vous la page d'accueil SO? Lorsque la réponse de Google Analytics est lente, ces utilisateurs le remarquent immédiatement. (Il existe beaucoup de solutions publiées sur le net pour charger de manière asynchrone le script ga.js, particulièrement utile pour ce type de sites, mais peut-être plus performant que les instructions mises à jour de Google.)
Une fois le code JavaScript chargé et exécuté, le chargement réel du bogue Web (l'image de suivi) doit être asynchrone. Donc, le chargement de l'image de suivi ne doit pas bloquer autre chose, sauf si la page utilise body.onload(). Dans ce cas, si le bogue Web ne se charge pas rapidement, le fait de cliquer sur recharger aggrave encore les choses, car cliquer sur recharger forcera également le navigateur à redemander le script, avec le If-Modified-Since décrit ci-dessus. Avant , le rechargement du navigateur n'attendait que le bogue Web, tandis que après cliquer sur le recharger a également besoin de la réponse pour le ga.js script.
Ainsi, les sites utilisant Google Analytics ne doivent pas utiliser body.onload(). Au lieu de cela, on devrait utiliser quelque chose comme $ (document) .ready () de jQuery ou événement domready de MooTools.
Voir aussi Présentation fonctionnelle de Google, expliquant Comment Google Analytics collecte-t-il les données? , y compris Comment fonctionne le code de suivi . (Cela rend également officiel le fait que Google collecte le contenu des cookies propriétaires. C’est-à-dire: les cookies du site que vous consultez.)
Mise à jour: en décembre 2009 , Google a publié ne version asynchrone . Ce qui précède devrait dire à tout le monde de mettre à niveau juste pour être sûr, cependant la mise à niveau ne résout pas tout .
Utilisez FireBug et YSlow pour vérifier par vous-même. Ce que vous découvrirez cependant, c’est que GA a une taille d’environ 9 Ko (ce qui est en fait très substantiel pour ce qu’il fait) et qu’il ne charge pas aussi très vite (pour des raisons que je ne connais pas, Je pense que cela pourrait être les serveurs "étouffer" parfois)
Nous l'avons supprimé en raison de problèmes de performances sur notre Ajax Samples , mais encore une fois pour nous, ultra rapide et réactif était la priorité 1, 2 et 3
Cela dépend vraiment du jour. J'ajoute simplement ceci à un blog. Je suis en Californie, très proche de leurs principaux centres de données, sur un DSL professionnel à faible temps de latence, sur un i5 overclocké avec beaucoup de RAM exécutant un noyau Linux récent et un firefox stable.
voici un exemple de chargement de page: 
google-analytics seul a ajouté 5 secondes juste du temps de téléchargement du réseau ... pour obtenir 15Kb!
Vous pouvez voir que blogger.com a servi 34Ko en 300 mili secondes. C'est 32 fois plus vite!
Regardez aussi comment la ligne rouge (qui représente l’événement onLoad, c’est-à-dire qu’il n’ya plus de script qui s’exécute sur la page et que le navigateur peut enfin arrêter le chargement des indicateurs/spin/etc.) ... regardez à quel point il se trouve à droite est. c'est probablement 3 secondes de traitement javascript des ordures qui s'est passé là-bas. Il est très rare que cette ligne soit très éloignée de la fin des barres de téléchargement des ressources. J'ai terminé le débogage de cette erreur et il s'agit d'un tiers des erreurs d'analyse, des deux tiers des erreurs de blogueur. ... On pourrait penser que Google a été rapide.
Modifier:
Quelques données supplémentaires. Voici une demande avec tout ce qui est mis en cache. celui-ci était la première visite.
J'ai enlevé la merde googleplus d'en haut pour deux raisons. J'essayais de voir s'ils jouaient un rôle dans l'événement lent onLoad (ils ne le sont pas) et parce que c'est en grande partie inutile.
Donc, avec cela, nous pouvons voir que l'heure du réseau est le le moins de vos soucis. Même sur un ordinateur rapide doté de logiciels modernes, le temps de traitement de Google Analytics + Blogger continuera de transférer votre chargement de pages au-delà de 7 s. Sans le blogueur, il suffit de vérifier ce site, je vois un délai de 0,5 seconde après le chargement des ressources et le début de la ligne rouge.
Charger du javascript supplémentaire sur votre page va augmenter le temps de téléchargement du point de vue du client. Vous pouvez améliorer ceci en le chargeant au bas de votre page pour que votre page soit rendue même si GA n'est pas chargé. J'éviterais la mise en cache car vous perdriez l'avantage du cache client pour votre page. Si le client la met en cache depuis une autre page, la demande de votre page sera complétée par le client lui-même. Si vous le modifiez pour le charger à partir de votre site, un téléchargement sera nécessaire même si le client possède déjà le code (ce qui est probable). Ajouter une tâche à vos processus logiciels pour éviter de charger le fichier à partir de Google semble injustifié pour une optimisation inutile. Il serait difficile de tester cela car cela servirait toujours plus rapidement localement, mais ce qui compte vraiment, c'est à quelle vitesse cela fonctionne pour vos clients. Si vous décidez d’envisager de le conserver localement, assurez-vous de le tester à partir de votre connexion Internet domestique - et non de la machine assise à côté du serveur dans votre rack.
Rien de notable.
L'appel à Google (y compris la recherche DNS, le chargement du code Javascript s'il n'est pas déjà mis en cache et les appels du suivi eux-mêmes) doit être effectué par le navigateur du client dans un fil séparé pour le chargement de votre page. Certes, la recherche DNS sera effectuée par le système sous-jacent et, à ma connaissance, ne comptera pas comme une recherche dans le navigateur (les navigateurs ont une limite sur le nombre de threads de requête qu'ils utiliseront par site).
Au-delà de cela, le navigateur chargera le script Google en parallèle avec toutes les autres ressources intégrées. Vous obtiendrez ainsi une très légère augmentation du temps nécessaire pour tout télécharger, dans le pire des cas (nous parlons de l'ordre de millisecondes, non visible. Si le script Google est chargé en dernier par le navigateur, si votre page ne contient pas beaucoup de ressources externes, ou si les ressources externes de votre page sont mises en cache par le navigateur, ou si le script de Google est mis en cache par le navigateur ( il est tout à fait trivial, le même effet que de coller une très petite image sur votre page, grosso modo.
Si vous avez un comportement qui se déclenche lors de l'événement onLoad (qui attend le chargement de ressources externes), et , les serveurs de Google sont hors service. /lent. Il est peu probable que cela se produise souvent, mais si tel était le cas, onLoad ne se déclencherait pas tant que le script n'aurait pas été téléchargé. Vous pouvez néanmoins contourner ce problème en utilisant divers événements "lorsque le DOM est chargé", qui sont généralement plus réactifs, car vous n'avez pas à attendre que vos propres scripts/images soient chargés de cette façon.
Si les effets sur le temps de chargement des pages vous inquiètent vraiment, jetez un œil à la section "Vitesse nette" de Firebug , qui permettra de quantifier ceci et de vous tracer un joli graphique. De toute façon, je vous encourage à le faire vous-même, même si d’autres personnes vous donnent les chiffres et les points de repère que vous demandez, cela sera complètement différent pour vous-même. site.
Eh bien, j'ai effectué des recherches, des recherches et des analyses approfondies sur Internet. Mais je n'ai trouvé aucune donnée statistique qui soit en faveur ou en défaveur de la prémisse.
Cependant, cet extrait de http://www.ga-experts.com affirme que c'est un mythe que GA ralentit votre site Web.
Euh, d'accord, peut-être un peu, mais nous parlons de millisecondes. GÉORGIE fonctionne par balisage de page, et à tout moment vous ajoutez plus de contenu à une page Web, il va augmenter les temps de chargement. Toutefois Si vous suivez les meilleures pratiques (ajouter la balise avant la balise
</body>), alors votre page se chargera en premier. Aussi, ours en gardant à l'esprit que tout type de page basé sur le Web Le package d'analyse (qui est la majorité ) fonctionnera de la même manière
D'après les réponses ci-dessus et toutes les autres sources, ce que je ressens, c'est que le ralentissement qu'il provoque n'est pas perçu par l'utilisateur car le script est inclus au bas de la page. Mais si nous parlons de chargement de page complet, nous pourrions dire que cela ralentit le temps de chargement de page.
S'il vous plaît poster dans plus d'informations si vous avez et données si vous en avez.
La question était de savoir si Google Analytics ralentissait votre site et la réponse est oui. Pour le moment, au moment de la rédaction de ce document, Google-Analytics.com ne fonctionne pas. Par conséquent, les sites dont le contenu figure dans leurs pages ne seront pas chargés. Ainsi, cela peut ralentir et empêcher votre site de se charger. Il est rare que google-analytics.com soit sur une longueur de plus de 10 minutes, mais cela montre simplement que c'est possible.
Il y a deux aspects à cela.
- Le script d'analyse '' (et un gif) à télécharger
- Exécution des scripts téléchargés
Le temps de téléchargement est presque toujours inférieur à 100 ms, ce qui est acceptable.
Voici la torsion.
- analytics.js exécution 250ms
- re-marketing (si activé) 300ms
- demographic (si activé) 200ms
Donc, l’analyse avec le re-marketing prend 750 ms en moyenne. Je pense qu’il s’agit d’un chiffre énorme en ce qui concerne les frais généraux de performance.
Je ne pense pas que c’est ce que vous recherchez, mais pourquoi vous inquiétez-vous de la performance?
Si c'est votre serveur ... alors il n'y a évidemment aucun impact car il réside sur les serveurs de Google.
Si ce sont vos utilisateurs qui vous inquiètent, il n'y a aucun impact non plus. Tant que vous le placez juste au-dessus de la balise body, vos utilisateurs ne recevront rien de plus lent qu'avant ... le script est chargé en dernier et n'a aucun effet sur l'apparence de l'utilisateur. Donc, il ne faut essentiellement rien attendre et même continuer à parcourir la page sans se rendre compte que son chargement est toujours en cours.