動画 動画のサイズを正しく設定する 動画のサイズを確認する

エンコード済み動画のフレームサイズは、動画要素のサイズによって違ってくる場合があります（画像を実際のサイズでは表示できない場合があるため）。
エンコードされた動画サイズの確認方法は、動画要素の videoWidth と videoHeight プロパティを使用します。
width と height は、動画要素のサイズを返します。
この値は、CSS またはインラインの width と height 属性を使用してサイズが設定されている事があります。



関連記事

• 動画のサイズを確認する
• 動画がコンテナからはみ出さないようにする

動画 動画プレーヤーをカスタマイズする

動画の表示方法はプラットフォームごとに違います。
モバイルではデバイスの向き（縦向きか、横向きか）を考慮しなければなりません。
Fullscreen API は動画コンテンツのフルスクリーン表示を制御できます。

詳しくは以下の記事を参考にしてください。

• さまざまなデバイスでのデバイスの向きの影響
• インラインまたはフルスクリーン表示
• コンテンツのフルスクリーン表示の制御

関連記事

• 動画を追加する
• レガシー プラットフォーム用の代替手段を提供する
• 動画プレーヤーをカスタマイズする
• 動画のサイズを正しく設定する
• 利用しやすさに関する問題
• クイック リファレンス

動画 動画プレーヤーをカスタマイズする コンテンツのフルスクリーン表示の制御

フルスクリーンでの動画の再生を強制できないプラットフォームでは、Fullscreen API が幅広くサポートされています。

出典：http://caniuse.com/fullscreen

Fullscreen API を使用すると、コンテンツやページのフルスクリーン表示を制御できます。


video:のように要素をフルスクリーン表示する方法
elem.requestFullScreen();

ドキュメント全体をフルスクリーン表示する方法
document.body.requestFullScreen();

フルスクリーン状態の変更をリッスンする方法
video.addEventListener("fullscreenchange", handler);

要素が現在フルスクリーン モードかどうかを確認する。
console.log("In full screen mode: ", video.displayingFullscreen);

また、CSS で :fullscreen 疑似クラスを使用して、フルスクリーン モードの要素表示方法を変更できます。

Fullscreen API をサポートしているデバイスでは、動画のプレースホルダとしてサムネイル画像を使用することを推奨しています。

実際の動作を確認するには、グーグルのデモをご覧ください。

グーグルのデモ画面スクリーンショット

注意：requestFullScreen() は現在プリフィックスベンダーです。
完全なクロスブラウザの互換性のための余分なコードが必要な場合があります。



関連記事

• さまざまなデバイスでのデバイスの向きの影響
• インラインまたはフルスクリーン表示
• コンテンツのフルスクリーン表示の制御

動画 動画プレーヤーをカスタマイズする インラインまたはフルスクリーン表示

動画の表示方法はプラットフォームごとに違います。
iPhoneのSafariは、動画要素をウェブページ内で表示しますが、再生するときはフルスクリーンモードになります。

縦向きの iPhone に表示された動画要素のスクリーンショット

Androidは、フルスクリーン アイコンをクリックすることでフルスクリーン モードをリクエストできます。
デフォルトではインラインで動画を再生します。

縦向きの Android の Chrome で再生している動画のスクリーンショット

iPad の Safari では動画をインラインで再生します。

横向きの iPad Retina の Safari で再生している動画のスクリーンショット

関連記事

• さまざまなデバイスでのデバイスの向きの影響
• インラインまたはフルスクリーン表示
• コンテンツのフルスクリーン表示の制御

動画 動画プレーヤーをカスタマイズする さまざまなデバイスでのデバイスの向きの影響

デバイスの向きは、デスクトップやノートパソコンでは問題になりません。
しかし、携帯端末やタブレット末端ではデザインを検討する際には非常に重要です。
iPhone の Safari は、縦向きと横向きでの切り替えが非常にスムーズです。

縦向きの iPhone の Safari で再生している動画のスクリーンショット

横向きの iPhone の Safari で再生している動画のスクリーンショット

iPadやAndroidでは、デバイスの向きが問題になる場合があります。

例　横向きの iPad での動画の再生をカスタマイズしなかった場合。

横向きの iPad Retina の Safari で再生している動画のスクリーンショット

CSS で width: 100% または max-width: 100% と設定すると、デバイスの向きによるレイアウトの問題の多くは解決できます。
また、フルスクリーンの代替手段も検討しなければならない場合があります。




関連記事

• さまざまなデバイスでのデバイスの向きの影響
• インラインまたはフルスクリーン表示
• コンテンツのフルスクリーン表示の制御

動画 レガシー プラットフォーム用の代替手段を提供する

https://developers.google.com/web/fundamentals/media/video/provide-alternatives-for-legacy-platforms?hl=ja

