昨今、Webサイトの高速化（以下：Web高速化）が注目を浴びています。
業界動向を熱心に研究している方であれば、すでにさまざまな事例を数多く見かけていると思います。
今回は、“Web高速化”の重要性を感じ、これから取り組もうと考えている方に（すでに取り組んでいる方にも）、ぜひ読んでおいてほしい1冊『超速! Webページ速度改善ガイド』をご紹介します。
僕自身、Webサイトのパフォーマンスについて意識し始めたのはここ数年ですが、本書を読んでこれまでいかにサイトの機能要件（見た目や挙動といった部分）しか見てこなかったのかを痛感させられました。
なぜ今Web高速化なのか？
Webページの表示や動作を速くした方がいいというのは、昔から言われていると思いますが制作の現場での優先度はさほど高くないケースが多かったと感じます。
確か2010年頃にGoogleが検索ランキングのアルゴリズム要素の1つとしてページ読込速度を採用するとアナウンスしたと記憶していますが、このあたりのタイミングでその重要性がようやく明示化されたのではないでしょうか。
ただ、当時は200以上あるアルゴリズムの中の1つに組み込まれただけで、依然として上位表示のためには「検索キーワードとページとの関連性」が重要視されていました。
さらにインターネット利用者の利用端末の比率もパソコンの方が多く、表示が遅くてもストレスに感じにくい（悪くいうと気付かれにくい）ため、優先度はさほど高くない状況だったのかもしれません。
ですが、近年サイト高速化に取り組んでいる事例を目にする機会が増えていると感じます。
本書の序盤で「Webページ速度の重要性」について述べられていますが、それらの解釈をふまえると以下の3点がWeb高速化が盛り上がっている主な理由として挙げられると思います。
- ページ速度の向上がコンバージョンやエンゲージメントに良い影響を与えることが数値で裏付けられてきている
- ユーザーの閲覧環境が多様化し、非力な環境（低スペックで不安定な回線）からサイトを閲覧するケースが多くなった
- Webの表現の進化により表示するクライアント側の環境への要求スペックが向上しているが、速度を犠牲にせずそのようなインタラクティブで高度な表現をいかに実現できるかがプロダクトの鍵となってきている。
端的にいうと、表示速度が遅いということがビジネス上致命的なリスクとなりえる状況であることが寄与しているのだと思います。
また、上記の1と2どちらにも関連する内容として付け加えると、Googleが2018年7月に行った“Speed Update”の影響も大きいと思います。
推測するな、計測せよ
今や便利な世の中で、何か困ったらGoogleで調べれば大抵のことは解決できると思います。
Web高速化についても、調べれば先人のテクニックやノウハウがたくさん出てきます。
ですが本書は、「基本的な仕組みとロジックを理解せずに進めていくとあとあと大変です。」ということをまずはじめに強調しています。
とにかくコード書いてサンプル動かしてトライ＆エラーで学んできた方などは、割と陥りがちなんじゃないかなと思います。僕もその口だと思うので、読んでいて胸が痛かったです。
新しい技術を習得したり、新しい機能を開発する場合は、まず雰囲気を掴むことや動かすことが目的だったりするのでそれでいい場合もあるかもしれません。
ですが、“改善”という目的の場合、As-is（現状）とTo-be（あるべき状態）を明確にする必要があるのだと思います。
いざ取り組もうとしたときに目の前にある問題は人それぞれですし、取り巻く環境も異なります。
（中略）
いきなりコードを眺めて修正し始めるのは得策ではありません。その修正が速度の改善にどれくらいのインパクトがあるのか明らかではありませんし、無駄になってしまうことすらあります。『超速! Webページ速度改善ガイド』第1章 Webページの速度より
計測や原因の調査をせずにやみくもに修正を加えたところで、運良く改善されればよいですが、それでは当てずっぽうのようなものであって再現可能なエンジニアリングとは言えません。
サイトの内容はもちろんそれぞれ違いますし、見た目や仕様、動作環境も千差万別。当然問題となる箇所や対応内容も違ってきます。
つまり、速度向上においては、これさえやればOKという王道パターンのようなものは存在しません。
自分たちでどこが悪いのかを調査して原因を究明し、そこを改善する。シンプルですがそれに尽きるのだと思います。
本書の序盤で早々に以下のフレーズが登場しますが、重要なので強調しておきます。
Measure, Don’t Guess
推測するな、計測せよ
Webパフォーマンスチューニングは、この言葉に集約されると言っても過言ではないと思います。
広く捉えると「属人的なスキルでなく体系的なアプローチをすべきだ」というこの精神は、すべてのエンジニアリングにおいて肝に命じておくべきだと感じます。
ベンチマークをどこにすべきか？
計測することの重要性はわかりましたが、どのぐらいの速度を目安にしたらいいのでしょうか。
よくユーザーインターフェースを考える際に統計データから効果的な配置を考えたりしますが、Webページの速度についても同じように参考にできるデータがあります。
本書では、以下の2つを基準値として紹介しています。
- コンピュータ分野におけるユーザビリティの権威であるJakob Nielsen（ヤコブ・ニールセン）氏の調査結果による基準
- Googleのエヴァンジェリストたちが提唱する“RAILモデル”
それぞれについて簡単に説明します。
Jakob Nielsen氏の基準値
Jakob Nielsen（ヤコブ・ニールセン）氏が行った調査（応答時間に対する限界）から導き出されたデータがこちら。
リンクをクリックしてページが表示されるまでは、1秒以内。
クリックやスクロールといった何かしらのアクションに対する反応に至っては、0.1秒を超えるとユーザーはストレスに感じるとしています。
RAILモデルにおける応答性の目標時間
アプリケーションのライフサイクルの観点から、それぞれのフェーズの基準時間を定義しているためそれぞれの頭文字をとって“RAILモデル”と呼ばれています。
Googleで調べようとすると検索キーワードを“RAILSモデル”に改められそうになりますが、“Ruby on Rails”とは全く関係ないので注意してください。
Jakob Nielsen氏の調査データと共通する項目もありますが、より実装の観点からWeb速度と向き合うための指標となっています。
Response
Jakob Neilsen氏の示すUIの応答による限界時間に倣っているものと思われ、同じく0.1秒（100ミリ秒）が基準とされている
Animation
スムーズなアニメーションをキープするためには、1秒間に60フレーム（60FPS）を保つ必要があります。そのための基準値として1フレームあたり約0.016秒（16ミリ秒）を限界としています
※厳密にはアニメーション処理以外のコストもあるため0.01秒（10ミリ秒）が基準とされている
Idle
ユーザー操作による処理が何もないIdle状態では、バックグラウンドでUIなどに影響のない処理を行ったりしますが、その処理時間が長いとユーザーが操作しようとした時に反応が遅かったりしてしまいます。
そのためIdle時の処理は、他の処理が割り込み実行できるように基準値を0.05秒（50ミリ秒）にすべきとしています。
Load
ページが表示されるまでの時間ですが、こちらもJakob Neilsen氏の調査と同じく1秒以内にすべきとしています。
Webページを構成する重要な要素として、本書には“ページロード”と“ランタイム”がしきりに登場しますが、Jakob Nielsen氏が示した基準もRAILモデルも同程度のベンチマークが設定されていると解釈できるので、まず目指すべき速度は概ね以下のとおりと考えておいて良いと思います。
- ページロード：1秒
- ランタイム：0.1秒
Webページの速度はフロントエンドで決まる
Webのパフォーマンスはこの先ますます重要になってくると思います。
本書内では、Webパフォーマンス界のパイオニアと称されているSteve Souders氏の以下の言葉が紹介されていますが、それらの大部分はフロントエンドでの実装にかかってきます。
80%-90% of the end-user response time is spent on the frontend. Start there.
『超速! Webページ速度改善ガイド』第1章 Webページの速度より
エンドユーザーに対するレスポンスタイムのうち80%-90%は、Webフロントエンドで発生している。
サーバーはクライアント側で何が起こっているのかを知り得ないが、クライアント側はサーバーからどのようにリソースを取得し、どの程度の時間をかけてダウンロードできたかを全て知っている。
ブラウザの内部処理の過程を理解し、どういう実装がパフォーマンス向上につながるかという知識は、フロントエンドエンジニアとしてひとつ上のステップで活躍するために必要になってくると思います。
フロントエンドエンジニアとして成長するために
昨今、フロントエンドエンジニアが扱わなければならない領域は拡大していますが、フレームワーク云々の前にこれらの知識をしっかりと理解しておく必要があると強く感じました。
いかに最新の技術スタックを駆使していたとしても動作が遅ければユーザーからは支持されないと思います。
実際、手探りでとあるサイトをReactで構築しなおした時、余計な処理が多く、メモリリークを起こしたりとSPAにする前と比較してさほど速度の向上が見られないということがありました。（苦笑）
一見地味ではありますが、ブラウザレンダリングの仕組みをしっかりと理解したうえでアプローチできる知識があれば、単に“動けばよい”というレベルからひとつ上のレベルに進むことができると思います。
僕も目下勉強中なので偉そうに語っている構図にだいぶ違和感を覚えますが、このあたりを雰囲気で理解していた方は、ぜひこの機会に理解を深めてみてほしいと思います。
今回は、Webパフォーマンスチューニングの概念的な部分にフォーカスしましたが、次回以降、実践的な部分について掘り下げていこうと思います。
というか本記事を読んで、Webパフォーマンスチューニングにすぐにでもトライしたいと思った方は、僕の解釈とかはどうでもいいと思うので、本書を購入してガシガシ読み進めていただいた方が早いかもしれません。
Hivelocityでは、ロジカルな思考で体系的に開発に取り組むことが得意な（またはそうなりたい）フロントエンドエンジニアを求めています！
ご興味のある方は採用サイトよりぜひご応募ください。
