圧縮とエンコードの自動化

パフォーマンスの高い画像ソースをシームレスに生成開発プロセスに集中できます。

画像データのエンコードから情報密度の高いモデルまで、このコースのすべての構文をレスポンシブ画像を強化するマークアップとは、マシンがマシンと通信するための手法です。残高がありますは、クライアントのブラウザがニーズをサーバーに伝達し、サーバーが実質的に応答するさまざまな方法を発見しました。レスポンシブ画像マークアップ（特に srcset と sizes）は、驚くほど多くの情報を比較的数文字です。良くも悪くも、その簡略化は意図的なものです。つまり、構文を簡潔にし、デベロッパーが簡単に行えるようにします。 ブラウザが解析しにくくなる可能性もあります。文字列が複雑になるほど、パーサーのエラーや、ブラウザ間で意図しない動作の違いが発生する可能性があります。

自動画像エンコードウィンドウ。

しかし、こうした主題を怖がらせる可能性があるのと同じ特性が解決策を提供することも可能である。すなわち、構文が read は、マシンによって簡単に記述できる構文です。皆さんもほぼ間違いなく、自動化されたソリューションの例をウェブのユーザーとしての画像のエンコードと圧縮（ソーシャルメディアプラットフォームからウェブにアップロードされた画像、コンテンツメールクライアントでさえ、サイズ変更、再エンコード、圧縮します

同様に、プラグイン、外部ライブラリ、スタンドアロンのビルドプロセスツール、またはクライアントサイドスクリプトの責任ある使用レスポンシブ画像マークアップは自動化に適しています。

これらは、画像のパフォーマンスの自動化に関する 2 つの主な懸念事項です。1 つは画像の作成の管理、すなわちエンコード、圧縮、srcset 属性を入力し、ユーザー向けのマークアップを生成するために使用する代替ソース。このモジュールでは、最新のワークフローの一部としてイメージを管理するための一般的なアプローチをいくつか学びます。サイトを活用しているフレームワークやコンテンツマネジメントシステムを通じて、開発プロセスの自動化されたフェーズ。専用のコンテンツ配信ネットワークによってほぼ完全に抽象化されます。

圧縮とエンコードの自動化

通常は、最適なエンコードとレベルを手動で判断するために時間をかける必要はないでしょう。プロジェクトで使用する画像ごとに 1,500 倍の圧縮率を誇ります。として画像の転送サイズをできるだけ小さくすることが重要であり、圧縮設定を行い、本番環境のウェブサイト向けの画像アセットごとに代替ソースを再保存すると、大きなボトルネックになるでしょう

さまざまな画像形式と圧縮タイプについての説明を読んだときに学んだように、画像の最も効率的なエンコードは常にレスポンシブ画像で説明したとおり、画像ソースに必要な代替サイズは次のとおりです。ページレイアウト内で画像が占有する位置によって決まります。最新のワークフローでは、これらの決定に個別にではなく全体として、画像の適切なデフォルト値のセットを決定し、使用されることを想定しています。

写真画像のディレクトリのエンコードを選択する場合は、品質と転送サイズにおいて AVIF の方が明らかに優れています。サポートは限られています。WebP は最適化された最新のフォールバックを提供します。JPEG は最も信頼性の高いデフォルトです。代替ページレイアウトのサイドバーに表示される画像用に作成する必要がある画像は、ブラウザビューポート全体を占有します。圧縮設定では、ぼかしに注意する必要があります圧縮アーティファクトが生成され、各画像から可能な限りすべてのバイトを切り出すスペースが少なくなります。より柔軟で信頼性の高いワークフローを使用できます要するに、これまでと変わらない意思決定プロセスに沿って進めることになります。本コースで学んだことを大いに活用します

画像処理自体については、画像処理のメソッドを提供するオープンソースの画像処理ライブラリが数多くあります。画像の変換、変更、編集を一括で行い、スピード、効率、信頼性の面で競合します。これらの処理はライブラリを使用すると、エンコードと圧縮の設定を画像のディレクトリ全体に一度に適用できます。画像編集ソフトウェアを開く必要があります。また、設定が必要な場合は、元の画像ソースを維持する必要があります。その場で調整できますこれらはローカル開発環境からたとえば、圧縮にフォーカスした ImageMin を、ウェブサーバーに対して Node.js は、プラグイン、クロスプラットフォームの ImageMagick と Node.js ベースの Sharp 驚くほど多くの機能が最初から組み込まれています。

これらの画像処理ライブラリにより、デベロッパーは画像をシームレスに最適化するためのツールを構築できます。プロジェクトから常に本番環境に対応したイメージが参照されるようにするオーバーヘッドを最小限に抑えます。

ローカル開発ツールとワークフロー

Grunt、Gulp、Webpack などのタスクランナーとバンドラを使用して、画像アセットの最適化と、CSS や JavaScript の圧縮といったパフォーマンスに関連するその他の一般的なタスクを併用できます。宛先比較的シンプルなユースケースを見ていきましょう。たとえば、プロジェクトのディレクトリに 12 枚の写真画像が保存され、一般向けウェブサイトで使用することを想定した

