HTML5 사이트를 모바일화

소개

모바일 웹용 개발은 요즘 화두입니다. 올해는 처음으로 스마트폰 판매가 PC 판매를 앞섰습니다. 점점 더 많은 사용자가 휴대기기를 사용하여 웹을 탐색하고 있으므로 개발자가 모바일 브라우저에 맞게 사이트를 최적화하는 것이 중요해지고 있습니다.

'모바일' 전장은 아직 많은 개발자에게 미지의 영역입니다. 많은 사용자가 모바일 사용자를 완전히 무시하는 기존 사이트를 운영하고 있습니다. 대신 이 사이트는 주로 데스크톱 탐색을 위해 설계되었으며 모바일 브라우저에서는 성능이 저하됩니다. 이 사이트 (html5rocks.com)도 예외는 아닙니다. 출시 당시에는 사이트의 모바일 버전에 거의 신경을 쓰지 않았습니다.

모바일 친화적인 html5rocks.com 만들기

연습으로 html5rocks(기존 HTML5 사이트)를 모바일 친화적인 버전으로 보강해 보는 것이 재미있을 것 같았습니다. 저는 주로 스마트폰을 타겟팅하는 데 필요한 최소한의 작업량에 관심이 있었습니다. 이 연습의 목표는 완전히 새로운 모바일 사이트를 만들고 두 가지 코드베이스를 유지하는 것이 아닙니다. 그렇게 하면 시간이 너무 오래 걸리고 시간 낭비가 심해집니다. 이미 사이트의 구조 (마크업)를 정의했습니다. 디자인 및 작동 방식 (CSS)을 확인했습니다. 핵심 기능 (JS)이 있었습니다. 요점은 많은 사이트가 이와 비슷한 상황에 처해 있다는 것입니다.

이 도움말에서는 Android 및 iOS 기기에 최적화된 html5rocks의 모바일 버전을 만든 방법을 살펴봅니다. 이러한 OS 중 하나를 지원하는 기기에서 html5rocks.com을 로드하면 차이를 확인할 수 있습니다. m.html5rocks.com 또는 이와 유사한 리디렉션은 없습니다. html5rocks를 있는 그대로 사용할 수 있으며, 휴대기기에서 멋지게 표시되고 잘 작동하는 이점도 있습니다.

데스크톱 html5rocks.com 모바일 html5rocks.com
데스크톱 (왼쪽) 및 모바일 (오른쪽)의 html5rocks.com

CSS 미디어 쿼리

HTML4 및 CSS2는 한동안 미디어 종속 스타일 시트를 지원해 왔습니다. 예를 들면 다음과 같습니다.

<link rel="stylesheet" media="print" href="printer.css">

인쇄 기기를 타겟팅하고 페이지 콘텐츠가 인쇄될 때 특정 스타일을 제공합니다. CSS3에서는 미디어 유형의 개념을 한 단계 더 발전시키고 미디어 쿼리로 기능을 향상시킵니다. 미디어 쿼리는 스타일 시트를 더 정확하게 라벨링할 수 있도록 허용하여 미디어 유형의 유용성을 확장합니다. 이를 통해 콘텐츠 자체를 변경하지 않고도 콘텐츠의 프레젠테이션을 특정 출력 장치 범위에 맞게 맞춤설정할 수 있습니다. 수정이 필요한 기존 레이아웃에 적합한 것 같습니다.

외부 스타일시트의 media 속성에서 미디어 쿼리를 사용하여 화면 너비, 기기 너비, 방향 등을 타겟팅할 수 있습니다. 전체 목록은 W3C 미디어 쿼리 사양을 참고하세요.

화면 크기 타겟팅

다음 예에서 phone.css는 브라우저에서 '휴대용'으로 간주하는 기기 또는 화면 너비가 320픽셀 이하인 기기에 적용됩니다.

 <link rel='stylesheet'
  media='handheld, only screen and (max-device-width: 320px)' href='phone.css'>

미디어 쿼리의 접두어에 'only' 키워드를 추가하면 CSS3를 준수하지 않는 브라우저에서 규칙을 무시합니다.

다음은 641~800픽셀의 화면 크기를 타겟팅합니다.

 <link rel='stylesheet'
  media='only screen and (min-width: 641px) and (max-width: 800px)' href='ipad.css'>

