サードパーティのリソース(埋め込み、スクリプトなど)は現在、ウェブ全体で多用されています。ソーシャル メディア、動画、アナリティクス、チャット、広告、A/B テスト、パーソナライズなどを埋め込むために、すぐに使えるソリューションを提供しています。サードパーティ埋め込みは、最新のウェブサイトに不可欠な要素です。これにより、サイト所有者は中核的な能力に集中でき、標準ではあるものの重要な機能を外部のプロバイダに任せることができます。
ウェブページ上でファースト パーティとサードパーティの両方が調和していれば、ページで優れたユーザー エクスペリエンスを提供することが可能です。しかし、これにはエンジニアリング チームとビジネスチームの両方による多大な労力が必要で、見落とされがちです。その結果、ウェブページのパフォーマンスが低下し、Core Web Vitals などのユーザー中心の指標に悪影響がもたらされます。これは双方に悪影響を及ぼし、ビジネスにおける機会損失を生み出します。改善すべき点はありますか?
Google は、将来のウェブのビジョンとして、サードパーティのスクリプトやリソースが、ブラウザで使用するウェブサイトのパフォーマンスやユーザー エクスペリエンスの低下を最小限に抑えながら、意図したビジネス価値を提供するというビジョンを持っています。これにより、ページの読み込みが速くなることが理想的です。
Google はこの 1 年間、サードパーティ スクリプトがもたらす悪影響からユーザー エクスペリエンスを保護できる可能性があるものの、サイト所有者にとってのビジネス価値を損なうことなく、さまざまな可能性を検討、検討、テストしてきました。
この投稿では、Google が実施したテストに関する情報の一部をご紹介します。Google は、ユーザー エージェント、企業、サードパーティ プロバイダ間の透明性と可視性を促進し、ウェブの高速化への道を開くプロセスの始まりとなることを願っています。
サードパーティについて詳しく知る
サードパーティは、サイトの外部にあるプロバイダによって提供されるリソースです。サイト所有者の管理下には置かれませんが、サイト所有者の承認を得ます。サードパーティ リソースは次のとおりです。
- プライマリ サイトのオリジンとは異なる共有オリジンまたは公開オリジンでホストされている。
- 個々のサイト所有者によるものでも、影響を受けたものでもない。
- さまざまなサイトで幅広く使用されている。
広告による収益の創出から、優れたマーケティングの機会の提供(ソーシャル メディアの埋め込み)まで、サードパーティはさまざまなビジネス目標に対応しています。サードパーティの一般的なカテゴリは次のとおりです。
出典: サードパーティ(カテゴリ別)
カテゴリ | 定義 |
---|---|
広告 | 広告の配信や広告パフォーマンスの測定に使用するスクリプト。 |
動画 | 動画プレーヤーとストリーミング機能を有効にするスクリプト |
ホストされているライブラリ | 一般公開されているオープンソース ライブラリの組み合わせ。 |
Content | コンテンツ プロバイダからのスクリプト、またはパブリッシャー固有のアフィリエイト トラッキング。 |
カスタマー サクセス | チャットや問い合わせのソリューションを提供しているカスタマー サポート/マーケティング プロバイダからのスクリプト。 |
ホスティング | ウェブ ホスティング プラットフォームのスクリプト。 |
マーケティング | ポップアップやニュースレターなどを追加するマーケティング ツールのスクリプト。 |
ソーシャル | ソーシャル機能を有効にするスクリプト |
タグ マネージャー | 他の多くのスクリプトを読み込み、多くのタスクを開始するスクリプト。 |
分析 | ユーザーとその操作を測定または追跡するスクリプト。 |
Cookie 使用の同意プラットフォーム | サイトが情報に基づいた透明性の高い方法でユーザーの同意(GDPR、ePR、CCPA)を取得できるようにするスクリプト。 |
ユーティリティ | デベロッパー向けユーティリティであるスクリプト(API クライアント、サイト モニタリング、不正行為の検出など)。 |
Other | その他のスクリプトは、正確なカテゴリやアトリビューションのない共有オリジンを介して配信されます。 |
これらのサードパーティのスクリプトやライブラリを利用することで、ウェブ デベロッパーは、一から一から作り直すのではなく、実証済みのソリューションを活用して標準機能を実装できます。したがって、サードパーティは開発時間を短縮し、企業が製品をより迅速にリリースまたはアップグレードできるよう支援します。パソコンとモバイルのウェブサイトの 94% 以上がサードパーティを使用しているのも無理はありません。
サードパーティがパフォーマンスに与える影響
サードパーティのデベロッパーが、そのサードパーティが提供する特定の機能に関する対象分野のエキスパートであることが理想的です。人気の高いサードパーティは、すでに何回か反復処理を行っており、自社のビジネス目標に合わせてコードが最適化されることが期待できます。これには、そのサードパーティを使用するページのパフォーマンスが反映される場合と含まれない場合があります。ただし、十分に最適化されたサードパーティでも、パフォーマンスに影響を及ぼします。この変更が生じる主な理由は次のとおりです。
サイズとスクリプトの実行コスト: サードパーティは多くの場合、
<script>
要素または<iframe>
要素をページに挿入することで「だけ」重要な機能を提供しようとします。これらの要素は、サイズが非常に大きく、ダウンロードと実行に時間がかかるスクリプトとリソースを取り込みます。JavaScript が多すぎると、メインスレッドのビジー状態が長くなり、レンダリングがブロックされ、ユーザー操作が遅延します。一部の上位のサードパーティは、分析したサイトの 50% 以上でメインスレッドを 42 ミリ秒から 1.6 秒までブロックしていることがわかっています。メインスレッドがブロックされると、Total Blocking Time(TBT)が長くなります。これは、サイトのパフォーマンス スコアに影響する指標の 1 つです。さらに、ユーザー操作へのレスポンスが遅延し、ウェブサイトの応答性を測定するために使用される Interaction to Next Paint(INP)指標も低下します。そのため、スクリプトの実行コストはパフォーマンスに大きく影響します。数字: ウェブサイトは平均して、モバイルとウェブで約 21 のサードパーティを利用しています。第三者タグは多くの場合、技術チームや開発チームが直接管理していないタグ管理ツールによって追加されます。必要のないタグは、審査プロセスなしで他のチームによって追加されることがあり、削除されることはありません。これらは、ユーザー エクスペリエンス、ページのデータ量、CPU 使用率に大きな影響を与える可能性があります。ガバナンス プロセスを確立することで、このような状況に対処し、デベロッパーが各プロバイダの影響を監査できるようになります。パフォーマンスへの影響、メリット、トレードオフを比較するための特定の機能を提供するすべてのサードパーティ向けに、デベロッパーがいつでも利用可能なデータを用意できれば便利です。チームが直面するもう一つの課題は、多くのサイトでは、サードパーティ タグは本番環境でのみ実行され、開発環境では実行されないため、開発者がテストするのが難しいということです。
ネットワーク: サードパーティはホストされるオリジンが異なるため、ブラウザがコンテンツをダウンロードするには、より多くの接続を行う必要があります。それぞれの接続が優先度に基づいてダウンロードを調整できなくなり、ネットワーク競合が発生します。適切な最適化が行われないと、ページの読み込みがさらに遅れる可能性があります。
シーケンシング: サードパーティがメインスレッドをブロックし、より重要なリソースの帯域幅を奪い合う可能性があります。とはいえ、場合によっては、ページのレンダリングにサードパーティが重要なリソースになることもあります。ウェブサイトで複数のサードパーティを使用する場合は、ファースト パーティ リソースとサードパーティ リソースの最適な順序付けが必要になります。ウェブ デベロッパーには、配列の最適化に使用できるさまざまな方法を知っておく必要があります。
上記の結果として、サードパーティが Core Web Vitals の一部またはすべてのコンポーネントに影響を与える可能性があります。大半のサードパーティは、Largest Contentful Paint(LCP)と First Input Delay(FID)に悪影響を与えています。YouTube の埋め込みがメインスレッドをブロックしているのは、モバイル ウェブサイトの 10% で 4.5 秒、調査したウェブサイトの 50% で少なくとも 1.6 秒です。低速な接続で、このようなスクリプトが 20 個あるページにアクセスしたユーザーが、不満を抱いているとします。thirdpartyweb.today の以下の可視化では、現時点でパフォーマンスへの影響が最も大きいサードパーティが示されています。
「上位 400 万のサイトのうち、約 2, 700 のオリジンがスクリプト実行時間全体の約 57% を占め、上位 50 のエンティティはすでに約 47% を占めています」- サードパーティ ウェブ
Core Web Vitals で測定されるとおり、高速でレンダリングされ、妥当な期間内にインタラクティブになるページは、優れたユーザー エクスペリエンスに不可欠です。多くの場合、優れた UX はウェブサイトでの優れたビジネスにつながり、サードパーティを利用することも可能になります。連携してサードパーティの影響を軽減することは、チェーンのすべての関係者にとってメリットになります。
Google は、Google タグ マネージャー、YouTube 埋め込み、ReCaptcha など、一般的に使用される多数の第三者スクリプトを提供していることを認識しています。Google は、多くのスクリプトが Core Web Vitals に対するパフォーマンスへの影響を軽くする可能性があることを認識しており、今後もこの影響を可能な限り改善する方法を模索していきます。
Chrome はどのように役立ちますか。
サードパーティのリソースのパフォーマンスが低いことは、デベロッパーにとって一般的に課題であり、基盤となるエコシステムのダイナミクスに大幅な変革が必要になります。Chrome は、次のような成果を達成するためにこの領域を探求しています。
ユーザー エクスペリエンスやビジネスの成果を損なうことなく、ウェブ上でサードパーティのリソースを読み込むためのより良い方法を見つけます。
Google は、パートナー、企業、サードパーティ、デベロッパーと協力しなければ、この取り組みを進めることができないことを理解しています。Google は、公開された説明や仕様を通じて可能性について議論し、アイデアを交換できるオープンな場を作りたいと考えています。開発者には、フィードバックを提供し、これらの提案の多くの影響をテストする時間があります。
サードパーティ スクリプトのユーザーが、ツールとフィールドの費用をより適切にアトリビューションできるようにし、使用のための明確でよく整備された道筋、作成時のインセンティブをデフォルトで最適化できるようにします。
Google は、ユーザー エージェント、フレームワーク、サードパーティ スクリプトなどのすべてのレイヤを強化して、サードパーティがパフォーマンスに及ぼす影響を軽減したいと考えています。また、サイト所有者が各スクリプトについてベスト プラクティス(可能な場合は代替のスクリプトなど)を実践できるよう、十分な分析情報の提供を予定しています。
提案されたアプローチ
これらの成果を達成するために Google は 3 本柱のアプローチを提案します...
**デベロッパーは、RUM や Chrome のデベロッパー ツールを使用して、サードパーティごとの影響に関するより深いアトリビューションを提供できます。**
RUM は、ウェブ パフォーマンス モニタリング API を通じて利用可能な実際のユーザーに関する指標データ(フィールド データとも呼ばれます)です。Chrome のデベロッパー ツールには、Lighthouse、Chrome DevTools、Chrome ユーザー エクスペリエンス レポートなどがあります。Google は、利用可能な API とツールを強化し、サイト デベロッパーがあらゆるページで利用しているあらゆるサードパーティの影響を把握できるようにすることを提案します。このツールは、影響を軽減するために実施できるアクション(その影響を先送りする、ファサードを使用するなど)についても学習し、トレードオフを伴って他の潜在的なソリューション(他のサードパーティや DIY)を探求します。ウェブ パフォーマンス モニタリング API については、ユーザーのプライバシーとセキュリティを損なうことなくクロスオリジン リソースの適用範囲を拡大する方法を模索しています。
**サードパーティのリソースを効率的に読み込むための適切な道筋を企業に提供する。**
Google では、ユーザーの読み込みエクスペリエンスを向上させるために、ファーストパーティ リソースとサードパーティのリソースの読み込み方法のトレードオフをブラウザがよりインテリジェントに取り込めるよう、新しい標準を提案したいと考えています。後ほど、こうした提案のいくつかをご紹介します。たとえば、サードパーティの埋め込みをデフォルトで遅延読み込みしたり、ユーザーが最も関心を持つ初期コンテンツにとってそれほど重要ではないサードパーティのリソースに異なるリソース優先順位を適用したりするなどです。今回ご紹介したのは、Google がこの分野で評価しているアイデアのごく一部です。ウェブ パフォーマンスのエキスパートや、より広範なコミュニティと協力して、この取り組みを実現したいと考えています。
Google では、JavaScript フレームワークやコンテンツ マネジメント システム(CMS)についても同様に対処したいと考えております。Aurora や WordPress Performance Team などのプロジェクトから、読み込みに関する既知の問題を解決する組み込みデフォルトの重要性が学んできました。フレームワークと CMS に組み込まれたデフォルトが、明るい道を進む企業を導く。また、ユーザー エージェント(Chrome など)にとっても、ヒューリスティックを適用してページ読み込みと CWV を最適化するための手がかりとなります。このようなヒントは、ユーザー エージェントがページのライフサイクルで特定のサードパーティを読み込むタイミングや方法を決定する際に役立ちます。(たとえば、Next.js スクリプト コンポーネントには、ページがインタラクティブになった後にサードパーティのスクリプトを読み込むデフォルトの組み込みタイプがあります)。
**サードパーティにインセンティブを提供し、透明性を高める取り組みを通じてパフォーマンスへの影響を軽減できるようにする。**
サードパーティの開発者は現在のところ、自社のスクリプトがサイト全体に与える影響を把握するための情報を可視化できていません。Google は、この問題に対処し、これらのプロバイダが影響を分析して、同じ価値を提供する市場の他のプロダクトと比較するためのツールを提供する予定です。また、データを使用して影響の原因を診断できるように支援し、アップストリームでの影響を軽減できるようにしたいと考えています。成功するためには、Google が作成したものも含め、すべてのサードパーティを取り上げる必要があります。
チャレンジ
これほどの規模の取り組みには課題が伴います。考慮すべき主な課題は次のとおりです。
- サードパーティは、広告、アナリティクス、タグ管理、ユーティリティなど、さまざまな分野にまたがる問題です。分野ごとに固有の要件とトレードオフを考慮する必要があります。例:
- 広告の読み込みを最適化するかどうかの判断は、収益とユーザー エクスペリエンスのトレードオフによって決まります。早すぎると貴重なコンテンツをブロックし、遅すぎるとユーザーが目にする機会を失ってしまいます。
- アナリティクス スクリプトによってページのデータ量が増えますが、ユーザー アクションに関する貴重なデータをビジネスに提供します。
Google は、さまざまなカテゴリのサードパーティと提携し、関連するニュアンスを把握し、トレードオフを解決して、すべての関係者にとって有効なインセンティブを開発したいと考えています。YouTube の戦略を効果的に運用するには、あらゆる分野の企業と個別に協力する必要があります。これには、Google タグ マネージャー、Google 広告、YouTube などの内部パートナーも含まれます。
Google は、サイト デベロッパーとサードパーティ デベロッパーの両方に、より深いアトリビューションを提供したいと考えています。そのためには、影響の測定において最も関連性の高いデータを特定し、それを正確かつ詳細に関連付けて、正しい道筋を示すための意識的な取り組みが必要です。最終的には、特定のサードパーティが競合他社と比較してどのようなパフォーマンスを発揮するかの計算は、すべてのユーザーにとって透明性があるものでなければなりません。
Google では、Chrome を拡張して、ファースト パーティのリソースとサードパーティのリソースの読み込みの優先順位の適切なバランスを取るのに役立つ最適化を適用することを提案します。価値ある変更はすべてのブラウザで標準として利用可能になりますが、時間がかかります。たとえば、
<img>
要素と<iframe>
要素のloading
属性は Chrome/Edge では 2019 年から利用可能でしたが、Safari では 2022 年にしか利用できなくなりました。機能が標準化されるまで、サードパーティ リソースのユーザーは、他のブラウザにも最適化する必要があります。該当する場合は、ガイダンスでその旨を強調してサポートします。このプロジェクトを実行するには、パートナーやデベロッパーと協力して、特定の要件を理解するだけでなく、必要に応じて試験運用版のソリューションを大規模にテストし、フィードバックを提供し、イテレーションと改善を行います。テストと評価に合理的な期間を考慮して、変更を計画する必要があります。
初期標準提案
Google では初期テストを実施し、サードパーティの読み込み処理を最適化できる機能を開発しました。Google はこの結果に満足しており、現在、これらの機能のうち 2 つについて議論できると考えています。
LazyEmbeds
これまで Chrome では、ライトモードのユーザーのために、<img>
要素と <iframe>
要素が画面外に遅延読み込みされていました。この機能をすべてのユーザーに拡張すると、ユーザーがその近くでスクロールするまで、サードパーティの埋め込みであると判断された <iframe>
要素の読み込みを遅らせることができます。これにより、ページの他の部分の読み込み速度の向上、ウェブに関する主な指標の改善、メモリ使用量の削減、データの保存が可能になります。
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 の intent-to-experiment スレッドとテストの拡張機能をご覧ください。
ターゲットとするサードパーティのスロットリング
サードパーティのスクリプトは、多くの場合、包括的な監視プロセスなしでさまざまなチームによって追加されます。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 グループの投稿を参照してください。
Google は、この問題の分野をさらに探求し、学びについてコミュニティと交流できることを楽しみにしています。
Leena Sohoni-Kasture、Jeremy Wagner、Gilberto Cocchi、Kenji Baheux、Kuhei Ueno、Kentaro Hara、Alex N. Jose、Melissa Mitchell、Yoav Weiss、Shunya Shishido、Minoru Chikamune にフィードバックと貢献をしてもらいました。