HTML 반응형 이미지 문법 가이드

상황과 규칙에 따른 여러 옵션 중 한 이미지를 골라 제공하는 것이 반응형 이미지 문법이다. 반응형 이미지에는 두 가지 종류가 있으며 두 가지 목적으로 사용된다.

——————————————————————————————————————

할 이야기가 아주 많다. 문법과 관련 특성값을 모두 살펴보고, 도구 사용이나 브라우저 같은 몇 가지 관련 주제에 대해 이야기해보자.

——————————————————————————————————————

srcset 사용하기

<img srcset="" src="" alt=""> 문법으로 동일한 이미지를 다른 크기로 제공할 수 있다. 이 문법을 사용해 완전히 다른 이미지를 제공할 수도 있다. 하지만 브라우저는 srcset의 모든 이미지가 시각적으로 동일하다고 가정하고, 예측이 거의 불가능한 방식으로 가장 적합한 크기를 선택하기 때문에 권장하지는 않는다.

아마도 반응형 이미지 문법 중 가장 쉬운 것은 다른 픽셀 밀도를 가진 디스플레이를 위해 이미지에 x 설명자가 포함된 srcset 특성을 추가하는 것이다.

데모

srcset / w + size 사용하기

 w 설명자와 sizes 특성은 꽤 걸출한 물건이다. 이 방식은 웹에서 반응형 이미지 사용량의 약 85%를 차지한다. 이 방식을 통해 우리는 여전히 다양한 크기로 동일한 이미지를 제공할 수 있다. 하지만 브라우저에 더 많은 정보를 제공하여 픽셀 밀도와 레이아웃 크기에 따라 좀더 적합한 이미지를 선택하게 할 수 있다.

데모

정확한 sizes 지정하기

sizes 특성을 지정하는 것은 까다로울 수 있다. sizes 특성은 이미지가 특정 사이트 레이아웃 내에 표시되는 너비를 나타내며 이는 CSS와 밀접하게 관련되어 있다. 이미지가 렌더링하는 너비는 뷰포트 크기에 의존하지 않고 레이아웃에 따라 다르다!

분기점^breakpoints 3개가 있는 상당히 간단한 레이아웃을 살펴보겠다. 이를 보여주는 동영상은 다음과 같다.

데모

분기점은 CSS에서 미디어 쿼리로 표현된다.

 
이미지는 각 분기점마다 크기가 다르게 조정된다. 가장 큰 분기점에서 이미지의 레이아웃 너비에 영향을 미치는 요소를 분석해보았다(뷰포트가 700px보다 넓은 경우).

• 가장 큰 크기: 9rem의 명시적 간격이 있으므로 이미지의 너비는 calc(100vw - 9rem - 200px)이다. 해당 열이 200px 대신 fr 단위를 사용하는 경우 문제가 생길 수 있다.
• 중간 크기: 사이드바가 아래로 떨어지므로 고려할 간격이 줄어든다. 여전히 여백과 패딩을 설명하기 위해 calc(100vw - 6rem)를 적어야 한다.
• 가장 작은 크기: 본문 여백이 제거되므로 calc(100vw - 2rem)만 적어도 된다.

휴, 솔직히 이해하기 조금 어려웠고, 이것을 만들면서 많은 실수를 저질렀다. 결과물은 아래와 같다.

풍악을 울리기엔 아직 이르다. 여전히 문제가 남아 있다. 겉보기엔 CSS 레이아웃에서 발생하는 상황을 100% 설명하는 것처럼 보인다. 하지만 마르틴 아우스뵈거^{Martin Auswöger}의 RespImageLint에서 내 코드가 잘못됐다고 하니 그냥 잘못됐다고 보면 된다. 데모 사이트에서 해당 도구를 실행하면, 일부 뷰포트 크기에 대해 sizes 특성이 잘못됐다고 알려준다.

 
이 코드가 대체 어떻게 계산됐는지 모르겠고, 도저히 손으로 유지보수할 수 없는 수준이다. 하지만 정확하다. 마르틴의 도구는 프로그래밍으로 페이지 크기를 조정하고, 다양한 뷰포트 크기에서 실제로 관찰된 이미지 너비를 서술하는 sizes 특성을 작성한다. 컴퓨터가 계산했기 때문에 정확하다. 따라서 매우 정확한 sizes 특성을 원한다면 처음에는 잘못된 값을 넣고, 이 도구를 실행하여 계산된 내용을 복사 및 붙여넣기 하는 것이 좋다.

