반응형 이미지는 이름 때문에 CSS 이야기처럼 들리지만, 실제로는 어떤 파일을 내려받을지를 정하는 문제입니다. CSS 로 폭을 100%로 두어도, 브라우저가 이미 큰 파일을 받았다면 데이터는 이미 소비된 뒤입니다.
브라우저가 고르게 하는 구조
해법은 서버가 정해서 보내는 것이 아니라 브라우저에게 고르게 하는 것입니다. 브라우저만이 화면 폭 · 화면 밀도 · 현재 레이아웃을 전부 알고 있기 때문입니다.
이 구조는 두 부분으로 되어 있습니다. srcset 은 후보 파일들과 각각의 실제 픽셀 폭을 나열합니다. sizes 는 그 이미지가 화면에서 차지할 폭을 알려 줍니다. 브라우저는 둘을 맞춰 보고 가장 알맞은 후보를 하나 고릅니다.
sizes 가 틀리면 srcset 도 소용없습니다
가장 흔한 오해가 여기 있습니다. 후보를 아무리 잘 준비해도 “이 이미지는 화면 전체 폭을 차지한다” 고 알려 주면, 브라우저는 사이드바 안의 작은 썸네일에도 화면 폭에 맞는 큰 후보를 고릅니다. 브라우저는 우리 레이아웃을 읽어서 추측하지 않습니다 — sizes 에 적힌 대로 믿습니다.
그래서 sizes 는 레이아웃과 함께 관리되어야 하는 값입니다. 카드 그리드가 3열에서 2열로 바뀌는 리뉴얼을 하면 이 값도 함께 바뀌어야 합니다. 디자이너가 브레이크포인트를 정하는 사람이므로, 이 값은 사실상 디자인 결정의 일부입니다.
워드프레스가 해 주는 것과 안 해 주는 것
좋은 소식은 본문에 삽입한 이미지에 대해서는 워드프레스가 이 속성들을 자동으로 붙인다는 점입니다. 앞 회차에서 정리한 이미지 크기들이 바로 그 후보 목록이 됩니다 — 그래서 재료를 정리한 것이 여기서 값을 합니다.
자동으로 되지 않는 자리도 분명히 있습니다. CSS 배경 이미지는 이 구조를 쓰지 않습니다. 배경으로 넣은 히어로 이미지가 모바일에서도 데스크톱 파일을 받는 전형적인 경우입니다. 화면에서 의미를 갖는 이미지는 배경이 아니라 실제 이미지 요소로 두는 편이 접근성과 성능 양쪽에 유리합니다.
후보를 고르는 구조의 배경은 성능 최적화 아카이브에 더 있고, 템플릿마다 이 값이 맞는지 점검하고 교정하는 작업은 최적화 지원 사업에 포함됩니다.
다음 회차
어떤 파일을 받을지는 정해졌습니다. 다음은 언제 받을지입니다 — 지연 로딩은 대부분의 이미지에 옳지만, 딱 하나 반대로 해야 하는 이미지가 있습니다.