Skip to content

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

이 글은 반응형 이미지를 위한 HTML 문법(그리고 좋은 CSS 약간) 가이드다. 우리는 srcset를 알아보고 나아가 최상의 성능과 디자인 제어를 위한 팁들을 살펴볼 것이다.

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

 

만약 당신의 유일한 목적이…

성능 향상

그렇다면 필요한 것은…


반응형 이미지를 사용하면 성능이 많이 향상된다. 이미지 파일 크기는 페이지의 전반적인 성능에 큰 영향을 미치며, 반응형 이미지는 이미지 파일 크기를 줄이는 좋은 방법 중 하나이다. 브라우저가 300×300 이미지 또는 600×600 이미지 중에서 선택할 수 있다고 상상해보라. 브라우저가 300×300 이미지만 필요로 할 경우 4배 가까운 전송량을 절약할 수 있다! 일반적으로 디스플레이 해상도와 뷰포트 크기가 줄어들면 전송량도 절약된다. 몇 가지 사례 연구에 따르면 가장 작은 화면에서 70~90%의 전송량을 절약할 수 있었다.

srcset 사용하기

만약 이것도 필요하다면…

디자인 제어

그렇다면 필요한 것은…


같은 이미지를 서로 다른 크기로 제공하는 것 외에 반응형 이미지의 또 다른 활용 예는 아예 다른 이미지를 제공하는 것이다. 예를 들어, 화면 크기와 레이아웃의 차이에 따라 이미지를 다르게 자를 수 있다. 이것을 ‘이미지 연출art direction’이라고 한다.
<picture> 요소는 폴백fallback 이미지 유형이나 다른 종류의 미디어 쿼리 전환에도 사용된다(예: 다크 모드의 다른 이미지). 이를 통해 브라우저에 표시되는 내용을 보다 강력하게 제어할 수 있다.

<picture> 사용하기

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

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

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

srcset 사용하기

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

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

여기서는 기본 이미지(src)를 ‘낮은 해상도’(1x)로 지정했다. 일반적으로 가장 작거나 빠른 리소스를 기본값으로 설정하는 것은 현명한 선택이다. 또한 2x 버전도 제공한다. 브라우저가 픽셀 밀도가 더 높은 디스플레이(2x 부분)에서 돌고 있다는 것을 알면 2x 이미지를 사용한다.


데모

 

원하는 만큼 픽셀 밀도에 따라 이미지를 넣을 수 있다. x 설명자는 훌륭하고 유용하지만 반응형 이미지 사용량 중 극히 일부이다. 왜 그럴까? 디스플레이의 픽셀 밀도만으로 브라우저를 조정할 수 있기 때문이다. 하지만 반응형 이미지는 반응형 레이아웃과 함께 사용된다. 그리고 이미지의 레이아웃 크기가 뷰포트와 함께 축소되고 늘어나는 경우가 많다. 이런 상황에서 브라우저는 화면의 픽셀 밀도와 레이아웃상의 이미지 크기라는 두 가지 사항에 따라 보여줄 이미지를 결정해야 한다. w 설명자와 sizes 특성이 필요한 순간이다. 다음 섹션에서 살펴보자.

 

srcset / w + size 사용하기

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

같은 이미지를 다양한 사이즈로 제공하는 것은 이전과 동일하다. 하지만 픽셀 밀도(x 설명자)로 레이블을 지정하는 대신 w 설명자를 사용하여 이미지 너비로 레이블을 지정한다. 따라서 baby-s.jpg 크기가 300×450이면 300w로 레이블을 지정한다.

너비(w) 설명자와 함께 srcset 특성을 사용할 때는 이미지가 표시될 공간의 크기인 size 특성과 함께 사용해야 한다. 이 정보가 없으면 브라우저는 이미지를 똑똑하게 선택할 수 없다.

데모

정확한 sizes 지정하기

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

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


데모

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

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

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

 

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

레이아웃 그리드를 고려하여 이미지 너비에 영향을 끼치는 주변 간격, 여백, 패딩을 세 가지 분기점별로 제공하는 sizes 특성이다.

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

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

이에 대해 자세히 알아보려면 에릭 포티스Eric Portisw 설명자와 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>를 보자마자 선택하기에 충분한 정보를 브라우저에 제공하는 것이다.