이에 대해 자세히 알아보려면 에릭 포티스^{Eric Portis}의 w 설명자와 sizes 특성: 내부적으로를 확인하자.

sizes 특성을 좀더 냉정하게 생각해보자.

또 다른 옵션은 가까운 수를 사용하는 것이다. 강력하게 추천하는 방법이다.

예를 들어, sizes="96vw"는 “이 이미지는 페이지의 전체 너비를 거의 채우지만 항상 주위에 작은 패딩이 있다”라고 할 수 있고, size="(min-width: 1000px) 33vw, 96vw"는 “이 이미지는 큰 화면에서 3열 레이아웃으로 보이고, 전체 너비에 가깝다”라고 생각할 수 있다. 이것은 실제로 현명한 해결책이 될 수 있다.

당신이 짠 레이아웃을 알 방법이 없는 자동화된 반응형 이미지 솔루션은 sizes="(max-width: 1000px) 100vw, 1000px"와 같이 추측할 수 있다. “우린 이 레이아웃에 대해 잘 알지 못하지만 이미지를 전체 너비로 표시하고, 1000px보다 크게 렌더링하지 않기를 바랍니다.”

sizes 추상화

sizes가 잘못될 수 있을 뿐만 아니라, 시간이 지나며 사이트 레이아웃이 변경됨에 따라 오류가 얼마나 쉽게 발생하는지 상상할 수 있다. 템플릿 언어나 콘텐츠 필터를 사용해 추상화하면 모든 이미지의 값을 보다 쉽게 ​​변경할 수 있다.

변수로 sizes 값을 한 번 설정하고, 사이트 전체의 다양한 <img> 요소에 해당 변수를 사용하는 것에 대해 이야기하고 있다. 네이티브 HTML은 이런 기능을 제공하지 않지만 모든 백엔드 언어는 이를 제공한다. 예를 들어, PHP 상수, Rails 설정값, 전역 상태 관리에 사용하는 리액트 컨텍스트 API, Liquid와 같은 템플릿 언어 내의 변수는 모두 sizes를 추상화하는 데 사용할 수 있다.

“브라우저의 선택”

이제 sizes 특성을 설정했으므로 이미지가 렌더링될 크기 (혹은 비슷하게라도)를 브라우저가 알고 마술처럼 작동할 수 있다. 즉 화면의 픽셀 밀도와 이미지의 렌더링 크기에 영향을 미치는 계산을 수행한 다음 가장 적절한 크기의 이미지를 선택할 수 있다는 것이다.

계산은 처음엔 매우 간단하다. 너비가 1200px인 뷰포트, 2x 픽셀 밀도 화면에서 폭이 40vw인 이미지를 표시한다고 가정해보자. 완벽한 이미지의 너비는 960픽셀이므로 브라우저는 가장 가까운 것을 찾는다. 브라우저는 항상 뷰포트와 픽셀 밀도, sizes 특성에서 알고 있는 것을 기반으로 선호하는 대상 크기를 계산한다. 그리고 해당 대상을 srcset에서 선택해야 하는 대상과 비교한다. 하지만 브라우저가 고르는 방법은 약간 이상할 수 있다.

브라우저는 이 방정식에 더 많은 변수를 포함할 수 있다. 예를 들어, 사용자의 현재 네트워크 속도, 즉 사용자가 일종의 ‘데이터 절약’ 환경설정을 해두었는지 여부를 고려할 수 있다. 브라우저가 실제로 이런 종류의 일을 하는지는 확실하지 않지만, HTML 사양에 따르면 이런 작업을 자유롭게 수행할 수 있다. 일부 브라우저는 때때로 로컬 캐시에 저장해두었다가 가져오기도 한다. 계산에 따르면 300px 이미지를 사용해야 하지만, 로컬 캐시에 이미 600px 이미지가 있다면 그대로 사용한다. 이런 종류의 유연성은 srcset/sizes 문법의 강점이다. 또한 srcset 내에 항상 동일한 이미지를 서로 다른 크기로 사용하는 이유도 이 때문이다. 브라우저가 어떤 이미지를 선택할지 정확히 알 수 없기 때문이다. 결국 브라우저의 선택이다.
 