미디어 쿼리는 인라인 <style> 태그 내에 표시될 수도 있습니다. 다음은 세로 모드 방향일 때 all 미디어 유형을 타겟팅합니다.

 <style>
  @media only all and (orientation: portrait) { ... }
 </style>

media="handheld"

잠시 멈추고 media="handheld"에 대해 논의해야 합니다. 사실 Android와 iOS는 media="handheld"를 무시합니다. 사용자는 media="screen"를 타겟팅하는 스타일시트에서 제공하는 고급 콘텐츠를 놓치게 되고 개발자는 품질이 낮은 media="handheld" 버전을 유지할 가능성이 낮다는 주장입니다. 따라서 '전체 웹' 모토의 일환으로 대부분의 최신 스마트폰 브라우저는 휴대기기 스타일 시트를 무시합니다.

이 기능을 사용하여 휴대기기를 타겟팅하는 것이 가장 좋지만 다양한 브라우저에서 서로 다른 방식으로 구현했습니다.

  • 일부는 휴대기기 스타일 시트만 읽습니다.
  • 일부는 휴대기기 스타일 시트가 있는 경우에만 휴대기기 스타일 시트를 읽고 그렇지 않은 경우에는 화면 스타일 시트를 기본값으로 사용합니다.
  • 일부는 휴대기기 스타일 시트와 화면 스타일 시트를 모두 읽습니다.
  • 일부는 화면 스타일 시트만 읽습니다.

Opera Mini는 media="handheld"를 무시하지 않습니다. Windows Mobile에서 media="handheld"를 인식하도록 하는 방법은 화면 스타일시트의 미디어 속성 값을 대문자로 표시하는 것입니다.

 <!-- media="handheld" trick for Windows Mobile -->
 <link rel="stylesheet" href="screen.css" media="Screen">
 <link rel="stylesheet" href="mobile.css" media="handheld">

html5rocks에서 미디어 쿼리를 사용하는 방법

미디어 쿼리는 모바일 html5rocks 전반에서 널리 사용됩니다. Django 템플릿 마크업을 크게 변경하지 않고도 레이아웃을 조정할 수 있었습니다. 정말 큰 도움이 되었습니다. 또한 다양한 브라우저에서 지원이 매우 우수합니다.

각 페이지의 <head>에는 다음과 같은 스타일시트가 표시됩니다.

 <link rel='stylesheet'
  media='all' href='/static/css/base.min.css' />
 <link rel='stylesheet'
  media='only screen and (max-width: 800px)' href='/static/css/mobile.min.css' />

base.css는 항상 html5rocks.com의 기본적인 디자인을 정의해 왔지만 이제 800px 미만의 화면 너비에 새로운 스타일 (mobile.css)을 적용합니다. 미디어 쿼리는 스마트폰 (~320px)과 iPad (~768px)를 다룹니다. 효과: 모바일에서 더 나은 화면을 제공하기 위해 필요한 경우에만 base.css에서 스타일을 점진적으로 재정의합니다.

mobile.css에서 적용하는 스타일 변경사항은 다음과 같습니다.

  • 사이트 전반에서 여백/패딩을 줄입니다. 화면이 작으면 공간이 매우 중요합니다.
  • :hover 상태를 삭제합니다. 터치 기기에는 표시되지 않습니다.
  • 레이아웃을 단일 열로 조정합니다. 이건 나중에 다시 설명하죠
  • 사이트의 기본 컨테이너 div 주위의 box-shadow를 삭제합니다. 큰 박스 그림자는 페이지 성능을 저하시킵니다.
  • CSS 플렉스 박스 모델 box-ordinal-group를 사용하여 홈페이지의 각 섹션 순서를 변경했습니다. '주요 HTML5 기능 그룹별 학습'이 홈페이지에서는 '튜토리얼' 섹션 앞에 있지만 모바일 버전에서는 그 뒤에 표시됩니다. 이 순서는 모바일에 더 적합했으며 마크업을 변경할 필요가 없었습니다. CSS Flexbox가 최고야!
  • opacity 변경사항을 삭제합니다. 알파 값을 변경하면 모바일에서 성능이 저하됩니다.

모바일 메타 태그

