Html5-boilerplate: 利用可能な場合は、GoogleAnalyticsの追跡にlocalStorageを使用します

依存関係としてModernizrをロックインするかどうかはわかりませんが。

たぶん、それをドキュメントに追加するのが最善でしょうか？

また、@ mathiasbynensにpingを実行します。

切り取ったものを最適化してくれてありがとう、David。 @alrraとして、ドキュメントに追加するのは良いことだと思います。

クレジットは私のものではありません。 これは@elmerbulthuisによって私の注意を引きました。 私はこれを_snippet_自体の最適化とは実際には考えていませんが、それ自体は--- Web全体の最適化です:-p。

誰もがlocalStorageソリューションを採用した場合、グローバルに何バイト節約できるのだろうか。

私は明らかにこのソリューションの大ファンです。 ボイラープレートにデフォルトで含めることの唯一の問題は、 @ davidmurdochが言及したものです。最初に、 localStorageの機能テストを行う必要があります。 これは、Modernizrを使用するか、スタンドアロンコードの小さな部分を追加することで実行できますが、どちらの方法でもページサイズがわずかに大きくなります。 また、影響を受けるドメインのリソースのリクエストヘッダーでCookieが送信されないため、長期的には多くのバイトが節約されます。

このようなもの：

(function(b,o,i,l,e,r){b.GoogleAnalyticsObject=l;b[l]||(b[l]=
function(){(b[l].q=b[l].q||[]).push(arguments)});b[l].l=+new Date;
e=o.createElement(i);r=o.getElementsByTagName(i)[0];
e.src='//www.google-analytics.com/analytics.js';
r.parentNode.insertBefore(e,r)}(window,document,'script','ga'));
(function(){var a=(function(){var c=new Date,b;try{
localStorage.setItem(c,c);b=localStorage.getItem(c)==c;
localStorage.removeItem(c);return b&&localStorage}catch(d){}}());
ga('create','UA-XXXXX-X',a?{storage:'none',clientId:a.gaId}:{});
ga(function(b){a.gaId=b.get('clientId')});ga('send','pageview')}());

（http://mathiasbynens.be/notes/localstorage-patternから取得したlocalStorage機能テストを使用します。）

いくつかの簡単なテストの後、正常に動作しているようです。 これをより広範囲にテストした後、PRを作成します。 （もちろん、歓迎します！）

参考：これにより、影響を受けるドメインへのリクエストごとに、ラウンドトリップごとに約33のrawバイト（ヘッダー/ Cookieは圧縮されません）を節約できる可能性があります。

@mathiasbynensの現在のインライン機能検出ソリューションは130圧縮バイト*大きくなっています（明らかに、これは一意のページごとに異なりますが、大まかなアイデアが得られます）。 ですから、これをもう少しゴルフできるかどうかを確認する必要があります。

個人的には、gzipで圧縮された差分を65バイトまで見たいので、すぐに自分で試してみます。 :-)

_ ∗このデフレーターの使用： http ：//www.vervestudios.co/projects/compression-tests/snippet-deflator_

318 GZIPpedバイト（現在のバージョンは248 GZIPpedバイトです）：

(function(l,e){GoogleAnalyticsObject='ga',(window.ga||(ga=function(l,e){(ga.q=ga.q||[]).push(arguments)})).l=+new Date,l=document.createElement('script'),l.src='//www.google-analytics.com/analytics.js',(e=document.getElementsByTagName('script')[0]).parentNode.insertBefore(l,e);ga('create','UA-XXXXX-X',(function(l,e){try{l=(localStorage[ga.l]=ga.l)==ga.l;localStorage.removeItem(ga.l);return l}catch(l){}}())?{storage:'none',clientId:localStorage.clientId}:{});ga(function(l,e){localStorage.clientId=l.get('clientId')});ga('send','pageview')}())

これはあまりよくテストされていないので、私はまだそれをする必要があります。 しかし、それは始まりです。

残念ながら、 setItemとgetItemの呼び出しを取り除き、他のゴルフの「トリック」を使用したため、 localStorageテストはおそらくどこかのブラウザで危険にさらされています。

今のところ、これですべてです。 :-)