すべてのプラットフォームがすべての動画形式をサポートしていません。
プラットフォームでサポートされている動画形式を確認し、各プラットフォームで動画を再生できるようにします。
詳細は以下の記事を参考にしてください。

• サポートされている形式を確認する
• 複数の形式で動画を生成する
• 使用されている形式を確認する

関連記事

• 動画を追加する
• レガシー プラットフォーム用の代替手段を提供する
• 動画プレーヤーをカスタマイズする
• 動画のサイズを正しく設定する
• 利用しやすさに関する問題
• クイック リファレンス

動画 レガシー プラットフォーム用の代替手段を提供する 使用されている形式を確認する

ブラウザで選択されている動画形式を確認したい場合は、ソースを確認します。
JavaScriptは、動画の currentSrc プロパティを使用して、使用されているソースを取得できます。

Chrome と Firefox は chrome.webm を選択し、Safari は「chrome.mp4」を選択しています。





関連記事
サポートされている形式を確認する
複数の形式で動画を生成する
使用されている形式を確認する

動画 レガシー プラットフォーム用の代替手段を提供する 複数の形式で動画を生成する

同じ動画を異なる形式で保存できるツールがあります。

このツールを使い、様々なプラットフォームや形式で再生が出来るようにします。

代表的なツール

デスクトップ ツールFFmpeg・・・エンコード、トランスコード、マルチプレクサ、デマルチプレクサ、ストリーム、フィルタをデコードし、人間と機械が作成しているほとんど何でも再生することが主要なマルチメディアフレームワークです。
GUI アプリケーションMiro
HandBrake・・・近代的な、広くサポートされるコーデックの選択に、ほぼすべての形式からビデオを変換するためのツールです。
VLC・・・フリーなマルチプラットフォーム対応のマルチメディアプレイヤーであり、DVD、オーディオCD、VCDや様々なストリーミングプロトコルを再生可能なフレームワークです。
オンライン エンコーディング / トランスコーディング サービスZencoder・・・ライブでのパフォーマンスのリーダーとファイルクラウドエンコーディング、iOS用の完全なアダプティブビットレートソリューション、放送局やプロのコンテンツプロバイダのエンコード、マルチスクリーン、ライブストリームのためのアダプティブビットレートのトランスコーディング。
Amazon Elastic Encoder・・・クラウドのメディア変換サービス。高度なスケーラビリティ、使いやすさ、高い費用効率性を実現する設計で、開発者や企業は、メディアファイルをその元のソース形式からスマートフォン、タブレット、PC などのデバイスで再生可能できるバージョンに変換（または「トランスコード」）できます。

関連記事
サポートされている形式を確認する
複数の形式で動画を生成する
使用されている形式を確認する

動画 レガシー プラットフォーム用の代替手段を提供する サポートされている形式を確認する

サポートしている動画形式を検出する方法は、canPlayType() を使います。
このメソッドは、mime-type とオプションのコーデックで構成された文字列引数を受け取り、いずれかの値を返します。

関連記事
サポートされている形式を確認する
複数の形式で動画を生成する
使用されている形式を確認する

動画 動画を追加する

ユーザーの多くは動画を好む傾向にあります。
ユーザーにとって動画は、面白かったり判りやすかったりするからです。
携帯端末の場合、テキストや画像コンテンツより、動画コンテンツの方が情報を理解しやすい場合もあります。
一方で動画は帯域幅が必要な為、すべてのプラットフォームで常に同様に視聴できません。
ローディング時間が長く待たされたり、再生をタッチしても何も起きない場合があります。
その様な場合、ユーザーエクスペリエンスは最悪です。
動画をサイトに追加して、どのデバイスでも最高のユーザー エクスペリエンスを実現する方法が必要になります。
詳細は以下の各ページを参考にしてください。

• 動画要素を追加する
• 複数のファイル形式を指定する
• 開始時刻と終了時刻を指定する
• ポスター画像を含める

関連記事

• 動画を追加する
• レガシー プラットフォーム用の代替手段を提供する
• 動画プレーヤーをカスタマイズする
• 動画のサイズを正しく設定する
• 利用しやすさに関する問題
• クイック リファレンス

動画 動画を追加する ポスター画像を含める

動画要素に poster 属性を追加すると、ユーザーのデバイスが要素が読込んだ時に、内容をすぐに把握できます。
この場合、ユーザーは動画をダウンロードして再生する必要がなくなります。

<video poster="poster.jpg" ...>
  ...
</video>

ポスターは、動画の src が破損していたり、指定した動画形式がすべてサポートされていない場合には代替手段になります。
ポスター画像のデメリットは、追加のファイル リクエストによって帯域幅を消費し、レンダリングが必要になることです。
詳細は、画像の最適化を参考にしてください。

