フロントエンドパフォーマンス2021：資産の最適化

このガイドは、フロントエンドのパフォーマンスモニタリング、セッションの再生、および製品分析を組み合わせて、より良いカスタマーエクスペリエンスを構築するのに役立つ、LogRocketの友人から親切にサポートされています。 LogRocketは、主要なメトリックを追跡します。 DOM完了、最初のバイトまでの時間、最初の入力遅延、クライアントのCPUとメモリの使用量。 今すぐLogRocketの無料トライアルを入手してください。

目次

1. 準備：計画と指標
2. 現実的な目標の設定
3. 環境の定義
4. 資産の最適化
5. ビルドの最適化
6. 配信の最適化
7. ネットワーキング、HTTP / 2、HTTP / 3
8. テストとモニタリング
9. クイックウィン
10. 1ページのすべて
11. チェックリストをダウンロードする（PDF、Apple Pages、MS Word）
12. 次のガイドを見逃さないように、メールマガジンを購読してください。

資産の最適化

1. プレーンテキストの圧縮にはBrotliを使用します。
   2015年、Googleは新しいオープンソースのロスレスデータ形式であるBrotliを導入しました。これは、現在すべての最新のブラウザでサポートされています。 Brotli用のエンコーダーとデコーダーを実装するオープンソースのBrotliライブラリには、エンコーダー用に11の事前定義された品質レベルがあり、品質レベルが高いほど、より良い圧縮率と引き換えにより多くのCPUが必要になります。 圧縮が遅いと、最終的には圧縮率が高くなりますが、それでもBrotliは高速に解凍します。 圧縮レベル4のBrotliは、Gzipよりも小さく、圧縮速度も速いことに注意してください。

   実際には、BrotliはGzipよりもはるかに効果的であるように見えます。 意見や経験は異なりますが、サイトがすでにGzipで最適化されている場合は、サイズの縮小とFCPのタイミングで少なくとも1桁の改善、せいぜい2桁の改善が期待できます。 また、サイトのBrotli圧縮の節約を見積もることもできます。

   ブラウザは、ユーザーがHTTPS経由でWebサイトにアクセスしている場合にのみBrotliを受け入れます。 Brotliは広くサポートされており、多くのCDN（Akamai、Netlify Edge、AWS、KeyCDN、Fastly（現在はパススルーとしてのみ）、Cloudflare、CDN77）をサポートしており、まだサポートしていないCDNでもBrotliを有効にできます（サービスワーカーと）。

   欠点は、Brotliを使用してすべてのアセットを高圧縮レベルで圧縮するのはコストがかかるため、多くのホスティングプロバイダーは、コストのオーバーヘッドが大きいという理由だけで、Brotliをフルスコールで使用できないことです。 実際、最高レベルの圧縮では、Brotliは非常に遅いため、サーバーがアセットを動的に圧縮するのを待機するときにサーバーが応答の送信を開始するのにかかる時間によって、ファイルサイズの潜在的な増加が無効になる可能性があります。 （ただし、ビルド時間中に静的圧縮を使用する時間がある場合は、もちろん、より高い圧縮設定が推奨されます。）

   

   ただし、これは変更される可能性があります。 Brotliファイル形式には、組み込みの静的辞書が含まれており、複数の言語のさまざまな文字列を含むことに加えて、それらの単語に複数の変換を適用するオプションもサポートしているため、汎用性が向上します。 彼の研究で、Felix Hanauは、「デフォルトよりも特殊な辞書のサブセット」を使用し、 Content-Typeヘッダーを使用してコンプレッサーに、 HTML、JavaScriptまたはCSSの辞書。 その結果、「辞書の使用を制限したアプローチを使用して、高圧縮レベルでWebコンテンツを圧縮した場合、パフォーマンスへの影響はごくわずかです（通常の12％に比べてCPUが1％から3％多くなります）」。

   

   さらに、Elena Kirilenkoの調査により、以前の圧縮アーティファクトを使用して、高速で効率的なBrotli再圧縮を実現できます。 Elena氏によると、「Brotliを介してアセットを圧縮し、動的コンテンツをオンザフライで圧縮しようとすると、コンテンツが事前に利用可能なコンテンツに似ているため、圧縮時間の大幅な改善を実現できます。 「」

   どのくらいの頻度でそうですか？ たとえば、 JavaScriptバンドルサブセットの配信（たとえば、コードの一部がクライアントにすでにキャッシュされている場合、またはWebBundleで提供される動的バンドルを使用する場合）。 または、既知の高度なテンプレートに基づくダイナミックHTML、または動的にサブセット化されたWOFF2フォントを使用します。 Elenaによると、コンテンツの10％を削除すると、圧縮率が5.3％向上し、圧縮速度が39％向上します。また、コンテンツの50％を削除すると、圧縮率が3.2％向上し、圧縮率が26％向上します。

   Brotliの圧縮は向上しているため、静的アセットを動的に圧縮するコストを回避できれば、努力する価値は間違いありません。 言うまでもなく、Brotliは、HTML、CSS、SVG、JavaScript、JSONなどの任意のプレーンテキストペイロードに使用できます。

   注：2021年初頭の時点で、HTTP応答の約60％がテキストベースの圧縮なしで配信され、30.82％がGzipで圧縮され、9.1％がBrotliで圧縮されています（モバイルとデスクトップの両方）。 たとえば、Angularページの23.4％は圧縮されていません（gzipまたはBrotliを介して）。 しかし、多くの場合、圧縮をオンにすることは、スイッチを押すだけでパフォーマンスを向上させる最も簡単な方法の1つです。

   戦略は？ 静的アセットを最高レベルのBrotli + Gzipで事前圧縮し、（動的）HTMLをレベル4〜6のBrotliでオンザフライで圧縮します。 サーバーがBrotliまたはGzipのコンテンツネゴシエーションを適切に処理することを確認してください。

