前のモジュールでは、画像に関連するパフォーマンス手法をいくつか学習しました。画像はウェブ上で広く使用されているリソースタイプで、画像を最適化し、ユーザーのビューポートを考慮に入れないと大量の帯域幅を消費する可能性があります。
しかし、ウェブで一般的に見られているメディアタイプは画像だけではありません。動画も、ウェブページでよく使用される一般的なメディアタイプです。可能な最適化について確認する前に、まず <video>
要素の仕組みを理解することが重要です。
動画ソースファイル
メディア ファイルを操作する場合、オペレーティング システム(.mp4
、.webm
など)で認識されるファイルはコンテナと呼ばれます。コンテナには 1 つ以上のストリームが含まれます。ほとんどの場合、動画と音声のストリームです。
コーデックを使用して各ストリームを圧縮できます。たとえば、video.webm
は、VP9 を使用して圧縮された動画ストリームと Vorbis を使用して圧縮された音声ストリームを含む WebM コンテナです。
コンテナとコーデックの違いを理解しておくと役立ちます。メディア ファイルを圧縮する帯域幅を大幅に削減できるため、全体的なページ読み込み時間が短くなり、ユーザー中心の指標であり、ウェブに関する主な指標の 1 つであるページの Largest Contentful Paint(LCP)が改善される可能性があるためです。
動画ファイルを圧縮するには、FFmpeg を使用する方法があります。
ffmpeg -i input.mov output.webm
上記のコマンドは、FFmpeg を使用する場合と同じように基本的なものですが、input.mov
ファイルを取得し、デフォルトの FFmpeg オプションを使用して output.webm
ファイルを出力します。上記のコマンドは、最新のすべてのブラウザで動作する小さい動画ファイルを出力します。FFmpeg の動画やオーディオ オプションを微調整すると、動画のファイルサイズをさらに小さくできる場合があります。たとえば、<video>
要素を使用して GIF を置き換える場合は、音声トラックを削除する必要があります。
ffmpeg -i input.mov -an output.webm
さらに微調整する場合、FFmpeg では可変ビットレートのエンコードを使用せずに動画を圧縮する際に -crf
フラグを提供しています。-crf
は、Constant Rate Factor の略です。これは圧縮レベルを調整する設定です。指定された範囲内の整数値を使用することで圧縮レベルを調整します。
H.264 や VP9 などのコーデックは -crf
フラグをサポートしていますが、その使用法は使用しているコーデックによって異なります。詳しくは、H.264 で動画をエンコードするための一定レート係数と VP9 で動画をエンコードする際の一定の品質をご覧ください。
複数のフォーマット
動画ファイルを操作する場合、複数の形式を指定すると、最新の形式をすべてサポートしていないブラウザの代替手段として機能します。
<video>
<source src="video.webm" type="video/webm">
<source src="video.mp4" type="video/mp4">
</video>
最新のブラウザはすべて H.264 コーデックをサポートしているため、従来のブラウザの代替手段として MP4 を使用できます。WebM バージョンでは、新しい AV1 コーデック(まだ広くはサポートされていない)または以前の VP9 コーデック(AV1 よりも優れたサポート)を使用できますが、通常は AV1 ほど圧縮されません。
poster
属性
動画のポスター画像は、<video>
要素の poster
属性を使用して追加します。これにより、再生が開始される前に動画コンテンツの内容をユーザーに知らせることができます。
<video poster="poster.jpg">
<source src="video.webm" type="video/webm">
<source src="video.mp4" type="video/mp4">
</video>
自動再生
HTTP アーカイブによると、ウェブ全体の動画の 20% に autoplay
属性が含まれています。autoplay
は、動画をすぐに再生する必要がある場合に使用します。たとえば、動画の背景やアニメーション GIF の代わりとして使用している場合です。
アニメーション GIF は非常に大きくなることがあります。特に、入り組んだディテールのフレームが多数ある場合には注意が必要です。アニメーション GIF が数メガバイトのデータを消費することは珍しくありません。これは、より重要なリソースに費やす帯域幅が大幅に浪費される可能性があります。一般的に、アニメーション画像形式は使用しないでください。このタイプのメディアでは、<video>
と同等の形式のほうがはるかに効率的です。
ウェブサイトで動画の自動再生が必要な場合は、<video>
要素で autoplay
属性を直接使用できます。
<!-- This will automatically play a video, but
it will loop continuously and be muted: -->
<video autoplay muted loop playsinline>
<source src="video.webm" type="video/webm">
<source src="video.mp4" type="video/mp4">
</video>
poster
属性を Intersection Observer API と組み合わせると、動画がビューポート内に収まったときにのみ動画をダウンロードするようにページを構成できます。poster
の画像は、動画の最初のフレームなど、低画質の画像のプレースホルダです。動画がビューポートに表示されると、ブラウザは動画のダウンロードを開始します。これにより、最初のビューポート内のコンテンツの読み込み時間を短縮できます。ただし、欠点として、autoplay
に poster
画像を使用すると、動画が読み込まれて再生が開始されるまで、ユーザーには画像が表示される時間が短くなります。
ユーザーが開始する再生
通常、ブラウザは、HTML パーサーが <video>
要素を検出するとすぐに動画ファイルのダウンロードを開始します。ユーザーが再生を開始する <video>
要素がある場合、ユーザーが操作するまで動画のダウンロードを開始したくないとします。
<video>
要素の preload
属性を使用すると、動画リソースとしてダウンロードされる内容に影響を与えることができます。
preload="none"
を設定すると、動画のどのコンテンツもプリロードしないことがブラウザに通知されます。preload="metadata"
を設定すると、動画のメタデータ(動画の再生時間や、場合によってはその他の履歴情報など)のみが取得されます。
ユーザーが再生を開始する必要がある動画を読み込む場合は、preload="none"
を設定することをおすすめします。
この場合、poster
画像を追加すると、ユーザー エクスペリエンスを改善できます。これにより、動画の内容をユーザーが理解しやすくなります。また、ポスター画像が LCP 要素である場合は、<link rel="preload">
ヒントと fetchpriority="high"
を使用して、poster
画像の優先度を上げることができます。
<link rel="preload" as="image" href="poster.jpg" fetchpriority="high">
埋め込み
動画コンテンツを効率的に最適化して配信することは複雑なことを考慮すると、YouTube や Vimeo などの専用の動画サービスに問題を軽減するのが合理的です。このようなサービスでは動画の配信が最適化されますが、サードパーティのサービスからの動画を埋め込むことで、JavaScript などの追加のリソースを提供することが多いため、パフォーマンスに独自の影響を及ぼす可能性があります。
こうした現状を考えると、サードパーティの動画の埋め込みがページのパフォーマンスに大きな影響を与える可能性があります。HTTP アーカイブによると、中央値のウェブサイトの場合、YouTube の埋め込みはメインスレッドを 1.7 秒以上ブロックしています。メインスレッドを長時間ブロックすると、ユーザー エクスペリエンスに重大な問題が生じ、ページの Interaction to Next Paint(INP)に影響を与える可能性があります。ただし、最初のページ読み込みの際、すぐに埋め込みを読み込むのではなく、埋め込み用のプレースホルダを作成し、ユーザーが操作したときに実際の埋め込み動画に置き換えられるという方法もあります。
動画デモ
知識を試す
親 <video>
要素内の <source>
要素の順序によって、最終的にダウンロードされる動画リソースが決まることはありません。
<video>
要素の poster
属性は LCP の候補とみなされます。
次のトピック: ウェブフォントを最適化する
特定のリソースタイプの最適化に関する次のテーマはフォントです。ウェブサイトのフォントの最適化は見過ごされがちですが、ウェブサイトの全体的な読み込み速度、LCP や Cumulative Layout Shift(CLS)などの指標に大きな影響を与える可能性があります。