ポスター有りと無しでは表示が異なります。

ポスター有り

ポスターなし

ポスター有りの方がユーザーにとって親切であることが一目瞭然です。





関連記事

• 動画要素を追加する
• 複数のファイル形式を指定する
• 開始時刻と終了時刻を指定する
• ポスター画像を含める

動画 動画を追加する 開始時刻と終了時刻を指定する

動画コンテンツを使用する場合は、帯域幅を節約して、レスポンシブなサイトを構築します。
それには、Media Fragments API を使い、動画要素に開始時間と終了時間を追加します。

メディア フラグメントの追加は、メディアの URL に #t=[start_time][,end_time] を加えます。

例
5～10 秒の間だけ動画を再生する場合の指定。
<source src="video/chrome.webm#t=5,10" type="video/webm">

また、Media Fragments API を使用すると、同じ動画の複数のビューを配信でき、複数のファイルをエンコードする必要はありません。

覚えておかなければならないこと。 

• Media Fragments API は、ほとんどのプラットフォームでサポートされていますが、iOS はサポートされていません。

• 使っているサーバーが Range リクエストをサポートしている事を確認します。一部のホスティング サーバーでは無効の場合があります。

ブラウザ デベロッパー ツールを使用して、レスポンス ヘッダーの Accept-Ranges: bytes を確認します。




関連記事

• 動画要素を追加する
• 複数のファイル形式を指定する
• 開始時刻と終了時刻を指定する
• ポスター画像を含める

動画 動画を追加する 複数のファイル形式を指定する

すべてのブラウザが全ての動画形式をサポートしていません。
要素では、ユーザーのブラウザがいずれかの形式をサポートしていない場合の代替として、複数の形式を指定します。

例
    <video controls>
      <source src="chrome.webm" type="video/webm">
      <source src="chrome.mp4" type="video/mp4">
      <p>このブラウザは、video要素をサポートしていません。</p>
    </video>

 
ブラウザはオプションの type 属性を使用しタグの解析をおこない、どのファイルをダウンロードし、再生をするか判断します。
例の場合、ブラウザが WebM をサポートしている場合は chrome.webm で再生をします。
サポートしていない場合は MPEG-4 動画で再生します。
ウェブで動画と音声を使用する方法については、デジタル動画に関する、楽しくてためになる解説動画を参考にしてください。
これは、特に携帯端末でさまざまな HTML やサーバー側スクリプトを配信する場合に、次の4つのメリットがあります。

• デベロッパーが優先順位に基づいて形式を指定できる。
• ネイティブ クライアント側で切り替える為、コンテンツ取得リクエストが 1 つ生成するだけですみ、ロード時間が短縮できる。
• サーバー側でユーザー エージェントの検出機能とサポート データベースを使用するより、ブラウザで形式を選択する方がより簡単で迅速であり、信頼性も高くなります。
• ファイルごとにソースのタイプを指定するとブラウザが動画の一部をダウンロードして形式を識別しなくてすみ、ブラウザが動画ソースを選択する為にネットワークのパフォーマンスが向上します。

特にモバイルコンテンツは、帯域幅とロード時間が重視されます。
モバイル コンテキストではユーザーが我慢する局面がある場合、ユーザーエクスペリエンスが著しく低下する為、特に重要です。
type 属性を指定しない場合、複数ソースの中にサポートされていないタイプが存在すると、パフォーマンスに影響を及ぼします。
モバイル ブラウザ デベロッパー ツールを使用して、type 属性がある場合と type 属性がない場合でネットワークのアクティビティを比べてみましょう。
 また、ブラウザ デベロッパー ツールでレスポンス ハンドラを確認し、サーバーが適切な MIME タイプを報告することを確認します。
これが無いと動画のソースタイプのチェックが機能しません。





関連記事

• 動画要素を追加する
• 複数のファイル形式を指定する
• 開始時刻と終了時刻を指定する
• ポスター画像を含める

動画 動画を追加する 動画要素を追加する

サイトで動画の読み込み、デコード、再生を行うための動画要素を追加します。

この動画のソースは
<video controls=""><source src="video/chrome.webm" type="video/webm"><source src="video/chrome.mp4" type="video/mp4"><p>このブラウザは、動画要素をサポートしていません。</p></video>




関連記事

• 動画要素を追加する
• 複数のファイル形式を指定する
• 開始時刻と終了時刻を指定する
• ポスター画像を含める

モバイル SEO よくあるミスを回避する 再生できないコンテンツ

動画やコンテンツの種類により、モバイルで再生出来ない場合があります。

例

• ライセンスの制約があるメディア
• モバイル端末で幅広くサポートされていないFlash
• その他のプレーヤーを必要とする場合

