ゲソてんでLCPの改善に取り組みました

はじめに

こんにちは。ゲソてん開発チームの小山です。

ゲソてん開発チームでは、2021年の1~3月にSP向けページのユーザ体験の品質向上のためのチューニングを行いました。
Core Web Vitalsの指標であるLCP向上を目標として設定しました。
具体的には2021年3月の移動平均で計測するとし、デザイナー・エンジニアで協力して取り組みました。

その取り組み内容をまとめました。

実施の背景

改善前のゲソてんのSP向けページは、機能優先で開発してきたために、コンテンツが多く、わかりづらい・表示が遅いという課題がありました。

タイミング良く、Google社からCore Web Vitalsというユーザ体験(UX)の概念と、そのためのユーザ体験(UX)の指標が発表されたため、
チームのデザイナーとエンジニアでこちらを指標として改善に取り組もうという自発的な動き出しがありました。

対応前のスコアと指摘事項

対応前の状況を載せておきます。

トップページ

ゲームトップページ

LCPの表示まで、トップページで4秒余り、ゲームトップで3.3秒かかってます。

※ Core Web Vitalとは？

Googleで定義した、ユーザ体験を最適化させるためのWEBページの指標。検索結果にも影響を与えます
特に重要な指標として下記３項目を設定しています

- LCP (Largest Contentful Paint)
    - 最も大きなコンテンツ（画像など）が表示されるまでの時間
- FID (First Input Delay)
    - 読み込みの応答性。実際にページを操作できるまでの時間
- CLS (Cumulative Layout Shift)
    - 視覚的な安定性の指標

1. 初めにやったこと : 指標を定義

まず、ゲソてんのSP主要ページを、Page Speed Insightsで計測しました。
計測時の指摘内容も明確かつ大量にあり、実際に何を行なっていけばいいのかも明確でした。
その上で、目標としてPVの大きい下記２ページを設定しました。

• トップページ

• ゲームトップ

LCPのドキュメントを見ると、LCPで推奨される速度は2.5sec以内となっています。

サイトの表示内容は、キャンペーンやゲームの露出等で変わりますので、3月末時点で30日の移動平均の値が
この2.5秒を下回ることを目標としました。

2. 次にやったこと : 走る前の準備

1) Core Web Vitalsの勉強会の実施

社内でもまだノウハウがありませんでしたので、数回に分けてCore Web Vitalsの学習会を行いました。

Core Web Vitalsの測定のアルゴリズムを理解するためです。
ここでチームで理解を深めていたことで、施策を行なった際の効果について全員が共通言語で話せました。
また、効果があった場合も薄かった場合にも、仮説を立てながらの話し合いができたと思います。

特に、LCPを追いかける上で、下記の2つの概念は押さえておいたほうがいいです。

• 75%タイルLCPの計測ですが、75%タイルという計測手法での計測となっています。
  75%タイルとは、簡単に説明すると、4人中3番目の速度の人のアクセスを測定値にするということ。
  特にSPの場合、回線速度でページが表示されるまでの時間に差が出ます。

• 何をLargest Contentsとして扱うかページの表示上で最大のコンテンツがLC(Largest Contents)であり、LCPの測定時間になります。
  画像なのか、テキストなのかは問いません。ファーストビューでの表示領域が１番大きいものとなっています。

2) 日次での数値計測整備

学習会と合わせて、インフラチームに協力いただき、改善内容がスコアにどう反映されるか、
日次で集計してグラフで進捗が確認できるようにしていただきました。
数値を毎日確認できるため、実施した施策の効果が判断しやすくなります。

3) keep meetingの設定

短時間でも状況下人のためのKeep Meetingを週3会程度設定し、課題があれば都度共有・相談することにしました。
朝の5~10分程度ですが、問題があれば30分以上に長引くことも。

<主な議題>

• 数値の確認

• 作業進捗の報告

• 次にやるアクションの決定

• 問題や疑問があれば、共有・相談

基本、メンバーには他に通常業務がありますので、立て込んでいる時には改善のための作業が全くできない時も多々あります。
そういった状況も含めてチームで状況把握し、必要に応じてヘルプしあったことで、チームがうまく機能したと思います。

3. ページの最適化の実施 (PDCA)

Page Speed Insightsには、ページ上で改善したほうがいい事項がリスト化されて大量に記載されます。
その中で、対応しやすく、効果の高そうなものから順次、対応を行なっていきます。

page speed insitesの表示例

実施したことのうち、効果が高かったものから挙げておきます。

1) cssとjsファイルの整理 [効果 : 大]

サイト全体で使う共通のcssやjsファイルを圧縮して配置していたのですが、対象ページに表示される必要最低限のcssとjsのみを
読み込むように再構成
※ スコアは大きく改善されたのですが、共通ヘッダへの処理分岐が増えるなど、プログラム上の可読性は低下。