이상하다. 브라우저는 이미 내용을 알고 있을텐데······

“음, 왜 이미지가 렌더링될 크기를 브라우저에 알려줘야 하나요? 이미 알고 있지 않나요?” 물론, 맞는 말이다. 하지만 이는 브라우저가 HTML과 CSS를 모두 다운로드한 다음에야 가능하다. sizes 특성은 속도에 관한 것이다. <img>를 보자마자 선택하기에 충분한 정보를 브라우저에 제공하는 것이다.

sizes는 뷰포트보다 클 수 있다.

sizes에 대한 빠른 팁이 있다. 이미지를 클릭할 때 이미지가 ‘확대’되는 효과가 있다고 가정해보자. 전체 뷰포트를 채우도록 확장되거나 더 확대되어 더 자세하게 볼 수 있을 것이다. 과거에는 고해상도 버전으로 전환하기 위해 클릭 시 src 주소를 교체해야 했다. 하지만 이제 고해상도 소스가 이미 srcset에 있다고 가정하고, sizes 특성을 200vw 또는 300vw와 같이 거대하게 변경하여 브라우저가 자동으로 초고해상도 소스를 다운로드하게 할 수 있다. 이 기술에 대한 스콧 젤^{Scott Jehl}의 글이 있다.

 
맨 위로 가기

——————————————————————————————————————

<picture> 사용하기

우리는 이 동일한 이미지의 크기가 다른 버전을 제공하기 위한 것임을 배웠다. <picture> 문법으로도 그렇게 할 수 있다. 차이점은 브라우저가 당신이 설정한 규칙을 반드시 준수해야 한다는 것이다. 사용자의 상황에 맞게 이미지 해상도를 변경하는 정도 그 이상의 경우에 유용하다. 이런 의도적인 이미지 변경을 일반적으로 ‘이미지 연출’이라고 한다.
 

이미지 연출

<picture>
  <source 
    srcset="baby-zoomed-out.jpg"
    media="(min-width: 1000px)"
  />
  <source 
    srcset="baby.jpg"
    media="(min-width: 600px)"
  />
  <img 
    src="baby-zoomed-in.jpg" 
    alt="Baby Sleeping"
  />
</picture>

다음은 <picture>의 특성을 요약하기 위해 Pug로 작성된 데모이다.

- const base = `https://codepen-chriscoyier-bucket.imgix.net/baby.jpg`;
- const alt_text = `Baby Sleeping`;

- const large_params = `h=1100&w=2000&fit=crop&fp-x=0.55&fp-y=0.67`;
- const medium_params = `w=1200&fit=crop&crop=focalpoint&fp-x=0.55&fp-y=0.67&fp-z=1.4`;
- const small_params = `h=600&w=600&fit=crop&crop=focalpoint&fp-x=0.55&fp-y=0.64&fp-z=2.5`;

picture
  source(srcset=`${base}?${large_params}`, media="(min-width: 1000px)")
  source(srcset=`${base}?${medium_params}`, media="(min-width: 600px)")
  img(src=`${base}?${small_params}`, alt=alt_text)

img {
  max-width: 100%;
}
body {
  margin: 3rem;
}

이미지 연출은 자르기 그 이상도 할 수 있다.

자르기, 확대/축소는 가장 일반적인 이미지 연출의 형태이지만 훨씬 더 많은 작업을 수행할 수 있다. 예를 들어 다음을 수행할 수 있다.

• 다크 모드 사용자를 위한 Dark-ify™ 이미지
• 설정을 해둔 사용자들에게 애니메이션 GIF를 제공하지 않는다.
• 짧은 뷰포트에서 ‘어보브더폴드^{above the fold}’(페이지가 로딩된 직후의 화면)에 맞도록 이미지 내용을 다시 정렬하고,
• 최대 해상도 한도를 설정하여 3x 픽셀 밀도 이상의 기기에서 데이터를 절약하고,
• 정적 고해상도 흑백 이미지를 프린터나 이북 리더기로 전송한다.