1. アダプティブメディアローディングとクライアントヒントを使用していますか？
   これは古いニュースの世界から来ていますが、 srcset 、 sizes 、および<picture>要素を含むレスポンシブ画像を使用することを常にお勧めします。 特にメディアフットプリントが大きいサイトの場合、アダプティブメディアローディング（この例ではReact + Next.js）を使用してさらに一歩進め、低速のネットワークと低メモリデバイスに軽いエクスペリエンスを提供し、高速のネットワークと高速に完全なエクスペリエンスを提供できます-メモリデバイス。 Reactのコンテキストでは、サーバー上のクライアントヒントとクライアント上のreact-adaptive-hooksを使用してこれを実現できます。

   レスポンシブ画像の未来は、クライアントヒントの採用が広がるにつれて劇的に変わる可能性があります。 クライアントヒントは、HTTPリクエストヘッダーフィールドです。たとえば、 DPR 、 Viewport-Width 、 Width 、 Save-Data 、 Accept （画像形式の設定を指定するため）などです。 それらは、ユーザーのブラウザ、画面、接続などの詳細についてサーバーに通知することになっています。

   その結果、サーバーは適切なサイズの画像をレイアウトに入力する方法を決定し、これらの画像のみを目的の形式で提供できます。 クライアントヒントを使用して、リソースの選択をHTMLマークアップから、クライアントとサーバー間の要求/応答ネゴシエーションに移動します。

   

   Ilya Grigorikがしばらく前に指摘したように、クライアントのヒントが全体像を完成させます。これらはレスポンシブ画像に代わるものではありません。 「 <picture>要素は、HTMLマークアップで必要なアートディレクションコントロールを提供します。クライアントヒントは、リソース選択の自動化を可能にする結果の画像リクエストに注釈を提供します。ServiceWorkerは、クライアントに完全なリクエストおよびレスポンス管理機能を提供します。」

   たとえば、サービスワーカーは、リクエストに新しいクライアントヒントヘッダー値を追加したり、URLを書き換えて画像リクエストをCDNにポイントしたり、接続性やユーザー設定に基づいて応答を調整したりできます。これは、画像アセットだけでなく、他のほとんどすべてのリクエストについても同様です。

   クライアントヒントをサポートするクライアントの場合、画像で42％のバイト節約、70パーセンタイル以上で1MB以上のバイト削減を測定できます。 Smashing Magazineでは、19〜32％の改善も測定できました。 クライアントヒントはChromiumベースのブラウザでサポートされていますが、Firefoxではまだ検討中です。

   ただし、クライアントヒントに通常のレスポンシブ画像マークアップと<meta>タグの両方を指定すると、サポートするブラウザがレスポンシブ画像マークアップを評価し、クライアントヒントHTTPヘッダーを使用して適切な画像ソースを要求します。

2. 背景画像にレスポンシブ画像を使用していますか？
   きっと！ Safari 14およびFirefoxを除くほとんどの最新ブラウザでサポートされるようになったimage-setを使用すると、レスポンシブな背景画像も提供できます。

   background-image: url("fallback.jpg"); background-image: image-set( "photo-small.jpg" 1x, "photo-large.jpg" 2x, "photo-print.jpg" 600dpi);

   基本的に、 1x記述子を使用した低解像度の背景画像、 2x記述子を使用した高解像度画像、さらには600dpi記述子を使用した印刷品質の画像を条件付きで提供できます。 ただし、注意してください。ブラウザは支援技術に背景画像に関する特別な情報を提供しないため、理想的にはこれらの写真は単なる装飾にすぎません。

3. WebPを使用していますか？
   多くの場合、画像圧縮はすぐに成功すると考えられていますが、実際にはまだ十分に活用されていません。 もちろん、画像はレンダリングをブロックしませんが、LCPスコアの低下に大きく影響します。また、多くの場合、画像は、使用しているデバイスに対して重すぎたり大きすぎたりします。

   したがって、少なくとも、画像にWebP形式を使用して探索することができます。 実際、WebPの物語は、AppleがSafari 14でWebPのサポートを追加することで、昨年終わりに近づいています。したがって、長年の議論と議論の末、今日の時点で、WebPはすべての最新ブラウザーでサポートされています。 したがって、必要に応じて<picture>要素とJPEGフォールバックを使用して（Andreas Bovensのコードスニペットを参照）、またはコンテンツネゴシエーションを使用して（ Acceptヘッダーを使用して）WebP画像を提供できます。

   ただし、WebPには欠点があります。 WebP画像のファイルサイズは同等のGuetzliやZopfliと比較されますが、この形式はJPEGのようなプログレッシブレンダリングをサポートしていません。そのため、WebP画像はネットワークを介して高速化される可能性がありますが、ユーザーは古き良きJPEGで完成した画像をより速く表示できます。 JPEGを使用すると、WebPの場合のように半分空の画像を表示するのではなく、データの半分または4分の1で「まともな」ユーザーエクスペリエンスを提供し、残りを後で読み込むことができます。

   決定は、何を求めているかによって異なります。WebPを使用するとペイロードが減り、JPEGを使用すると知覚されるパフォーマンスが向上します。 WebPの詳細については、GoogleのPascalMassiminoによるWebPRewindトークをご覧ください。

   WebPへの変換には、WebP Converter、cwebp、またはlibwebpを使用できます。 Ire Aderinokunには、画像をWebPに変換するための非常に詳細なチュートリアルもあります。また、最新の画像形式を採用することについてのJoshComeauも同様です。

   

   SketchはネイティブにWebPをサポートしており、Photoshop用のWebPプラグインを使用してWebP画像をPhotoshopからエクスポートできます。 ただし、他のオプションも利用できます。

   WordPressまたはJoomlaを使用している場合は、WordPress用のOptimusやCache Enabler、Joomla独自のサポートされている拡張機能（Cody Arsenault経由）など、WebPのサポートを簡単に実装するのに役立つ拡張機能があります。 <picture>要素をReact、スタイル付きコンポーネント、またはgatsby-imageで抽象化することもできます。

   ああ—恥知らずなプラグ！ — Jeremy Wagnerは、WebPに関するSmashingの本を出版しました。これは、WebPに関するすべてのことに興味があるかどうかを確認することをお勧めします。

