GoDaddy が数百万ものサイトのウェブサイトのパフォーマンスを改善し、PageSpeed Insights と Core Web Vitals のスコアを高めるために実施した変更に関するケーススタディ。
GoDaddy は、世界中の起業家向けの世界最大のサービス プラットフォームです。YouTube は、世界中の 2,000 万人を超えるユーザーと、世界中の起業家を支援し、オンラインで成長するために必要なすべてのサポートとツールを提供することを使命としています。
GoDaddy は 2019 年に Websites + Marketing をリリースしました。これは、使いやすく、ビジネス オーナーの目標達成を支援するツールとサービスを提供することを目的としています。Websites + Marketing は、ウェブサイトの構築とマーケティング ツール、e コマース ツールを統合し、最高水準のガイダンスと組み合わせることで、お客様が新しいビジネスで成功を収めるのを支援します。
ウェブサイトとマーケティングのリリース以来、パフォーマンスはプロダクトの重要な要素であり、積極的にモニタリングされ、改善されてきました。この記事では、GoDaddy がラボのパフォーマンス テストから Core Web Vitals によるリアルワールド データの使用に至るまでの過程と、お客様のサイトの非常に高い合格率を達成するためにプロダクトに加えた一連の改善について説明します。
Lighthouse によるパフォーマンスのトラッキング
Google は、パフォーマンス トラッキングに Lighthouse のデータを使用していました。ウェブサイトがプラットフォームに公開されるたびに、GoDaddy は「Lighthouse4u」という社内ツールを使用してパフォーマンスを測定します。このツールは、Google Lighthouse をサービスとして提供しています（https://github.com/godaddy/lighthouse4u）。これにより、ラボ環境でサイトのパフォーマンスが一般的にどのようになっているかを把握できました。
Google のプラットフォームでホストされている数百万ものサイトには、さまざまな機能とコンテンツが含まれているため、テスト対象の各サイトに関するパフォーマンス データとメタデータ（使用されているテンプレート、レンダリングされるウィジェットのタイプなど）を組み合わせることが重要でした。これにより、パフォーマンスが低いウェブサイトの機能について結論を導き出すことができ、改善の余地がある部分についても分析情報を得ることができました。
たとえば、この機能によりページ速度が低下していることが判明しました。この機能を使用しているサイトは、使用していないサイトと比較して 12 ポイント低いパフォーマンスを示しています。JavaScript の読み込みを遅らせるようにコードを更新した結果、Lighthouse スコアが 2 ポイント向上しました。この学習結果は、ページの読み込み直後に表示される「Cookie バナー」などの他の機能にも適用できました。
機能に基づいて問題のあるサイトを調査するとともに、JavaScript バンドルを分析したところ、そのサイズの大部分は外部依存関係（immutable.js と draft.js）によるものであることがわかりました。コンシューマを再構築して、依存関係をオンデマンドで遅延読み込みするようにすることで、バンドルサイズを削減しました。その結果、一般的な JavaScript バンドルのサイズが 50% 以上削減され、200 KB 超から 90 KB 程度（圧縮後）になりました。バンドルサイズが小さくなったことで、ブラウザは外部アセットを読み込み、サイトの初期読み込みライフサイクルの早い段階で重要なスクリプトを実行できるようになりました。これにより、Largest Contentful Paint（LCP）とFirst Input Delay（FID）が改善されました。
継続的な取り組みの結果、お客様のサイトの Lighthouse スコアの平均は、2020 年 11 月の 40 点前後から 2021 年 5 月の 70 点以上に改善されました。ただし、すべての試みがうまくいったわけではありません。ローカルテスト環境でテストした結果と、現場で得られた結果が一致しないことがありました。ラボでのテスト結果は非常に役立ちましたが、次は現場で観察された実際のユーザー エクスペリエンスに焦点を当てる必要がありました。
Core Web Vitals で実際のユーザーデータをトラッキングする
web-vitals ライブラリをお客様のサイトに追加した後、実際の訪問者から実際のデバイスでデータを測定できるようになりました。ハードウェア、ネットワーク速度、ユーザー操作（スクロールやクリックなど）は、Lighthouse を使用したラボ環境のように一貫したベースラインではありません。ウェブサイト訪問者の行動を代表するデータが得られたことにより、正しい方向への大きな一歩を踏み出しました。
最も弱いリンク: Cumulative Layout Shift（CLS）に焦点を当てる
新しいデータを分析することで、ウェブサイトの速度を改善するために何が必要かについて新しい視点を得ることができました。Lighthouse スコアの改善に取り組んだ結果、75 パーセンタイル LCP は 860 ミリ秒、同じしきい値での FID は 10 ミリ秒未満となり、お客様のサイトでこれらの指標の合格率はそれぞれ 78% と 98% と高くなりました。ただし、累積レイアウト シフト（CLS）の数値は、Lighthouse で慣れ親しんだものとかなり異なるようです。75 パーセンタイルにおける CLS は 0.17 で、「合格」の基準となる 0.1 のしきい値を上回っており、すべてのサイトの合格率は 47% に過ぎませんでした。
この指標により、全体的な合格率が 40% に低下したため、2021 年 8 月末までにこの数値を 60% 以上に引き上げるという野心的な目標を設定しました。そのためには、CLS に重点を置く必要があります。
実際のユーザーはページを操作し、「上部」のコンテンツをスクロールします。これは Core Web Vitals でより正確に把握できます。サイトの初回読み込み中にユーザーがサイトを操作する方法が異なるため、CLS はラボデータとフィールドデータと異なります。
Core Web Vitals のすべての項目に合格する方法
パフォーマンスを改善するには試行錯誤が必要です。試行するたびに、想定どおりに機能するとは限りません。目標達成に役立った改善点は次のとおりです。
画像の読み込み用にスペースを予約することで、画像の下のコンテンツがずれるのを防ぎ、CLS スコアが大幅に改善されました。CSS aspect-ratio プロパティを使用して、これをサポートしているブラウザでこの問題に対処しました。キャッシュに保存されていない場合は、サイズが数バイトしかない透明なプレースホルダ画像を読み込み、ほぼ瞬時に読み込みます。
この汎用的な画像動作により、ビューポートの幅と画像のアスペクト比に基づいて、サーバーサイド レンダリング中に最終的な画像の高さを事前に計算できるようになりました。これにより、最終的な画像に適切に垂直方向のスペースが確保された HTML マークアップが作成されました。画像はモバイル ビューポート全体にレンダリングされるため、モバイル デバイスでは特に改善が顕著でした。
お客様のサイトの特定のコンポーネントには動的コンテンツ（外部顧客のレビューのリストなど）があり、サーバーサイド レンダリングのパフォーマンス上のメリットを活用するために純粋な CSS に変換できませんでした。コンテンツ（および高さ）が異なるため、レイアウト シフトを改善するのは難しい領域です。このような場合は、特定のコンポーネントの平均高さの観察に基づいて事前に決定された min-height を適用したコンテナにコンポーネントをラップしました。内部の動的コンポーネントのレンダリングが完了すると、min-height は削除されます。完璧ではありませんが、このソリューションにより、レイアウト シフトを大幅に軽減できました。
CLS の改善に重点を置きながら、LCP の改善にも引き続き取り組んできました。多くのウェブサイトでは、画像が LCP に最も大きく影響しています。これは、改善が必要な領域として明らかでした。IntersectionObserver を使用して画像の遅延読み込みを改善しましたが、画像サイズが各ブレークポイント（モバイル、タブレット、パソコン、大画面パソコン）に対して最適な方法で設定されていないことが判明しました。そこで、画像生成コードを更新して、ブレークポイントごとに画像をクリンプしてスケーリングし、ピクセル密度に基づいて解像度を再度スケーリングするようにしました。たとえば、特定の大規模な画像のサイズが 192 KB から 102 KB に削減されました。
ネットワーク接続が不安定なデバイスでウェブサイトをすばやくレンダリングするため、接続速度に基づいて画像品質を動的にスケールダウンするコードを追加しました。これを行うには、navigator.connection によって返される downlink プロパティを使用します。Google は、URL ベースのクエリ パラメータを適用し、ネットワークの状態に基づいてアセット API を介して画像の品質を低下させます。
お客様のサイトの多くのセクションは動的に読み込まれます。公開時に特定のサイトでレンダリングされるセクションがわかるため、rel=preconnect リソースヒントを使用して、接続と必要なハンドシェイクを事前に初期化しました。また、リソースヒントを使用して、フォントなどの重要なリソースをすばやく読み込みます。
サイトを構築する際に、さまざまなセクションを追加します。これらのセクションには、さまざまな機能を可能にするインライン スクリプトが含まれている場合があります。これらのスクリプトを HTML ページ全体にインラインで配置することは、必ずしもパフォーマンスに最適とは限りません。これらのスクリプトを外部化することで、ブラウザがスクリプト コンテンツを非同期で読み込み、解析できるようにしました。新たに外部化されたスクリプトは、ページ間で共有することもできます。これにより、ブラウザと CDN のキャッシュとしてパフォーマンスをさらに向上させることができました。ブラウザがスクリプトをより速く解析して実行できるように、重要なスクリプトはインラインのままにしました。
結果
CLS に重点を置いた結果、Core Web Vitals の合格率は 40% から 70% 近くにまで改善されました。75% の向上です。
ユーザーが Google のプラットフォームに戻ってサイトの更新と再公開を行うと、最新のパフォーマンス改善が適用されます。その結果、以下のグラフに示すように、「Core Web Vitals に合格」したサイトの数は着実に増加しています。
まとめ
パフォーマンスの改善が必要な領域を特定し、進捗状況を適切に追跡するには、測定に使用するツールが大きく影響します。Lighthouse は「ラボ環境」で上部に表示されるページのパフォーマンスを測定するには便利でしたが、ユーザー操作（ページのスクロールなど）によってのみ発生するパフォーマンスの問題を正確に把握することはできませんでした。
メタデータを使用して実際の Core Web Vitals をトラッキングすることで、改善の効果を可視化し、ターゲティングして測定できました。Core Web Vitals スコアの改善に向けて、チームはコードベース全体で見つかったパフォーマンスの低いパターンを特定して置き換えました。期待していた変更が想定していたほどの効果をもたらさなかった場合もあれば、その逆の場合もありました。外の世界は完璧なものではないため、何度も試す必要があります。