Mail.ru のホームページで Core Web Vitals を改善するための数か月間の取り組みにより、Cumulative Layout Shift（CLS）の 75 パーセンタイルが 60% 増加し、平均セッション時間が 2.7%、コアセクションのコンバージョン率が 10% 以上増加しました。
最初
Mail.ru はロシア語圏のインターネット大手のメール サービスの一つで、トラフィックでロシアの上位 5 つのサイトに入っています。Mail.ru は多くの人にとって重要なリソースです。1 か月に数億件のアクセスがあり、そこからメール、ニュース、ソーシャル メディア、パフォーマンス インターネット検索などにアクセスできます。
Mail.ru は訪問者に高品質のユーザー エクスペリエンスを提供したいと考え、Core Web Vitals を改善する取り組みを始めました。最適化戦略について説明する前に、まず Mail.ru ホームページの技術的な詳細をいくつか確認しておきます。
このプロジェクトは長い間、社内テンプレート エンジン Fest を使用して開発されてきましたが、2019 年に Svelte 3 への移行を開始しました。
Svelte は、Virtual DOM を使用しない方法でリアクティビティを実装しているため、リソース消費量が少なくなります。Svelte のアプローチでは、未使用の関数を製品版バンドルから削除します。これは、関数が使用されなければ、それらを実装するコードがコンパイラによって生成されないためです。コンパイル時に未使用のコードが削除されるため、バンドルのサイズが小さくなります。これにより、ページ起動時のTotal Blocking Time（TBT）を短縮できる可能性があります。
パフォーマンス指標の追跡
Core Web Vitals を最適化する前に、現場でのパフォーマンスを評価することをおすすめします。Core Web Vitals の導入前は、Google の内部パフォーマンス ダッシュボードで他の指標（First Contentful Paint（FCP））などもトラッキングしていました。
Core Web Vitals を収集し、可視化のためにパフォーマンス ダッシュボードに送信するように、指標収集スクリプトが変更されました。Google の推奨に沿って、このスクリプトは PerformanceObserver API を使用して指標を取得します。この API は、Mail.ru 内のユニバーサル フロントエンド「プラットフォーム」の一部です。
ダッシュボードには、ユーザーに関する次の指標が表示されました（2021 年 3 月 15 日～ 21 日の週の平均値）。
| 指標グループ名 | Core Web Vitals | その他のウェブに関する指標 | |||||
|---|---|---|---|---|---|---|---|
| 指標名 | LCP | FID | CLS | FCP | 未定 | おすすめスポット | |
| Core Web Vitals のしきい値に基づくユーザーのシェア | good | 52% | 92% | 33% | 35% | 42% | 43% |
| 改善の必要性 | 19% | 5% | 23% | 38% | 16% | 25% | |
| 危険 | 29% | 3% | 44% | 27% | 42% | 32% | |
Core Web Vitals の改善
Core Web Vitals を改善するためのガイダンスは豊富にありますが、プロジェクトごとに固有の課題があります。Mail.ru ホームページには、次のような改善の機会があります。
- 広告バナーのプレースホルダを実装することで、CLS を削減できます。
- サーバーサイド レンダリング（SSR）を使用して Largest Contentful Paint（LCP）を削減する。
- コード分割により LCP と初回入力遅延（FID）を低減。
CLS 改善のためのスケルトン
CLS は、Mail.ru ホームページのフィールド指標の中で最もパフォーマンスが低いものの 1 つでした。その後、Chrome の DevTools の [パフォーマンス] パネルでこのページをプロファイリングしたところ、広告が問題の原因となっていることがわかりました。そこで Google では、レイアウトの安定性を高めるために、広告が読み込まれる前に広告用のスペースを確保できるようプレースホルダを使用することにしました。
プレースホルダを実装する場合、最初のステップは、プレースホルダを置き換えるコンテンツのサイズを決定することです。幸いなことに、Mail.ru の PC 版ホームページには広告のサイズが厳密に記載されています。設計チームとの話し合いの結果、SVG アニメーションの UI スケルトンがプレースホルダとして使用されました。コンテンツの読み込みに要する時間が短くなるためです。
SSR のリターン
Fest から Svelte への移行を容易にするため、既存のプロジェクトを最初からやり直すのではなく、段階的に書き換えました。2021 年 3 月までに、フロントエンドの大部分を Svelte に移行し、バックエンドのパフォーマンスの問題をトリアージして修正した後、最終的に SSR を本番環境アプリケーションに導入しました。
SSR の実装後、チームは当初気づかなかった CLS 回帰の原因を発見しました。これは、ページの最初のコンテンツをレンダリングする時点で、ニュース セクションが挿入されていなかったことです。サーバーから提供されたページ マークアップの最初の描画から、クライアントのニュース セクションの挿入までに遅延が生じました。その結果、広告のスケルトンが変化し、CLS が悪化しました。
Chrome の DevTools には Layout Shift イベントが表示されていましたが、最初はその理由がわかりませんでした。SSR 自体は問題ではありませんでしたが、後で解決策を見つけるのに役立ちました。ペイントの遅延の原因となっているコードを修正することで、ニュース コンポーネントのレイアウトの安定性が向上しました。
SSR が CLS にもたらすもう一つの影響は、ハイドレーションの前後のコンポーネントの動きです。これは、さらなるレイアウト シフトにつながる可能性があります。これは特にモバイル版で発生しており、ハイドレートされたコンポーネントのマークアップには特に注意を払う必要がありました。この問題の解決策として、できる限り多くの表示ロジックを JavaScript から CSS へ転送する方法がありました。
コード分割と未使用のポリフィル
知覚されるページ読み込み速度を改善するには、LCP 値と FID 値を下げる作業が必要でした。これを実現する 1 つの方法は、コード分割です。Mail.ru のホームページに加えて、Google のチームはポータル ナビゲーション用のウィジェットを開発しています。現在、社内の多くのプロジェクトに組み込まれています。
歴史上の理由から、ウィジェットは同期読み込みスクリプトとしてページの先頭に挿入されています。このスクリプトにおけるポリフィルの割合は、時間の経過とともに増加しています。このようなポリフィルの読み込みによるパフォーマンスの低下を抑えるために、最新のブラウザと従来のブラウザの両方にコード分割を実装しました。
最新または従来のブラウザで JavaScript バンドルを読み込む場合、module/nomodule パターンは使用しないことにしました。これは、<script> 要素の type="module" 属性が、当社のニーズに十分対応できる最新のブラウザをターゲットとしていなかったためです。これに対処するために、Mail.ru はバックエンドで最新のブラウザ バージョンを識別する社内ツールを使用しており、それに応じて各ブラウザに適応しています。
バックエンドでブラウザを識別できるようになると、最新のブラウザと従来のブラウザのコード分割を実装しました。その結果、最新のブラウザでは同期的に読み込まれる JavaScript ウィジェットのサイズが 43.3% 削減されました。この手法は、他のいくつかのポータル スクリプトにも適用されています。
コード分割は、バンドルサイズの削減と Core Web Vitals の改善に加えて、デベロッパー エクスペリエンスも向上させます。従来のブラウザを使用しているユーザーはわずか 3.5% で、その割合は減少傾向にあります。そのため、コード分割を実装したことで、従来のブラウザに必要なポリフィルの肥大化をすべてのユーザーに導入することなく、最新のブラウザ API を使用できるようになりました。
結果
最適化の取り組みの後、フィールド データで 2021 年 5 月 24 日～ 30 日の週の平均値が観察されました。
| 指標グループ名 | Core Web Vitals | その他のウェブに関する指標 | |||||
|---|---|---|---|---|---|---|---|
| 指標名 | LCP | FID | CLS | FCP | 未定 | おすすめスポット | |
| Core Web Vitals のしきい値に基づくユーザーのシェア | good | 58%（+6%） | 93%（+1%） | 93%（+60%） | 43%（+8%） | 49%（+7%） | 51%（+8%） |
| 改善の必要性 | 18% | 4% | 3% | 34% | 17% | 24% | |
| 危険 | 24% | 3% | 4% | 23% | 34% | 25% | |
以下のグラフは、ウェブページのパフォーマンス指標の値の推移を「プラットフォーム」別に示しています。グラフ上の 2 つの重要な日付に注意してください。
- 2021 年 3 月 23 日: 最後のページ セクションを含む反復処理のリリースを Svelte に移行。
- 2021 年 4 月 19 日: SSR を返す反復処理をリリースし、CLS 回帰を修正するためにレイアウトを変更しました。
5 月 1 日から 5 月 10 日までの値の減少は、ロシアでの 5 月の祝日のためです。
[プラットフォーム] を使用して得られた結果は、Chrome UX レポート（CrUX）の指標値の増加と一致している。
ユーザー セッション継続時間の平均値を、初期改善のロールアウト前の 1 週間とリリース後の 1 週間で比較したところ、2.7% の伸びを示しています。さらに、ページのほとんどのセクションでコンバージョンが全体的に大幅に増加しています。特に、Mail.ru メールアプリのコンバージョンは 11.6% 増加し、ニュース セクションのコンバージョンは 13.5% 増加しました。
181%
良好な CLS しきい値のシェアの上昇
2.7%
平均セッション継続時間が長い
13.5%
ニュース セクションのコンバージョン率の伸び
予想外の結果となったのは、マーケティング バナーのクリック率（CTR）が 17.4% 上昇したことです（SSR とプリロード タグの導入により、表示時間が大幅に短縮されました）。
ページの他のセクションを分析したところ、その大部分で大幅なパフォーマンスの向上が確認されました。「天気」や「新型コロナウイルス」などのページは重要ではありませんが、コンバージョン率はそれぞれ 9.6% と 9.5% 増加しています。
おわりに
関連する作業に時間がかかるという点で、パフォーマンスの改善は困難です。指標の経時的な変化を定期的にモニタリングし、プロダクトのすべての新機能によって Core Web Vitals の回帰が発生しないようにする必要があります。これを実現するために、Google ではパフォーマンス バジェットで Core Web Vitals の変化をモニタリングしています。
最も重要な点として、マネージャーやデザイナーからテスターや QA まで、プロダクト チームのすべてのメンバーに対して Core Web Vitals の重要性を強調しました。各チームメンバーはパフォーマンス指標を認識し、指標を改善できるようにする必要があります。また、定期的にビジネス プロセスにパフォーマンスの最適化目標を組み込んでいます。質の高いユーザー エクスペリエンスの提供は、チームメンバー全員の共同作業によってのみ可能になります。