Mobile WebKit은 사용자에게 특정 기기에서 더 나은 탐색 환경을 제공하는 몇 가지 기능을 지원합니다.

표시 영역 설정

첫 번째 메타 설정 (가장 자주 사용)은 뷰포트 속성입니다. 표시 영역을 설정하면 브라우저에 콘텐츠가 기기 화면에 어떻게 표시되어야 하는지 알려주고 사이트가 모바일에 최적화되었다고 브라우저에 알립니다. 예를 들면 다음과 같습니다.

 <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes">

브라우저에 표시 영역을 기기 너비로 설정하고 초기 배율을 1로 설정하라고 지시합니다. 이 예에서는 웹사이트에는 유용할 수 있지만 웹 앱에는 유용하지 않은 확대/축소도 허용합니다. user-scalable=no를 사용하여 확대/축소를 방지하거나 특정 수준으로 크기 조정을 제한할 수 있습니다.

 <meta name=viewport
  content="width=device-width, initial-scale=1.0, minimum-scale=0.5 maximum-scale=1.0">

Android는 개발자가 사이트가 개발된 화면 해상도를 지정할 수 있도록 하여 표시 영역 메타 태그를 확장합니다.

 <meta name="viewport" content="target-densitydpi=device-dpi">

target-densitydpi의 가능한 값은 device-dpi, high-dpi, medium-dpi, low-dpi입니다.

다양한 화면 밀도에 맞게 웹페이지를 수정하려면 -webkit-device-pixel-ratio CSS 미디어 쿼리 또는 JavaScript의 window.devicePixelRatio 속성을 사용한 다음 target-densitydpi 메타 속성을 device-dpi로 설정하세요. 이렇게 하면 Android가 웹페이지에서 크기 조정을 실행하지 못하고 CSS 및 JavaScript를 통해 각 밀도에 필요한 조정을 할 수 있습니다.

기기 해상도 타겟팅에 관한 자세한 내용은 Android의 WebView 문서를 참고하세요.

전체 화면 탐색

다른 두 가지 메타 값은 iOS-sfic입니다. apple-mobile-web-app-capable 및 apple-mobile-web-app-status-bar-style는 앱과 같은 전체 화면 모드로 페이지 콘텐츠를 렌더링하고 상태 표시줄을 반투명하게 만듭니다.

 <meta name="apple-mobile-web-app-capable" content="yes">
 <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">

사용 가능한 모든 메타 옵션에 관한 자세한 내용은 Safari 참조 문서를 참고하세요.

홈 화면 아이콘

iOS 및 Android 기기에서는 링크에 rel="apple-touch-icon" (iOS) 및 rel="apple-touch-icon-precomposed" (Android)도 허용합니다. 이렇게 하면 사용자가 사이트를 북마크에 추가할 때 사용자의 홈 화면에 화려한 앱 아이콘이 생성됩니다.

 <link rel="apple-touch-icon"
      href="/static/images/identity/HTML5_Badge_64.png" />
 <link rel="apple-touch-icon-precomposed"
      href="/static/images/identity/HTML5_Badge_64.png" />

html5rocks에서 모바일 메타 태그를 사용하는 방법

모든 것을 종합하면 다음은 html5rocks의 <head> 섹션에서 가져온 스니펫입니다.

 <head>
  ...
   <meta name="viewport"
        content="width=device-width, initial-scale=1.0, minimum-scale=1.0" />

   <link rel="apple-touch-icon"
        href="/static/images/identity/HTML5_Badge_64.png" />
   <link rel="apple-touch-icon-precomposed"
        href="/static/images/identity/HTML5_Badge_64.png" />
  ...
 </head>

수직 레이아웃

작은 화면에서는 가로보다 세로로 스크롤하는 것이 훨씬 편리합니다. 모바일의 경우 콘텐츠를 단일 열 세로 레이아웃으로 유지하는 것이 좋습니다. html5rocks에서는 CSS3 미디어 쿼리를 사용하여 이러한 레이아웃을 만들었습니다. 마크업을 변경하지 않고 다시 실행합니다.

튜토리얼 색인 튜토리얼 HTML5 기능 페이지 저자 프로필 페이지
사이트 전체에 단일 열 세로 레이아웃이 적용됩니다.

모바일 최적화