2) サーバの応答速度改善 [効果 : 大]

プログラムの処理を確認、速度改善できそうな箇所を改修。

主にやったこと

• ゲームページのタブでの表示切替を画面遷移に変更

• 表示コンテンツの非同期化

• SQLの実行回数を減らす

• 未使用なロジックの削除（キャンペーンや以前のレイアウト改修で不要になった処理など）

速度改善はスコアに与える影響が大きいです。
げそてんのゲームトップページは、処理速度を半分程度にできました。

画面のタブ切り替えをシームレスに行うため、バックエンドで全タブで表示するための情報を取得していたのですが、ページをタブごとに切り出しました。

PVに比べてタブをクリックして遷移する頻度がだいぶ低かったので、ページ遷移にして正解だったと思います。

3) コンテンツの遅延読み込み [効果 : 中]

初期レンダリング時に不要なライブラリやコンテンツを、一部非同期での遅延読み込みに。
特殊な例として、GoogleAnaliticsのJSも同様にPage Speed Insightsで指摘されたため、遅延読み込みにしています。
（Googleさんの指示どうりにシンプルに埋め込んでいるのですが…)

また、ゲソてんトップで表示しているTwitterのタイムラインは、読み込みタイミングのせいなのか、レンダリングブロックしていると指摘されたため、こちらも遅延読み込みに変更して解消しました。

4) コンテンツの断捨離 [効果 : 中]

クリック数から、実際に表示コンテンツの利用状況を調査。
あまり使われてないコンテンツについては、ディレクターと相談してコンテンツ自体を消し、それに伴うバックエンド処理を削除。
合わせて、連携用や成果タグなどで今は使われてないものもあったので削除。
この手の対応は、１つ１つは効果が高くなくても、積み重なるとじわじわと効果が出てきます。

5) 画像の遅延読み込み [効果 : 中]

全てのimgタグに loading="lazy"オプションを追加。
背景画像はcssで指定していたのでSVG化。
スコアに対する効果は、そこまで高くはないかもしれませんが、シンプルな対応で指摘事項を一気に減らせました。

6) 画像のwebp化 [効果 : 低]

jpegやpngの画像を、全てwebp形式でサムネイルを作成。
webp対応ブラウザではwebpファイルの方を参照するようにしました。
ゲソてんはゲームポータルですので、ゲームのサムネイル画像やバナーが大量に表示されています。
スコアへの影響は思ったほどなかったのですが、副次的に、Page Speed Insightsでの指摘箇所が見やすくなりました。
50箇所以上、画像の指摘が出ていたものが一気に減らせたので、次の取り組み課題が見やすくなります。
今後もしiOSのSafariがwebp対応になるようでしたら、もう少し効果があるかもしれません。
あと、pngをwebp化した際に少しサイズが増えてしまったものがありましたので、ファイルサイズも軽量化できたらもう少し効果が出た可能性はあると思います。

7. 画像のwidthとheightを指定する [効果 : 低]

サイズがわかっている画像については、width, heightを指定しました。
ページの最も大きなコンテンツ(Largest Contents)がブラウザ側で早く確定できるようにするための対応です。
スコア上はそこまで効果はなかったのですが、すぐできてCLSにも良いので。
サイズが確定しているものについては、やっておいたほうが良さそうです。

結果

上記の対応の結果、レッド(poor)やオレンジ(needs improvement)だったLCPの値を、安定してグリーン(good)の状態まで持っていけました。

表示速度も、約半分まで減らせました。
スコアの推移と、結果の数値について載せておきます。

スコアの推移

トップページ

ゲームトップページ

参考: サイトスコア

BEFORE

AFTER

最後に

今回、ゲソてんというゲームポータルで実施したLCPの対応とその効果について述べさせていただきました。
上述の対応と効果ですが、サイトによって対応内容の効果は若干違うにしても、共通の箇所は多いかと思います。

あと、何気によかったのが、Core Web Vitalsのアルゴリズムを知り、チームで共通言語とできたことです。
今後、新規開発やデザイン変更があっても、この辺りの仕組みを意識して、デザインや開発を進められます。

課題ですが。
[3-1) cssとjsファイルの整理]でも触れましたが、今回の対応で、読み込みするcssやjsがページ単位になり、共通ヘッダに処理分岐が多数できてしまいました。
この辺りはシステム設計を見直して、仕組みである程度解消できるようにしたいですね。
また、今回Page Speed Insightsでの測定は未ログインページだけですので、ログイン時・ログイン後のUXに対してはまだ対応した方がいい箇所がたくさんあります。
(ログイン処理速度やマイページ周りなど)

今回の知見を参考にしつつ、今後もチームで相談しながら、ゲソてんをよりよくしていきたいと思います。

最後まで、読んでいただきありがとうございました！
もし似たようなチューニングを行う際に、少しでも参考になれば幸いです。