ページスピード改善の仮説検証が難しい理由
小さく試して、仮説を検証し、次の行動を柔軟に変えていく。いわゆるリーン開発の考え方は、いまや世界的な潮流です。大きなものを一発で正確に作ろうとするウォーターフォール型のアプローチは合わない場面がますます増えてきました。
仮説検証をクイックに回し、組織の学習スピードを上げていくことが強さにつながる。そうした成長の手応えを肌で感じている開発者やビジネスパーソンも多いのではないでしょうか。
しかし、この手法を ページスピードの改善に適用しようとすると、途端に技術的な壁が立ちはだかります 。
フロントエンドは部分的に切り出せない
バックエンドの処理にボトルネックがある場合、その部分だけを切り出してベンチマークを取り、最も効果的な方法を選んで本番に組み込むという部分的な実験が比較的やりやすいと思います。
一方、フロントエンドではこのアプローチが通用しません。Webページは HTML・CSS・JavaScript・画像といった 多数のリソースが相互に関係し合って成立している一つの表現 です。リソースの組み合わせ方や使い方はページによって千差万別であり、何か一つを変えると他に波及します。部分的に切り出して「この仮説は正しそうだ」と判断しても、他との兼ね合いによって成果がストレートに反映されないことが少なくありません。
デプロイという長いリードタイム
そのためフロントエンドのスピードを検証するには、ブラウザからちゃんと表示される形──つまり本番に近い状態まで構築を進めた上で計測する必要があります。本番環境であれ開発環境であれ、 Webページとして完全に表示できる状態までデプロイしなければ仮説検証ができない のです。
システムの構成が複雑であればあるほど、仮説を思いついてから実装・デプロイ・計測に至るまでのリードタイムは長くなります。ちょっとしたアイデアをさっと試して結果を見るという、クイックな仮説検証サイクルを回すことができません。結果として、 理論上は速くなるはずだという想定に頼り、大掛かりな実装と公開をぶっつけ本番で行う しかない──そんな状況に陥りがちです。
時間の経過が検証を曖昧にする
リードタイムが長くなると、もう一つ厄介な問題が生じます。その間に別のプログラム修正や機能改善が入り、スピード改善の施策と他の変更をまとめてリリースすることになりがちです。そうなると、スピード改善の効果だけを単独で検証することが困難になります。
たとえば1週間前のbeforeと今日のafterを比較したとしても、その1週間に起きた変化を考慮しなければスピードを公平に比較することはできません。そうなるとA/Bテストのような条件設定が必要となりますが、 スピード検証のためだけにA/Bテストを実装するのはさすがに開発コストが高すぎます 。
ブラウザが見ている世界だけを仮想化する
そこで弊社では、このフロントエンドのスピード改善における仮説検証の煩わしさを解決する方法として、一つの答えを出しました。実際のWebサイトにデプロイすることなく、 ブラウザが見ている世界だけを仮想化する というアプローチです。
まず、HTTPプロキシを介してブラウザとサーバー間のデータ通信を可能な限り正確に記録します。
次に、その記録したデータに変更を加え、HTTPプロキシから再生します。ブラウザはあたかも本番のWebサイトにアクセスしているかのように振る舞いますが、実際にはローカルで編集されたデータを読み込んでいます。
この仕組みにより、Webページの構成リソースの何をどう変えたらスピードにどのくらいの影響があるかを、 本番環境に一切手を加えることなくクイックに検証できます 。フロントエンドの仮説検証プロセスを極限まで凝縮するこの技術は、日本国および米国で特許を取得しています。
弊社の「ページスピード改善リハーサル」は、この特許技術に基づいてフロントエンドのスピード改善の仮説検証を短時間で繰り返し、本当に成果のある改善アイデアだけを事前に見極めた上で、確実な提案を行うサービスです。
ページスピード改善リハーサル
実装前に効果を証明。数値と動画で改善結果を見せてから、安心して実装に進めるスピード改善提案サービス