何百万ものサイトのウェブサイト読み込みパフォーマンスを改善し、PageSpeed Insights と Core Web Vitals の優れたスコアを獲得するための道筋を明らかにするために、Wix で導入されたいくつかの主要な変更のケーススタディです。
CrUX と HTTPArchive のデータによると、業界標準、クラウド プロバイダ、CDN 機能を活用してウェブサイトのランタイムを大幅に書き換えた結果、Core Web Vitals のすべての指標で 75 パーセンタイル スコアが良好になった Wix サイトの割合は、前年比で 3 倍以上に増加しています。
Wix はパフォーマンス指向の文化を採用しており、さらなる改善がユーザーに展開される予定です。パフォーマンス KPI に重点を置くと、Core Web Vitals のしきい値を満たすサイトの数が増えると予想されます。
概要
パフォーマンスの世界は美しく複雑で、多くの可変要素や複雑さがあります。調査によると、サイトの速度はビジネスのコンバージョン率と収益に直接影響します。近年、業界ではパフォーマンスの可視性とウェブの高速化がより重視されています。2021 年 5 月より、ページ エクスペリエンスのシグナルが Google 検索のランキングに含まれるようになります。
Wix 独自の課題は、数百万のサイトをサポートすることです。その中には何年も前に構築され、それ以降更新されていないサイトもあります。Google では、ユーザーがサイトのパフォーマンスを分析して改善する方法について、さまざまなツールや記事を用意しています。
Wix はマネージド環境であり、すべてがユーザーが管理できるわけではありません。共通のインフラストラクチャを共有することは、これらすべてのサイトで多くの課題に直面しますが、同時に、スケール メリットの活用など、全体的に大幅な機能強化を行う機会も生まれます。
共通言語で会話する
パフォーマンスに関する主な問題の一つは、技術的パフォーマンスと認識されるパフォーマンスの両方を考慮しながら、ユーザー エクスペリエンスのさまざまな側面について話し合うための一般的な用語を見つけることです。組織内で明確に定義された共通の言語を使用することで、さまざまな技術的部分とトレードオフについて簡単に議論および分類し、パフォーマンス レポートを明確にすることができ、最初に改善に注力すべき側面を理解するのに大いに役立ちました。
Google は、ウェブに関する指標などの業界標準指標を含めるように、すべてのモニタリングと社内での議論を調整しました。これには次のような指標が含まれます。
サイトの複雑さとパフォーマンス スコア
HTML のみを使用して非常にシンプルにし、CDN 経由で提供できれば、瞬時に読み込まれるサイトを作成するのはとても簡単です。
しかし実際には、サイトはますます複雑で洗練され、ドキュメントではなくアプリケーションのように動作し、ブログ、e コマース ソリューション、カスタムコードなどの機能をサポートするようになっています。
Wix は非常に大規模なさまざまなテンプレートを提供しており、ユーザーは多くのビジネス機能を備えたサイトを簡単に構築できます。多くの場合、こうした追加機能にはパフォーマンス コストがかかります。
プロセス
当初は HTML があり
ウェブページが読み込まれるたびに、HTML ドキュメントを取得するために、常に URL への最初のリクエストが行われます。この HTML レスポンスにより、サイトを実行してレンダリングするための追加のクライアント リクエストとブラウザ ロジックがすべてトリガーされます。レスポンスの先頭が到着するまで何も起こらないため、これはページの読み込みで最も重要な部分です（TTFB - 最初のバイトまでの時間）。
従来: クライアントサイド レンダリング（CSR）
大規模なシステムを運用する場合、パフォーマンス、信頼性、費用などのトレードオフが常に存在します。数年前まで、Wix はクライアントサイド レンダリング（CSR）を使用していました。実際の HTML コンテンツは、クライアント側（つまりブラウザ内）の JavaScript によって生成されるため、バックエンドの運用に多額の費用をかけることなく、大規模なサイトに対応できるようになりました。
CSR のおかげで、本質的に空の共通 HTML ドキュメントを使用できるようになりました。必要なコードとデータのダウンロードがトリガーされ、それを使用してクライアント デバイスで完全な HTML が生成されます。
現在: サーバーサイド レンダリング（SSR）
Google は数年前にサーバーサイド レンダリング（SSR）に移行しました。これは SEO にもパフォーマンスにもメリットをもたらし、JavaScript の実行を全面的にサポートしていない検索エンジンでは、最初のページの表示時間が短縮され、インデックス登録が改善されました。
このアプローチにより、特に低速のデバイスや接続での可視性が向上し、さらなるパフォーマンス最適化への扉が開かれました。ただし、ウェブページ リクエストごとに固有の HTML レスポンスが即座に生成されることになるため、特に閲覧回数の多いサイトの場合、最適とはかけ離れてなります。
複数ロケーションでのキャッシュ保存の導入
各サイトの HTML はほとんどが静的ですが、いくつか注意点がありました。
- 頻繁に変わります。ユーザーがサイトを編集するたび、またはサイトデータ（ウェブサイトの店舗の在庫など）を変更するたび。
- サイト訪問者にはユーザー固有の特定のデータと Cookie が含まれていました。つまり、2 人のユーザーが同じサイトを訪問しても、若干異なる HTML が表示されていました。たとえば、訪問者がカートに入れた商品を記憶する、訪問者が以前にビジネスとチャットを開始した、といったプロダクトの機能をサポートします。
- すべてのページがキャッシュに保存できるわけではありません。たとえば、カスタム ユーザーコードが含まれていて、ドキュメントの一部として現在の時刻を表示するページは、キャッシュの対象になりません。
当初は、ユーザー データなしで HTML をキャッシュするという比較的安全なアプローチを採用し、その後、キャッシュ ヒットごとに各訪問者の HTML レスポンスの特定の部分だけをその場で変更しました。
社内 CDN ソリューション
そのために社内ソリューションをデプロイしました。プロキシとキャッシュには Varnish HTTP Cache、無効化メッセージには Kafka、これらの HTML レスポンスをプロキシする Scala/Netty ベースのサービスを使用し、HTML を変換して、キャッシュされたレスポンスに訪問者固有のデータと Cookie を追加します。
このソリューションにより、これらのスリムなコンポーネントを、世界中に散らばる多くの地理的なロケーションと複数のクラウド プロバイダのリージョンにデプロイできるようになりました。2019 年には、15 を超える新しいリージョンを導入し、キャッシュの対象となったページビューの 90% 以上でキャッシュを徐々に有効にしました。複数の場所からサイトにサービスを提供することで、コンテンツをウェブサイトの訪問者の近くに配置できるため、HTML レスポンスを配信するクライアントとサーバー間のネットワーク レイテンシが短縮されます。
また、同じソリューションを使用して、特定の読み取り専用 API レスポンスのキャッシュ保存を開始し、サイト コンテンツが変更された場合はキャッシュを無効にしました。たとえば、サイト上のブログ投稿のリストは、投稿が公開または変更されたときにキャッシュされ、無効化されます。
複雑さの軽減
キャッシュの実装により、主に TTFB フェーズと FCP フェーズでパフォーマンスが大幅に向上しました。また、エンドユーザーに近い場所からコンテンツを提供することで信頼性が向上しました。
しかし、レスポンスごとに HTML を変更する必要があったため、不必要に複雑になり、削除すればパフォーマンスがさらに向上する可能性があります。
ブラウザのキャッシュ保存（および CDN の準備）
約 13%
HTML リクエストがブラウザ キャッシュから直接提供されるため、帯域幅を大幅に節約でき、繰り返し表示する場合の読み込み時間を短縮できます。
次のステップでは、この訪問者固有のデータを HTML から完全に削除し、HTML が到着した後に、この目的でクライアントによって呼び出される別のエンドポイントから取得します。
このデータと Cookie を慎重に新しいエンドポイントに移行しました。エンドポイントはページが読み込まれるたびに呼び出されますが、ハイドレーション プロセスで完全なページ インタラクティビティを実現する場合にのみ必要なスリムな JSON を返します。
これにより、ブラウザで HTML をキャッシュできるようになりました。つまり、ブラウザはリピート アクセス用に HTML レスポンスを保存し、コンテンツが変更されていないか検証するためにのみサーバーを呼び出します。これには HTTP ETag を使用します。これは基本的に、HTML リソースの特定のバージョンに割り当てられた識別子です。内容が同じである場合は、304 Not Modified レスポンスが本文なしでサーバーからクライアントに送信されます。
また、この変更により、Google の HTML はユーザー固有のものではなくなり、Cookie が含まれなくなりました。つまり、基本的には任意の場所にキャッシュできるため、世界中の何百ものロケーションで非常に優れた位置情報を提供する CDN プロバイダを利用できるようになるのです。
DNS、SSL、HTTP/2
キャッシュ保存を有効にすると、待ち時間が短縮され、初期接続のその他の重要な部分が大幅に増えました。ネットワーキング インフラストラクチャとモニタリングを強化することで、DNS、接続、SSL 時間を改善できました。
すべてのユーザー ドメインで HTTP/2 が有効になり、必要な接続量と新しい接続ごとに発生するオーバーヘッドの両方が削減されました。これは、HTTP/2 がもたらすパフォーマンスと復元力のメリットを活用しながら、デプロイが比較的簡単な変更でした。
Brotli 圧縮（gzip との比較）
21 ～ 25%
ファイル転送サイズの中央値の削減
これまで、すべてのファイルは gzip 圧縮を使用して圧縮されていました。gzip 圧縮は、ウェブ上で最も普及している HTML 圧縮オプションです。この圧縮プロトコルは 30 年ほど前に実装されました。
新しい Brotli 圧縮では、ほとんどトレードオフなしで圧縮が改善されており、毎年恒例のウェブ アルマナックの圧縮の章で説明されているように、徐々に人気が高まっています。しばらく前から、すべての主要なブラウザでサポートされています。
エッジにある nginx プロキシで Brotli をサポートするすべてのクライアントに対して、Brotli サポートを有効にしました。
Brotli 圧縮に移行することで、ファイル転送サイズの中央値が 21% から 25% 減少し、帯域幅の使用量が減少し、読み込み時間が改善されました。
コンテンツ配信ネットワーク（CDN）
動的 CDN 選択
Wix は常に CDN を使用して、ユーザーのウェブサイトで JavaScript のコードと画像の配信を行ってきました。
最近、Google は DNS プロバイダによるソリューションを統合し、クライアントのネットワークと送信元に応じてパフォーマンスが最も高い CDN を自動的に選択しました。これにより、各訪問者に最適な場所から静的ファイルを提供し、特定の CDN での可用性の問題を回避できます。
近日提供予定...CDN によって配信されるユーザー ドメイン
パズルの最後のピースは、最後の最も重要な部分である CDN を介して、ユーザー ドメインの HTML を提供します。
前述のように、Google はサイト固有の HTML と API の結果をキャッシュに保存して提供する独自の社内ソリューションを開発しました。非常に多くの新しいリージョンでこのソリューションを維持するには運用コストもかかります。新しいロケーションの追加は、Google が管理と継続的な最適化が必要なプロセスになります。
現在、Google はさまざまな CDN プロバイダと統合し、CDN ロケーションから Wix サイト全体に直接サービスを提供することで、世界中に分散するサーバーの配信を改善し、レスポンス時間をさらに改善しています。Google が処理するドメインは数多く、エッジで SSL 終端が必要になるため、これは課題です。
CDN との統合により、Wix ウェブサイトはこれまで以上に顧客との距離が縮まり、HTTP/3 などの新しいテクノロジーなど、追加作業なしで読み込みエクスペリエンスが改善されます。
パフォーマンス モニタリングについて
Wix サイトを運営している場合は、これが Wix サイトのパフォーマンス結果にどのように解釈されるか、他のウェブサイト プラットフォームと Google がどのように比較されるかを気になっているでしょう。
上で行った作業のほとんどは過去 1 年間にデプロイされており、一部は引き続きロールアウトされています。
HTTPArchive のウェブ アルマナックは最近 2020 年版を公開しました。これには CMS ユーザー エクスペリエンスに関する優れた章が含まれています。この記事で説明する数字の多くは、2020 年半ばのものです。
2021 年に更新されたレポートを楽しみにしています。また、Google のサイトの CrUX レポートと内部のパフォーマンス指標を積極的にモニタリングしています。
Google は、読み込み時間を継続的に改善し、パフォーマンスを損なうことなく、思いどおりにサイトを構築できるプラットフォームをユーザーに提供できるよう取り組んでいます。
DebugBear は最近、興味深いウェブサイト作成ツールのパフォーマンス レビューをリリースしました。このレビューでは、前述の領域について触れ、各プラットフォーム上に構築された非常にシンプルなサイトのパフォーマンスを検証しています。このサイトは約 2 年前に構築され、それ以降変更されていませんが、プラットフォームは継続的に改善され、それに伴うサイトのパフォーマンスは過去 1 年半のデータを表示することで確認できます。
おわりに
この経験が、組織にパフォーマンス重視の文化を取り入れるきっかけになれば幸いです。また、上記の詳細情報が皆様のプラットフォームやサイトに役立つことを願っています。
まとめます。
- 業界で認められているツールを使用して、一貫して追跡できる一連の指標を選択します。ウェブに関する主な指標をおすすめします。
- ブラウザ キャッシュと CDN を活用します。
- HTTP/2（可能であれば HTTP/3）に移行します。
- Brotli 圧縮を使用する。
ストーリーを学んでいただき、ありがとうございました。ぜひ、Twitter と GitHub で質問したり、アイデアを共有したり、お気に入りのチャンネルでウェブ パフォーマンスに関する会話に参加したりしてください。