webentwicklung-frage-antwort-db.com.de

Hat Google Analytics einen Performance-Overhead?

Inwiefern beeinflusst Google Analytics die Leistung?

Ich suche das Folgende:

  • Benchmarks (einschließlich Antwortzeiten/Seitenwechselzeiten usw.)
  • Links oder Ergebnisse zu ähnlichen Benchmarks

Eine (mögliche) Methode zum Testen von Google Analytics (GA) auf Ihrer Website:

  1. Stellen Sie ga.js (die Google Analytics-JavaScript-Datei) von Ihrem eigenen Server aus bereit.
  2. Update von Google Daily (Test 1) und Weekly (Test 2).

Es würde mich interessieren, wie dies die Kommunikation zwischen dem Client-Webserver und dem GA -Server reduziert.

Hat jemand einen dieser Tests durchgeführt? Wenn ja, können Sie Ihre Ergebnisse liefern? Wenn nicht, hat jemand eine bessere Methode, um den Performance-Hit (oder dessen Mangel) für die Verwendung von GA zu testen?

78
M.N

2018 Update : Wo und wie Sie Analytics einbinden, hat sich immer wieder geändert. Der aktuelle Code von gtag.js bewirkt ein paar Dinge:

  1. Laden Sie das gtag-Skript, aber asynchron (nicht blockierend). Dies bedeutet, dass Ihre Seite auf keine andere Weise verlangsamt wird als durch Bandbreite und Verarbeitung.
  2. Erstellen Sie auf der Seite ein Array mit dem Namen window.datalayer.
  3. Definieren Sie eine kleine gtag()-Funktion, die alles, was Sie darauf werfen, in dieses Array schiebt.
  4. Ruft das mit einem pageload-Ereignis auf.

Sobald das gtag-Skript geladen ist, synchronisiert es dieses Array mit Google und überwacht es auf Änderungen. Es ist ein gutes System und im Gegensatz zu den vorherigen Systemen (z. B. Stopfcode in </body>) bedeutet dies, dass Sie Ereignisse aufrufen können, bevor das DOM gerendert wird. Die Reihenfolge der Skripte spielt keine Rolle, solange Sie zuerst gtag() definieren.

Das heißt nicht, dass es hier keinen Performance-Overhead gibt. Beim Laden des Skripts wird immer noch Bandbreite verwendet (es wird lokal für 15 Minuten zwischengespeichert), und es ist kein kleiner Stapel von Skripts, die von Ihnen ausgegeben werden. Daher wird etwas CPU-Zeit für die Verarbeitung benötigt.

Aber es ist alles vernachlässigbar im Vergleich zu (zB) modernen Frontend-Frameworks.  

Wenn Sie sich für die absolut reduzierte Website entscheiden, sollten Sie diese vollständig vermeiden. Wenn Sie versuchen, die Privatsphäre Ihrer Benutzer zu schützen, verwenden Sie keine Skripte von Drittanbietern ... Wenn es sich jedoch um eine durchschnittliche moderne Website handelt, sind viel weniger hängende Früchte als gtag.js wenn Sie auf Leistungsprobleme stoßen.

32
Oli

Es gibt einige großartige Folien von Steve Souders (Client-seitiger Performance-Experte) über:

  • Verschiedene Techniken zum parallelen Laden externer JavaScript-Dateien
  • ihre Auswirkung auf die Ladezeit und das Rendern der Seite
  • welche Art von Statusanzeigen wird vom Browser angezeigt (z. B. "Laden" in der Statusleiste, Sanduhr-Mauszeiger).
10
orip

Ich habe kein ausgefallenes automatisiertes Testen oder programmatisches Zahlen-Crunching durchgeführt, aber ich habe guten alten Firefox mit dem Firebug-Plugin und einem Paar JS-Variablen verwendet, um den Zeitunterschied vor und nach dem Ausführen des gesamten GA -Codes zu ermitteln Ich fand.

Zwei Dinge werden heruntergeladen:

  1. ga.js ist die JavaScript-Datei, die den Code enthält. Dies ist 9 KB, also ist der anfängliche Download vernachlässigbar und der Dateiname nicht dynamisch, so dass er nach der ersten Anforderung zwischengespeichert wird.

  2. eine 35-Byte-GIF-Datei mit einer dynamischen URL (über Abfragezeichenfolge-Argumente), so dass dies jedes Mal angefordert wird. 35 Bytes ist auch ein vernachlässigbarer Download (Firebug sagt, dass ich 70ms dafür brauchte, um es zu dl).

