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