4. AVIFを使用していますか？
   あなたは大きなニュースを聞いたことがあるかもしれません：AVIFが上陸しました。 これは、AV1ビデオのキーフレームから派生した新しい画像形式です。 これは、非可逆および可逆圧縮、アニメーション、非可逆アルファチャネルをサポートし、シャープな線と単色（JPEGの問題でした）を処理できると同時に、両方でより良い結果を提供する、オープンでロイヤリティフリーの形式です。

   実際、WebPやJPEGと比較して、AVIFのパフォーマンスは大幅に向上し、同じDSSIMでファイルサイズの中央値を最大50％節約できます（人間の視覚に近いアルゴリズムを使用した2つ以上の画像間の（非）類似性）。 実際、Malte Ublは、画像の読み込みの最適化に関する徹底的な投稿で、AVIFは「非常に一貫して非常に重要な点でJPEGを上回っています。これは、常にJPEGよりも小さい画像を生成するわけではなく、実際にはネットである可能性があるWebPとは異なります。プログレッシブローディングのサポートの欠如による損失。」

   

   皮肉なことに、AVIFは大規模なSVGよりも優れたパフォーマンスを発揮しますが、もちろんSVGの代わりと見なすべきではありません。 また、HDRカラーサポートをサポートする最初の画像形式の1つです。 より高い輝度、カラービット深度、および色域を提供します。 唯一の欠点は、現在AVIFがプログレッシブ画像のデコードをサポートしていないことです（まだ？）。Brotliと同様に、デコードは高速ですが、高圧縮率のエンコードは現在非常に低速です。

   AVIFは現在Chrome、Firefox、Operaでサポートされており、Safariでのサポートは間もなく開始される予定です（AppleはAV1を作成したグループのメンバーであるため）。

   最近の画像を提供するための最良の方法は何ですか？ イラストやベクター画像の場合、（圧縮された）SVGが間違いなく最良の選択です。 写真の場合、 picture要素を使用したコンテンツネゴシエーションメソッドを使用します。 AVIFがサポートされている場合は、AVIFイメージを送信します。 そうでない場合は、最初にWebPにフォールバックし、WebPもサポートされていない場合は、フォールバックとしてJPEGまたはPNGに切り替えます（必要に応じて@media条件を適用します）。

   <picture> <source type="image/avif"> <source type="image/webp"> <img src="image.jpg" alt="Photo" width="450" height="350"> </picture>

   率直に言って、 picture要素内でいくつかの条件を使用する可能性が高くなります。

   <picture> <source type="image/avif" /> <source type="image/webp" /> <source type="image/jpeg" /> <img src="fallback-image.jpg" alt="Photo" width="450" height="350"> </picture>
   <picture> <source type="image/avif" /> <source type="image/webp" /> <source type="image/jpeg" /> <img src="fallback-image.jpg" alt="Photo" width="450" height="350"> </picture>

   動きを少なくすることを選択し、 prefers-reduced-motionを使用する顧客のために、アニメーション画像を静止画像と交換することで、さらに先に進むことができます。

   <picture> <source media="(prefers-reduced-motion: reduce)" type="image/avif"></source> <source media="(prefers-reduced-motion: reduce)" type="image/jpeg"></source> <source type="image/avif"></source> <img src="motion.jpg" alt="Animated AVIF"> </picture>
   <picture> <source media="(prefers-reduced-motion: reduce)" type="image/avif"></source> <source media="(prefers-reduced-motion: reduce)" type="image/jpeg"></source> <source type="image/avif"></source> <img src="motion.jpg" alt="Animated AVIF"> </picture>

   数か月の間に、AVIFはかなりの牽引力を獲得しました。

   • DevToolsの[レンダリング]パネルでWebP / AVIFフォールバックをテストできます。
   • Squoosh、AVIF.io、libavifを使用して、AVIFファイルのエンコード、デコード、圧縮、変換を行うことができます。
   • ワーカーでAVIFファイルをデコードし、結果をキャンバスに表示するJakeArchibaldのAVIFPreactコンポーネントを使用できます。
   • サポートしているブラウザにのみAVIFを配信するために、PostCSSプラグインと315Bスクリプトを使用して、CSS宣言でAVIFを使用できます。
   • CSSとCloudlareWorkersを使用して新しい画像形式を段階的に提供し、返されたHTMLドキュメントを動的に変更し、 acceptヘッダーから情報を推測して、必要に応じてwebp/avifなどのクラスを追加できます。
   • AVIFはすでにCloudinaryで利用可能であり（使用制限あり）、Cloudflareは画像のサイズ変更でAVIFをサポートしており、NetlifyのカスタムAVIFヘッダーでAVIFを有効にすることができます。
   • アニメーションに関しては、AVIFはSafariの<img src=mp4>と同様に機能し、GIFやWebP全体を上回っていますが、MP4の方が優れています。
   • 一般に、アニメーションの場合、Chromiumベースのブラウザが<img src=mp4>をサポートすると仮定すると、AVC1（h264）> HVC1> WebP> AVIF> GIFです。
   • AVIFの詳細については、NetflixのAdityaMavlankarによるAVIFfor Next Generation Image Codingトーク、およびCloudflareのKornelLesinskiによるAVIFImageFormatトークをご覧ください。
   • すべてのAVIFの優れたリファレンス：AVIFに関するJakeArchibaldの包括的な投稿が上陸しました。

   では、将来のAVIFはそうですか？ Jon Sneyersは同意しません。AVIFのパフォーマンスは、GoogleとCloudinaryによって開発されたもう1つの無料のオープンフォーマットであるJPEG XLよりも60％劣っています。 実際、JPEGXLのパフォーマンスは全体的にはるかに優れているようです。 ただし、JPEG XLはまだ標準化の最終段階にあり、どのブラウザでもまだ機能していません。 （古き良きInternet Explorerから9回提供されているMicrosoftのJPEG-XRと混同しないでください）。

