LIFULL Creators Blog

LIFULL Creators Blogとは、株式会社LIFULLの社員が記事を共有するブログです。自分の役立つ経験や知識を広めることで世界をもっとFULLにしていきます。

LIFULL HOME'Sのサイト速度を監視できるようにした話

エンジニアの寺井です。本記事では LIFULL HOME'S でのサイト高速化への取り組みについて紹介します。

今回の内容は高速化施策の一環で、サイト速度を計測して監視できるようにした話です。

LIFULL HOME'Sのサイト内の各URLのサイト速度を一覧で見られるようにして、遅い箇所の特定や改善に活用できるようにしました。この取り組みについてお話します。

はじめに ~なぜサイト高速化が重要なのか~

Webページを見る際に数秒経っても真っ白の画面で読み込まれない、あるいは読み込まれている途中で何も操作ができない、こんな経験みなさんはありませんか?中にはページが読み込まれずイライラしてそのページから離れてしまうといった経験をした方も少なくないでしょう。

2017年にGoogleが実施したモバイルページの調査によると、ページ読み込み速度が遅くなるにつれて直帰率(ページを離れてしまう確率)が跳ね上がるという結果が示されています。このことから、サイト速度が遅いというだけでユーザーがサイトを利用してくれる機会が損失してしまうことがわかります。

上記の調査結果はやや昔のものですが、時間あたりに得られる体験が特に重視される現代ではサイト速度による影響はさらに向上していると推測されます。

以上より、サイトの高速化は真摯に取り組むべき内容だと判断できます。

高速化指標の話

サイト高速化の重要性は前項で触れましたが、では実際にサイト速度はどのように測ればよいのでしょうか?

Webページを構成する上で必要な要素は数多あります。たとえば LIFULL HOME'S だと物件情報を取得してくるまでのバックエンドの処理部分、ネットワーク通信、物件画像を表示する処理などさまざまな要素が絡み合ってページが構成されています。実際に手元の端末でサイトにアクセスして比較して...といった方法では感覚的な比較にしかなりませんし、具体的にはどの部分の処理が遅いのかという判断も難しいでしょう。

そこで、サイト速度を測るための指標として存在する パフォーマンス指標 やそのパフォーマンス指標をスコアで評価するLighthouse score といった速度計測用の指標を計測することにしました。

サイト監視の現状と課題点

LIFULLには内製の「KEEL」というLIFULLグループ全体で利用することを目的としたKubernetesベースのアプリケーション実行基盤が存在します。
KEELについての詳しい話は以下のエントリで紹介されているのでよければご参照ください。
https://www.lifull.blog/entry/2020/12/02/000000

KEELチームの活動により、LIFULL HOME'Sへの一連のリクエストに共通のID(TraceId)が割り振られ、関連するリクエストのログを横断で絞り込むことができます。これにより一連のリクエストのトレーシングが可能になり、あるユーザーのリクエストに対して裏ではどの処理がどれほどの処理時間を占めているかを把握することが可能になりました。この機能を活用することにより、高速化指標のTTFB(Time to First Byte, サーバ処理が終わって最初のレスポンスが返ってくるまでの時間)とほぼ同値のものを詳しく解析できました。
この活動に関しての詳しい話は以下のエントリに記載されているのでこちらも合わせてお読みください。
https://www.lifull.blog/entry/2022/12/22/090000

(上記記事より引用)バックエンド処理を詳しく解析可能

一方で、実際のLighthouse scoreはコンテンツが表示されるまでの時間やJavaScriptによって操作できない時間など、フロントエンド部分の処理の評価も重要になってきます。

バックエンド部分の詳しい解析はできてもフロントエンド部分の解析はうまくできないのが現状の課題でした。

WebPageTest を使った計測

そこで WebPageTest (以下WPTと表記)を導入することにしました。

WPTのしくみとしては「agent」と呼ばれるインスタンスが実際に計測対象のページを訪問して、かかった読み込み時間を計測できます。また、通信の帯域を調整でき、擬似的にPC環境でアクセスした状況やモバイル環境でアクセスした状況を作り出すことが可能です。つまりPCサイトとモバイルサイトそれぞれで、実際のユーザーが使うシナリオに近い状態で計測を行うことが可能です。

もちろんLighthouseを直接実行して計測するのでもよかったのですが、Lighthouseと比較してWPTの方がより詳しい項目まで取得できることが決め手となりWPT導入に至りました。

WPTはブラウザからも実行できるのですが、たとえば NodeJS用のAPI実行パッケージ を使うことでAPIを叩いて実行することも可能です。そこで、WPTが動作するサーバとagentが動くインスタンスを立ち上げ、APIを叩くアプリケーションを作成し、定期的にサイト速度の計測を実行するシステムを構築しました。また、WPTで取得した計測データは、データ収集ツールのPrometheusを用いて集約した後、データ可視化ツールのGrafanaを用いてダッシュボード表示をするようにしました。これにより、LIFULL HOME'S 内の主要URLで今どれくらいの速度スコアが出ているのかを可視化することが可能になりました。

この一連のシステムを簡易的に表現すると以下のような図になります。

システム全体図

このダッシュボードを活用することにより、現在LIFULL HOME'S内で極端に遅くなっている箇所の洗い出しや、リリース前後で速度変化が起きたことも検知することが可能になりました。

LIFULL HOME'S 主要URLごとにLighthouse scoreをグラフで一覧表示するようにしました

もちろん、このダッシュボードからそれぞれのWPTテスト結果へ飛ぶことも可能にしました。WPTの個別結果では処理にかかった時間が時系列で見られる「Waterfall図」など、詳しく解析するためのデータが揃っています。

ある計測結果のWaterfall図

計測をするようになって所感や今後の展望

WPTを定期実行することにより、サイト内で弱点となっている遅い箇所の特定と改善に効率的に取り組むことができました。結果として大幅なスコア改善を達成できたこともありました。

詳しい数値はお見せできませんが、Lighthouse score が一気に30ptほど改善できた箇所もありました

Webサービスを継続していく上で、機能追加に伴いサイトが遅くなっていくことはどうしても起こりうる問題だと考えます。

それは知らず知らずの内に細かい処理が積み重なって遅くなってしまった、というパターンが多いと思われますが、その原因の根本はサイト速度という指標を誰もが簡単に見られないからではないでしょうか。

今回の施策では時間をかけて定期的な計測と監視をできるしくみを作り上げ、LIFULLの全エンジニアがサイト速度を監視することが可能になりました。今までは気付くことができなかった速度の劣化等も各々が検知できるようになり、各々が改善に取り組むことも可能になりました。長期間のサービス運用において、自分たち自身で気付くことができ、対応できる環境は大事だと考えるので、今後長い目で見た時に大きな効果があると良いなと思います。

おわりに

LIFULLではこのような内部システムの高速化や効率化などにも積極的に取り組んでいます。

本記事を読んでLIFULLに興味を持っていただけた方はぜひカジュアル面談を受けてみませんか?よろしければ以下の求人情報もご覧ください。

hrmos.co

hrmos.co