現在、ウェブ全体でサードパーティのリソース（埋め込みやスクリプトなど）が大量に使用されています。ソーシャル メディア、動画、分析、チャット、広告、A/B テスト、パーソナライズなどを埋め込むための、すぐに使えるソリューションを提供しています。サードパーティの埋め込みは、サイト所有者がコアコンピテンシーに集中し、標準的でありながら重要な機能を外部プロバイダにオフロードできるようにする、最新のウェブサイトに不可欠な要素です。
ウェブページでファーストパーティとサードパーティの両方が連携して機能すると、優れたユーザー エクスペリエンスを提供できます。ただし、エンジニアリング チームとビジネス チームの両方から多大な労力が必要であり、見落とされがちです。その結果、ウェブページのパフォーマンスが低下し、Core Web Vitals などのユーザー中心の指標に悪影響が及ぶ可能性があります。これは双方にとって有害であり、ビジネスの機会を逃すことになります。改善の余地はありますか？
Google は、サードパーティのスクリプトとリソースが、ブラウザでそれらを使用するウェブサイトのパフォーマンスやユーザー エクスペリエンスへの影響を最小限に抑えながら、意図したビジネス価値を提供できるウェブの未来を描いています。これにより、ユーザーはページの読み込みをより速く体験できるようになります。
Google は過去 1 年間、サイト所有者にとってのビジネス価値を損なうことなく、サードパーティ スクリプトの有害な影響からユーザー エクスペリエンスを保護できる可能性のある多くの方法を検討、議論、テストしてきました。
この投稿では、Google が実施している試験運用についてお知らせします。これは、ユーザー エージェント、企業、サードパーティ プロバイダ間の透明性と可視性を促進し、ウェブの高速化への道を切り開くプロセスの始まりとなることを願っています。
サードパーティについて詳しく
サードパーティとは、サイト外の提供元によって提供されるリソースです。サイト所有者が直接管理することはできませんが、サイト所有者の承認を得て表示されます。サードパーティ リソースは次のとおりです。
- プライマリ サイトのオリジンとは異なる共有のパブリック オリジンでホストされている。
- 個々のサイト所有者が作成したものではなく、その影響を受けていない。
- さまざまなサイトで広く使用されています。
サードパーティは、（広告による）収益の獲得から、（ソーシャル メディアの埋め込みによる）マーケティング機会の拡大まで、さまざまなビジネス目標を達成できるようサポートします。一般的なサードパーティのカテゴリには、次のようなものがあります。
ソース: カテゴリ別のサードパーティ。
| カテゴリ | 定義 |
|---|---|
| 広告 | 広告配信や広告パフォーマンスの測定に使用されるスクリプト。 |
| Video | 動画プレーヤーとストリーミング機能を有効にするスクリプト。 |
| ホストされているライブラリ | 一般公開されているオープンソース ライブラリの組み合わせ。 |
| コンテンツ | コンテンツ プロバイダのスクリプトや、パブリッシャー固有のアフィリエイト トラッキング。 |
| カスタマー サクセス | チャットと連絡先ソリューションを提供するカスタマー サポート/マーケティング プロバイダのスクリプト。 |
| ホスティング | ウェブ ホスティング プラットフォームのスクリプト。 |
| マーケティング | ポップアップやニュースレターを追加するマーケティング ツールのスクリプト。 |
| ソーシャル | ソーシャル機能を有効にするスクリプト。 |
| タグ マネージャー | 他の多くのスクリプトを読み込み、多くのタスクを開始するスクリプト。 |
| アナリティクス | ユーザーとそのアクションを測定またはトラッキングするスクリプト。 |
| Cookie 使用の同意プラットフォーム | サイトがユーザーの同意（GDPR、ePR、CCPA）を十分な情報提供と透明性のある方法で取得できるようにするスクリプト。 |
| ユーティリティ | デベロッパー ユーティリティのスクリプト（API クライアント、サイト モニタリング、不正行為の検出など）。 |
| その他 | 正確なカテゴリやアトリビューションのない、共有オリジン経由で配信されるその他のスクリプト。 |
これらのサードパーティのスクリプトとライブラリを使用すると、ウェブ デベロッパーは、自力で開発するのではなく、十分な試行を重ねたソリューションを活用して標準機能を実装できます。サードパーティを利用することで、開発時間が短縮され、製品のリリースやアップグレードが迅速に行えます。そのため、デスクトップとモバイルのすべてのウェブサイトの 94% 以上がサードパーティを使用しています。
サードパーティがパフォーマンスに与える影響
理想的には、サードパーティのデベロッパーは、提供する特定の機能に関する専門家である必要があります。一般的なサードパーティの多くは、何度も改良を重ねており、コードは独自のビジネス目標に合わせて最適化されています。この目標には、サードパーティ コードを使用するページのパフォーマンスが含まれる場合と含まれない場合があります。ただし、最適化が非常に進んだサードパーティでもパフォーマンスに影響することはわかっています。この影響の主な理由は次のとおりです。
サイズとスクリプト実行コスト: サードパーティは、
<script>要素または<iframe>要素をページに配置するだけで、重要な機能を提供しようとする傾向があります。これらの要素は、サイズが大きく、ダウンロードと実行に時間のかかるスクリプトとリソースを取得します。JavaScript が多すぎると、メインスレッドが長時間ビジー状態になり、レンダリングがブロックされ、ユーザー操作が遅延します。分析したサイトの 50% 以上で、主要なサードパーティの一部がメインスレッドを 42 ミリ秒から 1.6 秒ブロックすることが知られています。メインスレッドがブロックされると、合計ブロック時間（TBT）が高くなります。これは、サイトのパフォーマンス スコアに影響する指標の一つです。また、ユーザー インタラクションへの応答が遅れ、ウェブサイトの応答性を測定するために使用される Interaction to Next Paint（INP）指標が低下します。したがって、スクリプトの実行コストはパフォーマンスに大きな影響を与えます。数: ウェブサイトは、モバイルとウェブで平均 21 個のサードパーティを使用しています。サードパーティ タグは、技術チームや開発チームが直接管理していないタグ管理ツールによって追加されることがよくあります。不要なタグは、審査プロセスなしで他のチームによって追加され、削除されることはありません。これらは、ユーザー エクスペリエンス、ページの重み、CPU 使用率に大きな影響を与える可能性があります。ガバナンス プロセスを確立することで、このような状況に対処し、各プロバイダの影響を監査できます。デベロッパーが、特定の機能を提供するすべてのサードパーティについて、パフォーマンスへの影響、メリット、トレードオフを比較できるデータがすぐに入手できると便利です。多くのサイトで、サードパーティ タグが本番環境でのみ実行され、開発環境では実行されないため、デベロッパーがテストするのが難しいという課題もあります。
ネットワーク: サードパーティは異なるオリジンでホストされているため、ブラウザはサードパーティからコンテンツをダウンロードするためにより多くの接続を行う必要があります。異なる接続が優先度に基づいてダウンロードを調整できないため、ネットワーク競合が発生します。適切な最適化が考慮されていない場合、ページの読み込みがさらに遅くなる可能性があります。
シーケンス: サードパーティがメインスレッドをブロックし、より重要なリソースの帯域幅を競合する可能性があります。ただし、サードパーティがページのレンダリングに必要な重要なリソースである場合もあります。ウェブサイトで複数のサードパーティを使用している場合は、ファーストパーティとサードパーティのリソースを最適な順序で配置する必要があります。ウェブ デベロッパーは、シーケンスの最適化に使用できるさまざまなオプションを把握しておく必要があります。
そのため、サードパーティは Core Web Vitals の一部またはすべてのコンポーネントに影響する可能性があります。サードパーティのほとんどは、Largest Contentful Paint（LCP）とFirst Input Delay（FID）に悪影響を及ぼします。モバイル ウェブサイトの 10% で、YouTube 埋め込みがメインスレッドをブロックし、調査対象のウェブサイトの 50% で 1.6 秒以上ブロックしています。接続速度が遅いときに、このようなスクリプトが 20 個も含まれているページにユーザーが遭遇したら、ユーザーは不満を抱くでしょう。thirdpartyweb.today の次の可視化は、現在パフォーマンスに最も影響を与えているサードパーティを示しています。
「上位 400 万サイトのうち、約 2, 700 のオリジンがすべてのスクリプト実行時間の約 57% を占めており、上位 50 のエンティティがすでに約 47% を占めています。」- third-party-web
ページが迅速にレンダリングされ、妥当な時間内にインタラクティブになるようにすることは、Core Web Vitals で測定される優れたユーザー エクスペリエンスに不可欠です。優れた UX は、多くの場合、ウェブサイトのビジネスの向上につながり、使用されているサードパーティのビジネスの向上にもつながります。サードパーティの影響を軽減するために協力することは、サプライ チェーン全体にとって有益です。
Google は、Google タグ マネージャー、YouTube 埋め込み、ReCaptcha など、一般に使用されているサードパーティ スクリプトを多数提供しています。Google は、Google の多くのスクリプトが Core Web Vitals のパフォーマンスに軽微な影響を与える可能性があること認識しており、可能な限りこの影響を改善する方法を模索しています。
Chrome はどのように役立ちますか？
サードパーティ リソースのパフォーマンスが低いことは、デベロッパーにとって常に課題であり、基盤となるエコシステムのダイナミクスを大きく変える必要があります。Chrome では、この分野を探求して、次の成果を達成したいと考えています。
ユーザー エクスペリエンスやビジネス成果を低下させずに、ウェブでサードパーティ リソースを読み込むより良い方法を見つける。
Google は、パートナー、企業、サードパーティ、デベロッパーとの連携なしに、この取り組みを大きく進めることはできないと認識しています。Google は、公開されている説明と仕様を通じて、可能性について議論し、アイデアを交換できるオープンな場を創出したいと考えています。デベロッパーは、これらの提案の多くについてフィードバックを送信し、影響を確認する時間があります。
サードパーティ スクリプトを使用するユーザーが、ツールとフィールドでの費用をより正確に割り当て、使用方法を明確に把握し、作成時にインセンティブを高めて、デフォルトで最適な状態を確保できるようにします。
Google は、ユーザー エージェント、フレームワーク、サードパーティ スクリプトなど、すべてのレイヤを強化して、サードパーティによるパフォーマンスへの影響を軽減したいと考えています。また、埋め込まれた各スクリプトに関するベスト プラクティスをサイト所有者が実践できるよう、十分な分析情報を提供することも予定しています。これには、該当する場合はより高速な代替手段も含まれます。
提案されたアプローチ
こうした成果を達成するための 3 つのアプローチを提案します。
**RUM と Chrome のデベロッパー ツールで、サードパーティの影響をより詳細に特定できるようにします。デベロッパー向けの機能です。**
RUM とは、ウェブ パフォーマンス モニタリング API で利用できるリアルユーザー指標データ（フィールド データ）を指します。Chrome のデベロッパー ツールには、Lighthouse、Chrome DevTools、Chrome ユーザー エクスペリエンス レポートがあります。利用可能な API とツールを強化し、サイト デベロッパーが使用しているすべてのサードパーティがすべてのページに与える影響を把握できるようにすることを提案します。また、影響の軽減に役立つアクション（延期やファサードの使用など）や、トレードオフのある他のソリューション（他のサードパーティや DIY）についても説明します。ウェブ パフォーマンス モニタリング API については、ユーザーのプライバシーとセキュリティを損なうことなく、クロスオリジン リソースの対象範囲を拡大する方法を検討しています。
**サードパーティ リソースを効率的に読み込むための明確なパスをビジネスに提供します。**
Google は、ユーザーの読み込みエクスペリエンスを向上させるため、ファーストパーティ リソースとサードパーティ リソースの読み込み方法のトレードオフをブラウザがよりインテリジェントに行うことを促す新しい標準を提案したいと考えています。後ほど、サードパーティの埋め込みをデフォルトで遅延読み込みする、ユーザーが最も関心を持つ最初のコンテンツにそれほど重要でないサードパーティ リソースに異なるリソースの優先順位を適用するなど、これらの提案の一部について説明します。これらは、この分野で検討しているアイデアのほんの一部にすぎません。ウェブ パフォーマンスの専門家と幅広いコミュニティの両方と連携して、この取り組みを形作っていきたいと考えています。
同様に、JavaScript フレームワークやコンテンツ管理システム（CMS）でも、適切な場合はこのような問題に対処したいと考えています。Aurora や WordPress Performance Team などのプロジェクトでは、既知の読み込みの問題を解決する組み込みのデフォルトの重要性が明らかになりました。フレームワークや CMS に組み込まれたデフォルトは、明るい道を照らし、ビジネスを導きます。また、ユーザー エージェント（Chrome など）にとってもヒントとして役立ち、ヒューリスティクスを適用してページの読み込みと CWV を最適化できます。このようなヒントは、ユーザー エージェントがページのライフサイクルで特定のサードパーティをいつ、どのように読み込むかを決定するのに役立ちます。（たとえば、Next.js スクリプト コンポーネントには、ページがインタラクティブになった後にサードパーティ スクリプトを読み込むデフォルトが組み込まれています）。
**サードパーティに、透明性を高めてパフォーマンスへの影響を軽減するためのインセンティブを提供します。**
現在、サードパーティ デベロッパーは、スクリプトがサイト全体に与える影響を把握するために必要な可視性がありません。Google は、この問題に対処し、プロバイダにツールを提供する予定です。このツールにより、プロバイダは影響力を分析し、同じ価値を提供する市場の他の製品と比較できます。また、このデータを使用して影響の原因を診断し、上流で軽減できるようにしたいと考えています。成功するには、Google が作成したサードパーティを含むすべてのサードパーティを呼び出す必要があります。
課題
このような大規模な取り組みには、課題が伴います。考慮すべき主な課題は次のとおりです。
- サードパーティは、広告、分析、タグ管理、ユーティリティなど、さまざまな問題に関連するクロスカットの問題です。各領域では、固有の要件とトレードオフを考慮する必要があります。例:
- 広告の読み込みを最適化するかどうかは、収益とユーザー エクスペリエンスのトレードオフによって決まります。早すぎると、価値の高いコンテンツがブロックされ、遅すぎるとユーザーがコンテンツを見逃します。
- アナリティクス スクリプトはページの重量を増やしますが、ユーザー アクションに関する貴重なデータをビジネスに提供します。
Google は、さまざまなカテゴリのサードパーティと提携し、関連するニュアンスを把握し、トレードオフを解決し、すべての人に役立つインセンティブを開発したいと考えています。Google は、戦略を効果的にするために、各地域の組織と個別に連携する必要があることを認識しています。これには、Google タグ マネージャー、Google 広告、YouTube などの内部パートナーが含まれます。
Google は、サイト デベロッパーとサードパーティ デベロッパーの両方に、より詳細なアトリビューションを提供したいと考えています。そのためには、影響の測定に最も関連性の高いデータを特定し、正確かつ詳細に帰属を特定し、適切な今後の道筋を提示する、慎重な取り組みが必要です。最終的には、特定のサードパーティが競合他社と比較してどの程度パフォーマンスを発揮しているかを、すべてのユーザーが明確に把握できるようにする必要があります。
Google は、ファーストパーティとサードパーティのリソースの読み込みの優先順位付けにおいて適切なバランスを保つ最適化を適用できるように Chrome を強化することを提案します。有益な変更は、すべてのブラウザで標準として利用可能になりますが、時間がかかります。たとえば、
<img>要素と<iframe>要素のloading属性は、2019 年から Chrome と Edge で使用可能でしたが、Safari では 2022 年になってから使用可能になりました。機能が標準化されるまで、サードパーティ リソースを使用するユーザーは、他のブラウザでも最適化されていることを確認する必要があります。関連する場合は、ガイダンスでこの点に重点を置いて説明します。このプロジェクトを実行するには、パートナーやデベロッパーと連携して、特定の要件を把握するだけでなく、試験運用版のソリューションを大規模にテストし、フィードバックを提供するとともに、必要に応じて反復処理と即興演奏を行う必要があります。変更は、テストと評価に十分な時間を確保できるように計画する必要があります。
初期標準案
Google は、サードパーティの読み込みプロセスを最適化するために有効にできる機能を開発するための初期テストを実施しました。テストの結果は良好で、現在、そのうちの 2 つの機能について説明できます。
LazyEmbeds
以前の Chrome では、Lite モードのユーザーに対して、画面外の <img> 要素と <iframe> 要素を遅延読み込みしていました。この機能はすべてのユーザーに拡張され、サードパーティの埋め込みと判断された <iframe> 要素の読み込みが、ユーザーがその要素の近くまでスクロールするまで遅らせられるようになります。これにより、ページの他の部分の読み込みが速くなり、Core Web Vitals が改善され、メモリ使用量が削減され、データが節約されます。
以下は、LazyEmbeds を使用してページに YouTube 動画を遅延読み込みするデモです。通常、1 つの YouTube 動画を埋め込むと、500 ～ 600 KB の JavaScript がページに追加されます。LazyEmbeds を使用して、このような動画埋め込みが 14 個あるブログ投稿を最適化しようとしました。ページの読み込み時間とデータの節約の両方で、有望な結果が得られました。
| 変更前 | 変更後 | |
|---|---|---|
| データ | 15.4 MB | 6.1 MB |
| Total Blocking Time | 3.2 秒 | 1.6 秒 |
この作業の詳細については、説明と blink-dev のテストに関するスレッドとテストの拡張をご覧ください。
ターゲット設定されたサードパーティのスロットリング
サードパーティ スクリプトは、包括的な監督プロセスなしでさまざまなチームによって追加されることがよくあります。The Telegraph のエンジニアリング チームは、「誰もが、組織に収益をもたらす「あのタグ」をページに配置したいと思っている」と述べています。これにより、パフォーマンスへの影響を管理する負担が継続的に増加する可能性があります。
ターゲット設定されたサードパーティ スクリプトのスロットリングでは、特定の種類のサードパーティをスロットリングして、その影響を軽減することを提案します。これにより、ブラウザは重要なコンテンツと重要なサードパーティを早期に読み込み、後で読み込んでも安全なサードパーティはスロットリングできます。
RUM API の強化
また、サードパーティのパフォーマンスの評価に関連する情報を含めるよう RUM API を拡張することも検討しています。主な機能強化は次のとおりです。
<iframe>レポート: クロスフレーム レポートに Performance Timeline API を活用できるソリューションの開発に取り組んでいます。これにより、最上位ページの作成者は、ページに埋め込まれた協力的なサードパーティ iframe のパフォーマンス データを検査できます。長時間のタスクの割り当て: RUM の Long Tasks API を使用すると、メインスレッドを長時間ブロックしてインタラクションを遅らせる長時間のタスクをサイト所有者が特定できます。
その他の最新情報
Google では、このようなアイデアをまだ数多くテストしており、今後、変更に関する GitHub の説明と仕様ドラフトを公開する予定です。Google と提携したり、フィードバックを送信したりしたいサードパーティやサイト所有者は、これらのチャンネルを通じて議論に参加できます。サードパーティは、Core Web Vitals と INP の指標を重視して最適化を進め、Core Web Vitals/INP のデータが低下しないようにすることもできます。現時点では、最新情報を積極的に確認したい場合は、blink-dev グループの投稿を参照してください。
YouTube は、この問題領域をさらに調査し、学んだことをコミュニティと共有することを楽しみにしています。
Leena Sohoni-Kasture 氏、Jeremy Wagner 氏、Gilberto Cocchi 氏、Kenji Baheux 氏、Kouhei Ueno 氏、Kentaro Hara 氏、Alex N. 氏に特に感謝いたします。Jose、Melissa Mitchell、Yoav Weiss、Shunyou Shishido、Minoru Chikamune のフィードバックと貢献に感謝します。