1. JPEG / PNG / SVGは適切に最適化されていますか？
   ヒーロー画像が非常に高速に読み込まれることが重要なランディングページで作業している場合は、JPEGがプログレッシブであり、mozJPEG（スキャンレベルを操作することでレンダリング開始時間を改善する）またはGoogleのオープンソースであるGuetzliで圧縮されていることを確認してください知覚パフォーマンスに焦点を当て、ZopfliとWebPからの学習を利用するエンコーダー。 唯一の欠点：処理時間が遅い（メガピクセルあたり1分のCPU）。

   PNGの場合はPingoを使用でき、SVGの場合はSVGOまたはSVGOMGを使用できます。 また、WebサイトからすべてのSVGアセットをすばやくプレビューしてコピーまたはダウンロードする必要がある場合は、svg-grabberでもそれを実行できます。

   すべての画像最適化の記事でそれが述べられていますが、ベクターアセットをクリーンでタイトに保つことは常に言及する価値があります。 未使用のアセットをクリーンアップし、不要なメタデータを削除し、アートワーク（したがってSVGコード）のパスポイントの数を減らしてください。 （ありがとう、ジェレミー！ ）

   ただし、便利なオンラインツールもあります。

   • Squooshを使用して、最適な圧縮レベル（非可逆または可逆）で画像を圧縮、サイズ変更、および操作します。
   • Guetzli.itを使用して、GuetzliでJPEG画像を圧縮および最適化します。これは、シャープなエッジと単色の画像に適しています（ただし、かなり遅くなる可能性があります））。
   • Responsive Image Breakpoints GeneratorまたはCloudinaryやImgixなどのサービスを使用して、画像の最適化を自動化します。 また、多くの場合、 srcsetとsizesだけを使用すると、大きなメリットが得られます。
   • レスポンシブマークアップの効率を確認するには、ビューポートサイズとデバイスのピクセル比全体の効率を測定するコマンドラインツールであるイメージングヒープを使用できます。
   • GitHubワークフローに自動画像圧縮を追加できるため、圧縮されていない状態で画像が本番環境に到達することはありません。 このアクションでは、PNGおよびJPGで機能するmozjpegおよびlibvipsを使用します。
   • ストレージを内部的に最適化するには、Dropboxの新しいLepton形式を使用して、JPEGを平均22％ロスレスで圧縮できます。
   • プレースホルダー画像を早く表示したい場合は、BlurHashを使用してください。 BlurHashは画像を取得し、この画像のプレースホルダーを表す短い文字列（20〜30文字のみ！）を提供します。 文字列は十分に短いため、JSONオブジェクトのフィールドとして簡単に追加できます。

   

   画像を最適化するだけではうまくいかない場合があります。 重要な画像のレンダリングを開始するために必要な時間を改善するには、重要度の低い画像を遅延ロードし、重要な画像が既にレンダリングされた後にロードするスクリプトを延期します。 最も防弾の方法は、ハイブリッド遅延読み込みです。ネイティブの遅延読み込みとlazyloadを利用する場合、ユーザーの操作によってトリガーされる可視性の変化を検出するライブラリです（IntersectionObserverについては後で説明します）。 さらに：

   • 重要な画像をプリロードすることを検討してください。そうすれば、ブラウザはそれらを遅すぎて検出しません。 背景画像の場合、それよりもさらに積極的にしたい場合は、 <img src>を使用して画像を通常の画像として追加し、画面から非表示にすることができます。
   • メディアクエリに応じて異なる画像表示サイズを指定して、サイズ属性で画像を交換することを検討してください。たとえば、拡大鏡コンポーネントでソースを交換するためにsizesを操作します。
   • 前景画像と背景画像の予期しないダウンロードを防ぐために、画像のダウンロードの不整合を確認してください。 デフォルトで読み込まれるが、表示されない可能性のある画像（カルーセル、アコーディオン、画像ギャラリーなど）に注意してください。
   • 画像のwidthとheightは必ず設定してください。 CSSのaspect-ratioプロパティとintrinsicsize属性に注意してください。これにより、画像のアスペクト比とサイズを設定できるため、ブラウザは事前定義されたレイアウトスロットを早期に予約して、ページの読み込み中にレイアウトがジャンプしないようにすることができます。

   

   冒険心があれば、Edgeワーカー（基本的にはCDNにあるリアルタイムフィルター）を使用してHTTP / 2ストリームを切り刻み、再配置して、ネットワーク経由で画像をより高速に送信できます。 エッジワーカーは、制御可能なチャンクを使用するJavaScriptストリームを使用するため（基本的には、ストリーミング応答を変更できるCDNエッジで実行されるJavaScriptです）、画像の配信を制御できます。

   サービスワーカーの場合、ネットワーク上にあるものを制御できないため手遅れになりますが、エッジワーカーでは機能します。 したがって、特定のランディングページ用に段階的に保存された静的JPEGの上でそれらを使用できます。

   

   十分じゃない？ また、複数の背景画像の手法を使用して、画像の知覚パフォーマンスを向上させることもできます。 コントラストで遊んだり、不要な詳細をぼかしたり（または色を削除したり）すると、ファイルサイズも小さくなる可能性があることに注意してください。 ああ、品質を落とさずに小さな写真を拡大する必要がありますか？ Letsenhance.ioの使用を検討してください。

   これまでのところ、これらの最適化は基本的なことだけをカバーしています。 Addy Osmaniは、画像圧縮とカラーマネジメントの詳細を深く掘り下げたEssential ImageOptimizationに関する非常に詳細なガイドを公開しています。 たとえば、画像の不要な部分を（ガウスぼかしフィルターを適用して）ぼかしてファイルサイズを小さくしたり、最終的には色を削除したり、画像を白黒に変えてサイズをさらに小さくしたりすることができます。 。 背景画像の場合、Photoshopから0〜10％の品質で写真をエクスポートすることも絶対に許容できます。

   Smashing Magazineでは、画像名に接尾辞-optを使用します—たとえば、 brotli-compression-opt.png ; 画像にその接尾辞が含まれている場合は常に、チームの全員が画像がすでに最適化されていることを知っています。

   ああ、WebでJPEG-XRを使用しないでください—「CPUでソフトウェア側のJPEG-XRをデコードする処理は無効になり、特にSPAのコンテキストでは、バイトサイズの節約による潜在的なプラスの影響を上回ります」（ Cloudinary / GoogleのJPEGXLと混同することもあります）。

   