Was die Ausführungszeit angeht, betrug meine erste Anforderung mit einem sauberen Browser-Cache jedes Mal durchschnittlich etwa 330 ms und die nachfolgenden Anforderungen lagen zwischen 35 und 130 ms.

6
Rich

Aus meiner eigenen Erfahrung hat das Hinzufügen von Google-Analytics die Ladezeiten nicht geändert.

Laut FireBug wird es in weniger als einer Sekunde geladen (648MS avg), und dementsprechend waren einige meiner anderen Tests ~ 60% - 80% dieser Zeit waren das Übertragen der Daten vom Server zum Benutzer.

Ich glaube nicht, dass das lokale Zwischenspeichern des Analysecodes die Ladezeiten aus den oben genannten Gründen stark verändern wird.

Ich benutze Google-Analytics auf mehr als 40 Websites, ohne dass es jemals zu einer, auch nur geringen, Verlangsamung, kommt. Die meiste Zeit wird damit verbracht, Bilder zu erhalten, die aufgrund ihrer typischen Größe verständlich sind. 

5
UnkwnTech

Sie können die ga.js auf Ihren Servern ohne Probleme hosten. Die Idee ist jedoch, dass Ihre Benutzer die ga.js von einer anderen anderen - Site zwischengespeichert haben, die sie besucht haben. Das Herunterladen von ga.js, weil es so beliebt ist, verursacht in vielen Fällen sehr wenig Overhead (d. H. Es wurde bereits zwischengespeichert). 

Außerdem kosten DNS-Lookups aufgrund der Netzwerktopologie an verschiedenen Orten nicht dasselbe. Das Caching-Verhalten hängt davon ab, ob Benutzer andere Websites verwenden, die ga.js enthalten oder nicht.

Nach dem Laden des Javascript kommuniziert ga.js zwar mit Google-Servern, dies ist jedoch ein asynchroner Vorgang.

Hoffe das hilft. 

5
Dan Rosenstark

Es gibt keinen/minimalen Site-Overhead auf der Serverseite. 

Der HTML-Code für Google Analytics besteht aus drei Javascriptzeilen, die Sie am unteren Rand Ihrer Webseite platzieren. Es ist nichts wirklich und verbraucht keine Serverressourcen mehr als einen Copyright-Hinweis. 

Auf der Clientseite kann die Seite etwas (bis zu ein paar Sekunden) dauern, bis eine Seite fertig ist. Meiner Erfahrung nach ist der einzige Teil der Seite, der nicht geladen ist, der Google-Inhalt, sodass Benutzer Ihre Seite perfekt sehen können. Der Throbber oben auf der Seite wird noch ein wenig länger pulsieren. 

(Hinweis: Sie müssen Ihren Google Analytics-Codeblock am unteren Rand aller bereitgestellten Seiten einfügen, damit dies der Fall ist. Ich weiß nicht, was passiert, wenn der Codeblock oben in Ihrem HTML-Code platziert wird.)

3
seanyboy

Die traditionelle Anleitung von Google zur Einbindung von ga.js verwenden document.write(). Selbst wenn ein Browser externe JavaScript-Bibliotheken irgendwie asynchron laden würde, bis tatsächlich Code ausgeführt werden soll, würde die Funktion document.write() das Laden der Seite blockieren. Die späteren asynchronen Anweisungen verwenden document.write() nicht direkt, aber blockieren insertBefore möglicherweise auch das Laden von Seiten?

Google setzt den max-age des Caches jedoch auf 86.400 Sekunden (1 Tag und sogar auf public , was auch für Proxys gilt). Da viele Websites dasselbe Google-Skript laden, wird JavaScript häufig aus dem Cache abgerufen. Auch wenn ga.js zwischengespeichert ist, werden Sie durch einfaches Klicken auf die Schaltfläche zum Aktualisieren häufig von einem Browser nach Änderungen gefragt . Und dann, genau wie wenn ga.js noch nicht zwischengespeichert wurde, muss der Browser die Antwort abwarten, bevor er fortfährt:

