이 모듈에서는 브라우저에 표시할 이미지 선택권을 제공하는 방법을 배웁니다. srcset
특정 중단점에서 이미지 소스를 바꾸는 메서드가 아니며 한 이미지를 다른 이미지로 교체하는 것도 아닙니다. 이러한 구문을 사용하면
매우 어려운 문제를 해결하기 위해 브라우저를 사용하고 있습니다. 사용자의 탐색 컨텍스트에 맞는 이미지 소스를 원활하게 요청하고 렌더링하는 것입니다.
사용자 환경설정, 대역폭 및 기타 셀 수 있는 요소 등 다양한 요인이 포함될 수 있습니다.
이는 큰 요청입니다. 웹에 단순히 이미지를 마크업할 때 고려하고 싶은 것보다 더 좋은 것이고, 이를 잘 수행하기 위해서는 더 많은 작업이 필요합니다. 제한하기 때문입니다.
x로 밀도 설명
너비가 고정된 <img>는 사용자 화면의 밀도와 관계없이 모든 탐색 컨텍스트에서 표시 영역의 동일한 양을 차지합니다.
디스플레이—화면을 이루는 물리적 픽셀의 수입니다. 예를 들어 고유한 너비가 400px인 이미지는 거의
원래의 Google Pixel과 최신 Pixel 6 Pro의 전체 브라우저 표시 영역(두 기기 모두 정규화된 412px
논리 픽셀 넓은 표시 영역
Pixel 6 Pro의 디스플레이는 훨씬 선명하지만 6 Pro의 실제 해상도는 1440×3120픽셀인 반면 픽셀은 1080×1920픽셀입니다. 즉, 화면 자체를 구성하는 하드웨어 픽셀의 수입니다.
기기의 논리적 픽셀과 실제 픽셀 간의 비율은 해당 디스플레이 (DPR)의 기기 픽셀 비율입니다. DPR: 기기의 실제 화면 해상도를 표시 영역의 CSS 픽셀로 나누어 계산합니다.
따라서 원래 Pixel의 DPR은 2.6이고 Pixel 6 Pro의 DPR은 3.5입니다.
DPR이 1보다 큰 첫 기기인 iPhone 4는 기기 픽셀 비율이 2라고 보고하며, 화면의 물리적 해상도는 논리 해상도를 두 배로 늘립니다. iPhone 4 이전의 모든 장치는 논리 픽셀 1 대 물리적 픽셀 1의 DPR을 가지고 있었습니다.
DPR이 2인 디스플레이에서 400px 너비의 이미지를 보면 각 논리 픽셀은
가로 2개, 세로 2개라는 디스플레이의 물리적 픽셀입니다. 이 이미지는 고밀도 디스플레이의 이점을 누릴 수 없습니다.
DPR이 1인 디스플레이와 동일합니다. 물론 '그린' 것은 브라우저 렌더링 엔진(텍스트, CSS 도형 또는 SVG)에 의해
고밀도 디스플레이에 맞게 그려집니다. 하지만 이미지 형식 및 압축에서 알아본 것처럼 래스터 이미지는 고정되어 있습니다.
픽셀 그리드를 만들 수 있습니다. 항상 선명하게 보이는 것은 아니지만 고밀도 디스플레이에 맞게 업스케일링된 래스터 이미지가
해상도가 낮습니다.
이러한 확대를 방지하려면 렌더링되는 이미지의 고유 너비가 800픽셀 이상이어야 합니다. 축소 시
너비가 400 논리 픽셀인 레이아웃의 공간에 맞추기 위해 800픽셀 이미지 소스는 픽셀 밀도가 두 배로 DPR이 2인 디스플레이에서 두 배가 됩니다.
근사하고 선명하게 보일 것입니다.
DPR이 1인 디스플레이는 증가한 이미지 밀도를 사용할 수 없으므로
아시다시피 축소된 이미지도 괜찮습니다. 저밀도 디스플레이에서 고밀도에 적합한 이미지
다른 저밀도 이미지와 비슷해 보입니다.
이미지 및 성능에서 알아본 것처럼 저밀도 디스플레이를 사용하는 사용자는 400px로 축소된 이미지 소스를 봅니다.
고유 너비가 400px인 소스만 필요합니다. 훨씬 더 큰 이미지가 시각적으로 모든 사용자에게 효과적일 수 있지만
작은 저밀도 디스플레이에서 렌더링된 고해상도 이미지 소스는 다른 작은 저밀도 이미지와 같지만 훨씬 느리게 느립니다.
짐작할 수 있듯이 DPR이 1인 휴대기기는 거의 드문 기기입니다. 여전히 "데스크톱"에서 컨텍스트 탐색을 참조하세요. 데이터에 따르면 맷 홉스의 조사 결과, 2022년 11월 기준 GOV.UK 탐색 세션의 약 18% 가 DPR을 1로 보고함 고밀도 이미지는 사용자가 예상하는 대로 보이겠지만 훨씬 높은 대역폭과 처리 비용이 발생합니다. 특히 저밀도 디스플레이를 사용할 가능성이 높은 구식 및 덜 강력한 기기 사용자의 경우 특히 우려할 수 있습니다.
srcset를 사용하면 고해상도 디스플레이를 갖춘 기기만 선명하게 보일 만큼 큰 이미지 소스를 수신할 수 있으며, 이때 동일한 이미지를 전달하지 않습니다.
대역폭 비용을 저해할 수 있습니다.
srcset 속성은 이미지를 렌더링하기 위한 하나 이상의 쉼표로 구분된 후보를 식별합니다. 각 후보자는
src에서 사용하는 것과 같은 URL과 이미지 소스를 설명하는 문법이 있습니다. srcset의 각 후보자
이는 고유한 너비('w 구문') 또는 원하는 밀도('x 구문')로 설명됩니다.
x 문법은 '이 소스는 이 밀도가 있는 디스플레이에 적합'의 약식 표현으로, 2x가 뒤에 오는 후보는 다음과 같습니다.
디스플레이에 적합합니다.
<img src="low-density.jpg" srcset="double-density.jpg 2x" alt="...">
srcset을(를) 지원하는 브라우저에는 두 가지 후보(double-density.jpg(2x)가 적절하게 설명됨)가 표시됩니다.
DPR이 2이고 src 속성에 low-density.jpg인 디스플레이: 더 적절하지 않은 경우 선택된 후보
srcset에 있습니다. srcset를 지원하지 않는 브라우저의 경우 속성과 그 콘텐츠가 무시됩니다(src의 콘텐츠).
평소처럼 요청됩니다
srcset 속성에 지정된 값을 지침으로 잘못 판단하기 쉽습니다. 이 2x는 브라우저에
관련 소스 파일은 소스 자체에 대한 정보인 DPR이 2인 디스플레이에 사용하기에 적합합니다. 그것은 말하지
브라우저는 해당 소스를 사용하는 방법을 브라우저에 알립니다. 미묘하지만 중요한 차이점입니다.
이중 밀도 디스플레이에 사용하기 위한 이미지가 아닌 이중 밀도 이미지입니다.
'이 소스는 2x 표시에 적합합니다'라는 구문의 차이점 다른 하나는 "use this source on 2x 디스플레이"라고 되어 있습니다.
가 약간 크지만 디스플레이 밀도는 브라우저가 후보를 결정하는 데 사용하는 수많은 상호 연결된 요소 중 하나일 뿐입니다.
이 중 일부만 알고 있을 뿐입니다. 예를 들어, 개별적으로 사용자가 특정 기능을 사용 설정했는지 확인할 수
prefers-reduced-data 미디어 쿼리를 통해 대역폭을 절약하는 브라우저 환경설정을 구성하며, 이를 사용하여 항상 사용자가 저밀도 이미지를 선택하도록 합니다.
모든 개발자, 모든 웹사이트에서 일관되게 구현하지 않는다면 사용자에게 큰 도움이 되지 않습니다.
어떤 사이트에서는 선호도가 존중되고 있지만 다른 사이트에서는 대역폭을 허무는 이미지의 벽에 부딪히게 될 수도 있습니다.
srcset/sizes에서 사용하는 의도적으로 모호한 리소스 선택 알고리즘으로 인해 브라우저에서 더 낮은 밀도를 선택할 여력이 남습니다.
대역폭이 급락하는 이미지 또는 데이터 사용량을 최소화하려는 선호에 따라 Google이 이러한 이미지를
지정할 수도 있습니다 브라우저가 사용자를 위해 더 잘 처리할 수 있도록 책임과 추가 작업을 맡기는 것은 의미가 없습니다.
w로 너비 설명
srcset는 이미지 소스 후보에 대해 두 번째 유형의 설명어를 허용합니다. 이것은 훨씬 더 강력하며 우리의 목적에 따라
훨씬 쉽게 이해할 수 있습니다 주어진 디스플레이 밀도에 적합한 크기를 가진 것으로 후보를 플래그하는 대신
w 구문은 각 후보 소스의 고유한 너비를 설명합니다. 다시 말하지만 각 후보는 동일한 치수를 제외하고 동일합니다.
동일한 자르기,
가로세로 비율을 적용할 수 있습니다 그러나 이 경우에는 사용자의 브라우저가 다음 두 가지 후보 중 하나를 선택하게 하려고 합니다.
고유한 너비가 600px인 소스인 small.jpg와 고유 너비가 1200px인 large.jpg가 있습니다.
srcset="small.jpg 600w, large.jpg 1200w"
이 명령은 이 정보로 수행해야 하는 작업을 브라우저에 알려주지 않으며, 이미지를 표시할 후보 목록을 제공하기만 합니다.
브라우저가 렌더링할 소스에 대한 결정을 내리려면 먼저 다음과 같은 약간의 추가 정보를 제공해야 합니다.
페이지에서 이미지가 렌더링되는 방식에 대한 설명입니다. 이렇게 하려면 sizes 속성을 사용합니다.
sizes로 사용 설명
브라우저는 이미지 전송에 있어서 놀라울 정도로 뛰어난 성능을 발휘합니다. 이미지 확장 소재에 대한 요청이 오랫동안 시작됩니다. 을 사용해야 합니다. 이는 종종 마크업이 완전히 파싱되기 전에도 발생합니다. 브라우저에서 가 이러한 요청을 하는 경우 마크업을 제외하고 페이지 자체에 관한 정보가 없고 요청을 시작하지 않았을 수도 있습니다. 적용되지 않습니다. 브라우저가 마크업을 파싱하고 외부 요청에는 사용자의 표시 영역 크기, 사용자 디스플레이의 픽셀 밀도, 사용자 환경설정 등입니다.
이렇게 해도 이미지가 페이지 레이아웃에서 어떻게 렌더링되는지는 알 수 없습니다. 표시 영역을 사용할 수도 없습니다.
가로 스크롤 컨테이너를 차지할 수 있으므로 img 크기의 상한값의 프록시로 사용합니다. 따라서
브라우저에 이 정보를 제공하고 마크업을 사용합니다. 이 요청에 대해 사용할 수 있는 것은 이것뿐입니다.
srcset와 마찬가지로 sizes는 마크업이 파싱되는 즉시 이미지에 관한 정보를 제공하기 위한 것입니다. srcset와 동일
속성은 '소스 파일과 파일 고유의 크기'의 약칭입니다. sizes 속성은 '여기'의 약칭입니다.
는 레이아웃에서 렌더링된 이미지의 크기입니다." 이미지를 설명하는 방식은 표시 영역을 기준으로 합니다.
size는 이미지 요청이 있을 때 브라우저가 갖는 유일한 레이아웃 정보입니다.
인쇄판에서는 약간 복잡하게 들릴 수 있지만 실제로 이해하기 훨씬 쉽습니다.
<img
sizes="80vw"
srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 2000w"
src="fallback.jpg"
alt="...">
여기서 이 sizes 값은 img가 차지하는 레이아웃에서 공간의 너비가 80vw~80% 임을 브라우저에 알립니다.
있습니다. 이는 지침이 아니라 페이지 레이아웃의 이미지 크기에 관한 설명입니다. '이거 만들어 줘'라고
이미지가 표시 영역의 80% 를 차지합니다." 그러나 '이 이미지는 페이지가 렌더링되고 나면 표시 영역의 80% 를 차지하게 됩니다.'
개발자의 역할은 완료되었습니다. srcset의 후보 출처 목록과 이미지 너비를 정확하게 설명하셨습니다.
srcset의 x 구문과 마찬가지로 나머지는 브라우저에 따라 다릅니다.sizes
하지만 이 정보가 어떻게 사용되는지 완전히 이해하기 위해 사용자의 브라우저에서 다음과 같은 마크업을 확인합니다.
이 이미지가 사용 가능한 표시 영역의 80% 를 차지할 것이라고 브라우저에 알렸습니다. 따라서 이 img를
표시 영역이 1000픽셀인 경우 이 이미지는 800픽셀을 차지합니다. 그러면 브라우저는 이 값을 사용하여
srcset에서 지정한 각 이미지 소스 후보의 너비입니다. 가장 작은 소스의 고유한 크기는 600픽셀이며,
600÷800=0.75가 됩니다. 중간 이미지의 너비는 1200픽셀(1200÷800=1.5)이며 가장 큰 이미지의 너비는 2000픽셀(2000÷800=2.5)이며
이러한 계산의 결과 (.75, 1.5, 2.5)는 실질적으로 사용자의
표시 영역 크기입니다. 브라우저는 사용자의 디스플레이 밀도에 관한 정보도 보유하고 있으므로 다음과 같은 일련의 결정을 내립니다.
이 표시 영역 크기에서 small.jpg 후보는 사용자의 화면 밀도와 상관없이 삭제되며 계산된 DPR이 더 낮습니다.
1보다 낮은 경우 이 소스는 모든 사용자에 대해 업스케일링이 필요하므로 적절하지 않습니다. DPR이 1인 기기에서 medium.jpg는 다음을 제공합니다.
가장 가까운 일치 항목—소스가 1.5의 DPR에서 표시하기에 적합하므로 필요한 것보다 조금 더 크지만 축소는
시각적으로 원활한 프로세스를 구현할 수 있습니다. DPR이 2인 기기에서는 large.jpg이 가장 근접하므로 선택됩니다.
동일한 이미지가 600픽셀 너비의 표시 영역에서 렌더링되는 경우 계산의 결과는 완전히 달라집니다. 즉, 80vw는 이제 480픽셀이 됩니다.
우리가 출처를 나눌 때는 거기에 반대되는 너비는 1.25, 2.5, 4.1666666667를 얻습니다. 이 표시 영역 크기에서는 small.jpg이(가) 선택됩니다.
2배의 기기에서 medium.jpg의 광고가 게재됩니다.
이 이미지는 모든 탐색 컨텍스트에서 동일하게 보입니다. 모든 소스 파일은 크기를 제외하고 완전히 동일하지만
각 광고는 사용자의 화면표시 밀도에서 허용하는 한 선명하게 렌더링되어야 합니다. 하지만 모든 사용자에게 large.jpg를 제공하는 대신
가장 큰 표시 영역과 밀도가 높은 디스플레이를 수용하기 위해 사용자에게는 항상 가장 작은 크기의 적합한 후보가 게재됩니다.
규범적인 구문이 아닌 설명적 구문을 사용하면 수동으로 중단점을 설정하고 향후 표시 영역과 위치를 고려할 필요가 없습니다.
DPR—사용자는 브라우저에 정보를 제공하기만 하면 브라우저가 여러분을 위해 답을 결정하도록 할 수 있습니다.
sizes 값은 표시 영역을 기준으로 하고 페이지 레이아웃과 완전히 독립적이므로 정보 표시 레이어를 추가합니다.
이미지는 고정 너비의 여백이나 패딩, 영향 없이 표시 영역의 일정 비율만 차지하는 경우는 거의 없습니다.
다른 요소에서 추출됩니다. 단위의 조합을 사용하여 이미지의 너비를 표현해야 하는 경우가 많습니다. 백분율, em, px 등
다행히 여기에서 calc()를 사용할 수 있습니다. 반응형 이미지를 기본으로 지원하는 모든 브라우저는 calc()도 지원하므로
믹스 앤 매치 CSS 단위(예: 사용자 표시 영역의 전체 너비에서 양쪽의 여백을 1em만큼 뺀 이미지)
<img
sizes="calc(100vw-2em)"
srcset="small.jpg 400w, medium.jpg 800w, large.jpg 1600w, x-large.jpg 2400w"
src="fallback.jpg"
alt="...">
중단점 설명
반응형 레이아웃으로 작업하는 데 많은 시간을 보냈다면 다음 예에서 누락된 내용을 발견했을 수 있습니다.
레이아웃에서 이미지가 차지하는 공간은 레이아웃의 중단점 전체에서 변경될 가능성이 매우 높습니다. 이 경우
을 사용하여 브라우저에 좀 더 자세한 정보를 전달: sizes는
이미지에서는 srcset와 마찬가지로 이미지 소스에 쉼표로 구분된 후보를 허용합니다. 이러한 조건은 익숙한 미디어 쿼리 구문을 사용합니다.
이 구문은 첫 번째 일치로, 미디어 조건이 일치하면 브라우저에서 sizes 속성 및 값 파싱을 중지합니다.
적용됩니다.
1200px를 초과하는 표시 영역에서는 표시 영역의 80% 에서 양쪽의 패딩을 1em만큼 빼도록 되어 있는 이미지가 있다고 가정해 보겠습니다.
표시 영역이 작으면 표시 영역의 전체 너비를 차지합니다.
<img
sizes="(min-width: 1200px) calc(80vw - 2em), 100vw"
srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 2000w"
src="fallback.jpg"
alt="...">
사용자의 표시 영역이 1200px보다 크면 calc(80vw - 2em)는 레이아웃의 이미지 너비를 설명합니다. 만약
(min-width: 1200px) 조건이 일치하지 않는 경우 브라우저는 다음 값으로 이동합니다. 특정한
미디어 조건이 이 값에 연결된 경우 100vw가 기본값으로 사용됩니다. 다음을 사용하여 이 sizes 속성을 작성하려면
미디어 쿼리 max-width개:
<img
sizes="(max-width: 1200px) 100vw, calc(80vw - 2em)"
srcset="small.jpg 600w, medium.jpg 1200w, large.jpg 2000w"
src="fallback.jpg"
alt="...">
쉬운 표현: '(max-width: 1200px)이(가) 일치할까요? 그렇지 않다면 계속 진행하세요. 다음 값 calc(80vw - 2em)에는 적격 조건이 없습니다.
이것이 선택되어 있습니다.
이제 img 요소에 관한 이 모든 정보(잠재적 소스, 고유 너비,
이미지를 사용자에게 표시하는 방법을 결정하는데, 브라우저는
확인할 수 있습니다 그렇게 들리지 않는다면, 당연히 그렇게 설계되어 있기 때문입니다. 에서 인코딩된 소스 선택 알고리즘은
HTML 사양이 소스를 선택하는 방법에 대해 명시적으로 모호합니다. 소스, 설명어, 데이터가
이미지가 모두 파싱되면 브라우저에서 원하는 대로 작업을 수행할 수 있습니다. 즉, 어떤 이미지가 렌더링되었는지 알 수 없습니다.
선택하게 됩니다.
'고해상도 디스플레이에서 이 소스 사용'이라는 구문 예측 가능하기는 하지만 핵심적인 문제를 반응형 레이아웃의 이미지로 사용자 대역폭 절약 화면의 픽셀 밀도는 인터넷과 약간만 관련이 있음 연결 속도에 영향을 주지 않습니다. 최고급 노트북을 사용 중이지만 데이터 전송량 제한이 있는 연결을 통해 웹을 탐색하는 경우(테더링) 또는 불안정한 비행기 Wi-Fi 연결을 사용하는 경우, 어떤 경우에도 고해상도 이미지 소스를 선택 해제하는 것이 디스플레이 품질에 영향을 줄 수 있습니다.
최종 결정을 브라우저에 맡기면 엄격한 규범적 관리 방법을 사용하여 관리할 수 있는 것보다 훨씬 더 많은 성능 향상이 가능합니다.
구문을 사용합니다 예를 들어 대부분의 브라우저에서 srcset 또는 sizes 구문을 사용하는 img는 크기가 더 작은 소스를 요청하지 않습니다.
사용자가 이미 브라우저의 캐시에 가지고 있는 보다 큰 치수를 사용합니다. 소스에 새 요청을 하면 어떤 점이 중요한가요?
브라우저가 이미 있는 이미지 소스를 원활하게 축소할 수 있다면 동일하게 보일 수 있을까요? 하지만 사용자가
업스케일링을 피하기 위해 새 이미지가 필요한 지점까지 표시 영역이 닫히면 해당 요청이 계속 이루어지므로 모든 항목이
확인할 수 있습니다.
명시적인 제어 기능이 없다면 액면 그대로는 조금 무섭게 들릴 수 있지만
사용자에게 '깨진' 콘텐츠가 표시되는 경우가 단일 소스 src를 사용할 때보다 훨씬 더 효율적입니다.
브라우저에 의해 결정되지 않습니다.
sizes 및 srcset 사용
이는 사용자와 독자 및 브라우저 모두를 위한 많은 정보입니다. srcset와 sizes는 모두 밀집 문법입니다.
충격적인 양의 정보를 비교적 적은 수의 문자로 설명하기 즉, 좋든 나쁘든 설계상
이러한 구문은 덜 간결하고 사람이 더 쉽게 파싱할 수 있으므로 브라우저에서 파싱하기 더 어려울 수 있습니다. 이
문자열에 더 복잡해질수록 파서 오류나 의도치 않은 동작 차이가 있을 가능성이 더 커진다.
다른 브라우저로 이동할 수 있습니다. 그러나 여기에는 장점이 있습니다. 시스템에서 더 쉽게 읽을 수 있는 구문은 더 쉽게 작성되는 구문입니다.
있습니다.
srcset는 자동화에 대한 명확한 사례입니다. 매우 드문 경우지만, 완벽한 조화를 이루기 위해 여러 버전의 이미지를
프로덕션 환경에서 실행하는 대신, Gulp와 같은 작업 실행기, Webpack과 같은 번들러를 사용하여 프로세스를 자동화합니다.
Cloudinary와 같은 CDN 또는 원하는 CMS에 이미 내장된 기능 소스를 생성하기에 충분한 정보가 제공됨
첫째, 시스템은 실행 가능한 srcset 속성에 작성하기에 충분한 정보를 갖게 됩니다.
sizes는 자동화하기가 약간 더 어렵습니다. 아시다시피 시스템이 시스템에서 이미지의 크기를 계산할 수 있는 유일한 방법은
레이아웃을 렌더링한 것입니다. 다행히 많은 개발자 도구가 출시되어
sizes 속성을 필기하는 과정으로, 손으로는 절대 일치시킬 수 없는 효율성입니다.
예를 들어 respImageLint는 sizes 속성을 검사하기 위한 코드 스니펫입니다.
정확성을 높이고 개선을 위한 제안사항을 제공합니다. Lazysizes 프로젝트는
효율성을 높이기 위해 레이아웃이 설정될 때까지 이미지 요청을 지연시켜 JavaScript가
sizes 값을 자동으로 생성합니다. React 또는 Vue와 같은 완전한 클라이언트 측 렌더링 프레임워크를 사용하는 경우
srcset 및 sizes 속성을 작성하거나 생성하기 위한 솔루션 수에 관해서는 CMS 및 프레임워크에서 자세히 설명합니다.