1. ビデオは適切に最適化されていますか？
   これまで画像について説明してきましたが、古き良きGIFについての会話は避けました。 私たちがGIFを愛しているにもかかわらず、（少なくとも私たちのWebサイトやアプリでは）GIFを永久に放棄する時が来ました。 レンダリングパフォーマンスと帯域幅の両方に影響を与える重いアニメーションGIFをロードする代わりに、アニメーションWebP（GIFはフォールバック）に切り替えるか、ループHTML5ビデオに完全に置き換えることをお勧めします。

   画像とは異なり、ブラウザは<video>コンテンツをプリロードしませんが、HTML5ビデオはGIFよりもはるかに軽量で小さい傾向があります。 オプションではありませんか？ 少なくとも、不可逆GIF、gifsicle、またはgiflossyを使用してGIFに不可逆圧縮を追加できます。

   Colin Bendellによるテストでは、Safari Technology Previewのimgタグ内のインラインビデオは、ファイルサイズの一部であることに加えて、同等のGIFよりも少なくとも20倍速く、7倍速くデコードされることが示されています。 ただし、他のブラウザではサポートされていません。

   良いニュースの地では、ビデオフォーマットは何年にもわたって大幅に進歩しています。 長い間、WebMがそれらすべてを支配するフォーマットになり、WebP（基本的にはWebMビデオコンテナ内の1つの静止画像）が古い画像フォーマットの代わりになることを望んでいました。 確かに、Safariは現在WebPをサポートしていますが、最近WebPとWebMがサポートを獲得しているにもかかわらず、ブレークスルーは実際には起こりませんでした。

   それでも、最新のブラウザのほとんどにWebMを使用できます。

   <!-- By Houssein Djirdeh. https://web.dev/replace-gifs-with-videos/ --> <!-- A common scenartio: MP4 with a WEBM fallback. --> <video autoplay loop muted playsinline> <source src="my-animation.webm" type="video/webm"> <source src="my-animation.mp4" type="video/mp4"> </video>

   しかし、おそらく私たちはそれを完全に再考することができます。 2018年、Alliance of Open Mediaは、 AV1と呼ばれる新しい有望なビデオ形式をリリースしました。 AV1はH.265コーデック（H.264の進化形）と同様の圧縮を備えていますが、後者とは異なり、AV1は無料です。 H.265ライセンスの価格設定により、ブラウザベンダーは、代わりに同等のパフォーマンスを発揮するAV1を採用するようになりました。AV1（H.265と同様）は、WebMの2倍の圧縮率を実現します。

   

   実際、Appleは現在HEIF形式とHEVC（H.265）を使用しており、最新のiOSのすべての写真とビデオはJPEGではなくこれらの形式で保存されます。 HEIFとHEVC（H.265）は（まだ？）Webに適切に公開されていませんが、AV1は公開されており、ブラウザーのサポートを受けています。 したがって、すべてのブラウザベンダーが参加しているように見えるため、 <video>タグにAV1ソースを追加することは合理的です。

   現在、最も広く使用され、サポートされているエンコーディングはH.264であり、MP4ファイルによって提供されます。したがって、ファイルを提供する前に、MP4がマルチパスエンコーディングで処理され、frei0r iirblur効果（該当する場合）でぼやけていることを確認してください。サーバーがバイトサービングを受け入れている間、moovアトムメタデータはファイルの先頭に移動されます。 Boris Schapiraは、FFmpegがビデオを最大限に最適化するための正確な手順を提供します。 もちろん、代わりにWebM形式を提供することも役立ちます。

   ビデオのレンダリングをより速く開始する必要がありますが、ビデオファイルはまだ大きすぎますか？ たとえば、ランディングページに大きな背景動画があるときはいつでも？ 使用する一般的な手法は、最初に静止画像として最初のフレームを表示するか、ビデオの一部として解釈できる高度に最適化された短いループセグメントを表示してから、ビデオが十分にバッファリングされるたびに再生を開始することです。実際のビデオ。 Doug Sillarsは、その場合に役立つ可能性のあるバックグラウンドビデオパフォーマンスの詳細なガイドを作成しました。 （ありがとう、Guy Podjarny！ ）。

   上記のシナリオでは、レスポンシブポスター画像を提供することをお勧めします。 デフォルトでは、 video要素はポスターとして1つの画像のみを許可しますが、これは必ずしも最適ではありません。 レスポンシブビデオポスターを使用できます。これは、さまざまな画面にさまざまなポスター画像を使用できるJavaScriptライブラリであり、ビデオプレースホルダーのトランジションオーバーレイと完全なスタイリングコントロールも追加できます。

   調査によると、ビデオストリームの品質は視聴者の行動に影響を与えます。 実際、起動遅延が約2秒を超えると、視聴者は動画を放棄し始めます。 そのポイントを超えると、遅延が1秒増加すると、放棄率が約5.8％増加します。 したがって、ビデオの開始時間の中央値が12.8秒であり、ビデオの40％に少なくとも1つのストールがあり、20％に少なくとも2秒のビデオ再生が停止していることは驚くべきことではありません。 実際、ネットワークがコンテンツを提供できるよりも速くビデオが再生されるため、3Gではビデオのストールは避けられません。

   それで、解決策は何ですか？ 通常、小さな画面のデバイスは、デスクトップに提供している720pと1080pを処理できません。 Doug Sillarsによると、ビデオの小さいバージョンを作成し、Javascriptを使用して小さい画面のソースを検出して、これらのデバイスでの高速でスムーズな再生を保証することができます。 または、ストリーミングビデオを使用することもできます。 HLSビデオストリームは、適切なサイズのビデオをデバイスに配信します。これにより、画面ごとに異なるビデオを作成する必要がなくなります。 また、ネットワーク速度をネゴシエートし、使用しているネットワークの速度に合わせてビデオビットレートを調整します。

   帯域幅の浪費を避けるために、実際にビデオをうまく再生できるデバイスのビデオソースのみを追加することができました。 または、 videoタグからautoplay属性を完全に削除し、JavaScriptを使用してより大きな画面のautoplayを挿入することもできます。 さらに、 videoにpreload="none"を追加して、実際にファイルが必要になるまでビデオファイルをダウンロードしないようにブラウザに指示する必要があります。

   <!-- Based on Doug Sillars's post. https://dougsillars.com/2020/01/06/hiding-videos-on-the-mbile-web/ --> <video preload="none" playsinline muted loop width="1920" height="1080" poster="poster.jpg"> <source src="video.webm" type="video/webm"> <source src="video.mp4" type="video/mp4"> </video>

   次に、AV1を実際にサポートするブラウザを具体的にターゲットにできます。

   <!-- Based on Doug Sillars's post. https://dougsillars.com/2020/01/06/hiding-videos-on-the-mbile-web/ --> <video preload="none" playsinline muted loop width="1920" height="1080" poster="poster.jpg"> <source src="video.av1.mp4" type="video/mp4; codecs=av01.0.05M.08"> <source src="video.hevc.mp4" type="video/mp4; codecs=hevc"> <source src="video.webm" type="video/webm"> <source src="video.mp4" type="video/mp4"> </video>

   次に、特定のしきい値（ autoplayなど）を超えて自動再生を再度追加できます。

   /* By Doug Sillars. https://dougsillars.com/2020/01/06/hiding-videos-on-the-mbile-web/ */ <script> window.onload = addAutoplay(); var videoLocation = document.getElementById("hero-video"); function addAutoplay() { if(window.innerWidth > 1000){ videoLocation.setAttribute("autoplay",""); }; } </script>

   

   ビデオ再生パフォーマンスはそれ自体がストーリーです。詳細を知りたい場合は、ビデオ配信メトリックの詳細を含む、ビデオおよびビデオ配信のベストプラクティスの現状に関する別のダグシラーズのシリーズをご覧ください。 、ビデオのプリロード、圧縮、ストリーミング。 最後に、StreamまたはNotを使用して、ビデオストリーミングがどの程度遅くなるかまたは速くなるかを確認できます。