[/codepen_embed

“지연 로딩된 이미지는 어떻게 합니까?”라고 생각해볼 수 있다(지연 로딩 이미지가 요청되는 시점엔 이미 레이아웃이 그려졌으며, 브라우저가 이미지의 렌더링 크기를 알고 있다). 좋은 생각이다. 알렉산더 파르카스Alexander Farkaslazysizes 라이브러리는 지연 로딩 시 sizes 특성을 자동으로 작성한다. 또한 지연 로딩된 이미지의 sizes를 자동으로 세팅하는 방법에 대한 지속적인 논의가 이루어지고 있다.

 

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>

이 코드 블록은 3단계 ‘이미지 연출’ 이미지의 예이다.

  • 큰 화면에서는 축소된 사진을 보여준다.
  • 중간 화면에선 약간 확대된 동일한 사진을 보여준다.
  • 작은 화면에선 더 확대해서 보여준다.

브라우저는 미디어 쿼리를 존중해야 하며 정확한 분기점에서 이미지를 교체한다. 이 방법으로라면 작은 화면에선 작게 축소된 이미지를 아무도 볼 수 없으리라는 확신을 가질 수 있다. 큰 화면에서도 마찬가지로 확대된 버전을 볼 수 없을 것이다.

다음은 <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;
}

 

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

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

정말 한계가 없다.

 

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 이미지를 지원하는 브라우저에선 WebP 이미지를 제공하고, 그렇지 않은 브라우저에서는 JPEG 이미지로 대체된다.

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

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

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

이 문법(조시 코모Josh Comeau의 블로그 게시물 차용)은 한 번에 세 가지 ‘차세대’ 이미지 형식을 모두 지원한다. IE 11은 <picture> 문법을 지원하지 않지만, JPEG-XR 형식을 이해하는 <img> 폴백이 있기 때문에 문제가 되지 않는다.

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

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

맥의 미리보기 앱으로 이미지 크기를 조절하는 모습. 이는 말 그대로 모든 이미지 편집 응용프로그램(포토샵, 어피니티 디자이너Affinity Designer, 에이콘Acorn 등)에서 수행할 수 있는 작업이다. 또한 종종 다양한 형식을 한꺼번에 저장하는 데도 도움이 된다.

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

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

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

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

피그마로 내보내기

 

자동화된 반응형 이미지

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

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

 

gatsby-image의 추가 이미지 로딩 작업을 설명하는 랜딩 페이지이다.

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

 

관련된 개념들

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

 

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

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

이 CSS 문법을 사용하면 브라우저 조건에 따라 두 이미지 중 하나만 다운로드한다. 따라서 HTML의 반응형 이미지 문법과 동일한 성능 목표를 달성할 수 있다. 이것이 도움이 된다면 앞의 <picture> 문법과 동등한 CSS 버전으로 생각하면 된다. 브라우저는 이 규칙을 따르고 일치하는 것을 표시해야 한다.

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: 이미지를 완전히 로딩하지 않는 또 다른 방법이다. 지연 로딩은 이미지가 뷰포트에 있거나 뷰포트 근처에 올 때까지 이미지 다운로드를 기다리는 것을 의미한다. 예를 들어, 사용자가 스크롤하지 않으면 페이지 아래쪽의 이미지가 로딩되지 않는다.

 

다른 좋은 자료들

(이 글에 없는 자료들)

 

브라우저 지원

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

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

 

 

도서 소개


이단 마콧의 《반응형 디자인 패턴과 원리》
‘반응형 웹디자인’의 고안자, 이단 마콧의 《반응형 웹디자인》에서 한 걸음 더 나아간 책이다. 이 책에서는 반응형 내비게이션 시스템, 이미지 크기 조절과 배치, 반응형 맥락에서의 광고 관리, 기기에 종속되지 않는 가변적인 레이아웃을 디자인하기 위한 더 포괄적인 원리 등에 초점을 맞추어 성공적인 반응형 디자인 패턴과 원리를 제시한다. 저자는 모델로 삼을 만한 실제 사례와 함께 설명함으로써 패턴의 장점과 단점을 더 명확하게 이해할 수 있게 도와준다. 더불어 단점을 개선할 수 있는 방법도 제시한다.

저작권 정보이 글은 CSS-Tricks 기사를 번역한 것입니다. 저작권자의 정당한 허락을 받은 저작물로 한국어판 저작권은 웹액츄얼리에 있습니다. 웹액츄얼리의 서면 동의 없이 무단 전재, 복제를 금합니다. 원본은 A Guide to the Responsive Images Syntax in HTML에서 확인할 수 있습니다.
참여를 기다립니다!웹액츄얼리에서 웹디자인 관련 영문 번역자를 찾습니다. 웹 콘텐츠 번역에 관심 있는 분은 메일로 간략한 본인 소개와 번역 이력을 보내주시면 연락드리겠습니다.
books@webactually.com


맨위로