정말 한계가 없다.

source와 srcset 결합

<source>는 srcset 문법도 사용하기 때문에 조합하여 사용할 수 있다. 즉 시각적으로 다른 이미지를 <source>를 이용해 교체하는 동안에도 srcset의 성능 이점을 얻을 수 있다. 제법 장황해진다.

<picture>
  <source 
    srcset="
      baby-zoomed-out-2x.jpg 2x,
      baby-zoomed-out.jpg
    "
    media="(min-width: 1000px)"
  />
  <source 
    srcset="
      baby-2x.jpg 2x,
      baby.jpg
    "
    media="(min-width: 600px)"
  />
  <img 
    srcset="
      baby-zoomed-out-2x.jpg 2x
    "
    src="baby-zoomed-out.jpg"
    alt="Baby Sleeping"
  />
</picture>

최신 이미지 형식에 대한 폴백

<picture> 요소로 ‘폴백’을 처리할 수 ​​있다. 즉 모든 브라우저에서 아직 처리할 수 없는 최첨단 형식의 이미지를 대체하는 구형 이미지를 제공할 수도 있다. 예를 들어 WebP 형식의 이미지를 사용한다고 가정해보자. WebP는 꽤 훌륭한 이미지 형식으로, 보통 가장 성능이 좋다. 사파리^Safari를 제외한 <picture> 요소가 작동하는 모든 곳에서 지원된다. WebP가 지원되지 않을 경우 다음과 같이 폴백을 직접 제공할 수 ​​있다.

<picture>
  <source srcset="party.webp">
  <img src="party.jpg" alt="A huge party with cakes.">
</picture>

다음은 동일한 해상도의 사진(내 사진)의 예인데, WebP 버전이 JPEG 버전 용량의 약 10%(!!!)에 불과하다.

WebP 이미지는 어떻게 만들까? 음, 좀 까다롭다. 온라인 컨버터, CLI 도구, 스케치^Sketch와 같은 일부 최신 디자인 소프트웨어를 이용해 WebP 형식으로 내보낼 수 있다. 나는 브라우저에 이미지를 딱 맞는 형식으로 자동 전송하는 이미지 호스팅 CDN 서비스를 좋아한다(img/srcset만 사용하면 된다).

이런 장점을 갖고 있는 것은 WebP만이 아니다. 사파리는 WebP를 지원하지 않지만 JPEG보다 장점이 많은 JPG 2000이라는 형식을 지원한다. 인터넷 익스플로러^IE 11은 다른 장점이 있는 JPEG-XR이라는 이미지 형식을 지원한다. 세 가지를 모두 지원하는 코드는 다음과 같이 보일 수 있다.

에스텔 웨일^{Estelle Weyl}은 이미지 최적화에 관한 2016년의 블로그 게시물에서 이 아이디어를 다루었다.(2016년에 블로그 게시물에서 이미지 최적화에 관한 아이디어를 다루었다.)

크기가 다른 이미지는 어디서 구할 수 있을까?
직접 만들 수 있다. 내 맥^Mac의 무료 미리보기 앱조차도 이미지 크기를 조정하고 ‘다른 이름으로 저장^{Save As}’할 수 있다.

하지만 이런 이미지 변형 생성을 자동화하거나(아래 섹션 참조) 이미지 URL을 바꿔서 변형을 자동으로 생성할 수 있는 서비스를 사용하는 경우가 더 많다. 이는 대부분의 이미지 호스팅/이미지 CDN 서비스의 가장 일반적인 기능이다. 몇 가지 예를 들면 다음과 같다.

• 클라우디너리^Cloudinary
• 네틀리파이^Netlify
• 이미지 x^imgix
• 이미지옵팀^{Image Optim}
• 파일스택^Filestack
• 클라우드플레어^Cloudflare

 
이런 서비스들은 즉각적인 이미지 크기 조정뿐만 아니라 자르기, 필터링, 텍스트 추가 등 온갖 유용한 기능을 제공한다. CDN에서는 효율적으로 파일을 제공하고, 자동으로 차세대 형식을 제공한다. 따라서 이는 거의 모든 웹사이트에 적합한 선택이다.

다음은 이미지 CDN이 얼마나 유용한지에 대한 글렌 매던^{Glen Maddern}의 스크린 캐스트다.