이번에 이루어진 최적화의 대부분은 애초에 실행했어야 하는 작업입니다. 네트워크 요청 수 줄이기, JS/CSS 압축, gzipping (App Engine에서 무료로 제공됨), DOM 조작 최소화 등이 여기에 해당합니다. 이러한 기법은 일반적인 권장사항이지만 사이트를 서둘러 출시할 때 간과되는 경우가 있습니다.

주소 표시줄 자동 숨기기

모바일 브라우저는 데스크톱 브라우저에 비해 화면 공간이 부족합니다. 최악의 경우 페이지 로드가 완료된 후에도 다양한 플랫폼에서 화면 상단에 큰 주소 표시줄이 표시되는 경우가 있습니다.

이를 처리하는 간단한 방법은 JavaScript를 사용하여 페이지를 스크롤하는 것입니다. 1픽셀만 이동해도 귀찮은 주소 표시줄이 사라집니다. html5rocks에서 주소 표시줄을 강제로 숨기기 위해 onload 이벤트 핸들러를 window 객체에 연결하고 페이지를 세로로 1픽셀 스크롤했습니다.

주소 표시줄
보기에 좋지 않은 주소 표시줄이 화면 공간을 차지합니다.
  // Hides mobile browser's address bar when page is done loading.
  window.addEventListener('load', function(e) {
    setTimeout(function() { window.scrollTo(0, 1); }, 1);
  }, false);

또한 이 리스너는 데스크톱에서 필요하지 않으므로 is_mobile 템플릿 변수로 래핑했습니다.

네트워크 요청 줄이고 대역폭 절약

HTTP 요청 수를 줄이면 성능이 크게 개선될 수 있다는 것은 잘 알려진 사실입니다. 휴대기기는 브라우저에서 동시에 연결할 수 있는 수를 더욱 제한하므로 이러한 불필요한 요청을 줄이면 모바일 사이트에 더 많은 이점이 있습니다. 또한 휴대전화에서는 대역폭이 제한되는 경우가 많으므로 모든 바이트를 줄이는 것이 중요합니다. 사용자에게 비용이 청구될 수 있습니다.

다음은 html5rocks에서 네트워크 요청을 최소화하고 대역폭을 줄이기 위해 취한 몇 가지 접근 방식입니다.

  • iframe 삭제 - iframe은 느립니다. 상당한 양의 지연 시간은 튜토리얼 페이지의 서드 파티 공유 위젯 (Buzz, Google Friend Connect, 트위터, Facebook)에서 발생했습니다. 이러한 API는 <script> 태그를 통해 포함되었으며 페이지 속도를 저하시키는 iframe을 만듭니다. 모바일의 경우 위젯이 삭제되었습니다.

  • display:none - 경우에 따라 마크업이 모바일 프로필에 맞지 않으면 숨겨졌습니다. 홈페이지 상단에 있는 네 개의 둥근 상자가 좋은 예입니다.

홈페이지의 상자 버튼
홈페이지의 상자 버튼

모바일 사이트에서 누락되었습니다. 컨테이너가 display:none로 숨겨져 있더라도 브라우저는 여전히 각 아이콘에 대해 요청한다는 점에 유의해야 합니다. 따라서 이러한 버튼을 숨기는 것만으로는 충분하지 않았습니다. 이렇게 하면 대역폭이 낭비될 뿐만 아니라 낭비된 대역폭의 성과를 사용자에게 보여주지도 못합니다. 해결 방법은 Django 템플릿에 'is_mobile' 불리언을 만들어 HTML 섹션을 조건부로 생략하는 것이었습니다. 사용자가 스마트 기기에서 사이트를 보는 경우 버튼이 표시되지 않습니다.

  • 애플리케이션 캐시 - 오프라인 지원을 제공할 뿐만 아니라 시작 속도를 높입니다.

  • CSS/JS 압축 - CSS와 JS를 모두 처리하기 때문에 주로 Closure 컴파일러 대신 YUI 압축기를 사용합니다. 발생한 한 가지 문제는 인라인 미디어 쿼리(스타일시트 내에 표시되는 미디어 쿼리)가 YUI 압축기 2.4.2에서 작동하지 않는 문제였습니다 (이 문제 참고). YUI Compressor 2.4.4 이상을 사용하면 문제가 해결되었습니다.

  • 가능한 경우 CSS 이미지 스프라이트를 사용합니다.

  • 이미지 압축에 pngcrush를 사용했습니다.

  • 작은 이미지에 dataURI를 사용했습니다. Base64 인코딩은 이미지 크기를 30%이상 늘리지만 네트워크 요청은 저장합니다.

  • google.load()로 동적으로 로드하는 대신 단일 스크립트 태그를 사용하여 Google 맞춤 검색을 자동으로 로드했습니다. 후자는 추가 요청을 실행합니다.

