One Size Fit Some: 반응형 웹 디자인 이미지 솔루션 가이드
게시 됨: 2022-03-11모바일 및 태블릿 장치가 최종 세계 정복에 가까워짐에 따라 웹 디자인과 기술은 계속해서 증가하는 화면 크기를 수용하기 위한 경쟁을 벌이고 있습니다. 그러나 이 현상의 문제를 해결하기 위한 도구를 고안하면 최신 유행어 중 하나가 "반응형 웹"으로 부상하는 등 완전히 새로운 문제가 발생합니다. 이것은 사용자 경험을 저하시키지 않으면서 모든 장치는 아닐지라도 대부분의 장치에서 웹이 작동하도록 하는 과제입니다. 데스크톱이나 랩톱에 맞게 콘텐츠를 디자인하는 대신 휴대전화, 태블릿 또는 웹에 연결된 모든 표면에서 정보를 사용할 수 있어야 합니다. 그러나 이 반응형 웹 디자인의 진화는 어렵고 때로는 고통스러운 것으로 입증되었습니다.
텍스트 정보를 수용하는 것은 거의 사소할 수 있지만, 한때 데스크탑만을 염두에 두고 설계되었던 반응형 이미지, 인포그래픽, 비디오 등과 같은 콘텐츠를 고려할 때 까다로운 부분이 발생합니다. 이것은 콘텐츠를 올바르게 표시하는 것뿐만 아니라 콘텐츠 자체가 다른 장치를 사용하여 소비되는 방식에 대한 질문을 제기합니다. 스마트폰 사용자는 데스크톱 사용자와 다릅니다. 데이터 계획 및 처리 속도와 같은 사항도 고려해야 합니다. Google은 검색 결과에서 모바일 친화적인 사이트를 강조하기 시작했으며 일부에서는 이러한 사이트에 대한 페이지 순위 향상으로 이어질 것이라고 추측합니다. 이전 솔루션은 모바일 전용 하위 도메인(및 리디렉션)을 배포하여 이 문제를 해결했지만 복잡성이 증가하고 빠르게 유행에서 벗어났습니다. (모든 사이트가 이 경로를 감당할 수 있는 것은 아닙니다.)
반응형 웹 이미지에 대한 탐구
이 시점에서 개발자와 디자이너는 웹 사이트 로드가 모바일 사이트에 있는 사용자를 충족하도록 최적화되어 있는지 확인해야 합니다. 현재 웹 트래픽의 20% 이상이 모바일 사용자이며 그 수는 계속 증가하고 있습니다. 페이지 콘텐츠 데이터의 가장 큰 부분을 차지하는 이미지의 경우 이 부하를 줄이는 것이 우선 순위가 됩니다. 서버 측 및 프런트 엔드 솔루션을 포함하여 반응형 디자인 이미지 크기 조정을 단순화하기 위한 여러 시도가 있었습니다. 이러한 반응형 이미지 솔루션에 대해 논의하려면 먼저 현재 이미지 연결의 단점을 이해해야 합니다.
<img>
태그에는 이미지 자체에 직접 연결되는 소스 속성만 있습니다. 추가 기능 없이 필요한 올바른 유형의 이미지를 결정할 방법이 없습니다.
HTML에 모든 이미지 크기를 포함하고 CSS 규칙을 사용하여 올바른 이미지를 제외한 모든 항목에 대해 display:none
할 수 없습니까? 그것이 완벽한 논리적 세계에서 가장 논리적인 솔루션입니다. 이런 식으로 브라우저는 표시되지 않는 모든 이미지를 무시하고 이론상 다운로드하지 않을 수 있습니다. 그러나 브라우저는 일반적인 논리 이상으로 최적화되어 있습니다. 페이지가 충분히 빠르게 렌더링되도록 하기 위해 브라우저는 필요한 스타일시트와 JavaScript 파일이 완전히 로드되기 전에 링크된 콘텐츠를 미리 가져옵니다. 데스크톱을 위한 큰 이미지를 무시하는 대신 모든 이미지를 다운로드하게 되어 페이지 로드가 훨씬 더 커집니다. CSS 전용 기술은 (미디어 쿼리를 사용하여) 스타일시트 내에서 설정할 수 있기 때문에 배경 이미지로 의도된 이미지에 대해서만 작동합니다.
그렇다면 웹사이트는 무엇을 해야 할까요?
백엔드 반응형 이미지 스케일링 솔루션
모바일 전용 사이트/하위 도메인을 제외하고 사용자 에이전트(UA)를 스니핑하고 이를 사용하여 사용자에게 올바른 크기의 이미지를 다시 제공해야 합니다. 그러나 모든 개발자는 이 솔루션이 얼마나 신뢰할 수 없는지 증명할 수 있습니다. 새로운 UA 문자열이 항상 계속 나타나므로 포괄적인 목록을 유지 관리하고 업데이트하기가 어렵습니다. 그리고 물론 이것은 처음부터 쉽게 스푸핑된 UA 문자열의 비신뢰성을 고려하지도 않습니다.
적응형 이미지
그러나 일부 서버 측 솔루션은 고려할 가치가 있습니다. 적응형 이미지는 백엔드 반응형 이미지 수정을 선호하는 사람들에게 훌륭한 솔루션입니다. 특별한 마크업이 필요하지 않지만 대신 작은 JavaScript 파일을 사용하고 백엔드 파일에서 대부분의 무거운 작업을 수행합니다. PHP 및 nginx 구성 서버를 사용합니다. 또한 UA 스니핑에 의존하지 않고 대신 화면 너비를 확인합니다. 적응형 이미지는 이미지를 축소하는 데 유용하지만 크기가 큰 이미지에 아트 디렉션, 즉 자르기 및 회전과 같은 기술을 통한 이미지 축소가 필요한 경우에도 유용합니다.
센차 터치
Sencha Touch는 또 다른 백엔드 반응형 디자인 이미지 솔루션이지만 타사 솔루션이라고 하는 것이 더 좋습니다. Sencha Touch는 UA를 스니핑하여 그에 따라 이미지 크기를 조정합니다. 다음은 서비스 작동 방식의 기본 예입니다.
<img src="http://src.sencha.io/http://example.com/images/kitty_cat.jpg" alt="My Kitty Cat">
Sencha가 이미지 크기를 자동으로 조정하는 것을 원하지 않는 경우 이미지 크기를 지정하는 옵션도 있습니다.
결국 서버 측(및 타사) 솔루션에는 올바른 이미지를 다시 보내기 전에 요청을 처리하기 위한 리소스가 필요합니다. 이것은 귀중한 시간을 필요로 하고 차례로 요청-응답 이동을 늦춥니다. 더 나은 솔루션은 장치 자체에서 직접 요청할 리소스를 결정하고 서버가 그에 따라 응답하는 경우일 수 있습니다.
프런트엔드 솔루션
최근에는 반응형 이미지를 처리하기 위해 브라우저 측에서 크게 개선되었습니다.
<picture>
요소는 W3C에 의해 HTML5 사양에 도입 및 승인되었습니다. 현재 모든 브라우저에서 널리 사용할 수 있는 것은 아니지만 기본적으로 사용할 수 있게 되기까지는 그리 오래 걸리지 않을 것입니다. 그때까지는 요소에 대해 JavaScript 폴리필에 의존합니다. 폴리필은 또한 요소가 없는 레거시 브라우저를 위한 훌륭한 솔루션입니다.
<img>
요소에 대해 여러 webKit 기반 브라우저에서 사용할 수 있는 srcset
속성의 경우도 있습니다. 이것은 JavaScript 없이 사용할 수 있으며 webKit이 아닌 브라우저를 무시해야 하는 경우 훌륭한 솔루션입니다. 다른 솔루션이 부족하지만 포괄적인 솔루션으로 간주되어서는 안 되는 이상한 경우에 유용한 임시 조치입니다.