디자인 소프트웨어는 종종 여러 개의 이미지 사본이 필요하다는 것을 알고 있다. 피그마^Figma의 내보내기 인터페이스는 매우 훌륭하다. 한 번에 여러 크기와 형식으로 내보낼 수 있으며 마지막으로 내보낸 작업을 기억한다.

자동화된 반응형 이미지

반응형 이미지의 문법을 손으로 직접 짜는 것은 너무나 복잡하다. 가능한 한 많이 자동화하고 추상화하는 것이 좋다. 다행히도 웹사이트 구축에 도움이 되는 도구가 많이 있으며, 이 작업들을 잘 지원한다. 소프트웨어는 완전히 프로그래밍 방식이며, 일부 작업은 인간보다 잘 수행한다. 몇 가지 예가 있다.

• 클라우디너리에는 완벽한 분기점을 생성하기 위한 API를 포함하는 반응형 분기점 도구가 있다.
• 워드프레스^WordPress는 기본적으로 여러 버전의 이미지를 생성하고 반응형 이미지 문법으로 출력한다.
• 개츠비^Gatsby에는 이미지를 변환하고 사이트에 적용하기 위한 다양한 플러그인이 있다. 이 중 반응형 이미지 및 기타 이미지 로딩 최적화를 구현하는 데 매우 좋은 개츠비 이미지^gatsby-image 플러그인을 사용하면 된다. 리액트^React에 관해선 “거의 이상적인 리액트 이미지 컴포넌트”라고 할 수 있다.
• 니콜라 아제^{Nicolas Hoizey}의 Images Responsiver 노드 모듈 (및 Eleventy plugin)은 수많은 스마트 마크업을 선택할 수 있고, 자동 크기 조정을 제공하는 CDN과 쉽게 연동할 수 있다.
• 이것은 그저 몇 가지 예일 뿐이다. 이러한 프로세스를 보다 쉽게, ​​또는 자동으로 만드는 것은 해볼 만한 가치가 있다.

 
나는 반응형 이미지 문법을 만드는 온갖 복잡한 작업을 자동화하는 데 도움이 되는 CMS나 기타 소프트웨어 제품이 더 많을 것으로 확신한다. 이 모든 문법들을 좋아하지만, 직접 작성하기에는 너무 번거로운 것이 사실이다. 그럼에도 추상화를 진행하거나 반응형 이미지가 잘 작동하는지 확인하기 위해 이 모든 문법을 알 필요가 있다고 생각한다.

관련된 개념들

• CSS의 object-fit 속성은 이미지가 박스 안에서 작동하는 방식을 제어한다. 예를 들어, 사이즈를 원래의 종횡비와 다르게 변경하면 이미지가 일반적으로 찌그러지지만, object-fit를 사용하여 이미지를 자르거나 꽉 차게 만들 수 있다.
• CSS의 object-position 속성을 사용하면 박스 내 이미지를 조금씩 움직일 수 있다.

CSS의 background-images에 반응형 이미지를 사용하는 방법은?

이를 다룬 적이 있다. @media 쿼리를 사용하여 배경 이미지 소스를 변경하면 된다. 예를 들면 다음과 같다.

srcset/sizes처럼 브라우저가 최상의 옵션을 선택하도록 놔두고 싶을 수 있다. CSS에서의 이 솔루션은 궁극적으로 image-set() 함수가 될 것이다. 오늘날 image-set() 함수에는 두 가지 문제가 있다.

• 아직 정식으로 지원되지 않는다. 사파리에서는 많이 구현되었지만 image-set()는 8년 동안 크롬^Chrome에서 접두사로 사용되었으며 파이어폭스^Firefox는 전혀 지원하지 않는다.
• 사양 자체도 시대에 뒤떨어져 있다. 예를 들어, x 설명자만 지원한다(아직 w 설명자는 지원하지 않는다.)

 
지금 당장은 미디어 쿼리를 사용하는 것이 가장 좋다.

폴리필을 사용해야 할까요?