まず、これらの画像を一貫して効率的にエンコードする必要があります。前のモジュールで学んだように WebP は、画質とファイルサイズの点で写真画像のデフォルトとして効率的です。WebP は十分にサポートされている すべてのケースでサポートされているわけではないため、プログレッシブ JPEG の形式の代替も含めます。その後、 srcset 属性を使用してこれらのアセットを効率的に配信するには、複数の代替サイズを指定します。

画像編集ソフトウェアを使用すると、これは繰り返しの手間と時間のかかる面倒になりますが、 Gulp は、まさにこのような繰り返しを自動化するように設計されています。gulp-response はプラグインは、Sharp を使用している多くの選択肢の 1 つで、いずれも同様のパターンに従います。ソースディレクトリですべてのファイルを収集し、再エンコードして、同じ標準化された「品質」に基づいて圧縮する「Image Formats and Compression」で学んだ省略形です。生成されたファイルは、定義したパスに出力されます。元のファイルはそのままにして、ユーザー向けの img 要素の src 属性で参照できるようにします。

const { src, dest } = require('gulp');
const respimg = require('gulp-responsive');

exports.webp = function() {
  return src('./src-img/*')
    .pipe(respimg({
      '*': [{
        quality: 70,
        format: ['webp', 'jpeg'],
        progressive: true
      }]
  }))
  .pipe(dest('./img/'));
}

このようなプロセスがあれば、プロジェクトの関係者が誤っていても、本番環境に害が及ぶことはありません。は、元の画像ソースを含むディレクトリに、大規模なトゥルーカラーの PNG でエンコードされた写真を追加しました。このタスクでは、効率的な WebP と信頼性の高いプログレッシブ JPEG フォールバックが生成されます。その場で簡単に調整できる圧縮レベルです。もちろん、このプロセスでは元の画像がファイルはプロジェクトの開発環境内に保持されるため、いつでも設定を変更できます。自動出力のみが上書きされます。

複数のファイルを出力するには、複数の設定オブジェクトを渡します。 width キーとピクセル単位の値:

const { src, dest } = require('gulp');
const respimg = require('gulp-responsive');

exports.default = function() {
  return src('./src-img/*')
    .pipe(respimg({
    '*': [{
            width: 1000,
            format: ['jpeg', 'webp'],
            progressive: true,
            rename: { suffix: '-1000' }
            },
            {
            width: 800,
            format: ['jpeg', 'webp'],
            progressive: true,
            rename: { suffix: '-800' }
            },
            {
            width: 400,
            format: ['jpeg', 'webp'],
            progressive: true,
            rename: { suffix: '-400' },
        }]
        })
    )
    .pipe(dest('./img/'));
}

上記の例では、元の画像（monarch.png）が 3.3 MB を超えています。生成される最大のファイルはこのタスク（monarch-1000.jpeg）のサイズは約 150 KB です。最もサイズが小さい monarch-400.web はわずか 32 KB です。

[10:30:54] Starting 'default'...
[10:30:54] gulp-responsive: monarch.png -> monarch-400.jpeg
[10:30:54] gulp-responsive: monarch.png -> monarch-800.jpeg
[10:30:54] gulp-responsive: monarch.png -> monarch-1000.jpeg
[10:30:54] gulp-responsive: monarch.png -> monarch-400.webp
[10:30:54] gulp-responsive: monarch.png -> monarch-800.webp
[10:30:54] gulp-responsive: monarch.png -> monarch-1000.webp
[10:30:54] gulp-responsive: Created 6 images (matched 1 of 1 image)
[10:30:54] Finished 'default' after 374 ms

もちろん、目に見える圧縮アーティファクトがないか慎重に結果を確認するか、場合によっては圧縮率を上げる必要があります。さらに節約できます。このタスクは非破壊的なので、この設定は簡単に変更できます。

端的に言えば、慎重な手動の細かい最適化によって数キロバイトを切り取ることと引き換えに、高パフォーマンスな画像アセットに関する知識をシームレスに応用できる、効率的かつ復元力があるツールプロジェクト全体に適用できます。

レスポンシブ画像のマークアップの実例

srcset 属性への入力は、通常は単純な手動プロセスになります。これは、この属性は実際にソースの生成時に行った設定に関する情報が表示されます。上記のタスクにおいて、属性がたどるファイル名と幅の情報:

srcset="filename-1000.jpg 1000w, filename-800.jpg 800w, filename-400.jpg 400w"

srcset 属性の内容は説明であり、規範的なものではありません。過負荷状態になっても srcset 属性。ただし、すべてのソースのアスペクト比が一貫している必要があります。srcset 属性には URI を含めることができます。サーバーで生成されたすべての代替カットの幅と幅が、不要なリクエストを発生させることなく提供されるソースにより、ブラウザはより効率的にリクエストを調整できます。

