数百万ものサイトのウェブサイトの読み込みパフォーマンスを改善し、PageSpeed Insights と Core Web Vitals のスコアを高めるために Wix で導入された主な変更に関する事例研究。
業界標準、クラウド プロバイダ、CDN の機能を活用し、ウェブサイトのランタイムを大幅に書き換えた結果、CrUX と HTTPArchive のデータによると、すべての Core Web Vitals 指標で良好な 75 パーセンタイル スコアに達する Wix サイトの割合が前年比で3 倍以上に増加しました。
Wix はパフォーマンス重視の文化を採用しており、今後もユーザー向けの改善を継続的に実施していきます。パフォーマンスの KPI に重点を置くにつれて、Core Web Vitals のしきい値を満たすサイトの数は増加すると予想されます。
概要
パフォーマンスの世界は美しく複雑で、多くの変数と複雑な要素があります。調査によると、サイトの速度はコンバージョン率と収益に直接影響します。近年、業界ではパフォーマンスの可視化とウェブの高速化に重点が置かれています。2021 年 5 月より、Google 検索のランキングにページ エクスペリエンス シグナルが含まれるようになります。
Wix の独自の課題は、数百万ものサイトをサポートすることです。これらのサイトの一部は何年も前に作成され、それ以降更新されていません。サイトのパフォーマンスを分析して改善するための方法については、さまざまなツールと記事をご利用いただけます。
Wix は管理対象の環境であり、すべてをユーザーが管理できるわけではありません。共通のインフラストラクチャを共有することは、これらのすべてのサイトにとって多くの課題を提示しますが、規模の経済を活用して全体的に大幅な改善を図る機会も開きます。
共通言語で話す
パフォーマンスに関する主な課題の一つは、技術的なパフォーマンスとユーザーが認識するパフォーマンスの両方を考慮しながら、ユーザー エクスペリエンスのさまざまな側面について議論するための共通の用語を見つけることです。組織内で明確で共通の言語を使用することで、さまざまな技術的な部分とトレードオフを簡単に議論して分類し、パフォーマンス レポートを明確にできました。また、最初に改善すべき点を把握するのに非常に役立ちました。
すべてのモニタリングと社内ディスカッションを調整し、ウェブバイタルズなどの業界標準の指標（以下を含む）を追加しました。
サイトの複雑さとパフォーマンスのスコア
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 リソースに割り当てられた識別子です。コンテンツが同じである場合、Google のサーバーからクライアントに 304 Not Modified レスポンスが本文なしで送信されます。
また、この変更により、HTML は訪問者固有のものではなくなり、Cookie が含まれなくなります。つまり、基本的にはどこでもキャッシュに保存できるため、世界中の何百ものロケーションに優れた地理的プレゼンスを持つ CDN プロバイダを使用できます。
DNS、SSL、HTTP/2
キャッシュを有効にすると、待ち時間が短縮され、最初の接続の他の重要な部分がより重要になりました。ネットワーク インフラストラクチャとモニタリングを強化することで、DNS、接続、SSL の時間を短縮できました。
すべてのユーザー ドメインで HTTP/2 が有効になり、必要な接続数と、新しい接続ごとに発生するオーバーヘッドの両方が削減されました。これは、HTTP/2 に付随するパフォーマンスと復元力のメリットを活用しながら、比較的簡単にデプロイできる変更でした。
Brotli 圧縮（gzip と比較）
21 ～ 25%
ファイル転送サイズの中央値の削減
従来、すべてのファイルは gzip 圧縮を使用して圧縮されていました。これは、ウェブ上で最も一般的な HTML 圧縮オプションです。この圧縮プロトコルは、ほぼ 30 年前に最初に実装されました。
新しい Brotli 圧縮は、トレードオフをほとんど発生させることなく圧縮を改善し、年次ウェブ アルマナックの圧縮に関する章で説明されているように、徐々に普及しつつあります。すでにすべての主要ブラウザでサポートされています。
エッジの nginx プロキシで、Brotli をサポートするすべてのクライアントに対して Brotli のサポートを有効にしました。
Brotli 圧縮の使用に移行したことで、ファイル転送サイズの中央値が 21% ～ 25% 減少し、帯域幅の使用量が削減され、読み込み時間が短縮されました。
コンテンツ配信ネットワーク（CDN）
動的 CDN 選択
Wix では、ユーザーのウェブサイト上のすべての JavaScript コードと画像を配信するために、常に CDN を使用してきました。
最近、DNS プロバイダのソリューションと統合し、クライアントのネットワークとオリジンに応じてパフォーマンスが最も優れた CDN を自動的に選択できるようになりました。これにより、各訪問者にとって最適なロケーションから静的ファイルを提供でき、特定の CDN での可用性の問題を回避できます。
近日提供予定... CDN によって配信されるユーザー ドメイン
パズルの最後のピースは、CDN を介して最後の最も重要な部分（ユーザー ドメインの HTML）を提供することです。
前述のように、サイト固有の HTML と API の結果をキャッシュして提供する独自の社内ソリューションを作成しました。多くの新しいリージョンでこのソリューションを維持するには運用コストも発生します。また、新しいロケーションを追加するには、管理と継続的な最適化が必要になります。
現在、Wix はさまざまな CDN プロバイダと統合し、CDN ロケーションから Wix サイト全体を直接配信できるようにしています。これにより、世界中のサーバーの分散が改善され、応答時間がさらに短縮されます。これは、エッジでの SSL 終端を必要とする大量のドメインを処理する必要があるため、課題となっています。
CDN と統合することで、Wix ウェブサイトはこれまで以上にユーザーに近づき、HTTP/3 などの新しいテクノロジーを含む読み込みエクスペリエンスがさらに改善されます。
パフォーマンス モニタリングについて
Wix サイトを運営している場合は、このことが Wix サイトのパフォーマンス結果にどのように反映されるのか、また他のウェブサイト プラットフォームと比較してどうなのか気になることでしょう。
上記の作業のほとんどは過去 1 年間にデプロイされており、一部はまだロールアウト中です。
HTTPArchive のウェブ年鑑の2020 年版が最近公開されました。この年鑑には、CMS のユーザー エクスペリエンスに関する優れた章が含まれています。この記事で説明する数値の多くは 2020 年半ばのものであることをご承知おきください。
2021 年に更新されたレポートを楽しみにしています。Google は、サイトの CrUX レポートと内部パフォーマンス指標を積極的にモニタリングしています。
Google は、読み込み時間を継続的に改善し、パフォーマンスを損なうことなく、ユーザーが思い描くサイトを構築できるプラットフォームを提供することに取り組んでいます。
DebugBear は最近、非常に興味深いウェブサイト ビルダーのパフォーマンス レビューを公開しました。このレビューでは、上記のいくつかの領域に触れ、各プラットフォームで構築された非常にシンプルなサイトのパフォーマンスを検証しています。このサイトはほぼ 2 年前に作成され、それ以降変更されていません。しかし、プラットフォームは継続的に改善されており、サイトのパフォーマンスも向上しています。これは、過去 1 年半のデータを表示することで確認できます。
まとめ
Google の経験が、組織でパフォーマンス指向の文化を採用するきっかけとなり、上記の詳細が貴社のプラットフォームやサイトに役立つことを願っております。
まとめます。
- 業界で認められているツールを使用して一貫して追跡できる指標のセットを選択します。ウェブに関する主な指標をおすすめします。
- ブラウザ キャッシュと CDN を利用する。
- HTTP/2（可能であれば HTTP/3）に移行します。
- Brotli 圧縮を使用する。
ここまでお読みいただきありがとうございました。Twitter や GitHub で質問やアイデアを共有したり、お気に入りのチャンネルでウェブ パフォーマンスに関する会話に参加したりしてください。