나는 지금 시점에서 폴리필을 사용하는 것에 대해 부정적인 편이다. 그래도 픽처필^Picturefill이라는 훌륭한 폴리필이 있으며, 필요한 경우 IE 9~11을 완벽하게 지원한다. 하지만 <img src="" alt="">이 있기 때문에 지원되지 않는 브라우저에서 이미지가 아예 표시되지 않는 일은 없을 것이다. 비교적 안전한 픽셀 밀도가 낮은 데스크톱 디스플레이에서 IE 11 브라우저가 실행되고 있다고 가정하고, 이것을 바탕으로 기본 이미지 소스를 지정할 수 있다.

다른 중요한 이미지 고려 사항

• 품질 최적화: 반응형 이미지는 가장 작고 영향력이 큰 리소스를 로딩한다. 이미지를 효과적으로 압축하지 않으면 이를 달성할 수 없다. 좋아 보이는 것과 가볍게 만드는 것 사이의 모든 이미지에 대해 ‘스위트스폿^{sweet spot}’을 목표로 하자. 나는 이미지 호스팅 서비스가 자동으로 이 문제를 해결하게 놔두기를 좋아한다. 하지만 엣시^Etsy는 자신이 구축한 인프라로 달성한 것들에 대해 훌륭한 글을 작성했다.
• CDN에서 제공: 이미지 호스팅 서비스와 관련하여 속도는 여러 형태로 나타난다. 지리적으로 사용자와 가까운 빠른 서버도 중요한 속도 요소이다.
• 캐싱^Caching: 네트워크를 통해 적은 양의 데이터를 로드하기보다 데이터를 로딩하지 않는 편이 낫다. 이것이 바로 HTTP 캐싱이다. 동일한 이미지가 다시 필요할 경우에 브라우저가 매번 이미지를 네트워크를 통해 다시 불러올 필요 없이 저장해두도록 Cache-Control 헤더를 사용하자. 반복적으로 커다란 속도 향상을 볼 수 있다.
• 지연 로딩^{Lazy loading}: 이미지를 완전히 로딩하지 않는 또 다른 방법이다. 지연 로딩은 이미지가 뷰포트에 있거나 뷰포트 근처에 올 때까지 이미지 다운로드를 기다리는 것을 의미한다. 예를 들어, 사용자가 스크롤하지 않으면 페이지 아래쪽의 이미지가 로딩되지 않는다.

다른 좋은 자료들

(이 글에 없는 자료들)

• 클라우디너리 블로그의 에릭 포티스^{Eric Portis}: ‘srcset’, ‘sizes’을 이용한 반응형 이미지와 클라우디너리
• 에릭 포티스의 srcset과 sizes에 대한 심층 분석
• 스매싱 매거진^{Smashing Magazine}의 에릭 포티스: 반응형 이미지 올바르게 사용하기 : <picture>와 srcset의 가이드
• MDN 가이드: 반응형 이미지
• 클라우드포^Cloudfour 블로그 제이슨 그릭스비^{Jason Grigsby}의 10부로 구성된 가이드
• 클라우드포 블로그의 스콧 밴더헤이^{Scott Vandehey}: 반응형 이미지 간단하게 짜기
• 브라우저의 반응형 이미지를 위해 싸워온, 오리지널 W3C 커뮤니티 그룹
• 구글 개발자 웹 기초 가이드의 피트 러페이지^{Pete LePage}: 이미지
• 애디 오스마니^{Addy Osmani}의 필수 이미지 최적화 e북
• 엘라드 셰히터^{Elad Shechter}의 반응형 이미지에 대한 완전한 안내서
• 매트 마키스^{Mat Marquis}의 콘퍼런스 토크: 반응형 이미지의 과거, 현재, 미래
• 매트 마키스의 책 이미지 성능
• 제이크 아치볼드^{Jake Archibald}의 반응형 이미지 분석
• 반응형 이미지, 워드프레스와 클라우디너리
• 오페라^Opera 개발자 블로그의 안드레아스 보벤스^{Andreas Bovens}: 반응형 이미지 – 사용 사례와 문서화된 코드 스니펫으로 시작하기

브라우저 지원

srcset/sizes에 대한 지원 상황이지만, <picture>도 동일하다.

이 브라우저 지원 데이터는 캔아이유즈^Caniuse의 데이터이며, 캔아이유즈에서 자세한 내용을 볼 수 있다.