그림 채우기
Picturefill은 <picture>
요소에 대한 폴리필 라이브러리입니다. 반응형 이미지 크기 조정 및 크기 조정 문제에 대한 프론트 엔드 솔루션 중에서 가장 인기 있는 라이브러리 중 하나입니다. 두 가지 버전이 있습니다. Picturefill v1은 span
을 사용하여 <picture>
요소를 모방하는 반면 Picturefill v2는 이미 제공하고 레거시 브라우저(예: IE >= IE9의 경우)에 폴리필을 제공하는 브라우저 중에서 <picture>
요소를 사용합니다. 여기에는 몇 가지 제한 사항과 해결 방법이 있습니다. 특히 Android 2.3의 경우입니다. 이는 우연히 img srcset
속성이 구출되는 위치의 예입니다. 다음은 Picturefill v2를 사용하기 위한 샘플 마크업입니다.
<picture> <source media="(min-width: 768px)"> <source media="(max-width: 767px)"> <img alt="My Kitty Cat"> </picture>
제한된 데이터 요금제를 사용하는 사용자의 성능을 향상시키기 위해 Picturefill을 지연 로딩과 결합할 수 있습니다. 그러나 라이브러리는 패치에 의존하기보다 광범위한 브라우저 지원을 제공하고 이상한 경우를 해결할 수 있습니다.
Imager.js
Imager.js는 BBC News 팀이 Picturefill에서 사용하는 것과 다른 접근 방식으로 반응형 이미지를 구현하기 위해 만든 라이브러리입니다. Picturefill이 지원되지 않는 브라우저에 <picture>
요소를 가져오려고 시도하는 동안 Imager.js는 네트워크 속도를 주시하면서 적절한 이미지만 다운로드하는 데 중점을 둡니다. 또한 타사 라이브러리에 의존하지 않고 지연 로딩을 통합합니다. 자리 표시자 요소를 사용하고 이를 <img>
요소로 대체하여 작동합니다. 아래 샘플 코드는 다음과 같은 동작을 보여줍니다.
<div> <div class="image-load" data-src="http://example.com/images/kitty_{width}.jpg" data-alt="My Kitty Cat"></div> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>
렌더링된 HTML은 다음과 같습니다.
<div> <img src="http://example.com/images/kitty_480.jpg" data-src="http://example.com/images/kitty_{width}.jpg" alt="My Kitty Cat" class="image-replace"> </div> <script> new Imager({ availableWidths: [480, 768, 1200] }); </script>
브라우저 지원은 미래 지향적인 것보다 더 실용적인 솔루션이기는 하지만 Picturefill보다 훨씬 낫습니다.
소스 셔플링
소스 셔플링은 나머지 프런트 엔드 라이브러리와 약간 다른 각도에서 반응형 이미지 문제에 접근합니다. 기본적으로 가능한 가장 작은 해상도를 제공하는 "모바일 우선" 사고 방식과 유사합니다. 장치에 더 큰 화면이 있음을 감지하면 이미지 소스를 더 큰 이미지로 바꿉니다. 해킹에 가깝고 본격적인 라이브러리가 아닌 것처럼 느껴집니다. 이것은 주로 모바일 사이트에 대한 훌륭한 솔루션이지만 데스크톱 및/또는 태블릿에 대한 이중 리소스 다운로드를 피할 수 없음을 의미합니다.
다른 주목할만한 JavaScript 라이브러리는 다음과 같습니다.
- HiSRC - 반응형 이미지를 위한 jQuery 플러그인. jQuery에 대한 종속성이 문제일 수 있습니다.
- Mobify.js - 이미지, 스타일시트, JavaScript를 포함한 반응형 콘텐츠를 위한 보다 일반적인 라이브러리입니다. 리소스 로드 전에 DOM을 '캡처'합니다. Mobify는 강력한 종합 라이브러리이지만 목표가 반응형 이미지일 경우 과도할 수 있습니다.
요약
결국 사용자 기반에 적합한 반응형 웹 디자인 이미지 접근 방식을 결정하는 것은 개발자의 몫입니다. 이는 데이터 수집 및 테스트를 통해 접근 방식에 대한 더 나은 아이디어를 얻을 수 있음을 의미합니다.
마무리로 아래 질문 목록은 적절한 반응형 이미지 솔루션을 결정하기 전에 고려하는 데 도움이 될 수 있습니다.
- 레거시 브라우저가 문제입니까? 그렇지 않은 경우 보다 현대적인 접근 방식(예: Picturefill,
srcset
속성) 사용을 고려하십시오. - 응답 시간이 중요합니까? 그렇지 않은 경우 타사 또는 백엔드 솔루션으로 이동하십시오.
- 솔루션이 사내에 있어야 합니까? 타사 솔루션은 분명히 배제됩니다.
- 반응형 이미지로 전환하려는 사이트에 이미 많은 이미지가 있습니까? 유효성 검사 또는 시맨틱 태그(또는 오히려 비시맨틱 태그)에 대한 우려가 있습니까? 이를 위해서는 이미지 요청을 적응형 이미지와 같은 것으로 라우팅하는 백엔드 솔루션이 필요합니다.
- 아트 디렉션이 문제입니까(특히 정보가 많은 큰 이미지의 경우)? Picturefill과 같은 라이브러리는 이러한 시나리오에 더 나은 솔루션이 될 것입니다. 또한 모든 백엔드 솔루션도 작동합니다.
- JavaScript 부족에 대한 우려가 있습니까? UA 스니핑에 의존하는 백엔드 또는 타사 옵션을 남기는 모든 프론트 엔드 솔루션은 문제가 되지 않습니다.
- 데스크톱 응답 시간보다 모바일 응답 시간에 우선 순위가 있습니까? 소스 셔플링과 같은 라이브러리가 더 적합할 수 있습니다.
- 이미지뿐만 아니라 사이트의 모든 측면에 반응형 동작을 제공해야 합니까? Mobify.js가 더 잘 작동할 수 있습니다.
- 완벽한 세상이 이루어졌습니까? CSS 전용
display:none
접근 방식을 사용하세요!