はじめに
こんにちは。Repro Booster プロダクトマネージャーの Edward Fox です。普段はRepro Boosterの製品戦略立案やロードマップの策定を担当していますが、プロダクトの提供とは別にお客様サイトの根本課題を一緒に解決する取り組みも行っています。本記事では、最近担当した大規模ECサイトのパフォーマンス改善事例を題材に、技術面と組織面の両方から「パフォーマンス改善をどう進めればよいか」という観点で記事を書いてみました。
Repro Booster と伴走支援の位置付け
Repro Booster は「タグを設置するだけでWebパフォーマンスを改善する」ことを目的にしたプロダクトです。一方、既存サイトに長年積み上がった負債や部門間の調整といった課題はツールだけでは解決が難しい領域でもあります。そこで私たちは、少人数の伴走チームを編成し「小さく試して、パフォーマンス改善のインパクトを実感していただく」ための支援も提供しています。
具体的な社名は伏せますが、今回は大手ECサイトのクライアント様から機会をいただき、パフォーマンス改善の取り組みを行うことになりました。サイトのもともとのCore Web Vitalsを見ると、LCP が2500ms、CLS が1.23、INP が200msほどでした。大規模サイトゆえ全ページの一斉改修は難しく、まずは領域を限定した上で効果検証したいという先方の要望もあり、流入の多いトップページのLCPおよびCLSの改善を狙った改修をすることになりました。
実装
トップページの改修について、具体的には5つ修正を行いました。まず最上部のカルーセルについては、1枚目の画像だけに fetchpriority="high" 属性を付与し、反対に2枚目以降は loading="lazy" と fetchpriority="low" を指定することで、Above-the-fold（ファーストビュー）の表示を優先するような通信の制御を試みました。次に、サイトにもともと存在していた「すべてのカルーセル画像が読み込まれるまでコンテナ要素を非表示にする」というJSの処理に手を加え、コンテンツ表示までの待ち時間をなくしました。
3つ目はレイアウトシフト対策です。カルーセルのコンテナ要素に対する height をあらかじめCSSに記述することで、画像の表示タイミングで要素がズレる問題を解消しました。4つ目は動的なレコメンドツールの読み込み方法を見直し、タグマネージャー経由ではなく <head> に直接スクリプトを配置して、DOM への挿入タイミングを可能な限り前倒ししました。その結果、ウィジェット読み込み・表示による主要コンテンツのレイアウトシフトを防いでいます。
最後に、画像の遅延読み込みの実装をJavaScriptのライブラリからブラウザネイティブの loading="lazy" に統一し、スクリプトのパースと実行に伴うオーバーヘッドを削減することを試みました。
改善結果
上記の施策を組み合わせた結果、LCP と CLS の双方を大幅に改善できました。 ※ 数値はどれも Chrome UX Report から抜粋したもので、各指標の75パーセンタイルの値を参照しています。
| 指標 | Before | After | 改善幅 |
|---|---|---|---|
| LCP | 2.5 秒 | 1.4 秒 | ▲1.1 秒 |
| CLS | 1.23 | 0.18 | ▲85 % |
上記のグラフは https://cruxvis.withgoogle.com/ からの引用です。改修の適用直後から大きくCLS（△マーク）が下がっているのが分かります。CLSと比較するとLCP（◯マーク）の変化量は小さく見えますが、1秒ほどの改善幅があるのでそこそこ大きな差が出ていますね。なお今回のサイトはメインリソース（HTML）をキャッシュさせないヘッダがついているため、改修の適用直後にのみ数値の変化が現れることを期待していましたが、1ヶ月ほど時間をかけながら効果が収束した点はやや想定外でした。
またこのパフォーマンス改善の結果として、トップページから流入したユーザーの直帰率が下がった傾向も見られました。単一のページのパフォーマンスを改善したことで、サイトのKPIにも好影響を出すことができ、私としてもこの結果には満足しています。
パフォーマンス改善に取り組む際のポイント
今回の取り組みに限った内容ではないのですが、パフォーマンス改善を進める上では次のような点を意識して提案・推進を行っています。
1. 部署を横断する取り組みはしない
大規模なサイトでは、担当する領域やKPIが部署／部門ごとに分かれていることがほとんどです。サイト全体にまたがる改修は調整コストも大きくなりがちで、意思決定のハードルも高くなってしまいます。このためにも、局所的な改善で、かつ一定のインパクトを残せる施策を探すことが非常に重要になってきます。
2. コスパの良い施策から始める
局所的といえど実装の難易度が高かったり、大規模な変更をいきなり提案すると、時間も工数も読めず意思決定が進みません。パフォーマンスの分析や計測を通して費用対効果の高そうな施策を洗い出し、また手元で簡易的に効果の程度を示した上で実施の判断を仰げると、合意形成がスムーズになることが多いです。また費用対効果を考える上では、インパクトを残したい指標と効果の程度をあらかじめ定義しておくのも良いでしょう。
このためには的確なパフォーマンス分析や計測のノウハウが必要にはなります。Chrome UX Report や Chrome DevTools であったり、各種計測ツール（WebPageTestやSpeedCurveなど）などにも習熟しておくことが肝心です。
3. 定性／定量の効果を示す
定量的な効果の計測に加えて、顧客体験がどう変わったのか、という定性的な側面からもインパクトを示すと、さらなる本格的な改善の取り組みに同意を得やすくなります。
上記のような観点のもと、段階的なパフォーマンス改善の取り組みを設計し、効果を示しながら少しづつ推進していくのが大きな意思決定への近道だと考えています。実際に今回の取り組みの結果について、クライアント様にも満足いただけており、継続的なパフォーマンス改善の取り組みについても前向きに検討いただいています。
余談（LCPとCLSの連動について）
本題からは逸れますが、LCPとCLSに関して得られた気付きを共有させてもらいます。LCP は最大コンテンツ要素が描画されるまでの時間を、CLS はレイアウトの安定性を評価するため、本来は個別に独立した指標だと考えていました。ところが、トップページのカルーセル画像の読み込み優先度（fetchpriority）を調整した結果、LCP が短縮されただけでなく、CLS も大幅に改善が見られました。
理由としては、1枚目の画像を最優先で読み込むことでブラウザのレンダリング処理が同一サイクル内で完了することになり、レイアウトシフトが発生しにくくなったのだと推測しています。Core Web Vitals では LCP・CLS・INP は独立した指標として定義されていますが、現実の Web パフォーマンスではこれらが互いに影響し合うケースも少なくありません。交絡する因子を丁寧に紐解き、「パフォーマンス予算」の観点から適切にネットワークやCPUなどのリソースを配分する重要性を改めて実感しました。
パフォーマンス予算について詳しくは下記リンクを参照してください。またどこかでパフォーマンス予算に関する実践的な内容を盛り込んだ記事を書いてみたいと思っていますのでご期待ください。
ref. Performance budgets
まとめ
本記事では「パフォーマンスを改善する技術」という切り口で実際の改善事例と進め方を紹介させてもらいました。また5/15（木）には同じテーマのもと、AI Shift CTOの brnさん とパネルディスカッションの形式で掘り下げるイベントを開催します。興味がある方はConnpassページをぜひ見てみてください。
Repro Tech Meetup #10: パフォーマンスを改善する技術
WE ARE HIRING!
最後に、Repro Boosterでは開発者を採用しています。「タグを入れる」だけでWebパフォーマンスを改善するRepro Boosterの技術に興味を持っていただけた方は、ぜひ気軽にご連絡ください。