最初の部分で、著者はレスポンシブ画像の作成と配置に関連する問題に言及し、またsrcsetプロパティを使用する例を示しました。これはブラウザが最適なソースを選択するのに役立ち、サイトの速度を大幅に向上させます。 ただし、このアプローチには1つの問題があります。適切なソースを選択するには、画像レイアウトのサイズを知る必要があります。 また、HTML、CSS、およびJavaScriptページが読み込まれて解釈されるまで、ブラウザに選択を延期するように依頼することはできません。 したがって、ブラウザに、別の新しい属性であるサイズを使用して画像の表示幅を評価する機能を提供する必要があります。
この不愉快な真実をこの瞬間までどうやって隠したのですか？ サンプルページの詳細な画像は特別な場合です。 それらは、ウィンドウ全体の幅-100vwを占有します。偶然に判明したように、デフォルトではサイズになります。 ただし、ブランケット全体の画像は段落の幅に収まり、多くの場合、かなり小さい領域を占有します。 これは、sizes属性を使用してブラウザに直接の幅を伝えるのに役立ちます。
サイズはCSSの長さの値を受け入れます。 したがって：
sizes="100px"
...彼はブラウザにこの画像を100ピクセルの固定幅で表示します。
この例はもっと複雑です。 ブランケット画像は、単純な幅：100％ルールを使用してスタイル設定されるため、それを配置する値の最大幅（最大幅）は33emです。 幸いなことに、サイズによって次の2つのことができます。
1.複数の長さをコンマ区切りリストで指定できます。
2.これにより、環境条件を長さの値に関連付けることができます。
たとえば、次のように：
sizes="(min-width: 33em) 33em, 100vw"
これは、ウィンドウが33emよりも広い場合を意味しますか？ 次に、この画像の幅は33emになります。 それ以外の場合、100vwになります。
これは、私たちが必要とするものに近いものですが、そうではありません。 emの相対的な性質により、この例は陰湿になります。 ページの本文のフォントサイズは1.25emなので、図のCSSに関して「1em」はブラウザの標準フォントサイズの1.25 xになります。 ハンドラーの一部として（したがって、サイズ属性の一部として）、emは常に標準フォントサイズに等しくなります。 つまり、1.25を掛けるのが適切です：1.25 x 33 = 41.25。
sizes="(min-width: 41.25em) 41.25em, 100vw"
したがって、毛布の幅はかなりよくキャプチャされており、率直に言ってこれは良いことです。 これは、サイズ属性に100％適しているため、ブラウザに画像レイアウトの幅の概算を提供します。 多くの場合、読みやすさと製造性を向上させるためにわずかな精度を犠牲にすることが正しい選択です。 一方、図の両側のemインデントを考慮して、例をより正確にしましょう。2辺x 1.25環境条件emそれぞれ= 2.5 emインデントを考慮します。
<img srcset="quilt_3/large.jpg 1240w, quilt_3/medium.jpg 620w, quilt_3/small.jpg 310w" sizes="(min-width: 41.25em) 38.75em, calc(100vw - 2.5em)" src="quilt_3/medium.jpg" alt="A crazy quilt whose irregular fabric scraps are fit into a lattice of diamonds." />
ここで何をしたか見てみましょう。 srcsetを使用してブラウザーに大きなラッパーと画像の小さなバージョンを提供し、wパラメーターを使用して幅をピクセル単位で指定しました。 また、サイズを使用して画像が占めるスペースをブラウザに伝えました。
これが単純な例である場合、ブラウザに単純なCSSの長さを、サイズ=「100px」またはサイズ=「50vw」の形式で与えます。 しかし、私たちはとても不運でした。 ブラウザに2つのCSS長を指定し、特定の条件が発生した場合にのみ最初の長さを使用するように指定する必要がありました。
幸いなことに、この作業はすべて無駄ではありませんでした。 srcsetとサイズを使用して、ソースを選択するために必要なすべてのものをブラウザに提供しました。 ピクセル単位のソースの幅とイメージレイアウトの幅がわかっている場合、ブラウザーは各ソースのソースレイアウトの幅の比率を計算します。 したがって、サイズが620ピクセルであるとします。 幅が620wのソースは、画像の1xピクセルに等しくなります。 1240wソースは2倍になります。 310w？ 0.5倍 ブラウザはこれらの比率を計算してから、どのソースが最も好きかを選択します。
条件によって比率を直接確立でき、特性のないソースは標準の1倍の比率を受け取るため、マークアップを次のように記述できることに注意してください。
<img src="standard.jpg" srcset="retina.jpg 2x, super-retina.jpg 3x" />
これは、高解像度の画像を作成するためのコンパクトな方法です。 しかし！ 固定幅の画像に対してのみ機能します。 キルトページの画像はすべて「液体」なので、特性xについて言及するのはこれが最後です。
計測
パッチワークページをsrcsetとサイズで書き直したので、パフォーマンスの面で何が得られましたか？
ページの重量が（最終的に！）ロード条件に適合しました。 それは変化するので、単一の数としてそれを想像することはできません。 Chromeでページを何度もリロードし、幅の異なる多数のウィンドウでその重量を測定しました。
上部の灰色の平らな線は、元のバージョンの重量を3.5 MBの量で表しています。 太い（1x）と細い（2x）緑の線は、ページの重量を表し、320〜1280ピクセルの幅の異なるウィンドウのsrcsetとサイズで更新されます。
320ピクセルの幅で2倍にすると、ページの重量が3.5 MBになる前に、ページの重量が3分の2に減少します。 現在は1.1 MBのみを送信しています。 320ピクセル幅の1倍のページの重さは、元のサイズの10分の1（306 Kb）未満です。
この時点から、大きなウィンドウを埋める大きなソースをロードすると、バイト単位のサイズが徐々に増加します。 2xデバイスでは、幅が約350ピクセルのウィンドウに強くジャンプし、480ピクセル後に現状の重みに戻ります。 1倍では、違いは顕著です。960ピクセルの境界を越えるまで、元のページの重量の70〜80％を切り捨てます。 ここで、元の値よりもまだ40％少ないページに遭遇します。
そのような削減-40％、70％、90％-はあなたを止めるはずです。 Retinaスクリーンを搭載したiPhoneを起動するたびに、約2.5メガバイトを削減します。 これをすべてミリ秒単位で数えるか、数千ページビューで乗算すると、この大騒ぎが何であるかを理解できます。
レスポンシブイメージの問題を解決する別のアプローチがあります。これについては、第3部で説明します。
パート3
Habré読者向けの便利なPaystoソリューション：