こんにちは。フロントエンドエンジニアの祐宗です。
今回は アスクルトップページ のLCPを改善するためにやったことについてご紹介します。
パフォーマンスの重要性
ECサイトのパフォーマンスはユーザ体験に直結します。
特にLCP（Largest Contentful Paint）は離脱率やコンバージョン率に高い相関があり、パフォーマンスにおける重要な指標となっています。
たとえばレストランへ行って料理が出てくるのが遅いと、もうそのお店には行きたくなくなりますよね。
それと一緒です。
引用：https://web.dev/case-studies/renault?hl=ja ｜Google
また2021年からLCPを含めたCore Web VitalsがSEOのランキング要因に取り入れられており、SEOの観点からもパフォーマンス対策は重要です。
ちなみにこのLCPはGoogleの推奨値では2.5秒以下となっています。
それではアスクルトップページのLCPがどうなっているか見てみましょう。
改善前の状態
2024年10月のトップページのLCP推移がこちらです。
元々5.0秒前後とかなり遅いのは一旦目を瞑り、10月末あたりでLCPが上昇していっていることが分かります。
原因究明と対策
このときの原因は10月末リリースした「いい明日が来る展」の販促エリア追加によるもので、
全体でリクエスト数が34、ページ容量が5.2MBも増えていました。
リリース当日10/29の平均LCPはなんと6.2秒。Google推奨値の倍以上となっています。
6.2秒あったら正しいフォームでスクワットが1回はできます。
こちらはその日の1日のページ容量推移ですが、一度画像サイズがどかっと増えているのが分かります。
サイトが重くなったことを確認してすぐに調査、対応しましたが結局5時間近く重い状態が発生してしまいました。
ここまで画像容量が増えているのはほとんどが未圧縮の画像を配信したことに起因しており、
圧縮後、サイズ上昇幅を0.2MBまで抑えられ、LCPも元の5秒前後まで戻りました。
再発防止のため、以降はリリース前確認と定期モニタリング、アラート設定をするようにしています。
その後他にも無駄に大きい画像があるのではないかと思いトップページの点検を始めました。
対策1：画像圧縮の横展開
費用対効果が一番あった対策です。
先ほどと同じように未圧縮の状態で配信されている画像がないかChrome開発者ツールのネットワークを重い順に眺めてみます。
基本的には圧縮済みなのですが、このように同じエリアに使用されている画像でもめちゃ大きい画像が混ざっていたりします。
コツコツ圧縮して再配信していきます。
また、画像圧縮を厳とするようデザインチームへ通達します。
ヒューマンエラーは発生してしまうもので、本当はCDN側で自動圧縮したいのですが、コストの面で見送っています。
大きな船は舵を取るのが大変なように、アスクルのような大規模ECサイトではこうしたインフラレベルの大きな変更をすぐに対応できない面があります。
コツコツ活動の結果、11月末から12月初旬までで画像ファイルサイズを2.1MBから1.1MBと半分近くにできました。
（11/26（左）と12/4（右）のファイルサイズ比較）
対策2：不要なJS配信の見直し
サードパーティファイル含め、不要なJSがないか、重複したファイルを読み込んでいないか点検をしました。
あるもんですね。サードパーティファイルで160KBもあるファイルが重複していました。
またアスクル側のファイルでも読み込みの必要のないJSも見つかり、3.75MBから3.35MBまで合計400KB削減できました。
（1/15（左）と1/16（右）のファイルサイズ比較）
正直まだまだあるんですが、すぐに対応できるファイルがこれくらいでした。
画像と比べると下がり幅も微妙なのですが、サードパーティのファイルも含まれているためこれくらいになっています。
また、JSはPC側の読み込みタスクについても関与するため、削減幅が小さくてもLCP影響があるため今後はもっと減らしていきたいところです。
その他対策など
その他にサードパーティファイルの読み込み遅延やAPI処理回数の削減など細かいものの対策をいくつか実施しました。
1つ1つの効果は小さいですが、全体を通してみると速度は改善していると思っています。
その他対策例
- サードパーティファイル遅延読み込み
- JSリファクタリング
- API実行回数見直し
- 画面外画像の遅延読み込み
結果
これらの改善をした結果、LCPが10/29の6.2秒から3/29には3.4秒まで高速化できました。
具体的にどの処理が重くて、「こう書き換えたら速度が改善した！」
みたいなテクニカルな内容がなくすみません。
単純にコンテンツの配信設計ミスでここまで早くなるのは少し恥ずかしいのですが、
逆にいうとリソース配信周りをめんどくさがらずにちゃんとチェックしていくと相応のリターンがあることがわかりました。
ではここで、今回の高速化がLighthouse的にどれくらい効果があったのか、私の好きなスコアリング計算機を見てみましょう。
LCP以外の項目をすべて満点とした場合、10/29日時点のスコアはこちらで、78点となります。
これを改善後の3.4秒にすると…。
92点で、14点も上がりました。
ここまで顕著に点数が上がると楽しいですね。
定期テストだとかなり親御さんが喜ばれる点数じゃないでしょうか。
とはいえ、目標はGoogle推奨値の2.5秒でまだまだ道のりは長いです。
また直近1ヶ月は改善が滞っており、なんなら2/14あたりと比較すると若干遅くなっているようにも見えるので、
パフォーマンス改善は継続的な努力が必要であり、技術の進歩に合わせて最適化を続けていくことが重要であることもわかります。
今後はサーバ側にアプローチできるものや、ともかく画像の容量を減らしたいためバナー画像の表示数自体の見直しなど、
まだまだ実施できていない対策があるので進めていく予定です。
また、今回改善が確認できた内容は順次他の主要ページへ反映していこうと思っています。
それでは、最後まで読んでいただきありがとうございました。