スニペット自体をgzipしていることに気づきましたが、これはちょっと無意味です。 Gzipの結果は、ドキュメントの残りの部分（つまり、ドキュメントにインライン化されている場合はHTMLソース、一部の場合はJavaScriptファイルの残りの部分）によって異なります。 たぶん、スニペットだけのgzip圧縮されたサイズを比較することは、これを測定するための最良の方法ではありませんか？

スニペットは見栄えがします。 新しいタイムスタンプを生成する代わりに、 ga.lタイムスタンプを再利用することをお勧めします。

そして残念ながら、私はsetItemとgetItemの呼び出しを取り除き、他のゴルフの「トリック」を使用したため、 localStorageテストはおそらくどこかのブラウザーで危険にさらされています。

もしそうなら、それはディールブレイカーの私見でしょう。

Firefox <9のサポートが問題ではなくなったときに、 document.getElementsByTagName('script')[0]をdocument.scripts[0]に置き換えることができます。

@mathiasbynens GZIPpingを実行すると、圧縮による_minimum_バイトの節約が概算されます。 したがって、それは完全に論点ではありません。 ほとんどの場合、ページサイズが大きくなると、スニペットの圧縮率が高くなります。

まだテストする必要があります！ getItemとsetItemの呼び出しを追加し直して、309バイトまで減らすことができました。

+function(l,e){(ct=this[GoogleAnalyticsObject='ct']||function(l,e){(ct.q=ct.q||[]).push(arguments)}).l=+new Date,l=document.createElement('script'),l.src='//www.google-analytics.com/analytics.js',(e=document.getElementsByTagName('script')[0]).parentNode.insertBefore(l,e);try{localStorage.setItem(ct.l,ct.l),l=localStorage.getItem(ct.l)-ct.l,localStorage.removeItem(ct.l)}catch(l){};ct('create','UA-XXXXX-X',l?{}:{clientId:localStorage.clientId,storage:'none'}),ct(function(l,e){localStorage.clientId=l.get('clientId')}),ct('send','pageview')}()

• 現在、括弧を折り返す代わりに+記号を使用するIIFEを使用しています。
• clientIdは一部のバイトを節約するため、 localStorage.gaId localStorage.clientIdも使用しています。
• window thisを使用すると、さらに1バイト節約できます（ GoogleAnalyticsObject割り当ての移動と組み合わせて）。
• gaをct （ctがより一般的）に変更すると、さらに1バイト節約されました（これはおそらく混乱する価値はありません）。
• 関数呼び出しを取り除き、 localStorageチェックにlを再利用して、成功したときに0に割り当てると、大量のバイトが節約されました。

繰り返しますが、これにはさらに多くのテストが必要です。

@davidmurdochテストに関する更新はまだありますか？ 他の人がテストを手伝うことができるように、このためのテストフローを書き留めることができますか？

申し訳ありませんが、私はMIAになりました。優先度の高い、6か月のプロジェクトに参加しましたが、他のことに多くの時間を割くことができませんでした。

これをテストする最も簡単な（そして最も愚かな）方法は、分析コードをこの新しいコードに置き換えて、数とブラウザーのバージョンに奇妙な変動がないかどうかを確認することです。 私はこれを自分で行いましたが、目立つものは何も見ていません。 しかし、とにかくoldieの訪問者はあまりいません。

別の方法は、生成されたiframeにこの実験的な分析スクリプトをロードして（安定した分析スニペットに干渉しないように）、もちろん別のGAアカウントでそこから_trackPageviewを呼び出すことです。 次に、1週間ほど後にデータを比較する必要があります。

すぐにこれをテストするためのドロップインスニペットに取り組むことができるとは約束できません。 私が隠れている間に他の誰かがこれらのアイデアの所有権を取得したい場合は、すぐに行ってください。 :-)

http://drublic.github.io/css-modal/のテストを開始しました。 私は先月97kのページビューを獲得しましたが、ブラウザ全体に乱暴に広がっています。

数字：

1. Chrome 44.01％
2. Firefox 34.38％
3. Internet Explorer 8.86％
4. Opera 5.26％
5. Safari 4.01％
6. Androidブラウザ2.22％

待って見てみましょう。 「通常の」統計を並行して実行しました。

それとは別に、コードは読みやすさのためにさらにいくつかの更新が必要だと思います（1行あたり80文字と識別子を挿入する場所）。