レスポンシブ画像で学んだように、<picture> 要素を使用して WebP をシームレスに処理することをおすすめします。いずれかを選択できますこの場合、type 属性と srcset を組み合わせて使用します。

<picture>
  <source type="image/webp" srcset="filename-1000.webp 1000w, filename-800.webp 800w, filename-400.webp 400w">
  <img srcset="filename-1000.jpg 1000w, filename-800.jpg 800w, filename-400.jpg 400w" sizes="…" alt="…">
</picture>

すでに学習したように、WebP をサポートするブラウザは type 属性の内容を認識し、その <source> を選択します。要素の srcset 属性を画像候補のリストとして指定します。image/webp を有効なメディアとして認識しないブラウザ型はこの <source> を無視し、代わりに内部 <img> 要素の srcset 属性を使用します。

ブラウザのサポートに関してもう一つ考慮すべき点があります。レスポンシブな画像のマークアップに対応していないブラウザでは、代替手段がまだ必要でない場合、特に古いブラウジング環境で画像が破損するリスクがあります。<picture>のため、これらのブラウザで <source> と srcset はすべて無視されるため、内部の <img> でデフォルトのソースを指定します。 src 属性。

画像を下方向に縮小することは視覚的にシームレスであり、JPEG エンコードは広くサポートされているため、最大の JPEG は合理的です

<picture>
  <source type="image/webp" srcset="filename-1000.webp 1000w, filename-800.webp 800w, filename-400.webp 400w">
  <img src="filename-1000.jpg" srcset="filename-1000.jpg 1000w, filename-800.jpg 800w, filename-400.jpg 400w" sizes="…" alt="…">
</picture>

sizes は処理が少し難しい可能性があります。学んだように、sizes は必ずしもコンテキストに依存します。は、レンダリングされたレイアウト内で画像が占めるはずのスペースを把握していないと、属性を入力できません。対象リクエストの効率を高めるためには、リクエストの際にマークアップに正確な sizes 属性を含める必要があります。ページレイアウトを管理するスタイルがリクエストされるはるか前に、エンドユーザーが作成する。sizes を完全に省略これは HTML 仕様に違反するだけでなく、sizes="100vw" と同等のデフォルトの動作になり、この画像はビューポートそのものにしか制約がないとブラウザに伝えるため、候補となるソースが最大となる選択します。

特に負担の大きいウェブ開発タスクの場合と同様に、 sizes 属性を手書きするプロセス。respImageLint は、 sizes 属性の正確性を精査し、改善の提案を行うことを目的とした重要なコードスニペットです。ブックマークレットとして動作し、画像を含む完全にレンダリングされたページをブラウザ内で実行するツールです。あります。ブラウザがページレイアウトを完全に理解している状況では、ほぼピクセルパーフェクトレイアウト内で画像が占有するスペースを、想定されるすべてのビューポートサイズで認識できるようにします。

サイズまたは幅が一致しないレスポンシブ画像レポート。

sizes 属性を lint チェックするツールは確かに便利ですが、属性を一括して生成するためのツールとして、さらに大きな価値があります。すでに説明したとおり、srcset と sizes の構文は、画像アセットのリクエストを視覚的にシームレスに最適化することを目的としています。しかし、本番環境で使用すべきではないものなので、デフォルトの sizes プレースホルダ値を 100vw にしても問題ありません。ローカル開発環境でページのレイアウトを編集するときにレイアウトスタイルを設定したら、respImageLint を実行します。では、カスタマイズされた sizes 属性が提供されます。これをコピーしてマークアップに貼り付けることができます。詳細なレベルでは、向上します

推奨サイズが表示されたレスポンシブ画像レポート。

サーバーレンダリングのマークアップによって開始された画像リクエストは短時間で発生しますが、JavaScript ではクライアント側の sizes 属性を生成できません。これらのリクエストがクライアントサイドで開始される場合には、同じ理由は適用されません。Lazysizes プロジェクトたとえば、レイアウトが確立されるまで画像リクエストを完全に延期し、JavaScript で Google の sizes 値。これは、ニュースメディアにとって大きな利便性であり、ユーザーにとって可能な限り効率的なリクエストを保証するものです。ただし、この方法ではサーバーレンダリングのマークアップの信頼性と処理速度が犠牲になることに注意してください。最適化が組み込まれており、ページがレンダリングされた後にのみこれらのリクエストを開始すると、 LCP スコアに悪影響を及ぼします

もちろん、React や Vue といったクライアントサイドのレンダリングフレームワークにすでに依存している場合、それは負担になってしまうことになるでしょう。その場合、Lazysizes を使用すると sizes 属性をほぼ完全に抽象化できます。さらに良い例: 遅延読み込み画像に対する sizes="auto" がコンセンサスを得て、実装すると、Lazysizes は実質的に、新たに標準化されたブラウザ動作のポリフィルになります。