GET /ga.js HTTP/1.1 
 Host: www.google-analytics.com 
 ... 
 If-Modified-Since: Mo, 22 Jun 2009 20:00: 33 GMT 
 Cache-Kontrolle: max-age = 0 
 
 HTTP/1.x 304 Nicht geändert 
 Zuletzt geändert: Mo, 22. Juni 2009 20: 00:33 GMT 
 Datum: Sonntag, 26. Juli 2009 um 12:08:27 GMT 
 Cache-Kontrolle: maximales Alter = 604800, öffentlicher 
 Server: Golfe 

Beachten Sie, dass viele Benutzer auf Neu laden klicken, um in einem Browserfenster bereits geöffnete Nachrichten-Websites, Foren und Blogs aufzurufen, und so viele Browser blockieren, bis eine Antwort von Google eingeht . ). Wie oft laden Sie die SO -Homepage neu? Wenn die Antwort von Google Analytics langsam ist, bemerken diese Nutzer dies sofort. (Es gibt viele Lösungen , die im Internet veröffentlicht wurden, um das Skript ga.js asynchron zu laden. Dies ist besonders nützlich für diese Art von Websites, ist aber möglicherweise nicht länger besser als die aktualisierten Anweisungen von Google.)

Sobald das JavaScript geladen und ausgeführt wurde, sollte das tatsächliche Laden des Web-Fehlers (des Tracking-Bildes) asynchron sein. Daher sollte das Laden des Verfolgungsbildes nichts anderes blockieren, es sei denn die Seite verwendet body.onload(). In diesem Fall verschlechtert das Klicken auf "Neu laden" die Situation, wenn der Web-Fehler nicht sofort geladen wird, da der Browser das Skript mit dem oben beschriebenen If-Modified-Since erneut anfordert, wenn er auf "Neu laden" klickt. Vor dem erneuten Laden wartete der Browser nur auf den Web-Fehler, während nach dem erneuten Laden die Antwort für das ga.js-Skript benötigt.

Daher sollten Websites, die Google Analytics verwenden, nicht body.onload() verwenden. Stattdessen sollte man so etwas wie jQueries $ (document) .ready () oder MooTools domready event verwenden.

Siehe auch Googles Funktionsübersicht , in dem erläutert wird, wie Google Analytics Daten sammelt , einschließlich , wie der Tracking-Code funktioniert . (Dies macht es auch offiziell, dass Google den Inhalt von Erstanbieter-Cookies sammelt. Das heißt: die Cookies von der Website, die Sie besuchen.)


Update: im Dezember 2009 , Google hat eine asynchrone Version veröffentlicht. Das obige sollte jedem empfehlen, nur um sicherzugehen, dass ein Upgrade durchgeführt wird ein Upgrade löst nicht alles .

3
Arjan

Verwenden Sie FireBug und YSlow, um sich selbst zu überprüfen. Was Sie jedoch entdecken werden, ist, dass GA ungefähr 9 KB groß ist (was eigentlich ganz wesentlich für das ist, was es tut) und dass es manchmal auch nicht sehr schnell geladen wird (aus welchen Gründen weiß ich nicht, glaube ich) es könnte sein, dass die Server manchmal "würgen"

Wir entfernt aufgrund von Leistungsproblemen in unseren Ajax Samples , aber andererseits war es für uns ultraschnell und reagierte mit Priorität 1, 2 und 3

2
Thomas Hansen

Das hängt wirklich vom Tag ab. Ich füge das nur einem Blog hinzu. Ich bin in Kalifornien, ganz in der Nähe ihrer Hauptrechenzentren, auf einem schnellen DSL mit niedriger Latenz, auf einem übertakteten i5 mit reichlich RAM, auf dem kürzlich ein Linux-Kernel und ein stabiles Firefox ausgeführt werden.

hier ist eine Beispielseite: enter image description here

google-analytics allein fügte nur 5 Sekunden hinzu, und zwar nur um die Downloadzeit des Netzwerks ... um 15Kb zu erhalten!

Sie können sehen, dass blogger.com 34 Kb in 300 mili Sekunden bedient. Das ist 32x schneller!

Schauen Sie auch nach, wie die rote Linie (die das onLoad-Ereignis darstellt. Das bedeutet, dass auf der Seite kein Skript mehr ausgeführt wird und der Browser die Ladeindikatoren/Spinings/etc schließlich stoppen kann) ... schauen Sie, wie weit rechts davon ist. Das ist wahrscheinlich 3 Sekunden von Müll Javascript Verarbeitung, die dort passiert ist. Es ist sehr ungewöhnlich, dass diese Zeile sehr weit vom Ende der Download-Bars entfernt ist. Ich bin damit fertig, das zu debuggen und es ist 1/3 Analysefehler, 2/3 Bloggerfehler. ... man könnte denken, dass Google Sachen schnell waren.

