本来のAdvent Calendarとは、12月1日からクリスマスの25日まで、カードに作られた窓を1日に1つずつ開けていくというものです。一方、技術系のAdvent Calendarは、12月1日から25日までの間、毎日違う人が特定のテーマに沿ってブログ記事を書くというものです。もちろん、ここでのテーマは「HTML5」になります。HTML5に関することならなんでもOKです！
ども、HTML5 Advent Calendar 2011, 19日目担当のt32kでございます。今回もがんばります！
若干、9日目の@jovi0608さんとかぶってますが、気にせずNavigation Timingを実際にどのように利用できるかについて書きたいと思います。
Navigation Timing
Navigation TimingはW3C Web Performance Working Groupが策定している仕様の一つで、ページの読み込み時間やネットワークにかかる時間など取得することができる仕様です。2011年12月現在、IE9+, Firefox7+, Chrome6+, Android Browser 4.0+ (When can I use Navigation Timing API?) が対応しています。
取れるタイミングというのは以下のようにいっぱいありますｗ
- navigationStart
- unloadEventStart
- unloadEventEnd
- redirectStart
- redirectEnd
- fetchStart
- domainLookupStart
- domainLookupEnd
- connectStart
- connectEnd
- secureConnectionStart
- requestStart
- responseStart
- responseEnd
- domLoading
- domInteractive
- domContentLoadedEventStart
- domContentLoadedEventEnd
- domComplete
- loadEventStart
- loadEventEnd
これの何が嬉しいかと言いますと、これまでページのWebパフォーマンスを計測するとなると、BODY要素の始めのほうでnew DateしてgetTimeして、BODY要素の終わりのほうで、またnew DateしてgetTimeして差分を取るのが一般的な計測方法だと思うのですが、それですとサーバー側と接続したりする時間などが考慮されておらず、実際の体感時間とずれた計測結果になります。
むしろ、こういったレイテンシこそ読み込み時間の大半を占める部分で重要になってきます。つまり、Navigation Timingを使えばこのような部分も計測することができ、みんなハッピーということですね。
var timing = window.performance.timing;
var loadTime = timing.loadEventEnd – timing.navigationStart;こんな感じで、サクっとページの読み込み時間というのが取れます。
参考
- Using HTML5′s Navigation Timing API to measure Page Load speed | Web Builder Zone
- HTML5 Rocks – Measuring Page Load Speed with Navigation Timing
- Navigation Timing – MDN
Measuring Web Performance
とはいっても、ちょっと僕JavaScriptよく分からないし、取れるタイミングも多くてよく分かんないっす。って方は大丈夫！あきらめないで（誰 ってことで、このNavigation Timingを活用した「サイトの速度」というGoogle アナリティクスのメニューから利用できます。
_gaq.push(['_trackPageLoadTime']);現在では、コード追加なしでレポートから確認することできると思います。なかったらコード追加して確認してみてください。
これらの情報は、最初に述べたNavigation Timingに対応しているブラウザに、プラス、Google ツールバーをインストールしたInternet Explorer(9以前)からも情報を取得しています。
こういった情報が分かることで、読み込み時間が長いために離脱率が高いページなど改善の効果測定ができるようになります。
また、「技術」というリンクをクリックすればネットワーク、サーバーに関するタイミング情報も確認することができます。
参考
- サイトの速度 – アナリティクス ヘルプ
- Google Analytics Blog: Greater insights from the Site Speed report – Technical section
Measuring Social Interaciton
話は変わって、最近ソーシャルボタンが流行していますね、Twitter, Facebook, Google+などなどたくさんのいいね、シェアボタンがあります。ブログ読んでいると末尾にズラーッと並んだボタンをよく見かけます。あんなにつけて意味あるのかなーっと思ってしまいます。何よりも重いだろうよ。。。ってのが個人的な印象です。
しかし、そうゆうご時世かお仕事でも依頼があったので仕方なく実装したのですが、ちゃんと効果測定したいなと思い、Google アナリティクスで計測してみたいと思います。
_gaq.push(['_trackSocial', network, socialAction, opt_target, opt_pagePath]);基本となるのはこの_trackSocialという、_trackEventに似たメソッドです。これを利用して、Twitterのつぶやき数や、Facebookのいいね数をGoogle アナリティクス上から確認することができます。
// Facebook いいね
FB.Event.subscribe('edge.create', function(targetUrl) {
_gaq.push(['_trackSocial', 'facebook', 'like', targetUrl]);
});// Twitter つぶやき
twttr.events.bind('tweet', function(event) {
if (event) {
var targetUrl;
if (event.target && event.target.nodeName == 'IFRAME') {
targetUrl = extractParamFromUri(event.target.src, 'url');
}
_gaq.push(['_trackSocial', 'twitter', 'tweet', targetUrl]);
}
});Facebook, Twitterに関しては、上記のコードを計測したいページに記述します。注意としては、iframe形式には対応していないので、公式サイトからいいねなどのウィジェットをダウンロードしてくるときはJavaScript形式にしてください。
<a href="http://b.hatena.ne.jp/" onclick="_gaq.push(['_trackSocial', 'hatena', 'bookmark']);">...Google+のプラス数は特に何もしなくても勝手に認識してくれます。
そのほかにも、はてなブックマーク、mixiチェックも実装しましたが、ブックマーク、チェック完了時点のイベントが取れない（分からない）ので、単純にonclick時にtrackSocialを飛ばす対応しました。この結果から出る数字というのは実際にブックマークされた数、チェック数ではないので注意してください。ただmixiチェックはmixiデベロッパーサイト、パートナーダッシュボードからCSV形式でいいね数、チェック数、いいね・チェックから流入数などがダウンロード可能なので、そこから確認してもいいかもしれません。
GREEのいいねに関してiframe形式でしかウイジェットが配布されてなかったのでお手上げです :(
実装してデータが集まると、Googleアナリティクスの「ソーシャル」のメニューからサイト内のソーシャルアクション数が確認できます。hatena:bookmark, mixi:checkは実際にブックマークが完了された数、チェックが投稿された数ではないこと考慮しておくにして、このサイトにおいてはFacebookのいいね！が多いねみたいなことが確認できます。
Practice
さて、ソーシャルインタラクションのウイジェットを置いたことで、当初に懸念していたページの読み込み時間はどーなっているでしょうか。
Google 「サイトの速度」で、ウイジェット設置前後の3週間を比較してみると、平均で0.8~1.0秒ほど読み込み時間が増加してしまいました。
Aberdeen Group (PDF)というリサーチ会社が出したレポートによると、一般的に表示スピードが1秒遅くなると、PVは11%、CVは7%、顧客満足度は16%ダウンするといったことが報告されています。またこういったビジネスにおけるWebパフォーマンスの重要性も訴えられています。
実際に、ソーシャルウイジェットを設置したサイトで、上記のような結果が起きたかといと、計測した3週間においては見受けられませんでした。というのもソーシャルウイジェット用にSCRIPT要素を5つくらい読み込んだのですが、BODY要素の最後の方に置いたので読み込みに時間はかかりますがレンダリングに対して余り影響しなかったのではないかと考えています。
とはいえ、利用率から考えてみると、ソーシャルアクション数 / ソーシャルウイジェットを置いたページのPVで算出してみると、0.2~0.01％ という低い数値がでました。あんまり使われていないってことですね。。。
読み込み時間と言えば、Googleが読み込み時間をランキングに考慮するとかしないとか（最近まったく聞きませんね…）ありますし、単純に外部からスクリプトを多く読みこむことで、不具合の発生する確率も多くなるかもしれません。
やっぱりこんなもの取り外したい。でも取り外せないということで、単純にブックマークレット形式に変更しました。各ブックマークレットの方法は以下参照で。
- 気になるページをもっと共有しやすくする「mixiチェックブックマークレット」 | THINK SOCIAL
- 共有ブックマークレット | Twitter Developers
- Web Intents | Twitter Developers
- はてなブックマーク – はてなブックマークをはじめる (セットアップ)
- Share Bookmarklet | Facebook
現状は各ソーシャルウイジェットを生成するためにSCRIPT要素を読み込んでiframeを生成するパターンなのですが、ブックマークレットですと、投稿する利便性は落ちてしまいますがSCRIPT要素を読む込む必要もなくなるので安心です。非同期で読み込む方法も考えましたが、UIスレッドと非同期で読み込めるだけで読み込み時間自体は変わらないですし、なによりも管理が複雑です。
実際に施策後の経過を確認んしてみると変更前は3秒近くあった読み込み時間が、2秒台になりました。ソーシャルアクションに関しては、「いいね！」のブックマークレットがなくて「シェア」に変更する必要があったり、ソーシャルアクション計測するためのコードは元のiframeを生成するスクリプトに依存するので、それを読みこまなくなったため計測できず、単純にはてな、mixiチェックのようにclick数になり、正確な比較はできませんが、アクション数が激減したということは見受けられませんでした。
このサイトにおいて特にがっつりソーシャルと絡んでいくといった方向性もないので、パフォーマンスは犠牲にせずにこういった最小限のブックマークレットシェアボタンを置くというのが現実解かなと個人的には考えています。
ということで、結構マイナーだと思ってたNavigation Timingですが、Googleアナリティクス入れていれば実務でもガンガン使っていけると思いますんで、パフォーマンス改善に役立てもらえればと思います。
Tags: html5