1. Webフォントの配信は最適化されていますか？
   質問する価値のある最初の質問は、最初にUIシステムフォントの使用を回避できるかどうかです。さまざまなプラットフォームで正しく表示されることを再確認する必要があります。 そうでない場合は、提供しているWebフォントに、使用されていないグリフや追加の機能やウェイトが含まれている可能性が高くなります。 書体ファウンドリにWebフォントのサブセット化を依頼するか、オープンソースフォントを使用している場合は、GlyphhangerまたはFontsquirrelを使用して独自にサブセット化することができます。 Peter Mullerのサブフォントを使用してワークフロー全体を自動化することもできます。これは、ページを静的に分析して最適なWeb​​フォントサブセットを生成し、それらをページに挿入するコマンドラインツールです。

   WOFF2のサポートは素晴らしく、WOFFをサポートしていないブラウザーのフォールバックとして使用できます。あるいは、レガシーブラウザーにシステムフォントを提供することもできます。 Webフォントの読み込みには非常に多くのオプションがあり、ZachLeathermanの「フォント読み込み戦略の包括的なガイド」（コードスニペットはWebフォント読み込みレシピとしても利用可能）から戦略の1つを選択できます。

   おそらく、今日検討すべきより良いオプションは、 preloadを使用したクリティカルFOFTと「妥協」方式です。 どちらも2段階のレンダリングを使用してWebフォントを段階的に配信します。最初に、Webフォントを使用してページを高速かつ正確にレンダリングするために必要な小さなスーパーサブセットを使用し、次にファミリの残りの部分を非同期でロードします。 違いは、「妥協」手法は、フォントロードイベントがサポートされていない場合にのみポリフィルを非同期にロードするため、デフォルトでポリフィルをロードする必要がないことです。 迅速な勝利が必要ですか？ Zach Leathermanには、フォントを整理するための23分間の簡単なチュートリアルとケーススタディがあります。

   一般に、 preloadリソースヒントを使用してフォントをプリロードすることをお勧めしますが、マークアップでは、重要なCSSおよびJavaScriptへのリンクの後にヒントを含めます。 preloadを使用すると、優先順位のパズルが発生するため、外部ブロッキングスクリプトの直前にrel="preload"要素をDOMに挿入することを検討してください。 Andy Daviesによると、「スクリプトを使用して挿入されたリソースは、スクリプトが実行されるまでブラウザーから隠されます。この動作を使用して、ブラウザーがpreloadヒントを検出するのを遅らせることができます。」 そうしないと、フォントの読み込みに最初のレンダリング時にコストがかかります。

   

   選択して最も重要なファイルを選択することをお勧めします。たとえば、レンダリングに不可欠なファイルや、目に見えて混乱を招くテキストのリフローを回避するのに役立つファイルなどです。 一般に、Zachは、各ファミリの1つまたは2つのフォントをプリロードすることをお勧めします。重要度が低い場合は、フォントのロードを遅らせることも理にかなっています。

   @font-faceルールでフォントfont-familyを定義するときに、 local()値（名前でローカルフォントを参照する）を使用することが非常に一般的になっています。

    /* Warning! Not a good idea! */ @font-face { font-family: Open Sans; src: local('Open Sans Regular'), local('OpenSans-Regular'), url('opensans.woff2') format ('woff2'), url('opensans.woff') format('woff'); }

   アイデアは合理的です。OpenSansなどの人気のあるオープンソースフォントには、一部のドライバーやアプリがプリインストールされているため、フォントがローカルで利用できる場合、ブラウザーはWebフォントをダウンロードする必要がなく、ローカルを表示できます。すぐにフォント。 Bram Steinが指摘したように、「ローカルフォントはWebフォントの名前と一致しますが、同じフォントではない可能性があります。多くのWebフォントは、「デスクトップ」バージョンとは異なります。テキストのレンダリングが異なる場合があり、一部の文字が落ちる場合があります。他のフォントに戻ると、OpenType機能が完全に欠落しているか、行の高さが異なる可能性があります。」

   また、書体は時間の経過とともに進化するため、ローカルにインストールされたバージョンはWebフォントとは大きく異なり、文字の外観も大きく異なる可能性があります。 したがって、Bramによれば、ローカルにインストールされたフォントとWebフォントを@font-faceルールに混在させない方がよいとのことです。 Google Fontsはそれに続いて、Robotoに対するAndroidリクエストを除く、すべてのユーザーのCSS結果でlocal()を無効にしました。

   コンテンツが表示されるのを待つのが好きな人はいません。 font-display CSS記述子を使用すると、フォントの読み込み動作を制御し、コンテンツをすぐに（ font-display: optionalで）またはほぼすぐに（フォントが正常にダウンロードされる限り、3秒のタイムアウトで）読み取り可能にすることができます。 font-display: swap ）。 （まあ、それよりも少し複雑です。）

   ただし、テキストリフローの影響を最小限に抑えたい場合は、 Font Loading API （最新のすべてのブラウザでサポートされています）を使用できます。 具体的には、すべてのフォントについて、 FontFaceオブジェクトを作成し、それらをすべてフェッチしてから、ページに適用することを意味します。 このように、すべてのフォントを非同期でロードしてすべての再描画をグループ化し、フォールバックフォントからWebフォントに1回だけ切り替えます。 32:15から始まるザックの説明とコードスニペットを見てください）：

   /* Load two web fonts using JavaScript */ /* Zach Leatherman: https://noti.st/zachleat/KNaZEg/the-five-whys-of-web-font-loading-performance#sWkN4u4 */ // Remove existing @font-face blocks // Create two let font = new FontFace("Noto Serif", /* ... */); let fontBold = new FontFace("Noto Serif, /* ... */); // Load two fonts let fonts = await Promise.all([ font.load(), fontBold.load() ]) // Group repaints and render both fonts at the same time! fonts.forEach(font => documents.fonts.add(font));
   /* Load two web fonts using JavaScript */ /* Zach Leatherman: https://noti.st/zachleat/KNaZEg/the-five-whys-of-web-font-loading-performance#sWkN4u4 */ // Remove existing @font-face blocks // Create two let font = new FontFace("Noto Serif", /* ... */); let fontBold = new FontFace("Noto Serif, /* ... */); // Load two fonts let fonts = await Promise.all([ font.load(), fontBold.load() ]) // Group repaints and render both fonts at the same time! fonts.forEach(font => documents.fonts.add(font));

   Font Loading APIを使用してフォントの非常に早いフェッチを開始するために、AdrianBeceは改行しないスペースnbsp; bodyの上部にあり、 aria-visibility: hiddenおよび.hiddenクラス：

   <body class="no-js"> <!-- ... Website content ... --> <div aria-visibility="hidden" class="hidden"> <!-- There is a non-breaking space here --> </div> <script> document.getElementsByTagName("body")[0].classList.remove("no-js"); </script> </body>
   <body class="no-js"> <!-- ... Website content ... --> <div aria-visibility="hidden" class="hidden"> <!-- There is a non-breaking space here --> </div> <script> document.getElementsByTagName("body")[0].classList.remove("no-js"); </script> </body>

   これは、さまざまな読み込み状態に対してさまざまなフォントファミリが宣言されているCSSに対応しており、フォントが正常に読み込まれると、Font LoadingAPIによって変更がトリガーされます。

   body:not(.wf-merriweather--loaded):not(.no-js) { font-family: [fallback-system-font]; /* Fallback font styles */ } .wf-merriweather--loaded, .no-js { font-family: "[web-font-name]"; /* Webfont styles */ } /* Accessible hiding */ .hidden { position: absolute; overflow: hidden; clip: rect(0 0 0 0); height: 1px; width: 1px; margin: -1px; padding: 0; border: 0; }
   body:not(.wf-merriweather--loaded):not(.no-js) { font-family: [fallback-system-font]; /* Fallback font styles */ } .wf-merriweather--loaded, .no-js { font-family: "[web-font-name]"; /* Webfont styles */ } /* Accessible hiding */ .hidden { position: absolute; overflow: hidden; clip: rect(0 0 0 0); height: 1px; width: 1px; margin: -1px; padding: 0; border: 0; }

   すべての最適化にもかかわらず、なぜLighthouseがレンダリングブロックリソース（フォント）を削除することを提案しているのか疑問に思ったことがある場合は、同じ記事でAdrian Beceが、パフォーマンスの高い非同期フォントであるGatsby Omni Font Loaderとともに、Lighthouseを幸せにするためのいくつかのテクニックを提供します。 Gatsby用のUnstyledText（FOUT）処理プラグインのロードとフラッシュ。

   現在、私たちの多くは、CDNまたはサードパーティのホストを使用してWebフォントをロードしている可能性があります。 一般に、可能であればすべての静的アセットをセルフホストすることをお勧めします。そのため、GoogleFontsをセルフホストする手間のかからない方法であるgoogle-webfonts-helperの使用を検討してください。 それが不可能な場合は、ページの原点を介してGoogleFontファイルをプロキシすることができます。

   グーグルは箱から出してかなりの作業を行っているので、サーバーは遅延を避けるために少し調整する必要があるかもしれません（ありがとう、バリー！ ）

   これは特に重要です。Chromev86（2020年10月にリリース）以降、ブラウザのキャッシュが分割されているため、フォントなどのクロスサイトリソースを同じCDNで共有できなくなりました。 この動作は、何年もの間Safariのデフォルトでした。

   しかし、それがまったく不可能な場合は、ハリー・ロバーツのスニペットを使用して、可能な限り最速のGoogleFontsにアクセスする方法があります。

   <!-- By Harry Roberts. https://csswizardry.com/2020/05/the-fastest-google-fonts/ - 1. Preemptively warm up the fonts' origin. - 2. Initiate a high-priority, asynchronous fetch for the CSS file. Works in - most modern browsers. - 3. Initiate a low-priority, asynchronous fetch that gets applied to the page - only after it's arrived. Works in all browsers with JavaScript enabled. - 4. In the unlikely event that a visitor has intentionally disabled - JavaScript, fall back to the original method. The good news is that, - although this is a render-blocking request, it can still make use of the - preconnect which makes it marginally faster than the default. --> <!-- [1] --> <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin /> <!-- [2] --> <link rel="preload" as="style" href="$CSS&display=swap" /> <!-- [3] --> <link rel="stylesheet" href="$CSS&display=swap" media="print" onload="this.media='all'" /> <!-- [4] --> <noscript> <link rel="stylesheet" href="$CSS&display=swap" /> </noscript>

   ハリーの戦略は、最初にフォントの出所を先制的にウォームアップすることです。 次に、CSSファイルの優先度の高い非同期フェッチを開始します。 その後、優先度の低い非同期フェッチを開始します。このフェッチは、ページが到着した後にのみ適用されます（印刷スタイルシートのトリックを使用）。 最後に、JavaScriptがサポートされていない場合は、元のメソッドにフォールバックします。

   ああ、Google Fontsについて話します。 &textで必要な文字だけを宣言することで、Google Fontsリクエストのサイズを最大90％削減できます。 さらに、フォント表示のサポートが最近Google Fontsにも追加されたため、そのまま使用できます。

   ただし、簡単に注意してください。 font-display: optionalを使用する場合、 preloadを使用すると、そのWebフォント要求が早期にトリガーされるため、最適ではない可能性があります（フェッチする必要のある他のクリティカルパスリソースがある場合、ネットワークの輻輳が発生します）。 クロスオリジンフォントリクエストを高速化するにはpreconnectを使用しますが、異なるオリジンwlllからフォントをpreloadするとネットワークの競合が発生するため、プリロードには注意してください。 これらのテクニックはすべて、ZachのWebフォント読み込みレシピでカバーされています。

   一方、ユーザーがユーザー補助設定で[モーションの削減]を有効にしている場合、またはデータセーバーモードを選択している場合は、Webフォント（または少なくとも第2段階のレンダリング）をオプトアウトすることをお勧めします（[ Save-Data ]ヘッダーを参照）。 、またはユーザーの接続が遅い場合（Network Information API経由）。

   ユーザーがデータ保存モードを選択した場合は、 prefers-reduced-data CSSメディアクエリを使用してフォント宣言を定義しないこともできます（他のユースケースもあります）。 メディアクエリは基本的に、CSSでの使用を可能にするためにクライアントヒントHTTP拡張機能からのSave-Dataリクエストヘッダーがオン/オフであるかどうかを公開します。 現在、フラグの背後にあるChromeとEdgeでのみサポートされています。

   指標？ Webフォントの読み込みパフォーマンスを測定するには、 All Text Visibleメトリック（すべてのフォントが読み込まれ、すべてのコンテンツがWebフォントで表示される瞬間）、Real Italicsまでの時間、および最初のレンダリング後のWebフォントのリフローカウントを考慮します。 明らかに、両方のメトリックが低いほど、パフォーマンスは向上します。

   可変フォントについてはどうですか？ 可変フォントでは、パフォーマンスを大幅に考慮する必要がある場合があることに注意してください。 それらは活版印刷の選択のためのはるかに広いデザインスペースを私たちに与えます、しかしそれは多くの個々のファイル要求とは対照的に単一のシリアル要求の代償を伴います。

   可変フォントはフォントファイルの全体的な合計ファイルサイズを大幅に削減しますが、その単一の要求は遅く、ページ上のすべてのコンテンツのレンダリングをブロックする可能性があります。 したがって、フォントをサブセット化して文字セットに分割することは依然として重要です。 ただし、良い面としては、可変フォントを使用すると、デフォルトでリフローが1つだけ取得されるため、再描画をグループ化するためにJavaScriptは必要ありません。

   では、防弾Webフォントの読み込み戦略を立てるにはどうすればよいでしょうか。 フォントをサブセット化して2段階レンダリング用に準備し、 font-display記述子で宣言し、Font Loading APIを使用して再描画をグループ化し、永続的なServiceWorkerのキャッシュにフォントを保存します。 最初の訪問時に、ブロックする外部スクリプトの直前にスクリプトのプリロードを挿入します。 必要に応じて、BramSteinのFontFaceObserverにフォールバックできます。 また、フォント読み込みのパフォーマンスの測定に関心がある場合は、AndreasMarschkeがFontAPIとUserTimingAPIを使用したパフォーマンス追跡について説明します。

   最後に、 unicode-rangeを含めて、大きなフォントを小さな言語固有のフォントに分解し、Monica Dinculescuのfont-style-matcherを使用して、フォールバックとWebフォント。

   または、フォールバックフォントのWebフォントをエミュレートするには、@ font-face記述子を使用してフォントメトリックをオーバーライドします（デモ、Chrome 87で有効）。 （ただし、複雑なフォントスタックでは調整が複雑になることに注意してください。）

   未来は明るく見えますか？ プログレッシブフォントエンリッチメントを使用すると、最終的には「任意のページでフォントの必要な部分のみをダウンロードし、その後のリクエストで、後続のページで必要に応じて元のダウンロードに追加のグリフセットを動的に「パッチ」することができるようになります。ジェイソン・パメンタルが説明しているように。 インクリメンタル転送デモはすでに利用可能であり、進行中です。

目次

1. 準備：計画と指標
2. 現実的な目標の設定
3. 環境の定義
4. 資産の最適化
5. ビルドの最適化
6. 配信の最適化
7. ネットワーキング、HTTP / 2、HTTP / 3
8. テストとモニタリング
9. クイックウィン
10. 1ページのすべて
11. チェックリストをダウンロードする（PDF、Apple Pages、MS Word）
12. 次のガイドを見逃さないように、メールマガジンを購読してください。