Webの表示高速化は、多くの制作現場において難易度の高いミッションになりがちです。

選択肢多すぎ問題

ネットワーク・バックエンド・フロントエンドのどれから着手すべきか、それぞれ多くの手法のどれから着手するべきか、どのページから着手すべきか。

継続が力なり問題

一発ですべてを解決する銀の弾丸はない。複数のアプローチを、コツコツ長期的に積み上げるしかない。

副作用が出る問題

速化によって運用の利便性が損なわれたり、最悪、不具合につながることも。

ぶっつけ本番問題

どのくらい速度が改善され、サイトの成果にどう貢献するか。予測が困難でやってみないとわからない。成果があったかすらわからない。

こういった複雑さから優先順位をなかなか決められず、先延ばしになりがち、長続きしない活動になりがちです。

高速化のアイデアは3つに分類するとわかりやすい

ここでWebの表示高速化とは「ファーストビューを早く見せること！」と断言します。

はじめからサイト全体、ページ全体の軽量化を考えるより、そう考えた方が気が楽ではないでしょうか？

実際にPageSpeed Insightsはファーストビューの描画が早くなると、劇的にスコアが改善されることが多いです。ファーストビューの表示の早さは、FCP、FMP、Speed Indexなどの指標で計測できます。

その視点に立つと、高速化のアプローチは次のいずれかに分類できます。

1. サーバーの応答速度を上げる

リクエストから応答までの時間(TTFB: Time To First Byte)を早くします。

2. ダウンロードの絶対量を減らす

データの道幅にも限度があります。データ量・リクエスト数・距離、これらの絶対量を減らすことはとにかく正義です。

3. ダウンロードの優先順位を整える

ページの下部に必要な素材が先にダウンロードされると、その分ファーストビューに必要な素材の到着が遅れます。

大事なのはこれらの分類それぞれについてバランスよく施策を行うことです。どれかに偏っては改善の成果を最大化できません。

1. サーバーの応答速度を上げる

静的コンテンツであればあまり問題にはなりませんが、複雑な機能を持つ動的サイトではいちばん重要です。

ここが遅くなると全体が遅くなり、後続の頑張りではそれを取り戻すことのできない「クリティカルパス」に当たります。

• データベースのスロークエリの解決
• キャッシュ(全体・部分)の有効活用
• ファーストビュー以外の要素の非同期読み込み

などのアプローチがあります。

パレートの法則に則り、80%の待ち時間が20%のコンテンツに費やされている関係がどのサイトにも散見されます。

そこで個人的には、その部分だけをやっつける部分キャッシュ(パーシャルキャッシュ)がおすすめです。影響範囲も狭く、手軽です。

2. ダウンロードの絶対量を減らす

ネットワークというデータが通る道は物理的に限られた幅があり、気合いと根性で限界を突破できるものではありません。

また、電気や光がいくら速いとは言え物理的な距離が伸びると通過する機器が増え、遅れを体感し易くなります。

• データ量を軽くする
• リクエスト回数を減らす(同じ種類のデータをまとめる)
• キャッシュを活用してダウンロード自体を回避する
• 再利用されない小さなCSSやJavaScriptはインライン化する
• CDNでユーザーに近いサーバーにキャッシュを残す

世界的に、Webページを構成するデータの約半数に当たる51%(2019年3月)を画像が占めており、データタイプとしては最も高いシェアを占めています。

画像はデザイン要素のみではなく、ユーザーが目にしたい「コンテンツ」としても使われます。

画像はCSSやJavaScriptに比べてサイト固有のテクニカルな課題がなく、単純に軽量化しやすい、自動化しやすいという利点もあります。

だから「ダウンロードの絶対量を減らす」という問題について、画像は最初に取り組むべきです。その発想から私たちはLightFileという製品に提供しています。

3. ダウンロードの優先順位を整える

もし、終わりからデータを読み込む画期的な動画サイトがあったら利用するでしょうか？

バカバカしいと一笑に付すジョークですが、Webサイトの多くがそんな愚を放置しています。

• 外部のJavaScriptはレンダリングを妨げるのでできるだけHTMLの下部で読み込むか、インライン化する
• ファーストビューに必要のない画像、CSS、JavaScriptは非同期で読み込む(遅延読み込みする)

ゲームのようなインタラクティブ性のない通常のWebサイトでは、3つの問題の中でもっとも地味で効果は薄いと言えますが、全ページに等しく影響する問題なので甘くみることはできません。

画像の遅延読み込みはライブラリも多く、効果が高いのでおすすめです。Chromeがブラウザの機能として実験的なサポートを試みていることも興味深い話題です。

多くのユーザーに影響があり、簡単にできることから始めてもOK

サイトの離脱ポイントが明確になっている場合はそこから取り組むべきですが、合意を固められない場合は次の軸で評価してみてはどうでしょうか。

• 多くのユーザーやセッションに影響があるページや画面(アクセス解析から評価)
• 簡単に対処できる問題(作業見積から評価)

いずれも成果の予測より、遙かに正確に定量化できる評価軸です。

評価軸を決められず手をこまねくくらいなら、そういった視点でタスクを決めてもよいでしょう。

まとめ

以上、つい後回しになりがちなWebの表示高速化の課題を整理し、ひとつひとつ着実に進めるための考え方でした。

• とにかくファーストビューの表示が早くなれば成果あり！
• 成果の大きさを正しく予見してホームランを打つより、バランス良く、コツコツとヒットを積み重ねることが大事！
• そもそも成果の予測は難しい。悩むくらいなら多くのユーザーに影響のあり、簡単にできることから始めよう！

せっかくコストをかけて集めたみなさんのサイトのお客さんが、ストレスで無為に離脱することが減るように願っています。