GoDaddy が実装し、何百万ものサイトのパフォーマンスを向上させ、PageSpeed Insights と Core Web Vitals の優れたスコアを達成した変更のケーススタディです。
GoDaddy は、世界中の起業家向けの世界最大のサービス プラットフォームです。Google は、2,000 万人を超えるお客様と世界中の起業家の方々に、オンラインでの成長に必要なあらゆるサポートとツールを提供することで、このコミュニティを活性化するという使命を担っています。
2019 年、GoDaddy は、使いやすいツールとサービスを提供し、ビジネス オーナーの目標達成を支援することを目標に、ウェブサイト + マーケティングを立ち上げました。ウェブサイト + マーケティングは、ウェブサイトの構築をマーケティング ツールや e コマース ツールと統合し、クラス最高のガイダンスと組み合わせ、顧客が新規ベンチャーで成功を収められるように支援します。
ウェブサイトとマーケティングの立ち上げ以来、パフォーマンスは同サービスの重要な部分を占めており、モニタリングされ、積極的に取り組まれています。この記事では、ラボのパフォーマンス テストの使用から、Core Web Vitals による実際のデータの使用に至るまでの GoDaddy の取り組みと、顧客のサイトで非常に高い合格率を得るために GoDaddy に行われた一連の改善について説明します。
Lighthouse を使用してパフォーマンスを追跡する
パフォーマンスのトラッキングには Lighthouse のデータを利用しました。Google では、プラットフォームでウェブサイトが公開されるたびに、Google の社内ツール「Lighthouse4u」を使用してパフォーマンスを測定しています。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% でした。しかし、Cumulative Layout Shift（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 マークアップが最終的な画像用に適切に確保されました。モバイル ビューポート全体に画像がレンダリングされるため、特にモバイル デバイスで改善が顕著でした。
Google のお客様サイトの一部のコンポーネント（社外のカスタマー レビューのリストなど）には動的なコンテンツが含まれており、サーバーサイド レンダリングによるパフォーマンス上のメリットを活用するために、純粋な CSS に変換することができませんでした。このような領域は、コンテンツ（高さ）が変わるため、レイアウト シフトを改善するのは困難です。その場合は、特定のコンポーネントの平均の高さに基づいて事前に決定された min-height が適用されたコンテナにコンポーネントをラップします。内部動的コンポーネントのレンダリングが完了すると、min-height は削除されます。完璧ではありませんが、このソリューションによってレイアウト シフトを大幅に削減できました。
Google は CLS の改善に注力する一方で、LCP にも引き続き取り組みました。多くのウェブサイトでは、画像が LCP の最大の原因であり、Google にとっては明らかに改善の余地がある領域でした。IntersectionObserver を使用して画像の遅延読み込み機能を改善しましたが、各ブレークポイント（モバイル、タブレット、パソコン、大型パソコン）で画像サイズが最適な方法で設定されていないことに気づきました。そのため、ブレークポイントごとに画像をクランプしてスケーリングし、さらにピクセル密度に基づいて解像度を調整するように画像生成コードを更新しました。例として、特定の大きな画像のサイズを 192 KB から 102 KB に縮小しました。
ネットワーク接続が不安定なデバイスでウェブサイトをすばやくレンダリングするため、接続速度に応じて画質を動的にスケールダウンするコードを追加しました。そのためには、navigator.connection から返される downlink プロパティを使用します。URL ベースのクエリ パラメータを適用し、これらのネットワーク状態に基づいてアセット API を通じて画質を下げます。
お客様サイトの多くのセクションは動的に読み込まれます。公開時に特定のサイトでレンダリングされるセクションがわかっているため、rel=preconnect リソースヒントを使用して、接続と必要な handshake を事前に初期化しました。また、リソースヒントを使用して、フォントやその他の重要なリソースをすばやく読み込みます。
サイトを構築する際には、さまざまな機能を可能にするためにインライン スクリプトを含むさまざまなセクションを追加します。これらのスクリプトを HTML ページ全体にインライン化すると、常に最適なパフォーマンスが得られるとは限りません。そこで、これらのスクリプトを外部化して、ブラウザでスクリプト コンテンツを非同期で読み込んで解析できるようにすることにしました。新たに外部化されたスクリプトをページ間で共有することもできます。これにより、ブラウザと CDN キャッシュという形でパフォーマンスがさらに向上しました。重要なスクリプトは、ブラウザでより速く解析して実行できるように、インラインで配置しました。
結果
CLS に重点を置いて成果を挙げた結果、Core Web Vitals の合格率は約 40% から約 70% に上昇し、75% の改善となりました。
ユーザーが Google のプラットフォームに戻ってサイトを更新して再公開すると、最新のパフォーマンス改善を受けられます。その結果、下記のグラフに示すように、「Core Web Vitals に合格」したサイトの数が着実に増えています。
まとめ
パフォーマンスの改善が見込める領域を見つけ出し、進捗状況を適切に把握できるかどうかは、測定に使用するツールに大きく左右されます。Lighthouse は、「ラボの設定」でのスクロールせずに見える範囲のパフォーマンスの測定には役立ちましたが、ユーザー インタラクション（ページのスクロールなど）からのみ発生するパフォーマンスの問題を正確に把握することはできませんでした。
実際の Core Web Vitals をメタデータとともに追跡することで、改善の効果を可視化し、ターゲット設定し、測定できるようになりました。Core Web Vitals のスコアを改善する取り組みにより、チームはコードベース全体でパフォーマンスの低いパターンを特定して置き換えることができました。期待できる変更でも期待していたほどの効果が得られなかったり、逆であったりすることがありました。ここは純粋な世界じゃないから、やってみないといけない。