Bearbeiten:

Noch mehr Daten. Hier ist eine Anfrage mit alles zwischengespeichert. Der oben genannte war der erste Besuch.

Ich habe den googleplus-Mist aus zwei Gründen von oben entfernt. Ich habe versucht herauszufinden, ob sie beim langsamen onLoad-Ereignis eine Rolle gespielt haben (sie sind es nicht) und weil es meist nutzlos ist.

enter image description here

So können wir sehen, dass die Netzwerkzeit das least Ihrer Sorgen ist. Selbst auf einem schnellen Computer mit moderner Software wird die Ladezeit der Seite von Google Analytics + Blogger für die Verarbeitung nach 7s immer noch größer. Wenn Sie keinen Blogger haben, sehen Sie sich diese Website an. Ich sehe eine Verzögerung von 0,5 Sekunden, nachdem Ressourcen geladen wurden und die rote Linie beginnt.

2
gcb

Wenn Sie zusätzliches Javascript auf Ihre Seite laden, erhöht sich die Downloadzeit aus der Perspektive des Kunden. Sie können dies verbessern, indem Sie es am unteren Rand Ihrer Seite laden, sodass Ihre Seite auch dann gerendert wird, wenn GA nicht geladen ist. Ich würde das Caching vermeiden, da Sie den Vorteil des Client-Caches für Ihre Seite verlieren würden. Wenn der Client von einer anderen Seite zwischengespeichert wurde, wird die Anforderung Ihrer Seite vom Client selbst ausgefüllt. Wenn Sie es ändern, um es von Ihrer Site zu laden, ist ein Download erforderlich, selbst wenn der Client bereits über den Code verfügt (was wahrscheinlich ist). Das Hinzufügen einer Aufgabe zu Ihren Softwareprozessen, um zu vermeiden, dass die Datei von Google geladen wird, scheint ungerechtfertigt für eine möglicherweise unnötige Optimierung zu sein. Es wäre schwierig, dies zu testen, da es vor Ort immer schneller sein würde, aber es ist wirklich wichtig, wie schnell es für Ihre Kunden funktioniert. Wenn Sie entscheiden, ob Sie das Gerät lokal aufbewahren möchten, stellen Sie sicher, dass Sie es von Ihrer Heim-Internetverbindung aus testen. Nicht die Maschine, die neben dem Server in Ihrem Rack sitzt.

2
tvanfosson

Nichts auffällig.

Der Aufruf von Google (einschließlich DNS-Lookup, Laden des Javascript, wenn es nicht bereits zwischengespeichert ist, und der eigentliche Tracer-Aufruf selbst) sollte vom Browser des Clients in einem separaten Thread erfolgen, um Ihre Seite tatsächlich zu laden. Sicher wird die DNS-Suche vom zugrunde liegenden System durchgeführt und gilt meines Wissens nicht als Suche innerhalb des Browsers (Browser haben ein Limit für die Anzahl der Anfragethreads, die sie pro Site verwenden).

Darüber hinaus lädt der Browser das Google-Skript zusammen mit allen anderen eingebetteten Ressourcen parallel, so dass Sie möglicherweise im schlimmsten Fall (wir sprechen in der Reihenfolge von) einen extrem geringen Zeitgewinn beim Herunterladen von Inhalten erzielen Millisekunden, nicht wahrnehmbar. Wenn das Google-Skript zuletzt vom Browser geladen wurde oder nicht viele externe Ressourcen auf Ihrer Seite vorhanden sind oder wenn die externen Ressourcen Ihrer Seite vom Browser zwischengespeichert werden oder wenn das Google-Skript vom Browser zwischengespeichert wird ( Sehr wahrscheinlich), dann werden Sie keinen Unterschied bemerken. Es ist insgesamt absolut trivial, der gleiche Effekt, als würde man grob gesagt ein extra kleines Bild auf Ihre Seite kleben.

Die einzige Möglichkeit, die einen konkreten Unterschied bewirken kann, besteht darin, dass bei einem Verhalten, das beim Ereignis onLoad ausgelöst wird (das darauf wartet, dass externe Ressourcen geladen werden), und die Google-Server ausgefallen sind /schleppend. Letzteres ist unwahrscheinlich, aber in diesem Fall wird onLoad erst ausgelöst, wenn das Skript heruntergeladen wurde. Sie können dies trotzdem umgehen, indem Sie verschiedene "When DOM Loaded" -Ereignisse verwenden, die im Allgemeinen reaktionsschneller sind, da Sie auch nicht darauf warten müssen, dass Ihre eigenen Skripte/Bilder auf diese Weise geladen werden.

