(jp) =
私が Stitcher を使い始めたときの主な目標の 1 つは、画像を大幅に最適化することでした。 HTTP アーカイブの統計を見ると、何か間違ったことをしていることは明らかです。 幸いなことに、レスポンシブ画像仕様は、画像の問題に対処するために多くの賢い人々によって作成されました. 私の目標は、この仕様を開発者が十分に活用できるように、Stitcher に実装することでした。 まだ完全には達成できていませんが、近づいています。 このブログ投稿では、このライブラリの作成に直面した課題についてお話したいと思います。 そして、ブログ投稿を読むよりもコードに興味がある場合は、どうぞ。
明確にするために、レスポンシブ画像仕様の目標は、画像のダウンロード時に使用される帯域幅を削減することです。 今日の画像は非常に多くの帯域幅を必要とします。 考えてみると、画面上の画像の幅が 500 ピクセルしかないのに、幅が 2000 ピクセルの画像をロードするのは正気ではありません。 それが仕様が対処する問題であり、私が Stitcher で解決したかった問題です。
したがって、1 つの画像を入力し、さまざまなサイズの同じ画像の x 量を出力し、どの画像を読み込むのが最適かをブラウザーに判断させます。 そのソース画像を縮小するにはどうすればよいですか? それが私が答えたかった最も重要な質問でした。 テンプレートのアクセシビリティや、生成された画像ファイルを公開する方法など、他のすべての問題は、Stitcher 自体の問題でした。
画像のダウンスケーリングに関する私の最初の見解は次のとおりです。
ソース イメージと一連の構成パラメーターを取得します。 これらのパラメータは、画像のバリエーションの最大量と画像の最小幅を決定します。 例えば。 最大 10 個の画像が必要で、最小の画像は幅 300 ピクセルです。 現在、アルゴリズムは最大 10 回ループし、常に前の画像より幅が 10% 小さい画像を作成します。
これが最適なアプローチではないことは既にお分かりかもしれません。 結局のところ、画像をロードするときに使用される帯域幅を削減しようとしています。 10% 縮小された画像のサイズも縮小される保証はありません。 どの画像コーデックが使用されているか、および画像自体に何が含まれているかによって大きく異なります。 しかし、早い段階でこのアプローチを使用することで、Stitcher でこの「イメージ ファクトリ」を実装することができました。 次にアルゴリズムの最適化に取り組みますが、当面はStitcherの統合に取り組むことができました.
# スティッチャーとの連携
レスポンシブ画像についてスティッチャーに知らせることは、簡単であると同時に困難でもありました。 基本的な枠組みはすでにそこにありました。 そのため、レスポンシブ ファクトリを使用して画像の配列表現を返す画像プロバイダーを簡単に作成できました。 テンプレートの構文は次のようになります。
<img src="$image.src" srcset="$image.srcset" sizes="$image.sizes" />残念ながら、すべての CSS のクロールを開始し、基本的に PHP でブラウザー エンジンを実装しない限り、サイズの部分を自動化する方法はありません。 この部分に対する私の解決策は、事前に定義されたサイズのセットです。 それはまだ進行中の作業ですが、使いやすくする方法はまだわかりません. 今のところ、テンプレート コードを記述するときに手動でサイズを指定しているだけです。
しかし、難しいのはサイズではなく、srcset でもありません。 パスと URL を処理していました。 私は、Stitcher フレームワーク全体でこれに気付きました。正しいパスと URL (正しい数のスラッシュ、正しいルート ディレクトリなど) を作成することは、実際には管理が非常に面倒です。 私は、常に正しいパスと URL をレンダリングする何らかのヘルパーが必要であると確信しています。 それは私のtodoリストにあります。
このブログ投稿は以上です。次は、画像アルゴリズムの最適化について書きます。