HTML ドキュメントの body タグの末尾にスクリプトを追加するだけで、Google アナリティクスで処理できるようになることを理解しています。私の質問は、これがパフォーマンス (ダウンロード時間とサーバー負荷) に大きな影響を与える可能性があるかどうかです。IIS によって提供される、たとえば 100k の静的ページを想定してみましょう。ありがとう。
15 に答える
ウェブサイトの外観やパフォーマンスは Google アナリティクスの影響を受けますか?
Google アナリティクスを使用しても、ウェブサイトの外観が影響を受けることはありません。ページに画像やテキストを配置することはありません。同様に、トラッキング コードを追加した後の最初のページ読み込みを除いて、ページのパフォーマンスに影響を与えることはありません。この最初のページビューは、Google のサーバーで JavaScript を呼び出します。これには、通常のページの読み込みよりも少し時間がかかる場合があります。 以降のページビューではキャッシュ データが使用されるため、影響はありません。
インターネット上の多くの Web サイトは、Google のサーバー上の同じ場所から同じ Javascript を使用しているため、そのファイルがローカルにキャッシュされていない状態で新しいユーザーがサイトにアクセスすることはほとんどありません。
はい、パフォーマンス ヒットがありますhttp://dotnetperls.com/Content/Google-Analytics-Speed.aspxを参照してください 。速度を上げるには、ga.js ファイルをローカルにダウンロードして代わりに呼び出すことをお勧めします。
はい。
addblock フィルターに Google アナリティクスを追加してから、ブラウジング速度が大幅に向上したように感じます。
いいえ。
最後に配置すると、最後にロードされるため、Google のサーバーが少し遅くても、訪問者は気付かないでしょう。
ga.js は 9.58k で、ロギング呼び出しは約 1.2k です。js は最初の読み込み後にキャッシュされるため (複数のサイトにまたがっていると思いますか?)、サイズ的にはほとんど無視できます。
コードの一番下に Analytics コードを配置したとしても、ユーザーの観点からは、一番下の小さな青いバーが消えるまで、サイトは読み込まれていません。
これは、(驚くべきことに) ユーザー接続の遅延に応じて、サイトが「遅く感じる」ことを意味します。ダイアルアップ ユーザーおよび海外から Web サイトにアクセスするユーザー (要求の遅延がより重要な場合) にとって、追加の要求は Web サイトの応答がわずかに低下することを意味します。
ただし、すべての画像、すべての JavaScript ファイル、およびその他の埋め込みオブジェクトが追加の要求であることを考えると、リッチな Web サイト レイアウトを既に使用している場合は、分析を使用しない理由にはなりません。
すべてのユーザーが米国ベースの高速接続を使用しているわけではないことに注意してください。
米国以外の国からの接続が遅い場合、違いは確かに顕著です。
標準外の低速のコンピューターやブラウザー(つまり、古いバージョン、携帯電話など)を実行している人は、すべてjavascriptの実行時間の影響を受ける可能性があります。
それを使用するページでラグが発生することがあります。ロードされるのを待っている唯一のスクリプトであるため、GA まで問題を追跡できます。これが発生してはならないことはわかっていますが、一部のページ要求ではランダムに発生します。ページ全体が既に読み込まれているため、読み始めることができるので、通常は問題ありません。しかし、ajax を使用するページや、一般的にドキュメントの準備完了イベントで何かを行うページでは、小さな問題になります。だから私はそれをアドロックフィルターに追加します。
競争の言葉を見てみましょう。
ユーザー エクスペリエンスは、低速接続での GA によって確実に遅くなります。
GAがハッシュが添付された小さなGIFファイルをダウンロードするのを見たこともあります...しかし、これのサイズがパフォーマンスに大きな影響を与えるとは思えません。
個人的には、ブラウザは最初のリクエストの後にそれをキャッシュし、その後、他の各ページで使用することに大きな違いがあるとは本当に思いません。
スクリプトはページの一番下にもロードされるため、他のすべてはすでにロードされているはずです。
サーバーの負荷に関しては、スクリプトはお客様のサーバーではなく Google のサーバーから取得されるため、サーバー側に顕著な影響はありません。明らかに、JavaScript をロードするコードがない場合よりもすべてのページがわずかに大きくなりますが、その違いに気付くことはありません。
実際の ga.js をダウンロードして実行するのは高速ですが、ヨーロッパ全体でさまざまな接続/コンピューター/OS/ブラウザーで気付いたのは、最後のバイト間の大きな遅延 (0 から 30 ( 30 ) 秒のどこか) です。 HTTP リクエストの最初のバイトと HTTP レスポンスの最初のバイト。
GA の絶大な人気を考えると、これは理解できますが、これは window.onload が起動する前に発生しています。そのため、ページが JS に依存していて、ユーザーがこの遅延に遭遇した場合、ユーザーはどのコンポーネントが原因であるかを分析しようとせず、サイトが非常に遅いと想定します。
これを回避するには、GA スクリプトを追加する window.onload 関数を登録します。例 (window.onload=function()
簡単にするために " " を使用):
window.onload = function() {
var gaJsHost = (("https:" == document.location.protocol)
? "https://ssl."
: "http://www.");
var s = document.createElement('script');
s.src = gaJsHost + "google-analytics.com/ga.js";
s.type='text/javascript';
var bodies = document.getElementsByTagName('body');
if (bodies.length > 0) {
bodies[0].appendChild(s);
} else { // this should never happen, but sometimes does (curse you IE6!)
document.appendChild(s);
}
// this says 100ms, but won't happen until ga.js is loaded
window.setTimeout(function(){
if (window['_gat']) {
var pageTracker = _gat._getTracker("UA-xxxxxx-x");
pageTracker._trackPageview();
}
},100);
}
コードをページの下部に追加しても、おそらく大きな違いはありません。
ただし、違いを生じさせたくない場合は、次のリンクをご覧ください。
http://lyncd.com/2009/03/better-google-analytics-javascript/
Steve Souders があらゆる種類の I/O ブロックを完全に回避するために採用したアプローチについて説明しています。