- 標準の YouTube `` 埋め込みは、空のページに1つ置いただけでも 32件のリクエスト、1.3MBの転送量が発生し、小さな動画UIに対して負担が大きい
- 複数の動画を並べるとリソースが共有されず、重さが 線形に増加 し、Zach Leatherman の計測では2件で2.4MB、3件で3.6MBまで増える
- 最初に見える機能はポスター画像、タイトル、大きな再生ボタン程度なので、`` のような Web Component で同じ体験をより軽く再現できる
lite-youtube-embed は約 100KB 規模で、複数の埋め込み間でリソースを共有し、機能を損なわずに速度と効率を改善する- YouTube埋め込みは広く使われているだけに、埋め込み1件あたりメガバイト単位のデータを削減することは、電力使用と 炭素排出 まで抑える実質的な最適化になる
標準 `` 埋め込みのコスト
- YouTube の共有メニューで
Embed を選ぶと、`` ベースの HTML が提供される
- 標準コードには
loading="lazy" がなく、画面外の動画も即座に読み込まれる可能性がある
- YouTube が標準 iframe に 遅延読み込み だけでも追加すれば、即効性のある性能改善が可能になる
- iframe をレスポンシブにし、元の比率を維持するには、CSS で YouTube embed iframe を直接指定できる
iframe[src^="https://www.youtube.com/embed/";] {
inline-size: 100%;
block-size: auto;
aspect-ratio: 16 / 9;
}
実測値と線形増加
- 空のページに YouTube 埋め込みを1つ入れただけでも、読み込みコストは大きい
-
32件のリクエスト
- 1.3MB のデータ転送
- 著者の Wi‑Fi 環境で 2.76秒 で読み込み
- Zach Leatherman は、埋め込みが増えるほどリソースが共有されず、重さが線形に増加すると記録している
- 埋め込み2件: 2.4MB
- 埋め込み3件: 3.6MB
- 現在は Zach が確認した時点よりもサイズがさらに増えているようだ
ユーザーが最初に見る UI はシンプル
- YouTube 埋め込みで、ユーザーが最初に目にする要素は限られている
- 動画の ポスター画像
- 動画 タイトル
- クリックで再生される大きな 再生ボタン
- この程度の UI と動作なら、YouTube プレイヤー全体のリソースを先に読み込まなくても実装できる
- 軽量な埋め込みがエンゲージメントを下げるという話は、方法論とデータが公開されない限り判断しにくい
- 過去に YouTube エンジニアがより軽い動画ページをテストした際、平均読み込み時間がかえって増えた事例もある
- より軽いページが、低性能デバイスや低速回線のユーザーにまで届くようになった
- 新たにアクセス可能になったユーザーの利用が、平均読み込み時間の指標を遅く見せた可能性がある
- 平均読み込み時間だけを見ると、ユーザーごとの実際の速度改善を見落としかねない
代替案: `` Web Component
- Google のパフォーマンス分野で知られる Paul Irish が作った lite-youtube-embed は、標準埋め込み体験をより軽く再現する Web Component である
- プロジェクトの説明では、実際の埋め込みのようにレンダリングしながら約 224倍高速 だと紹介している
- ユーザー体験は標準の YouTube 埋め込みとほぼ同じ
- ポスター画像を表示
- タイトルを表示
- 大きな再生ボタンを表示
- クリック時に動画を再生
- 違いはリソース使用量と共有方式にある
- 標準の YouTube 埋め込み: 約 1.3MB
- ``: 約 100KB
- 複数の埋め込み間でリソース共有が可能
- 機能を損なわずに、速度、効率、基本的なプライバシー保護を得られる
使い方と関連実装
- JavaScript で Web Component を登録したあと、`` 要素を使う方式である
- npm インストール、直接コピー、CDN リンクのいずれでも利用できる
import "https://esm.sh/lite-youtube-embed";;
- README の推奨方式は、まず HTML を置き、その後スクリプトを非同期で読み込んで プログレッシブエンハンスメント を適用する形である
- JavaScript が読み込まれる前でも正しく見えるよう、
background-image を HTML 内に入れられる
[Play Video: Keynote (Google I/O '18)](https://youtube.com/watch?v=ogfYd705cRs)
2件のコメント
lite-youtube-embed - より高速な YouTube 埋め込み
Hacker News の意見
コミュニティフォーラムのプラットフォームで YouTube 埋め込みを検出し、クリックされるまでは読み込まれないプロキシサムネイルに置き換えている
スレッド内の誰かが YouTube 動画を共有したからといって、そのページを開く全員が 1MB超の JavaScript をダウンロードし、Google に IP 追跡までされる必要はない
追跡はあまり気にしていないので、YouTube が提供するサムネイルをそのまま使っている
SoundCloud プレイヤーもものすごく重い
サムネイルをホットリンクすると、Google はそこでも追跡できる
筆者は、より軽いバージョンがエンゲージメントを下げるという証拠を信じていないと言っていたが、私は十分あり得ると思う
推奨されている lite-youtube-embed プロジェクトのデモにはライトプレイヤーと通常プレイヤーの両方があるが、ライト版は動画再生開始まで明らかに長くかかる
読み込み時間が1ミリ秒増えるごとにエンゲージメントは下がり、ここでは差が数百ミリ秒以上に見える
https://paulirish.github.io/lite-youtube-embed/
すべてのミリ秒が重要だという論理はウェブページにも当てはまる。ユーザーがページから離脱すれば、動画にたどり着くこともない
また、ユーザーが動画を見たくないというのも問題ない場合がある。個人的には、ウェブページに要約があれば動画を避けられるのでありがたい
YouTube のデスクトップ版刷新にも不満がある。見に来た動画そのものより、ほかの動画を宣伝するために画面を使いすぎている。邪魔な要素は少ない方がいい
信号で言えば、すべての信号が短く赤になるより、自分が近づいている信号が青である方がいい
大企業の実際の振る舞いを見ると、そうしたことを気にしていないのは明らかで、彼らにとって重要でないなら、私たちが代わりに最適化してやる理由もない
このユースケースでは大きな問題ではないが、スタックの残りの部分では性能を気にするべき
どうしてこんな後退が起きたのか分からないし、Google は問題なく動いていたものをどんどん壊しているように見える
環境によって変わり得る: Firefox、2年ほど前の i7-1185G7 ノートPC、Windows 11、32ビットモードの Edge が継続的に更新中で、数週間再起動していない状態
遅いという印象を与えているのは、回転するローディング表示の影響が大きい。自分で遅いと宣伝しているようなものだ
クリック後に再生されるまでの遅延は影響するだろうが、その程度をきちんと測定するには YouTube ほどの規模の主体が必要だ
より軽い埋め込みがエンゲージメントを下げるという噂と、提案されている lite-youtube-embed について、ユーザーはプレイヤーの見た目や動作が少し違うだけでも、見慣れず信用できないものとして受け取る可能性がある
デモの lite-youtube-embed はタイトルが表示されても実際の YouTube ページへ移動するリンクがなく、元の「コンテンツ」に行けないように妨げているような敵対的な印象すら与える
もちろんその機能は簡単に追加できるだろうが、より大きな問題を示している
私は埋め込み動画をほとんど再生しないが、再生するなら普通の YouTube 体験で十分だ。さらに別の得体の知れないレイヤーで包まれていると、クリックする可能性は下がる
この記事の「犠牲になるものはない」という表現は、開発者がユーザーのソフトウェアの使い方を分かっていると勘違いしている例だ。実際には常に推測にすぎない
動画が減り、あらゆる場所での Google 依存と JavaScript の塊が減ることを願う。より良いウェブのために、YouTube 動画をどこにでも埋め込まないでほしい
https://paulirish.github.io/lite-youtube-embed/
今は分かったので、こうしたライトプレイヤーにもそのボタンがあるといい。それでもこの実装は、リンクを取得する簡単な方法を完全に塞いでいるわけではない
動画を再生すればアクセスはできるが、それでは目的に反する。動画を再生したいわけではないし、読み込まれるまで待って一時停止してから保存ボタンを押したいわけでもない
あとはブロガーたちに GitHub Gist 埋め込みを使わせないようにするだけでよい
Hugoと、おそらく他の静的サイトジェネレーターは、シンタックスハイライト付きのコード片を標準でサポートしているし、より動的なサイトでも highlight.js を使えばサードパーティサービスへの依存をなくせる
小さなコード片に重い iframe を使うのは本当に奇妙
https://gohugo.io/content-management/syntax-highlighting/
https://highlightjs.org
自分の気に入らなくても、自分の好みに合わせてサイト変更を「強制」するのは筋が通らない
数週間以内に修正されたが、その状態が何年も続いていたことに驚いた
ページで Content Security Policyを活用できるなら、広告をブロックして埋め込み全体の重さを減らし、ユーザー体験も改善できる
関連情報: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
Content-Security-Policyに unsafe-inlineをうっかり入れないほうがよいCSPのインジェクション攻撃防御を無効にしてしまうから。どうしても必要なら、インラインスクリプトを許可するより安全な方法がある
https://content-security-policy.com/
「より軽い埋め込みがエンゲージメントを下げた」という話には、大きな部分が抜けているように思う
当然、ロード時間が速くなればエンゲージメントは良くなるはず。なのに軽い埋め込みでエンゲージメントが落ちたなら、何らかの機能や挙動が犠牲になったということ
ところがこの記事は 犠牲になったものはないと言っているので、話のどこかが抜けている
ここでも似たことが起きている可能性がある。より軽い埋め込みのおかげで多くの人が初めて動画をロードできるようになったが、端末や接続が遅く、再生段階で離脱したのかもしれない
すると以前はプレイヤーを完全にロードできず何のデータも残らなかった人たちが、今は「動画視聴を中断」した割合を押し上げる形に見える可能性がある
ユーザーは対象によってロード時間への期待値や許容値が異なり、ページとその中の動画は別の対象
ページ全体のロード時間が埋め込みのロード時間に常に結び付いているわけでもなく、ページ全体のロードがコンテンツのロード時間を覆い隠すこともある
より重要な指標は、埋め込みのロード時間ではなく クリック後に再生されるまでの遅延かもしれない
uBlockユーザー向けのユーザー側の解決策として click2load フィルターを使える
ただし、Chrome は Manifest V3 へ移行中なので動作しない可能性もある。yokoffing/filterlists のフィルターを参考にすればよい
https://raw.githubusercontent.com/yokoffing/filterlists/main...
Betterfox の作者で、GitHub には他にも便利なフィルターがある
望んでいるのは単なる普通のリンクなので、以前ページ上のYouTube iframeをリンクに置き換える短いユーザースクリプトを作ったことがある
単純な実装のわりに驚くほどよく動く。
youtube.com/embedとyoutube-nocookie.com/embedの iframe を探してwatch?v=リンクに置き換え、タイムスタンプも維持できるようにし、望めばサムネイル画像も付けられる「埋め込みの数が増えるほど重さも線形に増える。2つなら2.4MB、3つなら3.6MB」という部分が変
なぜこれらのリソースが キャッシュから取得されないのか気になる。すべて
www.youtube.comからロードされるなら、同一オリジンポリシー上、キャッシュされたリソースを使えるはずではないかと思う記事で一番よかった部分は、軽いページに変えたところ平均ページロード時間がむしろ上がったというくだり
さらに詳しく見ると、低スペック・低速インターネット端末のユーザーまで初めてYouTubeを実際に使えるようになり、彼らが多く利用したことで平均が遅くなったように見えていた
実際の利用速度は全員にとって相対的に速くなっており、平均ページロード速度という指標は結局、意味のない釣り餌だったという点が印象的
以前、Firefox拡張で、すべてのYouTube埋め込みをサムネイルに置き換え、クリックするとYouTubeを開くものを作ったことがある
もともとは携帯電話にFlashがないのにFlash埋め込みが一般的だったため作ったもので、後にはiframe埋め込みまで処理するように拡張した
ほとんどの場合、小さな埋め込みウィンドウよりも、YouTubeのWebサイトやアプリ全体で開くほうがユーザー体験も良かった
当時の新しい高レベル拡張APIに合わせて書いたにもかかわらず、ブラウザバージョン間のサポートが期待したほど続かず、面倒になってWebExtensionには移植しなかった。この記事を見て、また移植したくなった