約1週間でこのテストに戻ります。

私は少し早いですが、私の調査結果は現時点ではかなり安定しています。 残念ながら、両方のアカウントの訪問者数に大きな違いがあります。

デフォルトの実装では、3月13日から17日の間に2,964回のユニーク訪問が表示されます。
ローカルストレージベースでは、同じ時間枠で756回のユニーク訪問が表示されます。

3つの理由が考えられます。

• 切り取られた私の実装が壊れています
• iframeの読み込みがブラウザによってブロックされている
• 切り取られたローカルストレージ統合が壊れています

現在、コードに間違いはありません： http ：//drublic.github.io/css-modal/test-gau-localstorage.html（これはサイトに統合されているiframeです）。

また、ブラウザやページによってiframeがブロックされたことはありません。 これが起こるかもしれないかどうか誰かが考えていますか？

これは、GUAが切り取ったローカルストレージにバグがあるという解決策につながります。 私は問題が何であるかを調べていません。
さらなるテストのために最小化されていないバリアントを開発し、実用的なソリューションができた後に最小化できますか？

また、これをHTML5BP v5.0からデスコープし、解決策が見つかった場合は5.1でリリースすることを選択します。 皆さんはどう思いますか？

また、これをHTML5BP v5.0からデスコープし、5.1でリリースすることを選択します

@drublic ：+1：（ v5.1.0マイルストーンに問題を追加）。