Wenn Sie wirklich so besorgt über die Auswirkungen auf die Ladezeit sind, schauen Sie sich den Abschnitt "Nettogeschwindigkeit" von Firebug an, der dies quantifiziert und Ihnen ein hübsches Diagramm zeichnet. Ich würde Sie auf jeden Fall dazu ermutigen, dies für sich selbst zu tun, denn selbst wenn Ihnen andere Leute die Zahlen und Benchmarks geben, die Sie anfordern, wird es für Ihre eigene Site völlig anders sein.

1
Andrzej Doyle

Nun, ich habe ausführlich im Netz gesucht, recherchiert und ausgiebig gesucht. Ich habe jedoch keine statistischen Daten gefunden, die entweder für oder gegen die Prämisse sprechen.

Dieser Auszug aus http://www.ga-experts.com behauptet jedoch, es sei ein Mythos, dass GA Ihre Website verlangsamt.

Ähm, okay, vielleicht etwas, aber wir sprechen von Millisekunden. GA arbeitet nach Seiten-Tagging und jederzeit Sie fügen einer Webseite mehr Inhalt hinzu, es erhöht die Ladezeiten. Jedoch Wenn Sie die bewährte Methode befolgen (das Tag vor dem Tag </body> hinzufügen....), dann Ihre Seite wird zuerst geladen. Auch tragen Bedenken Sie, dass jedes auf Seiten-Tags basierende Web Das Analysepaket (die Mehrheit) funktioniert auf dieselbe Weise

Aus den obigen Antworten und aus allen anderen Quellen gehe ich davon aus, dass die vom Benutzer verursachte Verlangsamung nicht als das Skript wahrgenommen wird, das am Ende der Seite enthalten ist. Wenn wir jedoch von kompletten Seitenladungen sprechen, könnte man sagen, dass dies die Ladezeit der Seite verlangsamt.

Bitte schreiben Sie in mehr Info, wenn Sie haben und DATEN, wenn Sie welche haben.

1
M.N

Die Frage war, ob Google Analytics dazu führen würde, dass Ihre Website langsamer wird, und die Antwort lautet Ja. Zum Zeitpunkt des Schreibens dieser Website funktioniert Google-Analytics.com nicht, so dass Websites, die auf ihren Seiten enthalten sind, die Seiten nicht laden. Ja, sie können langsamer werden und dazu führen, dass Ihre Website nicht geladen wird. Es ist ungewöhnlich, dass google-analytics.com so lange ausfällt, was jetzt schon über 10 Minuten dauert, aber es zeigt nur, dass es möglich ist. 

0

Es gibt zwei Aspekte.

  1. Download des Analytics-Skripts (und eines GIF)
  2. Heruntergeladene Skriptausführung

Die Downloadzeit beträgt fast immer weniger als 100ms, was akzeptabel ist.

Hier kommt die Wendung.

  1. analytics.js Ausführung 250ms 
  2. re-Marketing (falls aktiviert) 300ms
  3. demografisch (wenn aktiviert) 200ms

Daher dauert die Analyse mit Re-Marketing im Durchschnitt 750 ms. Ich denke, dass dies eine enorme Zahl ist, wenn es um Performance-Overhead geht.

0
Joseph Kulandai

Ich glaube nicht, dass Sie danach suchen, aber wieso machen Sie sich Sorgen um die Leistung?

Wenn es Ihr Server ist ... dann hat dies offensichtlich keine Auswirkungen, da es sich auf Google-Servern befindet.

Wenn es Ihre Benutzer sind, um die Sie sich Sorgen machen, dann gibt es auch keine Auswirkungen. Solange Sie es direkt über dem Body-Tag platzieren, erhalten Ihre Benutzer nichts langsamer als zuvor ... Das Skript wird zuletzt geladen und hat keine Auswirkungen auf das Erscheinungsbild des Benutzers. Es wird also praktisch nicht auf irgendetwas gewartet und Sie können die Seite auch weiterhin durchsuchen, ohne zu bemerken, dass sie noch geladen wird.

0
youdontmeanmuch