考えるフェーズ
表示速度設計 速くする前に、どこが遅いのかを切り分ける。
表示速度で最初に確認すること
表示速度の問題では、まず、画像の重さが疑われます。
しかし、スマートフォンで動画を見る時代に、画像が表示速度を下げる圧倒的要因になることは、あまり考えられません。
そして、次に疑われるのは、サーバーです。
安いからか、古いからか、ベンダーが悪いのか、やっぱりAWSか、といった議論が起きることもよくあります。
その前に、まず、どこが遅いのか？を確認し、問題を切り分ける必要があります。
例えば、Webサイトへアクセスしてからの反応を検証することで、対応方法はかわってきます。
表示速度の改善では、どこが表示に負荷をかけているのか？というボトルネックを特定することから始まります。
まずはChromeの検証ツールを見る
表示速度の問題を調査するとき、私たちはまずChrome DevToolsの「Network」を確認します。
ここを見ることで、
- サーバーが遅いのか
- データ取得が遅いのか
- 表示処理が遅いのか
を大まかに切り分けることができます。
Waiting（TTFB）が長い
- Waiting：2.5秒
- Download：0.1秒
→ サーバー側を確認する
特定ページだけ極端に遅い
- 一覧ページだけ遅い
- 検索結果だけ遅い
→ データ取得方法を確認する
HTMLはすぐ返るが表示が遅い
- Waiting：0.1秒
- Download：0.1秒
- 白い状態が長い
→ HTMLの外部ファイルを確認する
Waiting（TTFB）が長い場合
まず疑うのはサーバー側です。
例えば、
- サーバースペック
- PHPのバージョン
- MySQL / MariaDBのバージョン
- キャッシュ設定
- Webサーバー設定
などです。
特に5年以上運用されているWebサイトでは、PHPやデータベースのバージョンが古いために遅くなっている可能性もあります。
実際には、サーバー環境を見直しただけで体感速度が改善することもあります。
そのため、まずHTMLを返すまでに時間がかかっているのかを確認します。
サーバーの問題であれば、サーバーのチューニングや乗り換えを検討するのも一つの方法です。
まずはサーバーが正常に応答できる状態になっているかを確認することが重要です。
特定ページだけ極端に遅い場合
- 一覧ページだけ遅い
- 検索結果だけ遅い
このような場合には、表示するためのデータ取得処理に問題があるケースが考えられます。
例えば、
- 不要なリレーション
- N+1問題
- 全件取得
- 複雑な検索SQL
- APIの多重呼び出し
などです。
特にWordPressなどのCMSや業務システムでは、データ量が少ない初期のころには問題がなくても、データの増加や機能の追加により、徐々に遅くなり、ある一定段階から、急激に遅くなる場合があります。
表示速度の問題は、見た目よりもデータ構造に存在していることも少なくありません。
CMSだから遅いわけではない
例えば、リニューアルのご相談の場合に、最も実装されているCMSといえば、WordPressです。
WordPressはコンテンツ管理システム（Content Management System：CMS）として非常に優秀です。
そもそもCMSと名の通り、コンテンツの管理という部分では、使いやすく、更新のしやすいシステムですので、一般的なコーポレートサイトやブログであれば、大きな問題になりません。
一方で、WordPressは、PHPのバージョンアップにあわせ、バージョンアップをし続けてきていますので、このバージョンの低さによって負荷に耐えられなくなったり、そもそものPHPのバージョンの低さが問題になるケースがあります。
また、表示速度の問題が発生している場合、WordPressそのものよりも、
- 長年の運用で追加されたプラグイン
- 複雑化した検索機能
- 独自の会員機能
などによるDBへの負荷や複雑な処理が速度低下の原因になっていることがあります。
リアルタイム取得は本当に必要か
表示速度設計では、リアルタイム取得が必要かどうかを整理することも重要です。
例えば、
- エリア一覧
- カテゴリ一覧
- 実績一覧
- マスターデータ
などは、必ずしも毎回リアルタイム取得する必要がない場合があります。
しかし、リアルタイム取得を前提に設計すると、毎回データベースへアクセスすることになります。
その結果、アクセス数やデータ量の増加とともに負荷が増えていきます。
表示速度改善とは、処理を速くすることではなく、不要な処理を減らすことでもあります。
JsonSnapshotという選択肢
FHWでは、更新頻度の低い情報や、一覧表示などで利用するデータについて、JsonSnapshotという考え方を活用しています。
これは高速化技術ではありませんが、リアルタイム取得が不要な箇所を切り分け、DBとのやり取りを減らす設計です。
例えば、DBのアクセスにより取得していたデータを事前生成したJSONデータとして保持することで、
- DBアクセス回数削減
- サーバー負荷軽減
- 表示速度安定化
につなげることができます。
HTMLはすぐ返るが表示が遅い場合
WaitingもDownloadも短いのに、画面が表示されるまで時間がかかる場合には、サーバー側ではなく、ブラウザ側の処理を疑います。
例えば、
- JavaScript
- CSS
- フォント
- 外部ライブラリ
- 画像
などの読み込み負荷です。
一般的に「表示速度改善」というと、この部分が語られることが多くあります。
例えば、
- WebP
- AVIF
- Lazyload
- CSS最適化
などが良く上がってきます。
もちろん重要な施策ではありますが、お客様の表示スピードの課題では、多くはここではなく、サーバー側の問題である場合がほとんどです。
Flying High Worksの考え方
表示速度の問題は、公開後に発生することが少なくありません。
それなりのコンテンツ数と実際のアクセスがあって初めてわかることもあります。
しかし、その原因の多くは公開前の設計でつぶせるものがあります。
- データ取得
- リレーション構造
- 検索設計
- サーバー構成
- 更新方法
これらを整理せずに作られたサイトは、運用が進むほど遅くなる可能性があります。
表示速度の改善とは、遅くなってから、初期の状態に近づける作業とも言えます。
だからこそ、公開時だけ速いサイトではなく、
- データが増えても
- 記事が増えても
- 機能が増えても
遅くなりにくい構造を考える必要があります。
それが、FHWの表示速度設計の考え方です。