数字がそれだけ離れている場合は、 ga('create', w / storage:'none'を呼び出すときに、デフォルトのclientIdを指定する必要があるという事実があります。

https://developers.google.com/analytics/devguides/collection/analyticsjs/domains#disableCookies

私のサイトでこの問題についてブログに書いたところです： LocalStorageを使用したGoogle Async Analyticsと、ここでテストページを設定します：http：//davidmurdoch.com/google-async-analytics-using-localstorage-test/ 。

読んで、共有して、テストしてください。

（注：これらのページでタイプミスやエラーを見つけた場合は、twitter @ pxcoachでお知らせください。

ねえ、パーティーに少し遅れてここに来てすみません。 私はGoogleAnalyticsチームで働いており、この問題についてコメントし、考えを述べたいと思いました。

まず第一に、H5BPプロジェクトが、公式に推奨されているものとは機能的に異なるGoogleAnalyticsトラッキングスニペットを推奨することは良い考えではないと思います。 人々はおそらく彼らが同じであると思い込むでしょう、そして彼らが実際にそうでないならば、それは混乱を引き起こすでしょう。 Google Analyticsのドキュメントで、GAが一部の機能をサポートしていると主張しているが、誰かが別のスニペットを使用しているためにサポートしていない場合は、デバッグがかなり困難になる可能性があります（特に、H5BPでスニペットが異なることが明らかにならない場合）。

GAがもっとうまくできることがあれば、コミュニティから分岐するのではなく、コミュニティのニーズに合わせて進化したいと思っています。 （ところで、GA関連のGithubの問題については、遠慮なくpingまたはccしてください。）

とにかく、ここにlocalStorageの主な問題と、GAがデフォルトのストレージメカニズムとしてそれを提供しない理由があります。

localStorageのスコープはlocation.originですが、Cookieのスコープはトップレベルドメインです。 Cookieストレージを使用すると、analytics.jsでサブドメインの追跡をすぐに実行できますが、これはlocalStorageでは不可能です。 さらに、サイトの一部がHTTPで、他の部分がHTTPSの場合、それも失敗します（失敗すると、ストレージが共有されないため、クライアントIDが失われ、GAはそれを別のセッションとして扱います。 ）。 これらはほとんどのGAユーザーにとって問題ではないことは事実ですが、今説明した機能の喪失のために、この提案されたスニペットをドロップイン置換として提供するのは悪いことだと思います。

そうは言っても、この問題と@davidmurdochのブログ投稿に基づいて、公式にサポートされているlocalStorageメカニズムの構築を優先するように努めます。 現在、 storageパラメータはオプションcookieとnoneのみをサポートしていますが、3番目のlocalStorageオプションを追加したいので、サポートしていないユーザーはサブドメインまたはクロススキームトラッキングが必要です。オプトインできます。これがいつ追加されるかはわかりませんが、追加される場合は更新できます。

これは誰にとっても合理的だと思いますか？

@philipwaltonコメントありがとうございます！

これは誰にとっても合理的だと思いますか？

Cc： @ davidmurdoch 、 @ mathiasbynens

そうは言っても、この問題と@davidmurdochのブログ投稿に基づいて、公式にサポートされているlocalStorageメカニズムの構築を優先するように努めます。

：+1：

これが追加されたら、問題を更新してください。 ありがとう！

@philipwalton 、：+ 1：すばらしいニュースです！ ただし、ビルドするために「試す」必要はありません。すでに行っています。 :-p（私は子供です、私は子供です）。

先に進んでこのニュースでブログ投稿を更新し、非公式のlocalStorageトラッキングコードを使用してGitHubリポジトリを作成し、その欠点を強調します。 ありがとう！

：+1：しかし、将来のWebにはある種のtopLevelStorageが必要なようです。 オプションが利用可能になることをうれしく思います。 それを念頭に置いて、スニペットが入ったとき、h5bpの好みは何でしょうか？

@ jonathantneal 、FirefoxにはglobalStorageがあり、クロススキーム、ポート、およびサブドメインストレージを実行しました。 Firefoxはそれを実装した唯一のものであり、それ以来、廃止されたとマークされています。 :-(

@davidmurdochこの号を開いて掘り下げてくれてありがとう、心から感謝します！

@philipwaltonディスカッションに参加していただき、ありがとうございます。 @ mathiasbynensが言ったように、最新情報をお届けします。

非公式のlocalStorageトラッキングコードを使用してGitHubリポジトリを作成し、その欠点を強調してください。

@davidmurdochのリポジトリはhttps://github.com/davidmurdoch/ga-localstorageです（まだ更新されていませんが）。

「localStorageを使用したGoogleAnalytics」スクリプトをnpmに公開しました： https ：//www.npmjs.org/package/ga-localstorage

https://github.com/davidmurdoch/ga-localstorageリポジトリもコードで更新されました。

こんにちは、このSOコメントを読んだことがありますか？

http://stackoverflow.com/questions/4502128/convert-google-analytics-cookies-to-local-session-storage/19207035#comment -44767913

皆さんのご意見をお聞かせください。

@caesarsolそれは本当に悪い考えだと思います。 コメントで説明したように、CookieとlocalStorageには同じ制限がないため、ページで実行されるすべてのスクリプトに対してそれらを交換することは非常に危険です。

こんにちは@philipwalton 、応答をありがとう、しかし多分私は不十分に説明しました、私はSOユーザー_smhmic_によるこのコメントを参照していました：

これはGATOSに違反する可能性があります。 GAチームメンバーからの引用です。「HTTP状態管理メカニズムの使用」（読み取り：localStorage）「Cookieの状態を伝播することは、プライバシー保護の回避策です。これは、GoogleAnalyticsの利用規約に違反します。 "。 私の解釈では、GAはlocalStorageではなくCookieを使用しています。これは、Cookieの概念とCookieをクリアする方法に精通しているユーザーが増えているためです。 したがって、GAによるCookieの使用はプライバシー機能です。 – smhmic

「HTTP状態管理メカニズムの使用」（読み取り：localStorage）を使用してCookieの状態を伝播することは、プライバシー保護の回避策です。これを行うと、Googleアナリティクスの利用規約に違反します。

うーん、これは本当ではないと思います。 GAが提供するオプトアウト機能（Chrome拡張機能など）があり、Cookieを使用する実装者に依存しません。 TOSのこのセクションのポイントは、公式の「追跡しない」拡張機能を使用している人が追跡されるメカニズムを作成できないことだと思います。

私はそれをさらに調べることができ、このスレッドを更新します。私の仮定は誤りであることが判明しました。

アップデート：

localStorageを使用してClientIDを保存することはTOSに反しません。 現在、Googleによって正式にサポートされています： https ：//developers.google.com/analytics/devguides/collection/analyticsjs/cookies-user-id#using_localstorage_to_store_the_client_id

注:(非常に）古いブラウザー（iOS5やFF4など）をサポートする必要がある場合、それらのサンプルスニペットは失敗する可能性があります（https://github.com/Modernizr/Modernizr/blob/master/feature-detects/storage/localstorageを参照）。 js）。