[번역글]반응형 웹 디자인의 단점
(원제: You may be losing users if responsive web design is your only mobile strategy)
반응형 페이지로 사이트를 제작하고서, 브라우저를 크기를 조절하며 아마도 뿌듯한 미소를 지을겁니다. 모바일에 우호적인 웹사이트 제작이라는 목적을 달성했다고 생각할 것입니다. 그러나 반응형 웹 디자인이 전체 목적이자 모바일을 위한 유일한 해결책이라면, 사용자와 아마도 그에 따른 수입을 잃게 될지도 모릅니다.
어떻게 하면 반응형 디자인을 현명하게 적용할 수 있는지부터 시작해서, 왜 모바일에서의 퍼포먼스가 중요한지, 왜 반응형 디자인이 웹 사이트의 최종 목표가 되어서는 안되는지, 마지막으로 문제를 이해하도록 도와줄 반응형 디자인의 기술적 퍼포먼스 이슈까지 다루면서 모바일 웹과 반응형 디자인의 관계에 대해서 살펴보고자 합니다.
디자이너와 개발자는 2000년부터 모바일 페이지의 문제를 지나치게 단순화했고, 일부는 지금 그 모든 문제를 해결해주는 답이 반응형 웹 디자인이라고 생각하고 있을 것입니다. 우리는 다른 어떤 목표보다 모바일 웹 경험은 아주 빨라야 한다는 것을 이해할 필요가 있습니다. 빠르고, 사용하기 편리하고, 모든 모바일 기기에서 호환되는 경험을 전달하는 것은 언제나 도전 과제가 되어왔으며, 반응형 기술을 구현할 때도 마찬가지 입니다.
반응형 웹 디자인은 훌륭하지만, 묘책은 아닙니다. 이것이 모바일을 위한 유일한 대책이라면, 아마도 성능 문제가 사이트의 전환 비율(conversion rate)를 떨어뜨릴지도 모릅니다. 약 11%의 웹사이트가 반응형이고(2014년 7월 기준), 그 수는 매달 증가합니다. 그러므로 지금이 이 문제를 논의할 때입니다.
Guy Podjarny의 연구에 따르면, 72%의 반응형 웹 사이트가 스크린 사이즈, 심지어는 속도가 느린 모바일 네트워크 접속 여부에 관계없이 같은 양의 바이트를 전송합니다. 모든 사용자가 웹 사이트가 로딩될 때까지 기다리지 않습니다. 문제에 대한 기본적인 이해만 있어도, 이 손실을 최소화할 수 있습니다.
과거의 모바일 웹사이트
반응형으로 디자인을 하면 안된다거나 m.*로 시작하는 서브 도메인을 반드시 채택해야한다는 것이 아닙니다. 사실, 문서당 하나의 URL을 할당하는 것이 기기에 상관없이 현명한 방법입니다. 그러나 이것은 하나의 URL이 반드시 같은 문서를 전송해야 한다거나 또는 모든 기기가 같은 리소스를 다운로드 해야한다는 것을 의미하지는 않습니다. "반응형 웹 디자인(responsive web design)"이라는 용어를 만든 Ethan Marcotte은 이렇게 말했습니다.
"가장 중요한 것은, 반응형 웹 디자인이
모바일 웹 사이트를 위한 대체 수단으로서의 역할을 수행하기 위해 의도된 것이 아니라는 점이다."
반응형 모바일 속도
특정한 기술을 사용한다면 모바일에서의 성능에 영향을 주지 않고 반응형 웹 디자인의 이점만 얻을 수 있습니다. 반응형 웹 디자인은 성능문제를 "해결"하려고 한적이 없습니다. 그렇기 때문에 기술 자체를 비난할 수는 없습니다. 그러나, 많은 사람들이 그러는 것처럼 모든 문제를 반응형으로 해결할 수 있다고 믿는 것은 틀릴 수 있습니다.
반응형으로 디자인하는 것은 중요합니다. 왜냐하면 데스크탑과 모바일에 걸친 뷰포트 사이즈의 범위를 다루어야할 필요가 있기 때문입니다. 그러나 스크린 사이즈만을 생각하면 모바일 장치의 특성을 무시하게 될 수 있습니다. 데스크탑과 모바일 사이의 경계는 옅어져가는 반면에, 장치 유형에 대한 다른 가능성은 아직도 열려있습니다.
묘책과 여러 유형의 문서에 적용할 수 있는 해결책은 없지만, 성능을 최대화하고 기존의 반응형 문제점을 개선할 수있는 몇 가지 트릭(trick)을 사용할 수 있습니다.
- 각 문서가 모든 기기에 같은 URL로 같은 컨텐츠를 전송하지만, 필수적으로 같은 구조는 아니다.
- 기획 단계부터, 모바일 우선 접근법을 따른다.
- 리소스가 로드될 때와 display:none이 적용될 때 일어나는 일을 실제 기기에서 테스트 한다.
데스크탑 브라우저 리사이징을 통한 테스트에 의존하지 않는다.
-최적화 툴을 사용하여 측정하고 성능을 개선한다.
-JavaScript나 srcset을 통해서 반응형 이미지를 전송한다.
-조건적인 로딩을 사용하여 현재 장치를 위해 필요한 자바스크립트만 로딩한다.
-이 기술들의 하나 혹은 그 이상의 반응형 웹 해결책을 적용한다: 조건적 로딩, 그룹에 따른 반응형, 서버 사이드 레이어(적응형 접근-adaptive approach-과 같은)
조건적인 로딩
CSS안에 있는 미디어 쿼리에 언제나 의존하면 안됩니다. 왜냐하면 브라우저는 모든 기기에 대한 스타일과 셀렉터 전체를 로드하고 파싱할 것이기 때문입니다. 이것은 모바일에서 더 큰 스크린을 위한 CSS를 다운로드하고 파싱한다는 것을 의미합니다. 그리고 CSS가 렌더링을 방해하기 때문에, 모바일 접속에 대해서 소중한 시간을 낭비하게 됩니다.
앞으로 변화가 일어나지 않을 장치에 대해서는 CSS 미디어 쿼리를 JavaScript의 matchMedia 쿼리로 대체할 수 있습니다. 예를 들어, 우리는 아이폰이 급작스럽게 아이패드의 사이즈로 전환될 수 없다는 것을 알고 있습니다. 그래서 정말 필요한 부분의 CSS만을 로드하면 됩니다.
Modernizr와 같이 사용자 브라우저에서의 특징을 감지해주는 JavaScript 라이브러리를 이용할 수 있습니다. 이것은 스크린 차원에서의 기능뿐만 아니라 UI측면에서도 더 나은 선택입니다.
그룹에 따른 반응
단순한 문서를 다룰 때 모든 스크린을 위한 반응형 디자인과 단일 HTML에 의존하지만, 데스크탑과 스마트폰에 같은 HTML을 전송하는 것은 최선의 해결책이 아닙니다. 왜냐하면 아까도 언급했듯이 모바일의 성능때문입니다.
서버 사이드에 같은 문서를 저장하고 있다고 할지라도, 장치 그룹에 기반을 두어 사용자마다 다르게 전송할 수 있습니다. 예를 들어, 6인치 스크린과 그보다 큰 스크린에는 큰 메뉴를, 6인치보다 작은 스크린에는 작은 메뉴를 전송할 수 있습니다. 각 그룹 안에서, 아이폰(320px), 5인치 안드로이드 장치(360px), 패블릿(400px 이상)별로 다양화시키던지, portrait와 landscape 모드를 바꾸는 것과 같이 다른 시나리오를 적용시키는 반응형 기술을 사용할 수 있습니다.
서버 사이드 레이어
현명한 반응형 해결책의 마지막 옵션은 서버입니다. 서버 사이드 특징 감지와 결정은 모바일웹에서 새로운 것이 아닙니다. WURFL과 Device Atlas과 같은 라이브러리가 몇 년 동안 사용되어 왔습니다. 서버 사이드 콤포넌트와 반응형 디자인을 혼합하는 것은 새롭지 않습니다. 한때 반응형 디자인과 서버 사이드 콤포넌트(responsive design and server-side components;RESS)로 알려지기도 했고, 한때는 적응형 디자인(adaptive design)으로 알려졌습니다. 이는 모든 서버 사이드에 단일 코드에 기반을 두면서도, 반응형 디자인의 사용성과 속도를 개선시켰습니다.
반응형 디자인, 성능과 기술적 데이터
반응형 디자인은 흔히 모든 장치에 같은 HTML 문서를 전송하고 다른 CSS와 이미지 파일을 로드하기 위해 미디어 쿼리를 사용합니다. 조금 다르게 생각할 수도 있겠지만, 이것이 보통 반응형 웹디자인이 구현되는 방법입니다. 아마 요즘 모바일 네트워크는 뛰어난 사용경험을 줄 수 있을 정도로 빠르다고 생각할 수도 있고, 실제로 장치는 점점 빨라지고 있습니다. 그러나 결론을 내리기 전에 데이터를 보려고 합니다.
모바일 연결
흔히 모바일 네트워크 속도를 표현할 때 대역폭이라는 용어를 떠올립니다. 3G는 5Mbps, 4G는 50Mbps 정도 입니다. 그러나 이것은 모바일 웹 브라우저 경험을 위해 가장 중요한 요인은 아닙니다. 대역폭이 크면 큰 파일(예를 들어, 유투브 비디오)을 전송하기에 유용하지만, 작은 파일을 많이 다운로드 할 때는 별다른 영향을 주지 못하며, 호출 시간이 길고 고정적입니다. 호출 시간은 리퀘스트 이후에 모든 패키지의 첫 바이트가 장치에 도달하는 왕복 시간입니다.
모바일 네트워크는 다른 연결에 비해 보다 긴 호출시간을 가지고 있습니다. 미국의 경우, DSL 연결에서 호출 시간은 20~45 밀리초, 3G는 150~450밀리초, 4G에서는 100~180 밀리초입니다. 달리 말하면, 호출 시간은 일반 홈 네트워크에 비해 5~10배 정도입니다.
클라우드 기반 브라우저
만약 여전히 모바일 웹의 성능이 의심스럽다면, 브라우저 벤더들이 만들 고 있는 클라우드 기반 브라우저를 고려할 수 있습니다. 오페라 미니, UC 브라우저, 아마존 Fire의 Silk, 구글 크롬(설정 옵션을 통한) 등이 있습니다. 이 벤더들은 클라우드에서 웹 사이트와 리소스를 합축하고, 브라우저는 모바일 장치에 최적화된 버전을 다운로드 합니다.
모바일 웹의 과소평가
웹 커뮤니티는 언제나 모바일 브라우저의 중요성에 대해 과소평가 해왔습니다. 일부는 오늘날의 모바일웹은 iOS를 위한 Safari, 안드로이드를 위한 크롬이며, 반응형 디자인을 위해 신경쓸 것은 오로지 320px 폭의 뷰포트라고 말합니다. 그러나 실제로는 훨씬 복잡합니다.
오늘날, 10개가 넘는 브라우저가 1% 이상의 시장 지분을 가지고 있습니다. iOS와 안드로이드를 위한 기본 브라우저만 신경을 쓰면 된다고 생각할 수도 있지만 그렇게 간단하지 않습니다. 모바일 유저의 대략 50%는 iOS에서, 안드로이드는 38%, 윈도우폰은 3%, 오페라 미니는 4%(다양한 운영체제에서), 다른 플랫폼에서 4%가 웹에 접속합니다.
안드로이드에서, 사용자의 64%는 구글 크롬이 아닌 안드로이드에 내장된 브라우저를 사용하며, 각각 버전도 상이합니다. 게다가, 삼성의 갤럭시는 커스터마이즈된 엔진을 사용하는 안드로이드 브라우저의 버전을 갖고 있습니다. 뷰포트 사이즈와 관련하여, 안드로이드 스마트폰 하나만해도 320, 360,400, 540px 너비를 다뤄야 합니다. 따라서 모바일웹을 절대 과소평가해서는 안되며 고유의 특징을 배워야 할 것입니다.
전체를 위한 하나의 HTML
전형적인 반응형 디자인은 TV, 데스크탑, 태블릿, 스마트폰, 피쳐폰 등의 모든 장치를 위해 단일 HTML 문서를 전송합니다. 훌륭하게 들릴 수도 있지만, 지금은 핸드폰과 다른 문제들이 있는 시대입니다. 반응형 HTML은 모바일 장치에서 올바르게 렌더링될 것이지만, 달성해야 하는 속도보다 느릴 것이며, 이것은 전환비율에 영향을 줄 것입니다.
CSS에서 'display: none' 이 하나라도 사용된다면, 웹 사이트는 최대 속도에 비해 느려집니다. 대부분 큰 스크린을 위해 사용되는jQuery 플러그인과 고급 라이브러리 등 40개의 외부 스크립트를 포함하고 있다면, 반응형 웹사이트는 과부하가 걸릴 것입니다. 같은 HTML을 사용할 때, 모든 장치를 위한 같은 외부 리소스가 선언될 것입니다.
반응형 디자인 단독으로는 안된다는 것이 아니라, 웹사이트가 초기설정에 의해 최적화되지 않는다는 것입니다.
아래는 스타벅스 웹사이트 입니다. 홈페이지는 반응형이고, 세 개의 뷰 포트에서 훌륭하게 나옵니다. 그러나 내부를 확인해보니 모든 버전에서 33개의 외부 자바스크립트 파일과 6개의 CSS 파일을 로드하고 있었습니다. 모바일 장치가 3G라면 아래와 같은 화면이 보이기 위해서 39개의 외부파일을 로드하기 위한 호출 시간이 가치가 있는 것일까요?
일부는 기술이 아니라 구현방법이 잘못되었다고 생각할 수 있습니다. 맞는 말입니다. 말하고자 하는 것은 단지 스타벅스 웹사이트의 사례에서 봤듯이, 반응형을 목표로 설정하는 것과 성능보다 반응형이 우선시 되는 것이 잘못되었다는 점입니다. 브라우저를 리사이즈했을 때 훌륭하게 보이지만, 그것이 중요한 것의 전부는 아닙니다. 많은 모바일 사용자에게는 성능도 아주 중요한 요소입니다.
반응형 웹사이트의 성능 문제를 겪고 있다면, 목표 설정에 문제가 있을 것입니다. 반응형 디자인을 위한 예산이 있다면, 성능을 위한 예산 또한 반드시 있어야할 것입니다.
리소스 로딩
미디어 쿼리는 보통 아래에서 한 가지 방법으로 다르게 구현됩니다.
- 여러개의 @media 선언을 한 단일 CSS 파일
- 미디어 속성을 통해 메인 페이지에 링크가 걸린 여러개의 CSS 파일
첫번째 경우, 단지 하나의 CSS 그룹만 있기 때문에 어느 장치나 모든 장치를 위한 CSS를 로드합니다. 어쨌든 한 번도 사용되지 않을 수백개의 선택자가 전송되고 브라우저에서 파싱될 것입니다.
breakpoint에 기반을 둔 리소스 로드 때문에 복수의 외부 파일이 더 나을 것이라고 생각할 수 있습니다. 이는 블로그, 잡지, 책, 훈련 코스에서 많이 알려진 방법입니다.
<link rel="stylesheet" href="desktop.css"
media="(min-width: 801px)">
<link rel="stylesheet" href="tablet.css"
media="(min-width: 401px) and (max-width: 800px)">
<link rel="stylesheet" href="mobile.css"
media="(max-width: 400px)">
하지만 꼭 그렇지는 않습니다. 모든 브라우저는 모든 외부 CSS를 로드할 것입니다. 아래의 스크린샷은 아이폰이 링크된 모든 불필요한 CSS 파일까지 다운로드 하고 있는 것을 보여줍니다.
왜 브라우저는 모든 CSS 파일을 다운로드 할까요? 예를 들어 portrait 기반을 위한 CSS 파일과 landscape를 위한 CSS 파일을 가지고 있다고가정해봅시다. 로드되는 몇 초간 CSS가 적용되지 않은 화면을 봐야하기 때문에, 사용자는 화면이 전환되었을 때 브라우저가 CSS를 로드하기를 원치 않습니다. 미리 두 개의 파일을 로드해 놓기를 바랍니다. 이것이 스크린 차원에 기반하여 미디어 쿼리를 정의했을 때 발생하는 일입니다.
진짜 문제는 반응형 디자인이 목표로 되는 것
디자이너는 "반응형"을 다르게 정의하고, 이것은 의사소통의 문제를 불러올 수 있습니다. 근본으로 돌아가보겠습니다. '반응형'이라는 용어는 Ethan Marcotte의 2010년 포스트에서 처음 등장하였습니다. Ethan은 '반응형'을 유동적 그리드, 플렉서블 이미지와 미디어 쿼리의 세 가지 기술을 사용하여 넓은 범위의 장치들에서 최선의 화면을 제공하는 것이라고 정의하였습니다.
정의는 아무것도 잘못되지 않았습니다. 진짜 문제는 달성해야하는 더 큰 목표에 대한 이해 없이 웹 사이트의 목표를 반응형으로 설정하는 것입니다. 반응형 디자인을 목표로 설정했을 때, 전체 문제를 올바르게 보는 능력을 잃게 되기 쉽습니다. 해결하려는 진짜 문제가 무엇일까요? 반응형으로 만드는 것이 진짜 문제일까요? 아마도 아닐 것입니다. 그러나 '반응형으로 만드는 것'이 '모바일과 호환하는 것'을 의미한다고 이해하고 있지는 않은가요?
웹 사이트의 최종 목표는 좀 더 높은 전환율을 이끌 수 있는 '사용자의 만족'이 되어야 합니다. 방문자가 입소문을 내고, 정보를 제공하고, 구매를 하게 만들어야 합니다. 사용자는 높은 성능의 웹사이트가 아니라면 만족하지 않습니다. 특히 모바일에서 성능이 전환율에 직접적인 영향을 가지고 있다는 것이 여러번 증명되어 왔습니다. 이 내용을 처음 듣는다면, Steve Souders의 웹 성능 최적화에 관한 전문 서적을 확인해 보세요. 목표를 알아야, 그것을 달성하기 위한 최선의 툴과 기술들을 결정할 수 있습니다. 반응형 디자인을 '사용'하되, 그것을 '달성'하려고 해서는 안될 것입니다.
반응형 VS 사용자
뉴욕 타임즈는 사용자를 염두에 두고, 1년 전 웹 사이트를 재디자인 하였습니다. 한편으로는, 수 천개의 큰 회사들이 새로운 반응형 웹사이트에 자부심을 드러내고 있습니다. 뉴욕 타임즈는 다른 방법으로 반응형 디자인을 구현하였으나, 일부는 같은 HTML에 기반을 둔 레이아웃을 정용하는 대신에 분리된 모바일 버전을 사용하는 것에 대해 불평하였습니다. "최근 뉴욕타임즈의 웹 앱이 반응형 디자인의 포인트를 놓쳤다."는 제목의 기사가 나오기도 했습니다.
반응형 웹 디자인이 같은 HTML로 모든 가능한 사이즈의 스크린을 지원하는 것을 의미할까요? 물론, 일반적인 이해는 그렇지만, 규칙은 어디에도 쓰이지 않았습니다. 단지 문제를 단순히 하기 위한 필요에 의해서 그렇게 된 것입니다. 최근 몇달간, 회사들은 "새로운 반응형 디자인을 적용하였고, 이제는 모바일 접속이 100%로 늘었다."는 말을 해오고 있습니다. 그러나 웹 사이트가 반응형으로 만들어졌기 때문에 접속이 증가하거나 사용자가 반응형 사이트라는 것을 깨닫고 더 만족하며 접속하는 것일까요?
사람들의 모바일 기기에 대한 경험이 증가하였고 더욱 빨라졌기 때문에 모바일 접속이 높아진 것입니다. 반응형은 단지 아무것도 없는 것보다 낫고 예전의 모바일 구현보다 나은 것입니다. 그러나 같은 디자인의 분리된 모바일 웹사이트 혹은 기술을 통한 더 나은 해결책이 더 높은 접속율을 달성할 수 있을 것입니다.
결론
사용자는 사용하기 쉽고 빠른 것을 원합니다. 사용자들은 보통 브라우저를 리사이징하지 않고, '반응형'이 무엇인지 이해하고 싶어하지도 않습니다. 사이트가 단지 반응형이고, 모바일을 포용하고 있다는 것에 만족하지 않고, 반응형 디자인이 성능상 좋지 않다는 것을 인지해야 합니다. 최종목적은 사용자가 되어야 합니다. 툴 혹은 기술 혹은 디자이너들의 만족이 목표가 되어서는 안 될 것입니다.
