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