再生できないコンテンツがあるとユーザーの不満の原因になります。
モバイルでサポートされていないコンテンツが含まれているページにアクセスすると、エラー メッセージが表示されます。

動画を再生できない

ユーザーにとって快適なモバイルサイトではありません。
独自の動画プレーヤーや、サポートされていない形式のコンテンツを提供するのではなく、HTML5 標準タグを使用して動画等のコンテンツをアップする事をグーグルは推奨しています。

Flashやマルチメディア プレーヤーでレンダリングする動画コンテンツがある場合は、すべてのウェブブラウザで動作する HTML5 のアニメーションの使用をグーグルは推奨しています。
Google Web Designer はHTML5で簡単に作成できます。

グーグルの推奨する対処方法

• アニメーションに HTML5 標準を使用します。

• すべての端末で再生できる動画を埋め込んで使用します。

• 動画の字幕を利用します。ブラウジング支援機能を利用している人や、独自の動画形式を再生できないブラウザを利用している人が、アクセスできます。

詳しくは、Google の Web Fundamentals で動画に関するおすすめの方法を参照してください。







関連記事

• JavaScript、CSS、画像ファイルをブロックしている
• 再生できないコンテンツ
• 間違ったリダイレクト
• モバイル端末でのみ 404 エラーが発生する
• インタースティシャル
• 不適切な相互リンク
• 表示速度の遅いモバイルページ

モバイル SEO よくあるミスを回避する JavaScript、CSS、画像ファイルをブロックしている

最適なレンダリングとインデックスを実施するには、ウェブサイトで使用している JavaScript、CSS、画像ファイルについて、常に Googlebot からのアクセスを許可します。
Googlebot がウェブサイトの表示をユーザーと同様に確認する為です。
ボットのクロールを、robots.txtファイルで禁止している場合、コンテンツのレンダリングとインデックスの作成をするアルゴリズムにダイレクトに悪影響があります。
その結果、ランキングが最適化されません。

グーグルが推奨する対処方法

• Google Search Consoleの「Fetch as Google」で、Googlebot が JavaScript、CSS、画像ファイルをクロールしている事を確認します。「Fetch as Google」は Googlebotがどんな形でコンテンツ認識し、レンダリングしているか確認出来る為、インデックス登録時の問題を特定して修正できます。
  

• Google Search Console　robots.txt テスターで、robots.txt のチェックとテストをします。
  

• モバイル フレンドリー テストで、モバイルページをテストし、モバイルユーザーが利用できるサイトか確認します。 
  

• モバイルページ用に別の URL を使う（既に使用している）場合は、必ずモバイルとパソコン双方のURL をテストをおこない、リダイレクトが認識され、クロール出来ることを確認します。

関連記事

• JavaScript、CSS、画像ファイルをブロックしている
• 再生できないコンテンツ
• 間違ったリダイレクト
• モバイル端末でのみ 404 エラーが発生する
• インタースティシャル
• 不適切な相互リンク
• 表示速度の遅いモバイルページ

ユーザーエージェントの正確な検出

ユーザーエージェントの検出はミスが発生しやすい傾向があります。
あらゆる原因がありますが、主な原因は次の3つです。
この3つの原因は発生率が高くなっています。

• ユーザーエージェントの検出は、ユーザーエージェント ストリング（またはサブストリング）リストとマッチングをします。このリストは、常に更新する必要があり、更新しないと新しいユーザーエージェントとあわなくなります。実際、リストの多くは適切に保守されていないのげ現状です。最新の状態でない場合、ユーザーエクスペリエンスが低下する原因になっています。
• ユーザーエージェントを照合した場合、不一致が頻繁に起こります。PC ユーザーがモバイル端末ユーザーとして検出される場合や、その逆があります。タブレットがスマートフォンとして処理される場合もあります。サイトにアクセスするブラウザのユーザーエージェントを検出する場合は、モバイル ストリングを探すのではなく（たとえば「ios」だけをチェックする）、スマートフォン固有のストリングを探します（たとえば「ios」と「Mobile」の両方をチェックする）。詳しくはMo’ better to also detect “mobile” user-agentを参照してください。
• ユーザーエージェントの検出ではクローキングに十分配慮します。ユーザーエージェントを検出する際は、ユーザーエージェントストリングでデバイス名を探してデバイスのクラスやタイプを検出します。Googlebot だけを対象にはできません。すべての Googlebotユーザーエージェントは、Googlebot自体を特定のモバイル端末と見なします。モバイル端末の場合と同一に扱います。例）スマートフォン用 Googlebot が自身を iPhone と見なしている場合、iPhone ユーザーに対するのと同じレスポンス（リダイレクト、最適化されたコンテンツなど）を返さなければなりません。