<script src="//www.google.com/jsapi?autoload={"modules":[{"name":"search","version":"1"}]}"> </script>
  • 코드 뷰티 프린터와 Modernizr가 사용되지 않았는데도 모든 페이지에 포함되었습니다. Modernizr는 좋지만 로드할 때마다 여러 테스트를 실행합니다. 이러한 테스트 중 일부는 DOM을 비용이 많이 드는 방식으로 수정하고 페이지 로드를 느리게 만듭니다. 이제 이러한 라이브러리는 실제로 필요한 페이지에만 포함됩니다. 요청 -2개 :)

추가 성능 조정:

  • 가능한 경우 모든 JS를 페이지 하단으로 이동했습니다.
  • 인라인 <style> 태그를 삭제했습니다.
  • 캐시된 DOM 조회 및 최소화된 DOM 조작 - DOM을 터치할 때마다 브라우저가 리플로를 실행합니다. 휴대기기에서는 리플로가 더 많은 비용이 듭니다.
  • 낭비적인 클라이언트 측 코드를 서버로 오프로드했습니다. 특히 현재 페이지의 탐색 스타일을 설정하는 확인란은 다음과 같습니다. js var lis = document.querySelectorAll('header nav li'); var i = lis.length; while (i--) { var a = lis[i].querySelector('a'); var section = a.getAttribute("data-section"); if (new RegExp(section).test(document.location.href)) { a.className = 'current'; } }
  • 고정 너비의 요소가 유동적인 width:100% 또는 width:auto로 대체되었습니다.

애플리케이션 캐시

html5rocks의 모바일 버전은 애플리케이션 캐시를 사용하여 초기 로드 속도를 높이고 사용자가 콘텐츠를 오프라인으로 읽을 수 있도록 합니다.

사이트에서 AppCache를 구현할 때는 매니페스트 파일을 캐시하지 않는 것이 매우 중요합니다 (매니페스트 파일 자체에서 명시적으로 또는 캐시 제어 헤더가 많은 경우 암시적으로). 매니페스트가 브라우저에 캐시되면 디버그하기가 매우 어렵습니다. iOS와 Android는 이 파일을 캐시하는 데 특히 효과적이지만 데스크톱 브라우저와 달리 캐시를 플러시하는 편리한 방법을 제공하지 않습니다.

사이트에서 이러한 캐싱을 방지하기 위해 먼저 App Engine이 매니페스트 파일을 캐시하지 않도록 설정합니다.

- url: /(.*\.(appcache|manifest))
  static_files: \1
  mime_type: text/cache-manifest
  upload: (.*\.(appcache|manifest))
  expiration: "0s"

둘째, JS API를 사용하여 새 매니페스트 다운로드가 완료되면 사용자에게 알렸습니다. 페이지를 새로고침하라는 메시지가 표시됩니다.

window.applicationCache.addEventListener('updateready', function(e) {
  if (window.applicationCache.status == window.applicationCache.UPDATEREADY) {
    window.applicationCache.swapCache();
    if (confirm('A new version of this site is available. Load it?')) {
      window.location.reload();
    }
  }
}, false);

네트워크 트래픽을 줄이려면 매니페스트를 간단하게 유지하세요. 즉, 사이트의 모든 페이지를 호출하지 마세요. 중요한 이미지, CSS, JavaScript 파일만 나열하면 됩니다. 마지막으로 앱 캐시가 업데이트될 때마다 모바일 브라우저에서 많은 수의 애셋을 강제로 다운로드하도록 해서는 안 됩니다. 대신 사용자가 방문할 때 브라우저가 html 페이지를 암시적으로 캐시한다는 점에 유의하세요(<html manifest="..."> 속성이 포함된 경우).