srcset과 sizes를 사용한 반응형 이미지

올바른 패턴 선택하기

해상도 전환(resolution switching)은 구성(composition)을 동일하게 유지하면서 여러 파일 너비를 제공하는 패턴입니다. 제품 사진, 기사 삽화, 카드에 보통 사용됩니다. 렌더링 너비가 레이아웃에 따라 바뀌면 480w나 1200w 같은 너비(width) 디스크립터를 사용하세요. 숫자는 폰 목표값이나 CSS 명령이 아니라 파일의 실제 픽셀 너비입니다.

밀도 전환(density switching)은 고밀도 디스플레이에 대해 더 많은 소스 픽셀을 제공하면서 고정된 CSS 슬롯을 서비스합니다. 디스크립터는 1x, 1.5x, 2x 등이며, 예를 들어 항상 160 CSS 픽셀 너비인 로고나 아이콘에 적합합니다. 하나의 srcset에서 너비(w) 디스크립터와 밀도(x) 디스크립터를 혼합하지 마세요.

sizes가 선택에 미치는 영향 이해하기

너비 디스크립터를 사용할 때 브라우저는 이미지를 다운로드하기 전에 sizes를 평가합니다. 각 항목은 선택적 미디어 조건과 길이(length)를 쌍으로 가집니다. 첫 번째로 일치하는 조건이 소스 사이즈를 제공하며, 마지막의 무조건 길이는 폴백입니다. sizes는 선택 힌트(selection hint)이지 CSS 규칙이 아닙니다.

브라우저는 그 소스 사이즈를 후보 너비들과 비교해 유효 밀도(effective density)를 계산한 다음 디스플레이 밀도, 확대/축소, 네트워크 조건 등을 고려할 수 있습니다. 브라우저가 수학적으로 가장 근접한 파일명을 선택할 의무는 없습니다. 정직한 후보와 신뢰할 만한 슬롯 추정치를 제공하세요; 최종 선택은 사용자 에이전트(브라우저)에 달려 있습니다.

실제 레이아웃에서 후보 파생하기

페이지가 아니라 컴포넌트를 목록화(inventory)하세요. 히어로(hero), 편집용 삽화, 제품 갤러리, 검색 썸네일, 푸터 로고는 종종 서로 다른 슬롯 너비를 가집니다. 각 항목에 대해 좁은 상태와 가장 큰 렌더링 너비, 종횡비(aspect ratio), 크롭 동작, 초기 화면 가시성을 기록하세요.

컴포넌트의 의미 있는 슬롯 범위 주변에서 너비를 생성하고, 상세가 필요할 경우 더 큰 옵션을 포함하세요. 거의 동일한 파일들이 빌드와 캐시 복잡도를 증가시킵니다; 극히 작은 파일과 매우 큰 파일만이 타협을 강요합니다. 이미지 변환이 작동한다고 가정하지 말고 생성한 URL을 테스트하세요.

유효한 src 폴백과 제공된 비율과 일치하는 width 및 height 값을 유지하세요. 이들은 공간을 예약하지만 최종 치수를 변경하는 반응형 CSS를 막지 않습니다.

아트 디렉션에는 picture 사용하기

아트 디렉션은 단순한 파일 크기 변경이 아니라 구성 변경입니다. 넓은 풍경 사진은 좁은 화면에서 주요 피사체가 보이도록 더 타이트한 세로 크롭이 필요할 수 있습니다. picture 요소는 미디어별 소스 옵션을 제공한 뒤 하나의 img 폴백을 가질 수 있습니다. 브라우저는 각 source의 media, type, srcset 정보를 고려하며 img는 대체 텍스트(alt), 치수 및 폴백 동작을 담당합니다.

각 크롭은 편집 및 접근성 검토를 거치게 하세요. 모바일 크롭이 제품 상세나 대체 텍스트에 언급된 사람을 제거할 수 있습니다. alt는 img에 넣고 이미지가 전달하는 정보나 기능을 설명하세요. 진정으로 장식용 이미지인 경우에만 alt=""를 사용하세요; 링크되거나 버튼인 이미지의 경우 외형 대신 동작을 설명하세요. 구성 변경이 없이 크롭이 동일하다면 picture를 도입하지 마세요: 보통의 너비 기반 srcset이 더 간단합니다.

비용이 큰 로딩 및 마크업 실수 피하기

일반적인 낭비는 모든 이미지에 sizes="100vw"를 복사하는 것입니다. 이것은 좁은 풀-너비 피겨에는 맞을 수 있지만 캡이 있는 컨테이너나 데스크톱 카드에는 맞지 않습니다. 반대의 실패는 리디자인 후 stale한(sizes가 오래된) sizes입니다. CSS와 sizes를 함께 변경하세요.

초기 가시 콘텐츠(initially visible content)에 중요한 이미지를 lazy-load하지 마세요. 권장 가이드라인은 화면 아래 이미지에 대해 지연 로딩을 하고, 보이는 히어로는 eager로 두는 것입니다. fetch priority는 진정으로 중요한 이미지를 우선시할 수 있지만, 광범위한 높은 우선순위나 preload 규칙은 성능을 해칠 수 있습니다. 파일명이나 캐시된 결과에 의존하지 마세요.

요청·크롭·수정 방법 테스트하기

그리드 브레이크포인트 바로 위·아래를 포함해 레이아웃 변경 너비에서 대표 페이지를 테스트하세요. 고밀도 설정, 넓은 데스크톱, 슬롯을 변경하는 상태들을 포함하세요. 렌더된 치수, 크롭, 대체 텍스트, 시각적 선명도를 확인하세요.

Chrome DevTools에서 Network(네트워크)를 열고 캐시 비활성화로 새로고침하거나 'Empty Cache And Hard Reload'를 사용하고 이미지 요청을 필터링하여 URL, 전송 크기, 헤더, initiator, 타이밍을 검사하세요. 지연(Throttling)을 적용해 늦거나 낭비적인 작업을 드러내세요. 뷰포트, 장치 스케일 팩터(device scale factor), 슬롯, 후보, 전송 바이트, 예상 결과를 기록하세요.

템플릿, 브레이크포인트, CDN 또는 자산 파이프라인이 변경될 때 이를 릴리스 게이트에 포함하세요. 좁게 수리하세요: sizes를 수정하거나, 디스크립터를 고치거나, 크롭을 재생성하거나, 폴백을 복원하거나, 불필요한 preload를 제거하세요. 빈 캐시 새로고침으로 재테스트하세요.

SIU 복원력 제어로 적용하기

반응형 이미지는 불필요한 전송을 줄이지만 성공적 요청을 보장할 수는 없습니다. 원본 오류, 변환 불가, 서드파티 호스트 및 CDN 장애는 별도의 연속성 및 복구 계획이 필요합니다.

SIU를 위해 테스트 기록을 사용해 전송 회귀를 조기에 포착하고, 책임 템플릿 또는 변환 규칙을 식별하며, 릴리스 전 가장 작은 안전한 수정을 수행하세요. 이를 가용성 사전 점검(availability preflight) 및 롤백 계획과 함께 사용하세요.