Google Analyticsはパフォーマンスにどの程度影響しますか？
私は以下を探しています：
サイトでGoogleAnalytics（GA）をテストする1つの（可能な）方法：
これにより、クライアントWebサーバーとGAサーバー間の通信がどのように減少するかを知りたいと思います。
誰かがこれらのテストのいずれかを実施しましたか？もしそうなら、あなたはあなたの結果を提供できますか？そうでない場合、GAを使用するためのパフォーマンスヒット（またはその欠如）をテストするためのより良い方法はありますか？
回答:
2018年の更新：アナリティクスをマウントする場所と方法が何度も何度も変更されました。現在のgtag.jsコードは、いくつかのことを行います。
window.datalayergtag()投げたものをその配列にプッシュするだけの小さな関数を定義します。メインのgtagスクリプトが読み込まれると、この配列がGoogleと同期され、変更がないか監視されます。これは優れたシステムであり、以前のシステム（たとえば、直前にコードを詰め込む</body>）とは異なり、DOMがレンダリングされる前にイベントを呼び出すことができ、gtag()最初に定義する限り、スクリプトの順序は実際には重要ではありません。
これは、ここにパフォーマンスのオーバーヘッドがないということではありません。スクリプトのロードにはまだ帯域幅を使用しています（15分間ローカルにキャッシュされます）。スクリプトがスローするのは小さな山ではないため、処理にCPU時間がかかります。
しかし、それは（例えば）現代のフロントエンドフレームワークと比較してすべて無視できます。
あなたが可能な限り絶対的で最も削減されたウェブサイトを探しているなら、それを完全に避けてください。ユーザーのプライバシーを保護しようとしている場合は、サードパーティのスクリプトを使用しないでください...しかし、平均的な最新のWebサイトについて話している場合、gtag.jsよりもはるかに少ない成果があります。パフォーマンスの問題にぶつかる。
Steve Souders（クライアント側のパフォーマンスの専門家）による素晴らしいスライドがいくつかあります。
派手な自動テストやプログラムによる数値計算は行っていませんが、古き良きFirefoxとFirebugプラグインおよびJS変数のペアを使用して、すべてのGAコードが実行される前後の時差を示しています。これが私が見つけたものです。
2つのものがダウンロードされます：
ga.jsは、コードを含むJavaScriptファイルです。これは9kbであるため、最初のダウンロードはごくわずかであり、ファイル名は動的ではないため、最初のリクエスト後にキャッシュされます。
動的URL（クエリ文字列引数を介して）を含む35バイトのgifファイルであるため、これは毎回要求されます。35バイトもごくわずかなダウンロードです（firebugによると、ダウンロードに70ミリ秒かかりました）。
実行時間に関しては、クリーンなブラウザキャッシュを使用した最初のリクエストは、毎回平均約330ミリ秒で、その後のリクエストは35〜130ミリ秒でした。
私自身の経験から、それはグーグルを追加しました-Analyticsはロード時間を変更していません。
FireBugによると、ロードは1秒未満（平均648MS）であるため、他のテストの一部では、その時間の約60％〜80％がサーバーからデータを転送していましたが、これはもちろんユーザーごとに異なります。
上記の理由から、アナリティクスコードをローカルにキャッシュしても、読み込み時間が大幅に変わるとは特に思いません。
私は40以上のウェブサイトでGoogle-Analyticsを使用していますが、それが小さな速度低下の原因になることはなく、通常のサイズのために理解できる画像の取得に最も多くの時間が費やされています。
サーバー上でga.jsを問題なくホストできますが、ユーザーがアクセスした可能性のある他のサイトからga.jsをキャッシュするという考え方です。したがって、ga.jsをダウンロードすると、非常に人気があるため、多くの場合、オーバーヘッドはほとんど追加されません（つまり、すでにキャッシュされています）。
さらに、ネットワークトポロジが原因で、DNSルックアップのコストが異なる場所で同じになることはありません。キャッシュの動作は、ユーザーがga.jsを含む他のサイトを使用するかどうかによって異なります。
javascriptが読み込まれると、ga.jsはGoogleサーバーと通信しますが、これは非同期プロセスです。
お役に立てれば。
サーバー側のサイトオーバーヘッドはありません/最小限です。
Google AnalyticsのHTMLは、Webページの下部に配置する3行のJavaScriptです。それは実際には何もありません、そして著作権表示より多くのサーバーリソースを消費しません。
クライアント側では、ページの表示が完了するまでに少し（最大で数秒）かかる場合があります。ただし、私の経験では、ロードされていないページのビットはGoogleのものだけなので、ユーザーはページを完全にきれいに見ることができます。ページの上部にあるスロバーが少し長くドキドキします。
（注：これを行うには、提供されたページの下部にGoogle Analyticsコードブロックを配置する必要があります。コードブロックをHTMLの上部に配置するとどうなるかわかりません）
使用を含める方法に関するGoogleの従来の指示。したがって、ブラウザが何らかのコードが実際に実行されるまで外部JavaScriptライブラリを非同期的にロードする場合でも、ページのロードをブロックします。後の非同期命令は直接使用しませんが、ページの読み込みもブロックしますか？ga.jsdocument.write()document.write()document.write()insertBefore
ただし、Googleはキャッシュmax-ageを86,400秒に設定します（1日であり、パブリックに設定されているため、プロキシにも適用できます）。そのため、多くのサイトがまったく同じGoogleスクリプトをロードするため、JavaScriptはキャッシュからフェッチされることがよくあります。それでも、キャッシュされている場合でもga.js、リロードボタンをクリックするだけで、ブラウザが変更についてGoogleに問い合わせる場合がよくあります。そして、ga.jsまだキャッシュされていないときと同じように、ブラウザは続行する前に応答を待つ必要があります。
GET /ga.js HTTP / 1.1 ホスト：www.google-analytics.com ..。 変更された場合-以降：2009年6月22日月曜日20:00:33 GMT キャッシュ制御：max-age = 0 HTTP / 1.x304は変更されていません 最終更新日：2009年6月22日月曜日20:00:33 GMT 日付：2009年7月26日日曜日12:08:27 GMT キャッシュ制御：max-age = 604800、public サーバー：ゴルフ
多くのユーザーは、ブラウザウィンドウで既に開いているニュースサイト、フォーラム、ブログの再読み込みをクリックし、Googleからの応答を受信するまで多くのブラウザをブロックすることに注意してください。SOホームページをどのくらいの頻度でリロードしますか？Google Analyticsの応答が遅い場合、そのようなユーザーはすぐに気付くでしょう。（スクリプトを非同期にロードするためにネット上で公開されている多くのソリューションがありga.js、特にこの種のサイトに役立ちますが、Googleの更新された手順よりも優れているとは言えません。）
JavaScriptがロードされて実行されると、Webバグ（追跡画像）の実際のロードは非同期になります。したがって、ページでを使用しない限り、トラッキング画像の読み込みによって他のものがブロックされることはありませんbody.onload()。この場合、Webバグがすぐに読み込まれない場合は、[再読み込み]をクリックすると、ブラウザがスクリプトを再度要求するため、実際には状況が悪化しIf-Modified-Sinceます。リロード前は、ブラウザはWebバグを待っているだけでしたが、リロードをクリックした後は、ga.jsスクリプトへの応答も必要です。
したがって、GoogleAnalyticsを使用しているサイトはを使用しないでくださいbody.onload()。代わりに、jQueryの$（document）.ready（）やMooToolsのdomreadyイベントのようなものを使用する必要があります。
Google Analyticsがデータを収集する方法を説明しているGoogleの機能概要も参照してください。、トラッキングコードの仕組みを含みます。（これにより、GoogleがファーストパーティのCookieのコンテンツを収集することも公式になります。つまり、アクセスしているサイトのCookieです。）
更新：2009年12月、Googleは非同期バージョンをリリースしました。上記は、アップグレードがすべてを解決するわけではありませんが、念のためにアップグレードするように全員に指示する必要があります。
それは本当に日によって異なります。これをブログに追加しているだけです。私はカリフォルニアにいて、メインのデータセンターに非常に近く、高速で低遅延のビジネスDSLを使用し、最近のLinuxカーネルと安定したFirefoxを実行する十分なRAMを備えたオーバークロックされたi5を使用しています。
これがサンプルページのロードです：
google-analyticsだけでも、ネットワークのダウンロード時間の5秒が追加されました... 15Kbを取得します！
あなたは300で34KB務めblogger.comを見ることができますミリ秒。それは32倍速いです！
また、赤い線（onLoadイベントを表します。つまり、ページ上でスクリプトが実行されていないため、ブラウザーが最終的に読み込みインジケーター/スピニングなどを停止できるようになります）...右にどれだけ離れているかを確認します。です。それはおそらくそこで起こったゴミjavascript処理の3秒です。その行がリソースのダウンロードバーの端から非常に離れていることは非常にまれです。これのデバッグは完了しました。1/ 3の分析障害、2/3のブロガー障害です。...グーグルのものは速かったと思うでしょう。
編集：
さらにいくつかのデータ。これは、すべてがキャッシュされたリクエストです。上記のものは最初の訪問でした。
私は2つの理由で上からgoogleplusのがらくたを削除しました、私は彼らが遅いonLoadイベントで何らかの役割を果たしているかどうかを確認しようとしていました（彼らはそうではありません）そしてそれはほとんど役に立たないからです。
したがって、これにより、ネットワーク時間が最も心配が少ないことがわかります。最新のソフトウェアを搭載した高速のコンピューターでも、有料のグーグルアナリティクスとブロガーが処理時間を費やしても、7秒を過ぎてもページの読み込みがダンプされます。ブロガーがいない場合は、このサイトを確認してください。リソースが読み込まれ、赤い線が表示されてから0.5秒の遅延が発生します。
追加のJavaScriptをページにロードすると、クライアントの観点からダウンロード時間が長くなります。GAがロードされていない場合でもページがレンダリングされるように、ページの下部にロードすることでこれを改善できます。ページのクライアントキャッシュの利点が失われるため、キャッシュは避けます。クライアントが他のページからキャッシュしている場合、ページのリクエストはクライアント自体から入力されます。サイトからロードするように変更すると、クライアントがすでにコードを持っている場合でもダウンロードが必要になります（おそらくそうです）。Googleからのファイルのロードを回避するためにソフトウェアプロセスにタスクを追加することは、不必要な最適化である可能性があるため、不当に思われます。これは常にローカルでより速く提供されるため、これをテストするのは難しいでしょうが、本当に重要なのは、顧客にとってどれだけ速く機能するかです。
FireBugとYSlowを使用して自分で確認してください。ただし、GAのサイズは約9KBであり（実際にはかなり実質的に機能します）、ロードがあまり速くない場合もあります（理由はわかりませんが、おそらくサーバーが時々「窒息」する）
私たちは、削除により、当社のパフォーマンスの問題にそれをAjaxのサンプルが、その後、再び私たちがあるために超高速で応答性の優先順位1、2と3でした
目立つものはありません。
Googleへの呼び出し（DNSルックアップ、まだキャッシュされていない場合はJavascriptの読み込み、実際のトレーサーの呼び出しなど）は、実際にページを読み込むために、クライアントのブラウザーで別のスレッドで行う必要があります。確かに、DNSルックアップは基盤となるシステムによって実行され、私の知る限り、ブラウザー内のルックアップとしてカウントされません（ブラウザーには、サイトごとに使用する要求スレッドの数に制限があります）。
Beyond that, the browser will load the Google script in parallel along with all other embedded resources, so you will potentially get an extremely slight increase in the time it takes to download everything, in the worst case (we're talking in the order of milliseconds, unnoticable. If the Google script is loaded last by the browser, or you don't have many external resources on your page, or if your page's external resources are cached by the browser, or if Google's script is cached by the browser (extremely likely) then you won't see any difference. It's just absolutely trivial overall, the same effect as sticking an extra tiny picture on your page, roughly speaking.
具体的な違いが生じる可能性があるのは、onLoadイベント（外部リソースのロードを待機する）で発生する動作があり、Googleサーバーがダウン/低速である場合のみです。後者が頻繁に発生する可能性は低いですが、その場合、スクリプトがダウンロードされるまでonLoadは起動しません。とにかく、さまざまな「DOMが読み込まれたとき」のイベントを使用してこれを回避できます。これらのイベントは、独自のスクリプト/イメージがこの方法で読み込まれるのを待つ必要がないため、一般的に応答性が高くなります。
ページの読み込み時間への影響が本当に心配な場合は、Firebugの「正味速度」セクションをご覧ください。これが定量化され、きれいなグラフが表示されます。他の人があなたが要求する数字やベンチマークをあなたに与えたとしても、それはあなた自身のサイトでは完全に異なるので、とにかくあなた自身のためにこれをすることをお勧めします。
ええと、私はネット上で広範囲に検索、調査、調査を行ってきました。しかし、私は、前提に賛成または反対のいずれかを主張する統計データを見つけていません。
ただし、このhttp://www.ga-experts.comからの抜粋は、GAがWebサイトの速度を低下させるという神話であると主張しています。
えーと、大丈夫、多分少しかもしれませんが、ミリ秒について話しています。GAはページのタグ付けによって機能し、Webページにコンテンツを追加するたびに、読み込み時間が長くなります。ただし、ベストプラクティス（タグの前に
</body>タグを追加する）に従うと、ページが最初に読み込まれます。また、ページタグベースのWeb分析パッケージ（大多数）は同じように機能することに注意してください
上記の回答と他のすべての情報源から、私が感じているのは、スクリプトがページの下部に含まれているため、それが引き起こす速度低下がユーザーに認識されないということです。しかし、完全なページの読み込みについて話すと、ページの読み込み時間が遅くなると言えます。
ある場合は詳細情報を投稿し、ある場合はDATAを投稿してください。
これはあなたが探しているものではないと思いますが、パフォーマンスについて何を心配していますか？
それがあなたのサーバーなら...それはグーグルサーバー上にあるので明らかに影響はありません。
あなたが心配しているのがあなたのユーザーなら、影響もありません。bodyタグのすぐ上に配置する限り、ユーザーは以前よりも遅くなることはありません...スクリプトは最後に読み込まれ、ユーザーの外観に影響を与えません。したがって、基本的に何も待つことはなく、ページがまだ読み込まれていることに気付かずにページを閲覧し続けることさえあります。
問題は、Google Analyticsによってサイトの速度が低下するかどうかであり、答えは「はい」です。この記事を書いている時点では、このGoogle-Analytics.comは機能していないため、ページにそれが含まれているサイトはページを読み込まないため、速度が低下し、サイトが読み込まれなくなる可能性があります。google-analytics.comがこれほど長くダウンすることはめったにありませんが、現在10分を超えていますが、それが可能であることを示しています。
それには2つの側面があります。
ダウンロード時間はほとんどの場合100ms未満であり、これは許容範囲です。
ここにひねりがあります。
したがって、リマーケティングを使用した分析には、平均で750ミリ秒かかります。パフォーマンスのオーバーヘッドに関しては、これは膨大な数だと思います。
cPanelで頻繁にI / OとCPUが過負荷になり、次の結果になることに気付きました。
サイト到達不能エラー
そして、WPAnalyticsプラグインを無効にした後は停止しました。ですから、それはある程度の影響があると思います。