[フロントエンド] 初期表示高速化を行ってPVアップをしようと思ったけど挫折した話
こんにちは、@yoheiMuneです。
今日は、フロントエンドの高速化をビジネスに生かそうと思ったけど、そうでもなさそうだったので挫折しちゃった話をブログに書きたいと思います。どんな数値をどのようにとって、何を判断したのかなど書けたらと思います。挫折しちゃったんですけどね、考え方やプロセスは良かったと思ってます。
これがきっかけで、「よしPageSpeedの点数を上げて表示を改善することで、PVも上げて使いやすくしよう」と思ったのが始まりでした。僕のブログにはSNSボタンや広告SDKが入っているので100点は無理ですが、できるだけ改善していけたらと思った次第です。
僕のブログの多くは検索からの流入で、技術的なキーワードで流入してきます。そしてアクセスはPCがメインで、時間帯としては平日のまさに勤務時間中にアクセスが多くあります。この状況から「技術的に何か悩んで検索をした時に、検索結果に出てきたからアクセスした」という状況がメインシナリオと思われます。そして、そのようなアクセスの目的は「悩んでいる技術的な問題を解決すること」が主だと思われます。
それを考慮すると、僕のサイトが提供するべきことは「有効な情報をいかに早く届けるか」という点になります。有効な情報か否かはブログの内容に寄りますが、いかに早く届けるかは初期表示のスピード改善の範疇かなと思いました。
上記をKPIに落とし込むと、「ユーザーが記事を読み始められるまでの時間」をいかに短縮するかが、僕のサイトとしては重要になります。
それを計測するために、以下のポイントに計測地点を設け、それを計測するために簡単な計測コードを書きました。
上記の「1.リクエストを受け付けた 〜 4. 記事が表示された」までの時間をユーザーは待機していて、その時間をいかに早くするかがポイントです。
そしてさらに、フロントエンドの初期表示の高速化という面では、「3. HTMLの
ソースコード全体は、以下をご参照ください。
https://github.com/yoheiMune/yoheim_net/blob/cd98138bf255c2c815e77c8f10120cc8ff62db4c/blog.php
ここまでは良かったんですけどね。
上記の各ステージで、どれほど離脱しているのかを集計して出してみました。
ということで、「フロントエンドの初期表示高速化でPVアップ」は改善幅が非常に小さいので、諦めることにしました。
最後になりますが本ブログでは、フロントエンド・Python・機械学習など雑多に情報発信をしていきます。自分の第2の脳にすべく、情報をブログに貯めています。気になった方は、本ブログのRSSやTwitterをフォローして頂けると幸いです ^ ^。
最後までご覧頂きましてありがとうございました!
今日は、フロントエンドの高速化をビジネスに生かそうと思ったけど、そうでもなさそうだったので挫折しちゃった話をブログに書きたいと思います。どんな数値をどのようにとって、何を判断したのかなど書けたらと思います。挫折しちゃったんですけどね、考え方やプロセスは良かったと思ってます。
目次
PageSpeedの点数が56点だった
GoogleのPageSpeed InsightsというツールではWebページの表示スピードやそれを改善するためのアドバイスを無料で受けることができます(詳細はこちらのブログをご参照ください)。それを使ってふと自分のブログを計測したら、56点と低い点数となっていました。これがきっかけで、「よしPageSpeedの点数を上げて表示を改善することで、PVも上げて使いやすくしよう」と思ったのが始まりでした。僕のブログにはSNSボタンや広告SDKが入っているので100点は無理ですが、できるだけ改善していけたらと思った次第です。
改善効果を明確に把握するための指標づくり
「PageSpeedの点数」もわかりやすい指標ではありますが、「PageSpeedの点数を上げたからPVも上がる」というのは少ししっくりと来ませんでした(途中に何か抜けていて「風が吹けば桶屋が儲かる」状態と感じました)。そこで少しだけ考えて、次のようにしようと考えました。僕のブログの多くは検索からの流入で、技術的なキーワードで流入してきます。そしてアクセスはPCがメインで、時間帯としては平日のまさに勤務時間中にアクセスが多くあります。この状況から「技術的に何か悩んで検索をした時に、検索結果に出てきたからアクセスした」という状況がメインシナリオと思われます。そして、そのようなアクセスの目的は「悩んでいる技術的な問題を解決すること」が主だと思われます。
それを考慮すると、僕のサイトが提供するべきことは「有効な情報をいかに早く届けるか」という点になります。有効な情報か否かはブログの内容に寄りますが、いかに早く届けるかは初期表示のスピード改善の範疇かなと思いました。
上記をKPIに落とし込むと、「ユーザーが記事を読み始められるまでの時間」をいかに短縮するかが、僕のサイトとしては重要になります。
それを計測するために、以下のポイントに計測地点を設け、それを計測するために簡単な計測コードを書きました。
計測地点
- リクエストを受け付けた
- PHPコードが終了した(=サーバー処理が終了した)
- HTMLの
head
タグが表示し始めた(ユーザーのHTMLが届いた) - 記事が表示された(ここまでを改善したい)
- (あと一応)DOMReadyのタイミング
- (あと一応)Onloadのタイミング
上記の「1.リクエストを受け付けた 〜 4. 記事が表示された」までの時間をユーザーは待機していて、その時間をいかに早くするかがポイントです。
そしてさらに、フロントエンドの初期表示の高速化という面では、「3. HTMLの
head
タグが表示し始めた 〜 4. 記事が表示された」の間をいかに早くするのかがポイントです。計測を行う簡単なコードを書いた
今回は上記を実現するために、以下のような簡単なコードを書きました。1. リクエストを受け付けた
### PHP(blog.php) # リクエストごとにユニークなIDを発行 $uid = uniqid(); # タイムスタンプ(ミリ秒まで表示) $dt = date("Y-m-d H:i:s") . "." . substr(explode(".", (microtime(true) . ""))[1], 0, 3); # タイプ $ty = "start"; # 一応ユーザーエージェント $agent = strtolower($_SERVER['HTTP_USER_AGENT']); # ファイル出力 $log = "$uid\t$dt\t$ty\t$agent\n"; $ymd = date('Y-m-d'); $path = "./logs/frontend-${ymd}.log"; $fp = fopen($path, "a"); fwrite($fp, $log); fclose($fp);
2. PHPコードが終了した(=サーバー処理が終了した)
### PHP(blog.php) # タイムスタンプ(ミリ秒まで表示) $dt = date("Y-m-d H:i:s") . "." . substr(explode(".", (microtime(true) . ""))[1], 0, 3); # タイプ $ty = "php_end"; # ログ出力 $log = "$uid\t$dt\t$ty\t$agent\n"; $path = "./logs/frontend-${ymd}.log"; $fp = fopen($path, "a"); fwrite($fp, $log); fclose($fp);
3. HTMLのhead
タグが表示し始めた(ユーザーのHTMLが届いた)、他
### JavaScript(blog.php) <head> <!-- フロントエンド計測 --> <script> var uid = '<?php echo $uid?>'; var sendSpeed = function (type) { var image = new Image(); image.src = "./frontend-measurement.php?type=" + type + "&uid=" + uid; image.onload = function () { this.remove(); } } // 01. Rendering. sendSpeed("render_start"); // 02. コンテンツ表示(→別の箇所で計測) // 03. DomReady. window.addEventListener('DOMContentLoaded', function () { sendSpeed('domReady'); }); // 04. onload. window.addEventListener('load', function () { sendSpeed('onload'); }); </script> ... </head>
4. 記事が表示された
<body> ... <div class="contents"> ...(ここに記事が入ります)... <script> // フロントエンド計測 // 04. 記事が表示された sendSpeed('show'); </script> </div> ... </body>上記の実装を行うと、以下のようなログを取得することができます。
ログ出力例
57121d47767f5 2016-04-16 20:08:55.485 start (UserAgentは省略) 57121d47767f5 2016-04-16 20:08:55.522 php_end (UserAgentは省略) 57121d47767f5 2016-04-16 20:08:55.674 render_start (UserAgentは省略) 57121d47767f5 2016-04-16 20:08:55.989 show (UserAgentは省略) 57121d47767f5 2016-04-16 20:08:56.486 domReady (UserAgentは省略) 57121d47767f5 2016-04-16 20:08:58.527 onload (UserAgentは省略)これで計測コードは完成です。これくらいライトなものであれば30分もあれば作れて、自分のサイトのUXを測定できるので良い感じです。
ソースコード全体は、以下をご参照ください。
https://github.com/yoheiMune/yoheim_net/blob/cd98138bf255c2c815e77c8f10120cc8ff62db4c/blog.php
けど、挫折しました
上記のログを見ると、「start 〜 render_start」まで200ms、「render_strat 〜 show」までで300msと、改善しがいのありそうな数値が出ています。ここまでは良かったんですけどね。
上記の各ステージで、どれほど離脱しているのかを集計して出してみました。
Exit Raito: =========================== start: 1711 php_end: 1703 99.53% render_start: 1106 64.64% show: 1098 64.17% domReady: 1093 63.88% onload: 1025 59.91%ここで、「render_start 〜 show」の間で、「0.47%」しか離脱していないことがわかりました。フロントエンドの初期化高速化でいうと、「render_start(ブラウザにHTMLが届いてheadが読み込まれた)」ところから「show(記事が表示された)」ところまでが主な範疇になるので、その改善対象が「0.47%」と低いわけです。
ということで、「フロントエンドの初期表示高速化でPVアップ」は改善幅が非常に小さいので、諦めることにしました。
ちなみに
今回の文脈(初期表示高速化でPVアップ)では、効果がほとんどないので諦めましたが、以下の文脈では初期表示の高速化はやりたいなーと思っています。- フロントエンドの仕事をしているので、顔となるブログでもしっかりとやりたい
- 画面が早く綺麗に表示されることで、その後の体験に良い影響を与えるかもしれない
最後に
フロントエンドの高速化とビジネスを結びつけるべく、僕のブログでのUXを定義して、それに合わせた計測を行い、結果として諦めたというお話でした。「僕のブログのUX」を定義できたこと、「それに合わせた計測」を行えたこと、そして「改善幅小のため諦めた」ことができたのは、最近のプランナーとしての仕事のおかげだと思います(エンジニアとして働き続けていたらこれはできなかった気がする)。だんだんと技術とビジネスを結びつけられるようになってきた実感があります。これからも技術とビジネスを結びつける動きは日々行っていけたらと思います。最後になりますが本ブログでは、フロントエンド・Python・機械学習など雑多に情報発信をしていきます。自分の第2の脳にすべく、情報をブログに貯めています。気になった方は、本ブログのRSSやTwitterをフォローして頂けると幸いです ^ ^。
最後までご覧頂きましてありがとうございました!