Google Analyticsにはパフォーマンスのオーバーヘッドがありますか？
Google Analyticsはパフォーマンスにどの程度影響しますか？
私は以下を探しています：
- ベンチマーク（応答時間/ページロード時間などを含む）
- 同様のベンチマークへのリンクまたは結果
サイトでGoogleアナリティクス（GA）をテストする（可能な）方法の1つ：
- 独自のサーバーからga.js（Google Analytics JavaScriptファイル）を提供します。
- Google Daily（test 1）とWeekly（test 2）から更新します。
これがクライアントのWebサーバーとGAサーバー間の通信を削減する方法を確認する方法に興味があります。
誰かがこれらのテストを実施しましたか？もしそうなら、あなたはあなたの結果を提供できますか？そうでない場合、誰もがGAを使用してパフォーマンスヒット（またはその欠如）をテストするより良い方法を持っていますか？
2018年の更新：Analyticsをマウントする場所と方法が何度も何度も変更されました。現在のgtag.jsコードはいくつかのことを行います：
- Gtagスクリプトを読み込みますが、非同期（非ブロッキング）です。つまり、帯域幅と処理以外の方法でページの速度が低下することはありません。
- _
window.datalayer_という名前のページに配列を作成します - 小さな
gtag()関数を定義して、投げたものをその配列にプッシュするだけです。 - Pageloadイベントでそれを呼び出します。
メインのgtagスクリプトが読み込まれると、この配列がGoogleと同期され、変更がないか監視されます。これは優れたシステムであり、以前のシステムとは異なり（たとえば、_</body>_の直前にコードを挿入する）、DOMがレンダリングされる前にイベントを呼び出すことができ、gtag()最初に。
ここにパフォーマンスのオーバーヘッドがないと言っているわけではありません。スクリプトのロードに帯域幅をまだ使用しています（ローカルで15分間キャッシュされます）。スクリプトが山のように山積みになるわけではないので、CPU時間で処理されます。
しかし、（たとえば）最新のフロントエンドフレームワークと比較すると、すべて無視できます。
あなたが可能な限り絶対的な、最も削減されたウェブサイトを目指しているなら、それを完全に避けてください。ユーザーのプライバシーを保護しようとしている場合は、サードパーティのスクリプトを使用しないでください...しかし、平均的な現代のWebサイトの場合は、がたくさんありますパフォーマンスの問題が発生している場合は、gtag.jsよりもぶら下がっているフルーツが少ない。
Steve Souders（クライアント側のパフォーマンス専門家）による 素晴らしいスライド については、次のようなものがあります。
- 外部JavaScriptファイルを並行してロードするためのさまざまな手法
- 読み込み時間とページレンダリングへの影響
- ブラウザが表示する「進行中」のインジケータの種類（ステータスバーの「読み込み中」、砂時計のマウスカーソルなど）。
私は特別な自動テストやプログラムによる数値の計算は行っていませんが、Firebugプラグインと2つのJS変数を備えた古き良きFirefoxを使用して、すべての前後の時間差を伝えていますGAコードは実行、ここに私が見つけたものがあります。
2つのものがダウンロードされます。
ga.jsは、コードを含むJavaScriptファイルです。これは9kbなので、最初のダウンロードはごくわずかで、ファイル名は動的ではないため、最初のリクエストの後でキャッシュされます。
（クエリ文字列引数を介して）動的URLを含む35バイトのgifファイルなので、これは毎回要求されます。 35バイトも無視できるダウンロードです（Firebugによると、ダウンロードに70ミリ秒かかりました）。
実行時間に関する限り、クリーンなブラウザキャッシュを使用した最初のリクエストは、毎回平均約330ミリ秒で、後続のリクエストは35〜130ミリ秒でした。
私自身の経験から、Google-Analyticsを追加しても読み込み時間は変わりません。
FireBugによると、1秒未満（平均648MS）で読み込まれるため、他のテストの一部によると、その時間の約60％〜80％がサーバーからデータを転送していました。ユーザーからユーザーへ。
上記の理由により、分析コードをローカルにキャッシュするとロード時間が大幅に変わるとは特に考えていません。
私は、40以上のウェブサイトでGoogleアナリティクスを使用していますが、それが少しの速度低下の原因になることもありません。通常、サイズが原因で理解できる画像の取得に最も多くの時間が費やされています。
サーバー上でga.jsをホストしてもまったく問題はありませんが、ユーザーがアクセスした可能性があるいくつかのotherサイトからga.jsがキャッシュされるという考え方です。そのため、ga.jsは非常に人気があるため、ダウンロードしても多くの場合オーバーヘッドはほとんど追加されません（つまり、すでにキャッシュされています）。
さらに、DNSルックアップは、ネットワークトポロジーが原因で、異なる場所で同じコストがかかることはありません。キャッシュの動作は、ユーザーがga.jsを含む他のサイトを使用するかどうかによって異なります。
JavaScriptが読み込まれると、ga.jsはGoogleサーバーと通信しますが、これは非同期プロセスです。
お役に立てれば。
本当に日によって異なります。これをブログに追加しています。私はカリフォルニアにいて、メインのデータセンターに非常に近く、高速低遅延のビジネスDSLで、オーバークロックされたi5で、RAMが最新のLinuxカーネルと安定したFirefoxを実行しています。
これがサンプルのページ読み込みです： 
google-analyticsだけで5 secondsネットワークダウンロード時間を追加しました... 15 KBを取得します！
Blogger.comが300 mili秒で34Kbを配信したことがわかります。これは32倍高速です。
また、赤い線（これはonLoadイベントを表します。つまり、ページ上で実行されているスクリプトがなく、ブラウザが最終的に読み込みインジケーター/回転などを停止できるようになっています）を見てください...です。これはおそらく、そこで発生したガベージJavaScript処理の3秒です。その線がリソースダウンロードバーの端から非常に離れていることは非常にまれです。私はこれをデバッグしました、そしてそれは1/3の分析の失敗、2/3のブロガーの失敗です。 ...グーグルのものは速かったと思うだろう。
編集：
もう少しデータ。すべてがキャッシュされたリクエストを次に示します。上記は初めての訪問でした。
私は2つの理由でgoogleplusがらくたを削除しました。スローなonLoadイベント（そうではない）で何らかの役割を果たしているかどうかと、ほとんど役に立たないためです。
これで、ネットワーク時間は心配の最小であることがわかります。最新のソフトウェアを備えた高速コンピューター上でも、Googleアナリティクス+ブロガーの処理時間がかかると、ページの読み込みが7秒を超えてダンプされます。ブロガーがいない場合は、このサイトを確認してください。リソースが読み込まれて赤い線が表示されてから0.5秒の遅延が発生します。
サーバー側にサイトのオーバーヘッドがないか、最小限です。
Google AnalyticsのHTMLは、Webページの下部に配置する3行のJavaScriptです。これは実際には何の問題もなく、著作権表示よりも多くのサーバーリソースを消費しません。
クライアント側では、ページの表示が完了するまでに少し（最大数秒）の時間がかかる場合があります。ただし、私の経験では、読み込まれていないページはGoogleのものだけなので、ユーザーはページを完全に正常に表示できます。ページの上部にあるドキドキする音が少し長くなります。
（注：これを行うには、Googleアナリティクスコードブロックを配信ページの下部に配置する必要があります。コードブロックをHTMLの上部に配置するとどうなるかわかりません）
ga.jsを含める方法についてのGoogleの 従来の指示 は、document.write()を使用します。そのため、実際にコードが実行されるまでブラウザが何らかの方法で外部JavaScriptライブラリを非同期にロードしても、document.write()はページのロードをブロックします。後の 非同期命令 はdocument.write()を直接使用しないでください。ただし、insertBeforeもページのロードをブロックしますか？
ただし、Googleはキャッシュのmax-ageを 86,400秒 に設定します（1日であり、publicにも設定されているため、プロキシにも適用されます）。そのため、多くのサイトがまったく同じGoogleスクリプトをロードするため、JavaScriptがキャッシュからフェッチされることがよくあります。それでも、ga.jsがキャッシュされている場合でも、リロードボタンをクリックするだけで、ブラウザがGoogleに変更を要求することがよくあります。そして、ga.jsがまだキャッシュされていないときと同様に、ブラウザは続行する前に応答を待機する必要があります。
GET /ga.js HTTP/1.1 ホスト：www.google-analytics.com ... If-Modified-Since：Mon、22 Jun 2009 20:00： 33 GMT Cache-Control：max-age = 0 HTTP/1.x 304 Not Modified Last-Modified：Mon、22 Jun 2009 20： 00:33 GMT 日付：日、2009年7月26日12:08:27 GMT キャッシュ制御：max-age = 604800、公開 サーバー：ゴルフ
多くのユーザーがブラウザウィンドウで既に開いているニュースサイト、フォーラム、ブログのリロードをクリックし、Googleからの応答が受信されるまで多くのブラウザをブロックすることに注意してください。 SOホームページをどのくらいの頻度でリロードしますか？Google Analyticsの応答が遅い場合、そのようなユーザーはすぐに気づきます。（ 多くの解決策 がネットで公開されています） ga.jsスクリプトを非同期でロードするには、特にこの種のサイトに役立ちますが、Googleの更新された指示よりも優れているとは言えません。）
JavaScriptが読み込まれて実行されると、Webバグ（追跡画像）の実際の読み込みは非同期になります。したがって、追跡画像の読み込みは他のものをブロックするべきではありません--nlessページはbody.onload()を使用します。この場合、Webバグがすぐにロードされない場合、[リロード]をクリックするとブラウザがスクリプトを再度要求するため、[リロード]をクリックすると、状況がさらに悪化します。上記のIf-Modified-Sinceを使用します。 変更前ブラウザのリロードはWebバグのみを待っていましたが、変更後リロードをクリックすると、ga.jsスクリプトの応答も必要になります。
したがって、Google Analyticsを使用するサイトではbody.onload()を使用しないでください。代わりに、jQueryの $（document）.ready（） またはMooToolsの domready event のようなものを使用する必要があります。
Google Analyticsがデータを収集する方法を説明するGoogleの 機能の概要 も参照してください[トラッキングコードのしくみを含む]。 （これにより、GoogleがファーストパーティCookieのコンテンツを収集することも正式になります。つまり、アクセスしているサイトのCookieです。）
更新： 2009年12月 、Googleは 非同期バージョン をリリースしました。上記は、念のためにアップグレードするようにすべてのユーザーに指示する必要があります アップグレードによってすべてが解決されるわけではありません 。
FireBugとYSlowを使用して自分自身を確認してください。ただし、GAのサイズは約9KBであり（実際には、実際に実行する場合はかなり大きくなります）、非常に高速にロードされないこともあります（理由がわからないため）。知っている、私はそれが時々「窒息する」サーバーかもしれないと思う）
Ajax Samples のパフォーマンスの問題のため、削除しましたが、再び超高速、レスポンシブは優先度1、2、3でした
ページに追加のJavaScriptをロードすると、クライアントの観点からダウンロード時間が長くなります。 GAがロードされていない場合でもページがレンダリングされるように、ページの下部にロードすることでこれを改善できます。クライアントキャッシュの利点を失うため、キャッシュは避けます。クライアントがそれを他のページからキャッシュしている場合、ページのリクエストはクライアント自体から入力されます。サイトからロードするように変更すると、クライアントがすでにコードを持っている場合でも、ダウンロードが必要になります（これは可能性があります。Googleからのファイルの読み込みを回避するためにソフトウェアプロセスにタスクを追加することは、不必要な最適化である可能性があるため保証されていないようです。常にローカルで高速に機能するため、これをテストすることは困難ですが、本当に重要なのはローカルで維持することを検討する場合は、自宅のインターネット接続からテストしてください-ラック内のサーバーの横にあるマシンではありません。
目立つものはありません。
Googleの呼び出し（DNSルックアップ、まだキャッシュされていない場合はJavaScriptの読み込み、実際のトレーサー呼び出し自体を含む）は、実際にページを読み込むために別のスレッドでクライアントのブラウザーで行う必要があります。確かにDNSルックアップは基盤となるシステムによって行われ、私の知る限り、ブラウザ内でのルックアップとしてはカウントされません（ブラウザには、サイトごとに使用するリクエストスレッドの数に制限があります）。
それを超えると、ブラウザは他のすべての埋め込みリソースと並行してGoogleスクリプトをロードするため、最悪の場合、すべてをダウンロードするのにかかる時間が非常にわずかに長くなる可能性があります（以下の順序で話します）ミリ秒、気付かれません。Googleスクリプトがブラウザによって最後にロードされた場合、またはページ上に多くの外部リソースがない場合、またはページの外部リソースがブラウザによってキャッシュされている場合、またはGoogleのスクリプトがブラウザによってキャッシュされている場合（非常に可能性が高いです）そうすれば、違いは見られません。
唯一の具体的な違いが生じる可能性があるのは、onLoadイベント（外部リソースが読み込まれるのを待つ）で起動するいくつかの動作がある場合およびGoogleサーバーがダウンしている場合のみです/スロー。後者が頻繁に発生することはほとんどありませんが、この場合、onLoadはスクリプトがダウンロードされるまで起動しません。とにかくこれを回避するには、さまざまな「DOMが読み込まれたとき」イベントを使用します。これは、独自のスクリプト/イメージがこの方法で読み込まれるのを待つ必要がないため、一般的に応答が速くなります。
ページの読み込み時間への影響が本当に心配な場合は、 Firebug の「ネット速度」セクションをご覧ください。これにより、これが数値化され、きれいなグラフが描かれます。とにかく、自分でこれを行うことをお勧めします。たとえ他の人からリクエストされた数値やベンチマークがあなたに与えられたとしても、それはwill自分のサイトとはまったく異なります。
さて、私はネット上で広範囲に検索、研究、調査してきました。しかし、賛成または反対を主張する統計データは見つかりませんでした。
ただし、この http://www.ga-experts.com からの抜粋では、その神話はGAが遅くなるとされていますあなたのウェブサイト。
エラー、まあ、少しかもしれませんが、ミリ秒について話しています。 GAはページのタグ付けで機能します。Webページにコンテンツを追加すると、読み込み時間が長くなります。ただし、ベストプラクティスに従うと（
</body>タグ）、ページが最初に読み込まれます。また、ページタグベースのウェブ分析パッケージ（大半）は同じように機能することに注意してください。
上記の回答と他のすべての情報源から、私が感じるのは、スクリプトがページの下部に含まれているため、ユーザーが認識できないスローダウンが発生したことです。しかし、完全なページロードについて説明すると、ページロード時間が遅くなると言えます。
詳細情報があればそれを投稿し、あればDATAを投稿してください。
問題は、Google Analyticsがサイトの速度を低下させることでしたが、答えは「はい」です。現時点では、このGoogle-Analytics.comは機能していないため、ページにそれが含まれているサイトではページが読み込まれません。そうなれば、速度が低下し、サイトが読み込まれなくなることもあります。 google-analytics.comがこれほど長くダウンしているのは珍しいことですが、現在は10分を超えていますが、それが可能であることを示しています。
これには2つの側面があります。
- 分析スクリプト（およびGIF）のダウンロード
- ダウンロードされたスクリプトの実行
ほとんどの場合、ダウンロード時間は100ミリ秒未満であり、許容範囲です。
ここにひねりがあります。
- analytics.js実行250ミリ秒
- リマーケティング（有効な場合）300ミリ秒
- 人口統計（有効な場合）200ms
したがって、リマーケティングによる分析には平均で750ミリ秒かかります。パフォーマンスのオーバーヘッドに関しては、これは膨大な数だと思います。
これはあなたが探しているものではないと思いますが、パフォーマンスについて何を心配していますか？
それがあなたのサーバーなら...それはGoogleサーバーに常駐しているので、明らかに影響はありません。
ユーザーが心配しているのであれば、影響もありません。 bodyタグのすぐ上に配置する限り、ユーザーは以前よりも遅く受信することはありません...スクリプトは最後に読み込まれ、ユーザーの外観には影響しません。したがって、基本的に何も待機せず、ページがまだ読み込まれていることに気付かずにページを閲覧し続けます。