IT/Web Dev | Posted by 철규님(최규철) 2011. 3. 10. 01:02

[펌/번역] "Mobifying" Your HTML5 Site

※ 잘못 번역된 내용이 “당연히” 있을 테니 참고해서 읽으세요.
번역 오류나 개선, 오타에 대한 피드백은 언제나 환영하고 감사드립니다. ^^

"Mobifying" Your HTML5 Site
당신의 HTML5 사이트를 “모바일화”하기


Written by Eric Bidelman - Developer Relations, Google on March 3, 2011
Translated by GyuCheol Choi(gc8134.choi@gmail.com) on March 9, 2011
원문 보기



개요

모바일 웹 개발이 최근 화두가 되고 있다. 최초로 올해에는 스마트폰이 PC보다 더 많이 팔릴 것이다. 더 많은 사용자가 웹 서핑을 위해 모바일 장치를 사용하게 될 것이고, 이것은 개발자들은 그들의 사이트를 모바일 브라우저에 최적화하는 것이 매우 중요해졌음을 의미한다.

"모바일"이라는 격전지는 아직 개발자들에게는 미지의 영역이다. 모바일 사용자들을 전혀 고려하지 않은 많은 전통적인 사이트들이 아직 존재한다. 대신 그 사이트들은 데스크탑 브라우징을 위해 디자인되고 모바일 브라우저용으로 조잡하게 변형되어 있다. 이 사이트(html5rocks.com) 역시 예외는 아니다. 초기에 우리는 사이트의 모바일 버전에는 전혀 신경을 쓰지 않았다.



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

시험삼아, html5rocks(현재의 HTML5 사이트)를 가지고 모바일 친화적인 버전을 만들어보는 것이 재미있겠다고 생각했었다. 나는 스마트폰을 타겟으로 할 때 필요한 일의 양이 최소한인 것에만 관심이 있었다. 나의 목표는 완전히 새로운 모바일 사이트를 만들고 두 개의 코드 베이스를 유지하는 것이 아니었다. 그것은 끝나지도 않을 것이고, 엄청난 양의 시간 낭비일 것이다. 우리는 이미 정의된 사이트 구조(마크업)을 가지고 있다. 우리는 룩&필(CSS)을 가지고 있다. 주요 기능성(JS)도 있다. 중요한 점은 많은 사이트들이 비슷한 처지라는 것이다.

이 글을 통해 우리가 어떻게 안드로이드와 iOS 장치에 최적화된 html5rocks의 모바일 버전을 만들었는지 알아보려고 한다. 차이점을 보길 원하면 이러한 OS를 지원하는 장치에서 html5rocks.com 사이트를 열어보라. m.html5rocks.com으로의 리디렉션이나 이와 같은 어떠한 멍청한 조취도 없다. 당신은 html5rocks를 ?모바일 장치에서 잘 보이고 잘 동작하는 그러한 이점만 추가된- 있는 그대로를 보게 된다.

데스크탑(좌)과 모바일 장치(우)에서의 html5rocks.com



CSS 미디어 쿼리

HTML4와 CSS2는 필요에 의해 미디어-의존적인 스타일 시트를 지원한다. 예를 들면

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

이 코드는 프린터를 타겟으로 하여, 이 페이지의 내용이 출력될 때를 위한 특별한 스타일을 제공한다. CSS3는 이 아이디어를 받아들여서 한 발 더 나아가 미디어 쿼리로 기능성을 향상 시켰다. 미디어 쿼리는 스타일 시트의 라벨에 더 자세한 사항을 기입할 수 있게 함으로써 미디어 타입의 사용성을 확장했다. 이것은 컨텐츠가 보여지는 것을 컨텐츠 자체를 수정하지 않아도 출력 장치의 특성에 맞게 최적화 할 수 있게 한다. 수정이 필요한 현재의 레이아웃에 있어서는 완벽한 것 같다!

타겟 스크린 폭, 장치의 폭, 방향 등을 나타내기 위해서 외부 스타일시트의 미디어 속성에 media 쿼리를 사용할 수 있다. 전체 리스트는 W3C media query specification을 보면 된다.


스크린 사이즈 지정하기

다음의 예제에서, phone.css는 브라우저가 "handheld"로 인식하는 장치나 320px 이하의 폭을 가진 장치에 적용될 것이다.

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

미디어 쿼리 앞에 "only"를 두는 것은 CSS3를 지원하지 않는 브라우저에서는 이 규칙을 무시하게 해준다. 다음은 641px과 800px 사이의 스크린 크기를 가진 장치를 대상으로 한다.

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

미디어 쿼리는 인라인 <style>태그 내에서도 사용될 수 있다. 다음은 가로 방향에서의 모든 미디어 타입을 대상으로 한다:

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


media="handheld"

일단 여기서 media="handheld"에 대해서 잠시 이야기를 할 필요가 있다. 사실 안드로이드와 iOS에서는 media="handheld"를 무시한다. 사용자들은 media=”"screen"으로 지정된 고품질의 컨텐츠를 놓쳐버릴 것이고, 개발자들은 저품질의 media="handheld" 버전을 유지하기를 별로 원하지 않았기 때문에 요구된 것이다. "full web"이라는 모토 하에, 대부분의 현재 스마트폰 브라우저는 handheld 스타일 시트를 무시한다.

모바일 장치를 대상으로는 이 속성이 사용되는 것이 이상적이겠지만, 많은 브라우저들은 다른 방법으로 그것을 구현했다.

  • handheld 스타일 시트만 읽음
  • 존재하는 경우에는 handheld 스타일 시트만을 읽고, 없으면 기본적으로 screen 스타일 시트를 읽음
  • handheld 스타일 시트와 screen 스타일 시트를 모두 읽음
  • screen 스타일 시트만 읽음

오페라 미니는 media="handheld"를 무시하지 않는다. 윈도우 모바일에서는 media="handheld"를 인식하기 위해서 screen 스타일시트를 위한 미디어 속성의 값을 대문자로 변환하는 트릭을 사용한다.

<!-- 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에 적용된 몇몇 스타일 변경 사항:

  • 사이트 전반적으로 불필요한 whitespace/padding을 제거함. 작은 화면에서는 공간이 최우선!
  • :hover 상태를 없앰. 터치 장치에서는 절대 보이지 않음.
  • 레이아웃을 단일 칼럼으로 조절함. 이후에 상세히 설명.
  • 사이트의 메인 컨테이너 div 주변의 box-shadow 효과를 없앰. 큰 박스-그림자 효과를 페이지 성능을 저하시킴.
  • 홈페이지에서 각 섹션의 순서를 변경하기 위해서 CSS 박스 모델인 box-original-group을 사용. 홈페이지에서 “LEARN BY MAJOR HTML5 FEATURE GROUP”이 “TUTORIALS” 섹션보다 이전에 있었는데, 모바일 버전에서는 이후에 있음을 확인할 수 있음. 이러한 순서는 모바일에서 인식성을 높여줬지만, 마크업의 변화는 없었음. CSS는 승리를 위한 FlexBox!! (Flexible Box Layout Module, 역자주)
  • opacity 변경을 제거함. 모바일에서는 알파 값 변경이 성능에 치명적.



모바일 메타 태그

모바일 웹킷은 사용자들에게 특정 장치에서 더 좋은 브라우징 환경을 제공하는 몇몇 장점을 지원한다.


뷰포트 설정

첫 번째 (그리고 가장 자주 사용할) 메타 셋팅은 뷰포트 속성이다. 뷰포트를 셋팅하는 것은 브라우저가 컨텐츠가 어떻게 장치의 화면에 맞게 보여야 되는지를 알려주고, 브라우저에게 사이트가 모바일에 최적화되어 있다는 점을 알려준다. 예를 들면:

<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">

노트 : width는 픽셀 값을 가질 수도 있다. width=320으로 셋팅하는 것은 아이폰이나 다른 일부 스마트폰에서는 width=device-width로 설정하는 것과 같은 효과를 가진다. 모든 폰이 이와 정확히 동일한 가로 크기를 가지고 있지 않음을 유념해야 한다. 그래서 device-width로 지정을 하고 브라우저가 나머지는 판단하도록 하는 것이 최선의 방법이다.

안드로이드는 개발자가 사이트가 어떤 화면 크기에 맞게 개발 되었는지를 명시함으로써 뷰포트 매타 태그를 확장할 수 있게 한다.

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

target-densitydpi에 적용 가능한 값은 device-dpi, high-dpi, medium-dpi, low-dpi가 있다.

만약 웹 페이지를 서로 다른 스크린 density에 모두 맞게 수정하고 싶다면 ?webkit-device-pixel-radio CSS 메타 태그와 자바 스크립트의 window.devicePixelRatio 속성을 이용하면 된다. 그러면 target-densitydpi 메타 속성을 device-dpi로 설정한다. 이러한 것은 안드로이드에서 웹 페이지의 크기 변경을 불가능하게 하고, 각각의 density에 대해서 CSS와 자바스크립트를 통해서 필요한 조절을 할 수 있게 해준다.

타켓 디바이스 해상도와 관련된 더 자세한 정보를 위해서는 안드로이드의 WebView documentation을 참고하면 된다.


풀 스크린 브라우징

iOS 전용인 메타 값이 두 가지가 있다. apple-mobile-web-app-capableapple-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 reference documentation을 참조하면 된다.


홈 스크린 아이콘

안드로이드와 iOS는 링크를 위해서 rel="apple-touch-icon" (iOS) 과 rel="apple-touch-icon-precomposed" (안드로이드) 를 허용한다. 이것들은 사용자가 사이트를 북마크에 추가했을 때 플래쉬 어플리케이션 같은 아이콘을 사용자의 홈스크린에 생성한다.

<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 미디어 쿼리를 이용했다. 다시 말하지만 마크업의 변경은 없었다.

사이트의 세로 레이아웃 화면들



모바일 최적화

우리가 한 대부분의 최적화 작업들은 첫 단계에서 완료되어야 하는 것들이다. 네트워크 요구의 횟수를 줄이는 것, JS/CSS 압축, gzipping, DOM 조작 최소화 등. 이러한 것들은 보편적인 최고의 행동들이지만, 사이트를 오픈할 때 때론 간과되기도 한다.


네트워크 요청을 줄이고 대역폭 아끼기

HTTP 요청 횟수를 줄이는 것은 성능을 극적으로 향상 시킬 수 있다는 점은 이미 알려진 사실이다. 모바일 장치는 브라우저가 생성할 수 있는 동시 접속수를 제한하기도 하는데, 때문에 모바일 사이트는 이러한 불필요한 요청을 줄이는 것으로도 상당한 효과를 볼 수 있다. 게다가, 폰에서는 대역폭이 제한되기 때문에 하나의 바이트라도 줄이는 것은 매우 중요하다. 사용자의 돈을 계산해야 한다!

다음은 네트워크 요청을 줄이고 대역폭을 줄이기 위해 html5rocks에서 사용한 몇 가지 접근법이다.?

  • ?iframe 제거 - iframe은 느리다! 튜토리얼 페이지에서 3자 제공 위젯(Buzz, Google Friend Connect, Twitter, Facebook) 때문에 많은 양의 지연이 발생했다. 이 API들은 <script> 태그를 통해서 포함되었고, 페이지의 속도를 느리게하는 iframe을 만들었다. 모바일 버전에서는 위젯을 제거했다.
  • display:none - 특정한 경우에, 모바일에 맞지 않으면 마크업을 숨겼다. 좋은 예로 홈페이지의 상단에 있는 네 개의 상자를 들 수 있다.
    이것들은 모바일 사이트에서는 빠졌다. 브라우저는 각 아이콘에 대해서는 여전히 요청을 한다는 것을 기억해야 한다. 대신에 그들은 display:none에 의해서 숨겨진다. 그러므로, 이것들을 단순히 숨기는 것은 충분하지 않다. 대역폭을 낭비하고 있을 뿐만 아니라, 그 대역폭을 낭비하는 요소들을 사용자들은 보지도 못한다! 해답은 HTML의 섹션을 조건에 따라 생략하기 위해 Django 템플릿의 “is_mobile” 이진변수를 생성하는 것이다. 사용자가 스마트 장치에서 사이트를 볼 때, 버튼들은 생략된다.
  • Application cache ? 이것은 오프라인 지원 뿐만 아니라, 더 빠른 시작을 가능하게 해준다.
  • CSS/JS 압축 ? CSS와 JS를 동시에 처리할 수 있다는 이유로 Closure compiler 대신에 YUI compressor를 사용했다. 우리가 겪은 하나의 이슈는 YUI compressor 2.4.2에서 인라인 미디어 쿼리(스타일 시트 내부에 있는 미디어쿼리)가 정상적으로 처리되지 않는 문제였다.(이 문제에 대해서는 여기를 보라.) YUI compressor 2.4.2+를 이용하니 그 문제가 해결됐다.
  • 가능한 곳에는 CSS 이미지 스프라이트(이미지를 등록해서 이용하는 기능, 역자주)를 사용했다.
  • 이미지 압축을 위해서 pngcrush를 사용했다.
  • 작은 이미지는 dataURI를 이용했다. Base64 인코딩은 이미지의 크기를 최대 30%까지 증가시키지만 네트워크 사용량을 절약할 수 있다.
  • google.load()를 이용한 동적인 구글 커스텀 서치 로딩보다는 단일 스트립트 태그를 이용한 자동 로딩을 사용했다. 전자는 추가의 요청을 필요로 한다.
    <script src="//www.google.com/jsapi?autoload={"modules":[{"name":"search","version":"1"}]}"></script>
    사용되지 않더라도 모든 페이지에 PrettyPrinter와 Modernizr(코드 정리 툴 등, 역자주)을 사용했다. Modernize는 훌륭한데, 매 페이지 로드마다 많은 테스트를 실행한다. 이러한 테스트 중 일부는 DOM에 꽤나 큰 수정을 만들어냈고, 페이지 로드 속도를 느리게 했다. 이제는 실제로 필요한 페이지에만 이 라이브러리들을 포함시켰다.

추가적인 퍼포먼스 향상 작업은:

  • 가능하다면 모든 JS를 페이지의 하단으로 옮겼다.
  • 인라인 <style> 태그를 제거했다.
  • DOM 검색을 캐쉬화하고 DOM 호출을 최소화했다 ? DOM을 건드릴 때마다, 브라우저는 reflow를 수행한다. Reflow는 모바일에서 더 낭비가 심하다.
  • 낭비성 클라이언트측 코드를 서버로 옮겼다. 특히, 현재 페이지의 네비게이션 스타일을 설정하는 것을 확인하는 체크 코드:
    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로 변경되었다.


어플리케이션 캐시

모바일 버전의 html5rock는 초기 로드 속도를 빠르게 하고 사용자가 오프라인에서도 컨텐츠를 볼 수 있도록 하기 위해서 어플리케이션 캐시를 사용한다.

사이트에 어플리케이션 캐시를 사용할 때, 매니페스트 파일 (명시적으로 매니페스트 파일이거나 또는 묵시적으로 무거운 캐시 컨트롤 헤더를 가진 경우 모두)을 캐시하지 않는 것이 매우 중요하다. 매니페스트가 브라우저에 의해서 캐시되면 디버깅하기에는 악몽이다. iOS와 안드로이드는 이 파일을 캐싱하는데 있어서 부분적으로 좋은 성능을 내기도 하지만, 데스크탑 브라우저처럼 캐시를 플러싱하는 편리한 방법을 제공하지는 않는다.

위에서 언급한 캐싱을 방지하기 위해서, 우리는 우선 어플리케이션 엔진이 매니페스트 파일을 캐시하지 못하도록 가장 먼저 설정 했다:

- 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, 자바스크립트 파일만 목록에 넣어라. 마지막으로 하고 싶은 것은 매 어플리케이션 캐시 업데이트마다 많은 양의 데이터를 브라우저가 다운로드 받게 하는 것이다. 대신에, 사용자가 페이지를 방문할 때 (그리고 <html manifest="..."> 속성을 가지고 있을 때) 브라우저는 묵시적으로 html 페에지를 캐싱한다는 것은 기억해야 한다.

댓글을 달아 주세요

IT/Web Dev | Posted by 철규님(최규철) 2011. 3. 9. 22:12

[펌/번역] "Mobifying" Your HTML5 Site

※ 이 글은 테스트를 위한 참조 링크용입니다. 정식으로 발행된 글을 보실려면 아래 링크를 참고하세요.
2011/03/10 - [IT/Computing] - [펌/번역] "Mobifying" Your HTML5 Site


"Mobifying" Your HTML5 Site
당신의 HTML5 사이트를 “모바일화”하기

Written by Eric Bidelman - Developer Relations, Google on March 3, 2011
Translated by GyuCheol Choi(
gc8134.choi@gmail.com) on March 9, 2011



개요

모바일 웹 개발이 최근 화두가 되고 있다. 최초로 올해에는 스마트폰이 PC보다 더 많이 팔릴 것이다. 더 많은 사용자가 웹 서핑을 위해 모바일 장치를 사용하게 될 것이고, 이것은 개발자들은 그들의 사이트를 모바일 브라우저에 최적화하는 것이 매우 중요해졌음을 의미한다.

“모바일”이라는 격전지는 아직 개발자들에게는 미지의 영역이다. 모바일 사용자들을 전혀 고려하지 않은 많은 전통적인 사이트들이 아직 존재한다. 대신 그 사이트들은 데스크탑 브라우징을 위해 디자인되고 모바일 브라우저용으로 조잡하게 변형되어 있다. 이 사이트(html5rocks.com) 역시 예외는 아니다. 초기에 우리는 사이트의 모바일 버전에는 전혀 신경을 쓰지 않았다.


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

시험삼아, html5rocks(현재의 HTML5 사이트)를 가지고 모바일 친화적인 버전을 만들어보는 것이 재미있겠다고 생각했었다. 나는 스마트폰을 타겟으로 할 때 필요한 일의 양이 최소한인 것에만 관심이 있었다. 나의 목표는 완전히 새로운 모바일 사이트를 만들고 두 개의 코드 베이스를 유지하는 것이 아니었다. 그것은 끝나지도 않을 것이고, 엄청난 양의 시간 낭비일 것이다. 우리는 이미 정의된 사이트 구조(마크업)을 가지고 있다. 우리는 룩&필(CSS)을 가지고 있다. 주요 기능성(JS)도 있다. 중요한 점은 많은 사이트들이 비슷한 처지라는 것이다.

이 글을 통해 우리가 어떻게 안드로이드와 iOS 장치에 최적화된 html5rocks의 모바일 버전을 만들었는지 알아보려고 한다. 차이점을 보길 원하면 이러한 OS를 지원하는 장치에서 html5rocks.com 사이트를 열어보라. m.html5rocks.com으로의 리디렉션이나 이와 같은 어떠한 멍청한 조취도 없다. 당신은 html5rocks를 –모바일 장치에서 잘 보이고 잘 동작하는 그러한 이점만 추가된- 있는 그대로를 보게 된다.

데스크탑(좌)과 모바일 장치(우)에서의 html5rocks.com



CSS 미디어 쿼리

HTML4와 CSS2는 필요에 의해 미디어-의존적인 스타일 시트를 지원한다. 예를 들면

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

이 코드는 프린터를 타겟으로 하여, 이 페이지의 내용이 출력될 때를 위한 특별한 스타일을 제공한다. CSS3는 이 아이디어를 받아들여서 한 발 더 나아가 미디어 쿼리로 기능성을 향상 시켰다. 미디어 쿼리는 스타일 시트의 라벨에 더 자세한 사항을 기입할 수 있게 함으로써 미디어 타입의 사용성을 확장했다. 이것은 컨텐츠가 보여지는 것을 컨텐츠 자체를 수정하지 않아도 출력 장치의 특성에 맞게 최적화 할 수 있게 한다. 수정이 필요한 현재의 레이아웃에 있어서는 완벽한 것 같다!

타겟 스크린 폭, 장치의 폭, 방향 등을 나타내기 위해서 외부 스타일시트의 미디어 속성에 media 쿼리를 사용할 수 있다. 전체 리스트는 W3C media query specification을 보면 된다.


스크린 사이즈 지정하기

다음의 예제에서, phone.css는 브라우저가 “handheld”로 인식하는 장치나 320px 이하의 폭을 가진 장치에 적용될 것이다.

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

미디어 쿼리 앞에 “only”를 두는 것은 CSS3를 지원하지 않는 브라우저에서는 이 규칙을 무시하게 해준다. 다음은 641px과 800px 사이의 스크린 크기를 가진 장치를 대상으로 한다.

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

미디어 쿼리는 인라인 <style> 태그 내에서도 사용될 수 있다. 다음은 가로 방향에서의 모든 미디어 타입을 대상으로 한다:

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


media="handheld"

일단 여기서 media=”handheld”에 대해서 잠시 이야기를 할 필요가 있다. 사실 안드로이드와 iOS에서는 media=”handheld”를 무시한다. 사용자들은 media=”screen”으로 지정된 고품질의 컨텐츠를 놓쳐버릴 것이고, 개발자들은 저품질의 media=”handheld” 버전을 유지하기를 별로 원하지 않았기 때문에 요구된 것이다. “full web”이라는 모토 하에, 대부분의 현재 스마트폰 브라우저는 handheld 스타일 시트를 무시한다.

모바일 장치를 대상으로는 이 속성이 사용되는 것이 이상적이겠지만, 많은 브라우저들은 다른 방법으로 그것을 구현했다.

  • handheld 스타일 시트만 읽음
  • 존재하는 경우에는 handheld 스타일 시트만을 읽고, 없으면 기본적으로 screen 스타일 시트를 읽음
  • handheld 스타일 시트와 screen 스타일 시트를 모두 읽음
  • screen 스타일 시트만 읽음

오페라 미니는 media='”handheld”를 무시하지 않는다. 윈도우 모바일에서는 media=”handheld”를 인식하기 위해서 screen 스타일시트를 위한 미디어 속성의 값을 대문자로 변환하는 트릭을 사용한다.

<!-- 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에 적용된 몇몇 스타일 변경 사항:

  • 사이트 전반적으로 불필요한 whitespace/padding을 제거함. 작은 화면에서는 공간이 최우선!
  • :hover 상태를 없앰. 터치 장치에서는 절대 보이지 않음.
  • 레이아웃을 단일 칼럼으로 조절함. 이후에 상세히 설명.
  • 사이트의 메인 컨테이너 div 주변의 box-shadow 효과를 없앰. 큰 박스-그림자 효과를 페이지 성능을 저하시킴.
  • 홈페이지에서 각 섹션의 순서를 변경하기 위해서 CSS 박스 모델인 box-original-group을 사용. 홈페이지에서 “LEARN BY MAJOR HTML5 FEATURE GROUP”이 “TUTORIALS” 섹션보다 이전에 있었는데, 모바일 버전에서는 이후에 있음을 확인할 수 있음. 이러한 순서는 모바일에서 인식성을 높여줬지만, 마크업의 변화는 없었음. CSS는 승리를 위한 FlexBox!! (Flexible Box Layout Module, 역자주)
  • opacity 변경을 제거함. 모바일에서는 알파 값 변경이 성능에 치명적.



모바일 메타 태그

모바일 웹킷은 사용자들에게 특정 장치에서 더 좋은 브라우징 환경을 제공하는 몇몇 장점을 지원한다.


뷰포트 설정

첫 번째 (그리고 가장 자주 사용할) 메타 셋팅은 뷰포트 속성이다. 뷰포트를 셋팅하는 것은 브라우저가 컨텐츠가 어떻게 장치의 화면에 맞게 보여야 되는지를 알려주고, 브라우저에게 사이트가 모바일에 최적화되어 있다는 점을 알려준다. 예를 들면:

<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">

노트 : width는 픽셀 값을 가질 수도 있다. width=320으로 셋팅하는 것은 아이폰이나 다른 일부 스마트폰에서는 width=device-width로 설정하는 것과 같은 효과를 가진다. 모든 폰이 이와 정확히 동일한 가로 크기를 가지고 있지 않음을 유념해야 한다. 그래서 device-width로 지정을 하고 브라우저가 나머지는 판단하도록 하는 것이 최선의 방법이다.

안드로이드는 개발자가 사이트가 어떤 화면 크기에 맞게 개발 되었는지를 명시함으로써 뷰포트 매타 태그를 확장할 수 있게 한다.

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

target-densitydpi에 적용 가능한 값은 device-dpi, high-dpi, medium-dpi, low-dpi가 있다.

만약 웹 페이지를 서로 다른 스크린 density에 모두 맞게 수정하고 싶다면 –webkit-device-pixel-radio CSS 메타 태그와 자바 스크립트의 window.devicePixelRatio 속성을 이용하면 된다. 그러면 target-densitydpi 메타 속성을 device-dpi로 설정한다. 이러한 것은 안드로이드에서 웹 페이지의 크기 변경을 불가능하게 하고, 각각의 density에 대해서 CSS와 자바스크립트를 통해서 필요한 조절을 할 수 있게 해준다.

타켓 디바이스 해상도와 관련된 더 자세한 정보를 위해서는 안드로이드의 WebView documentation을 참고하면 된다.


풀 스크린 브라우징

iOS 전용인 메타 값이 두 가지가 있다. apple-mobile-web-app-capableapple-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 reference documentation을 참조하면 된다.


홈 스크린 아이콘

안드로이드와 iOS는 링크를 위해서 rel="apple-touch-icon" (iOS) 과 rel="apple-touch-icon-precomposed" (안드로이드) 를 허용한다.

이것들은 사용자가 사이트를 북마크에 추가했을 때 플래쉬 어플리케이션 같은 아이콘을 사용자의 홈스크린에 생성한다.

<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 미디어 쿼리를 이용했다. 다시 말하지만 마크업의 변경은 없었다.

Tutorials index Tutorial

 HTML5 feature page Author profiles

사이트의 세로 레이아웃 화면들



모바일 최적화

우리가 한 대부분의 최적화 작업들은 첫 단계에서 완료되어야 하는 것들이다. 네트워크 요구의 횟수를 줄이는 것, JS/CSS 압축, gzipping, DOM 조작 최소화 등. 이러한 것들은 보편적인 최고의 행동들이지만, 사이트를 오픈할 때 때론 간과되기도 한다.


네트워크 요청을 줄이고 대역폭 아끼기

HTTP 요청 횟수를 줄이는 것은 성능을 극적으로 향상 시킬 수 있다는 점은 이미 알려진 사실이다. 모바일 장치는 브라우저가 생성할 수 있는 동시 접속수를 제한하기도 하는데, 때문에 모바일 사이트는 이러한 불필요한 요청을 줄이는 것으로도 상당한 효과를 볼 수 있다. 게다가, 폰에서는 대역폭이 제한되기 때문에 하나의 바이트라도 줄이는 것은 매우 중요하다. 사용자의 돈을 계산해야 한다!

다음은 네트워크 요청을 줄이고 대역폭을 줄이기 위해 html5rocks에서 사용한 몇 가지 접근법이다.

  • iframe 제거 - iframe은 느리다!  튜토리얼 페이지에서 3자 제공 위젯(Buzz, Google Friend Connect, Twitter, Facebook) 때문에 많은 양의 지연이 발생했다. 이 API들은 <script> 태그를 통해서 포함되었고, 페이지의 속도를 느리게하는 iframe을 만들었다. 모바일 버전에서는 위젯을 제거했다.

  • display:none - 특정한 경우에, 모바일에 맞지 않으면 마크업을 숨겼다. 좋은 예로 홈페이지의 상단에 있는 네 개의 상자를 들 수 있다.
    Box buttons on homepage
    이것들은 모바일 사이트에서는 빠졌다. 브라우저는 각 아이콘에 대해서는 여전히 요청을 한다는 것을 기억해야 한다. 대신에 그들은 display:none에 의해서 숨겨진다. 그러므로, 이것들을 단순히 숨기는 것은 충분하지 않다. 대역폭을 낭비하고 있을 뿐만 아니라, 그 대역폭을 낭비하는 요소들을 사용자들은 보지도 못한다! 해답은 HTML의 섹션을 조건에 따라 생략하기 위해 Django 템플릿의 “is_mobile” 이진변수를 생성하는 것이다. 사용자가 스마트 장치에서 사이트를 볼 때, 버튼들은 생략된다.
  • Application cache – 이것은 오프라인 지원 뿐만 아니라, 더 빠른 시작을 가능하게 해준다.
  • CSS/JS 압축 – CSS와 JS를 동시에 처리할 수 있다는 이유로 Closure compiler 대신에 YUI compressor를 사용했다. 우리가 겪은 하나의 이슈는 YUI compressor 2.4.2에서 인라인 미디어 쿼리(스타일 시트 내부에 있는 미디어쿼리)가 정상적으로 처리되지 않는 문제였다.(이 문제에 대해서는 여기를 보라.) YUI compressor 2.4.2+를 이용하니 그 문제가 해결됐다.
  • 가능한 곳에는 CSS 이미지 스프라이트(이미지를 등록해서 이용하는 기능, 역자주)를 사용했다.
  • 이미지 압축을 위해서 pngcrush를 사용했다.
  • 작은 이미지는 dataURI를 이용했다. Base64 인코딩은 이미지의 크기를 최대 30%까지 증가시키지만 네트워크 사용량을 절약할 수 있다.
  • google.load()를 이용한 동적인 구글 커스텀 서치 로딩보다는 단일 스트립트 태그를 이용한 자동 로딩을 사용했다. 전자는 추가의 요청을 필요로 한다.
    <script src="//www.google.com/jsapi?autoload={"modules":[{"name":"search","version":"1"}]}"></script>
    사용되지 않더라도 모든 페이지에 PrettyPrinter와 Modernizr(코드 정리 툴 등, 역자주)을 사용했다. Modernize는 훌륭한데, 매 페이지 로드마다 많은 테스트를 실행한다. 이러한 테스트 중 일부는 DOM에 꽤나 큰 수정을 만들어냈고, 페이지 로드 속도를 느리게 했다. 이제는 실제로 필요한 페이지에만 이 라이브러리들을 포함시켰다.

추가적인 퍼포먼스 향상 작업은:

  • 가능하다면 모든 JS를 페이지의 하단으로 옮겼다.
  • 인라인 <style> 태그를 제거했다.
  • DOM 검색을 캐쉬화하고 DOM 호출을 최소화했다 – DOM을 건드릴 때마다, 브라우저는 reflow를 수행한다. Reflow는 모바일에서 더 낭비가 심하다.
  • 낭비성 클라이언트측 코드를 서버로 옮겼다. 특히, 현재 페이지의 네비게이션 스타일을 설정하는 것을 확인하는 체크 코드:
    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로 변경되었다.


어플리케이션 캐시

모바일 버전의 html5rock는 초기 로드 속도를 빠르게 하고 사용자가 오프라인에서도 컨텐츠를 볼 수 있도록 하기 위해서 어플리케이션 캐시를 사용한다.

사이트에 어플리케이션 캐시를 사용할 때, 매니페스트 파일 (명시적으로 매니페스트 파일이거나 또는 묵시적으로 무거운 캐시 컨트롤 헤더를 가진 경우 모두)을 캐시하지 않는 것이 매우 중요하다. 매니페스트가 브라우저에 의해서 캐시되면 디버깅하기에는 악몽이다. iOS와 안드로이드는 이 파일을 캐싱하는데 있어서 부분적으로 좋은 성능을 내기도 하지만, 데스크탑 브라우저처럼 캐시를 플러싱하는 편리한 방법을 제공하지는 않는다.

위에서 언급한 캐싱을 방지하기 위해서, 우리는 우선 어플리케이션 엔진이 매니페스트 파일을 캐시하지 못하도록 가장 먼저 설정 했다:

- 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, 자바스크립트 파일만 목록에 넣어라. 마지막으로 하고 싶은 것은 매 어플리케이션 캐시 업데이트마다 많은 양의 데이터를 브라우저가 다운로드 받게 하는 것이다. 대신에, 사용자가 페이지를 방문할 때 (그리고 <html manifest=”…”> 속성을 가지고 있을 때) 브라우저는 묵시적으로 html 페에지를 캐싱한다는 것은 기억해야 한다.


댓글을 달아 주세요

IT/Web Dev | Posted by 철규님(최규철) 2011. 2. 23. 21:28

HTML5에서 <hgroup> 요소의 의미

HTML5에는 <h1>~<h6> 요소들을 묶는 <hgroup> 요소가 도입되었다. <hgroup> 요소의 사용 유무는 실질적으로 사용자에게는 드러나지 않는다. 다음 예제를 실행해보면 그 결과를 알 수 있다.


<!DOCTYPE html>
<html>
<head>
  <title>HTML5 - <hgroup> element 테스트</title>
</head>
<body>

<h1>장원준 "개막전 선발 욕심 있다"</h1>
<h2>日롯데 2군에 5이닝 무실점</h2>
<p>롯데 자이언츠가 일본 지바롯데 마린스 2군과의 연습경기에서 대승을 거뒀다.</p>

<hgroup>
  <h1>장원준 "개막전 선발 욕심 있다"</h1>
  <h2>日롯데 2군에 5이닝 무실점</h2>
</hgroup>
<p>롯데 자이언츠가 일본 지바롯데 마린스 2군과의 연습경기에서 대승을 거뒀다. </p>

</body>
</html>

결과 화면은 아래와 같다. (결과링크)



사용자에게 보여주는 화면은 <hgroup> 요소를 사용하나 사용하지 않으나 동일함을 알 수 있다. 하지만 HTML5에는 시멘틱 개념이 도입되었고, 이러한 관점에서는 두 소스 코드는 다른 의미를 가진다.

각각의 컨텐츠를 도식화 해 보면 다음과 같다.



첫번째 소스 코드에서는 <h2> 요소는 <h1> 요소의 '하위' 항목이 되고 <p> 요소는 <h2>요소에 대한 설명으로 인식된다.
두번째 소스 코드에서는 <h2> 요소는 <h1> 요소의 '부가' 항목이 되고 <p> 요소는 <h1>, <h2>요소에 대한 설명으로 인식된다.

만약 검색 엔진 등 기계적으로 본문에 대한 주제나 요약을 찾을 경우,
첫번째 소스코드에서는 <h2> 요소가 <p> 요소를 대표하게 되고,
두번 소스코드에서는 <h1>, <h2>요소가 모두 <p> 요소를 대표하게 되는데,
<h1>, <h2> 중 다시 하나를 선별한다면 <h1> 요소가 <p>요소를 대표하게 된다. 

댓글을 달아 주세요

IT/Web Dev | Posted by 철규님(최규철) 2011. 2. 21. 23:27

[펌/번역] Intelligent Site Structure for better SEO


특정 사이트를 검색 결과의 상단부에 나타내기 위한 노력은 예전부터 있어왔다. 이를 SEO(Search Engine Optimization, 검색 엔진 최적화)라고 하는데, 더 나은 SEO를 위한 사이트 구조에 대한 글이 있어서 참고하려고 한다.


[ 원문보기 : Intelligent Site Structure for better SEO (http://yoast.com/site-structure-seo/)  ]



Intelligent Site Structure for better SEO
더 나은 검색 엔진 최적화(SEO)를 위한 지능적인 사이트 구조
by Joost de Valk on 9 February, 2011 at 16:00




Search engines are still one of the most important traffic drivers to sites these days, which is why Search Engine Optimization (SEO) is incredibly important.
검색 엔진은 최근에도 여전히 가장 중요한 트레픽 유발 요소 중의 하나이며, 이점이 왜 검색 엔진이 그토록 중요한지를 말해주고 있다.
While SEO is often thought to be just a set of some technical tricks - and as a professional SEO, I confess to spending a lot of time with clients fixing technical issues - a site's structure, is just as important.
SEO는 종종 단순한 기술적 트릭의 모음으로 생각되지만, 전문적인 SEO로는 사이트 구조 또한 중요하다. (고백하건데 나는 고객과 많은 시간을 기술적 이슈를 해결하는데 소모한다.)
Your site's structure determines whether a search engine understands what the topic of your site is and how easily it will find and index content relevant to your site's purpose and intent.
당신의 사이트의 구조는 검색 엔진이 사이트의 주제가 무엇인지를 이해하고 얼마나 쉽게 당신의 사이트의 목적과 주제에 대한 정보를 찾고 정리할 수 있는지를 결정한다.


By creating a good structure, you can use the content you've written that has attracted links from others, and use your site's structure to spread some of that "linkjuice" to the other pages on your site.
좋은 구조를 만들어냄으로써, 당신은 다른 곳으로부터의 관심 링크를 가진 당신이 작성한 컨텐츠를 사용할 수 있고, 당신의 사이트 구조가 그러한 링크 가치를 당신 사이트의 다른 곳으로 확산시키게 할 수 있다.
On a commercial site, that means that you can use the quality content you've written to boost the search engine rankings of your sales pages too.
상업적 사이트에서는 당신이 작성한 고품질의 컨텐츠를 당신의 판매 페이지의 검색 엔진 순위를 높이는데 사용할 수 있다는 것을 의미한다.
Did I get your attention now? Ok, now we've covered what and why, let's get on to how.
어느 정도 관심이 생기는가? 그럼 '무엇'과 '왜'에 대해서 알아봤으니, '어떻게'에 대해서 이야기 해보자.



Developing a good site structure
좋은 사이트 구조 개발하기

When developing a new site, or restructuring an existing one, it helps to draw out your site's structure in something like Visio, or even putting it in Excel.
새로운 사이트를 개발하거나 기존의 사이트를 구조변경할 경우에는 Visio와 같은 툴을 이용하거나 Excel을 이용해서라도 사이트의 구조를 그려보는 것이 도움이 된다.
What you'll want to do is put all the pages and sections in there as a tree, something like that shown in Figure 1 (based on my own old site structure):
당신이 해야할 일은 Figure 1에서 보여지는 바와 같이 모든 페이지와 섹션을 트리 형태로 구성하는 것이다.


Now as you can see this structure is unbalanced, as the Code section constitutes more than half of the entire site.
당신도 볼 수 있듯이, 코드 섹션이 전체 사이트의 반정도로 구정되어 있어서, 이 구조는 비균형적이다.
You should make sure your site structure looks like a reasonably balanced pyramid.
당신은 당신의 사이트 구조가 적절하게 균형잡힌 피라미드처럼 보이도록 해야한다.
I'd advise you to have something between 2 and 7 main sections, depending on how content heavy your site is, and no section should be more than twice as large as any other section.
나는 당신에게 당신의 사이트의 컨텐츠 비중이 얼마나 큰지에 따라서 2~7개의 메인 섹션을 가지라고, 또한 어떠한 섹션도 다른 섹션보다 두 배 이상의 크기를 가져서는 안된다고 충고하고 싶다.


As well as the code section being way too big, there's another couple of points to consider about Figure 1.
Figure 1과 관련해서는 코드 섹션이 너무 크다는 점 뿐만 아니라 다른 몇 가지 고려할 사항도 있다.
First, there are three pages that are basically about me: "About Me", "Projects" and "Websites".
첫째, 기본적으로 나와 관련된 세개의 페이지, "About Me", "Project", "Websites"가 존재 한다.
In addition, upon checking out my site statistics I found that the WordPress pages were responsible for about 30% of my site traffic, yet they were down on the third and fourth level.
게다가 내 사이트의 통계를 확인해보니 'WordPress' 페이지가 내 사이트 트래픽의 30% 정도를 차지하고 있었는데, 이 페이지들은 3단계나 4단계 레벨까지 내려가 있었다.


The benefit of using a tool like Visio or OmniGraffle, as I did, is that it's quite easy to rearrange stuff, and it's easy to get a good "feel" for whether the new structure is going to work.
내가 그랬듯이 Visio나 OmniGraffle 같은 툴을 사용하면, 이런 것들을 정리하기가 꽤나 쉽고, 새로운 구조가 제대로 동작할지에 대한 느낌을 받기가 쉽다는 장점이 있다.
 I've often used a desk or a wall and a lot of post-it notes for this purpose too, and that has also worked fine for me.
나는 이런 목적으로 종종 책상이나 벽에 많은 포스트-잇을 이용하기도 했었는데, 이것 또한 좋은 방법이었다.


So I started to rearrange the sections and came up with the section structure seen in Figure 2.
그래서 나는 섹션들을 재정렬하기 시작했고, Figure2와 같은 섹션 구조 결과물을 얻었다.


As you can see I decided to move some pages "up" the tree, and I removed some pages.
보는 것과 같이 나는 일부 페이지를 트리의 상위로 옮기기로 하고, 일부 페이지는 삭제했다.
When you're rethinking your site structure you'll often find that some pages are not really beneficial to your users.
당신의 사이트 구조를 재고해보면, 일부 페이지는 사용자들에게 실제로 전혀 유익하지 않다는 것을 알게 될 것이다.
Deleting them is the best thing you can do if that's the case.
이러한 경우에는 그것들을 삭제하는 것이 최선의 방법이다.


Another choice I made was to move the blog to the homepage.

내가 선택한 또 다른 것은 블로그를 홈페이지로 옮기는 것이었다.
My homepage was utter nonsense, and basically yet another "About Me" page.
내 홈페이지는 완전히 넌센스였고, 기본적으로 또 다른 "About Me" 페이지였다.
And though I like myself, that's not what I was hoping people came to my site for.
비롯 내가 내 자신을 좋아하지만, 그것이 내가 사람들이 내 사이트를 방문하는 목적이길 바랬던 것은 아니다.
My blog is the basis of my site, so I decided to make it the cornerstone of this structure too.
내 블로그는 내 사이트의 기반이어서, 나는 이것을 이 구조의 초석으로 만들기로 했다.



Naming your sections
섹션 이름 붙이기

Once you're satisfied with your site structure, have a look at the names you've come up with for your sections.
일단 사이트 구조에 만족하게 되면, 섹션에 붙인 이름을 살펴보라.
If you have enough content about a subject for it to be able to have its own section, you can bet people are searching for it as well.
만약에 한 주제에 대해서 하나의 섹션이 될만한 충분한 컨텐츠를 가지고 있다면, 사람들 또한 그것을 찾는다고 할 수 있다.
That's why it's very wise to make sure your section names use the keywords people are searching for!
이것이 바로 사람들이 검색하는 키워드를 이용해서 섹션의 이름을 짓는 것이 얼마나 좋은 방법인지를 알려주는 점이다.
 

For example, if you're like me and you've written WordPress plugins and created a section for them, you should not call that section "WordPress".
예를 들어, 만약에 당신이 나와 같이 WordPress plugin에 대해서 글을 쓰고 이를 위한 섹션을 만들었다면, 그 섹션을 "WordPress"라고 하면 안된다.
What would you search for? "WordPress plugins", right?
당신이라면 뭐라고 검색하겠는가? "WordPress plugins" 아닌가?
So name it that (which doesn't mean you can't call it WordPress in your menu structure if that works better, just make sure the page title and breadcrumb links are "WordPress plugins").
그럼 그렇게 이름을 지어야 한다.(만약 그게 더 낫다면  메뉴 구조에서 WordPress라고 부르면 안되는 것은 아니다. 단지 페이지 제목과 네비게이션 링크의 이름이 "WordPress plugins" 이게만 하면 된다.)
You can do quite a bit of research on which keywords people search for.
상신은 어떤 키워드를 사람들이 검색하는지 약간의 조사를 할 수 있다.
Some freely available tools are:
무료로 사용 가능한 툴은 다음과 같다.

Pick the right names for your sections and subsections, and you're halfway there.
당신의 섹션과 부섹션에 맞는 이름을 고르면, 절반은 온 것이다.
Now use the same techniques to pick the titles for your pages, and make sure to keep them short and clean.
이제는 페이지의 타이틀을 고르는데 동일한 방법을 사용하라. 그리고 그것들은 간단명료해야 한다.
My sections now have names as shown in Figure 3.
이제 나의 섹션들은 Figure 3과 같이 되었다.


Now we've covered the two most important parts of defining your site structure, we'll turn our attention to some other important points to consider.
사이트 구조를 정의하는데 있어서의 가장 중요한 두 가지를 알아보았다. 이제 관심사를 또 다른 중요한 고려사항들로 옮겨보자.



Other Things to keep in mind
고려해야할 또 다른 사항들



There are another couple of things to keep in mind when working out the structure of your site.
당신 사이트의 구조에 대한 작업을 할때 기억해야할 몇 가지 사항이 더 있다.


Forums, and other user-controlled content:
포럼이나 다른 사용자 제어 컨텐츠:

If one part of your site is producing way more content then another part, and the quality of that highly productive part is poorer, you may not wish to mix the two.
만약 한 파트가 다른 파트들보다 더 많은 컨텐츠를 만들어 낸다면, 그리고 고생산적인 부분의 퀄리티가 더 낮다면, 두 개를 합치고 싶지느 않을 것이다.
For instance, let's say your front page is like A List Apart, updating every few weeks with very high quality articles gathering loads of links.
예를 들어서 당신의 전면 페이지는 'A List Apart;와 같이 링크 로드를 모으는 고품질의 기사를 몇주마다 업데이트 한다고 하자.
Another section of your site is your forums section, which produces loads of new threads every day, of questionable quality.
사이트의 다른 섹션은 포럼 섹션인데, 이것은 미심쩍은 질을 가지고 매일 새로운 몇 개의 쓰레드를 만들어낸다.

Your forum is probably going to deteriorate the rankings for your front page, because you're constantly "flowing" ranking strength from your high quality front page into your forums.
포럼들은 아마도 당신의 메인 페이지의 랭킹을 낮출 것이다. 왜냐하면 당신이 고품질의 메인페이지부터 포럼에 이르기까지 계속해서 랭킹 강도를 낮추고 있기 때문이다.(?)
So the best thing you can do with them is move them to a subdomain of your site.
당신이 할 수 있는 최선의 방법은 당신 사이트의 서브도메인 영역으로 그것들을 옮기는 것이다.

This is less of a problem when you have a blog on your site, which you control.
이것은 당신이 컨트롤하는 사이트에 블로그가 있을 때는 덜 심각한 문제점이다.
The quality of that will be less questionable, and you may want those blogposts to rank well.
그것의 질 또한 덜 의심스럽고, 당신은 그 블로그의 포스트들도 순위가 좋게 하고 싶을지도 모른다.



Redundant categories and tags:
불필요한 카테고리와 태그들:

Sooner or later you're going to fall into this trap - I know I have - of having multiple categories on your site/blog, and constantly assigning the same two categories to certain posts.
조만간 당신은 사이트나 블로그에 여러개의 카케고리가 있고 특정 포스트에 동일한 두 개의 카테고리를 계속해서 지정해야되는 함정에 빠져들 것이다. - 내가 해봤으니 안다 -
Let's say you have the "browsers" and "Opera" categories, and Opera is the only browser you write about.
당신 사이트에 "browser"와 "Opera" 카테고리가 있다고 하자. 그리고 브라우저 중 오페라에 대해서만 당신은 글을 쓴다.
Now when you look at the category overview page for the "browsers" category, you will be seeing the exact same content as when you look at the "Opera" category page - the two tags are basically redundant.
이제 당신이 "browser"의 카테고리 오버뷰를 보면, "Opera" 카테고리 페이지를 볼 때와 정확히 동일한 컨텐츠를 보게될 것이다. 이 두 태그는 기본적으로 불필요하다.

When you're using tags, this happens even more.
태그를 이용할 때는 이러한 문제가 더 자주 발생한다.
You're probably wondering "what's wrong with that?"
"뭐가 문제지?" 라고 생각할지도 모르겠다.
Well, let's say a few people wanted to link to all those posts, because they liked them so much.
몇몇 사람들이 모든 포스트가 매우 마음에 들어서 모두에 대해서 링크를 걸기를 원하는 경우를 생각해보자.
You've just lost control over which category they will link to - the first one might pick the "browsers" category, and the second person might pick the "Opera" category.
당신은 이미 그들이 어떤 카테고리에 링크를 걸고 싶어 하느냐에 대한 컨트롤을 잃어버렸다. 첫번째 사람은 "browser" 카테고리를 선택할 것이고, 두번째 사람은 "Opera" 카테고리를 선택할 것이다.
If this happens multiple times, you're "throwing away" good links.
이러한 일이 여러번 발생한다면, 당신은 좋은 링크들을 버리고 있는 셈이다.

Let's say you have 2 links to your "browsers" category page, and 2 links to your "Opera" category page.
당신이 "browser" 카테고리 페이지에 2 개의 링크가 있고, "Opera" 카테고리 페이지에 2개의 링크가 있다고 하자.
A less popular competitor has 3 links to his single "browser category" page, because he doesn't have a redundant "Opera" category.
덜 유명한 경쟁자 한 명은 불필요한 "Opera" 카테고리가 없어서 하나의 "browser category" 페이지에 세 개의 링크를 가지고있다.
In a real simple world where every link is equal, your competitor would now rank above you.
모든 링크가 동등한 실세계에서는, 당신의 경쟁자가 당신 위에 랭크될 것이다.

It's very important to make sure you're not showing the same content on multiple pages, because that's not helping your rankings.
동일한 컨텐츠를 여러 페이지에 보여주지 않도록 하는 것이 매우 중요한데, 그렇게 되면 당신의 랭킹에 아무런 도움이 되지 않기 때문이다.



Internal link structure
내부 링크 구조

If you did it all right with your new site structure, it should look like a pyramid.
새로운 사이트 구조를 잘 만들었다면, 피라미드처럼 보여야 한다.
Now you should consider how you're going to connect the sections of this pyramid together.
이제는 이 피라미드들을 하나로 어떻게 합치느냐를 고민해야 한다.
Look at those sections as small pyramids inside your larger pyramid.
당신의 큰 피라미드 안에 작은 피라미드 같은 섹션들을 살펴보자.
Each page in the top of that pyramid should link to all its sub pages, and the other way around.
그 피라미드의 상단에 있는 각 페이지는 그들의 서브 페이지로 모두 링크가 있어야 하고, 다른 부분으로도 있어야 한다.

Because you're linking from pages that are closely related to each other content-wise, you're increasing your site's possibility to rank.
컨텐츠가 밀접한 연관이 있는 페이지로부터 링크를 함으로써, 사이트의 순위를 올릴 수도 있다.
You're "helping" the search engine out by showing it what's related and what isn't.
당신이 검색 엔진에게 무엇이 연관이 있고, 무엇이 연관이 없는지를 보여줌으로써 검색 엔진을 도와주는 것이다.

Take figure 4 as an example.
Figure 4를 예제로 참고하라.


You should make sure you keep your links between each page relevant to those pages.
연관이 있는 페이지들 간에 링크를 만들어 주는 것도 필요하다.
For example, if you linked from subpage 3 to plugin 2 all the time, the search engine might think that subpage 3 was related to plugin 2, whereas it's only related to plugin 4.
예를 들면, subpage 3에서 plugin 2로 항상 링크를 건다면, 검색 엔진은 subpage 3이 plugin 2와 관계 있다고만 생각할 것이다. 그런데, plugin 2는 단지 plugin 4로만 연관이 있다.

 

From your new site structure to URLs
새로운 사이트 구조부터 URL 까지

Once you've created your new site structure, you can go forth and create the URLs for this structure.
일단 새 사이트 구조가 완성이 되면, 4단계로 가서 이 구조를 위한 URL을 만들어야 한다.
Each page's URL should describe the content of that page, yet be as short as possible.
각 페이지의 URL은 그 페이지의 내용을 가장 잘 설명하면서도 최대한 짧아야 한다.
If you have determined what keywords you want to rank for, you might include the most important ones in your URLs.
랭킹에 올리고 싶은 키워드들이 무엇인지 결정하면, URL에 가장 중요한 것을 포함시켜야 한다.

Things to keep in mind while implementing your new URLs:
다음은 새 URL을 만들면서 염두할 사항들이다:

  • If you're using multiple words, separate them with hyphens.
  • 여러 개의 단어를 사용하면, 하이픈으로 구분하라.
  • Mixed case URLs are an absolute no-no, as Unix and Linux servers are case sensitive. Having mixed case URLs drastically increases the possibility of typos - have you ever tried remember a URL that /LoOks/LiKe/ThiS/ ?
  • Unix와 Linux server 등은 대소문자를 구분하기 때문에, 대소문자를 섞어서 쓴 URL은 절대 안된다. 대소문자를 섞어서 쓴 URL은 오타 입력을 급증시킨다. - /LoOks/LiKe/ThiS/와 같은 URL을 기억할려고 해봤나?
  • Numbers might be easy for your CMS, but not for your users. Remembering a URL with a number in it is hard, so the chance people will remember it and link to it is smaller - don't use numbers in URLs.
  • 당신의 CMS에는 숫자가 쉬울지 모르지만, 사용자들에게는 아니다. 숫자가 있는 URL을 기억하는 것은 어렵다. 그러므로 사람들이 기억하고 링크를 걸 가능성은 더 적다. - URL에는 숫자를 쓰지 마라.
  • Make URLs guessable if you can. If people can remember your URLs they can also talk about it with their friends more easily.
  • 가능하면 URL을 추론 가능하게 만들어라. 사람들이 당신의 URL을 기억할 수 있다면, 그들의 친구들과 더 쉽게 그것에 대해서 이야기 할 수 있다.
  • Make sure you redirect all your old pages to their new equivalents using 301 redirects. A 301 redirect is a permanent redirect, and this way search engines will move all the link value from the old URL to the new one.
  • 301 reditect를 이용해서 모든 오래된 페이지는 새 페이지로 전환되게 하라. 301 recirect는 영구적인 전환이고, 이 경우에 검색 엔진이 링크 벨류를 구URL에서 신URL로 옮진다.
  • Make sure content is available under one URL and one URL only, for example by implementing print stylesheets on your pages. There's no valid reason anymore to have a different page for printing purposes because all major browsers support print stylesheets.
  • 페이지 내에 프린트 스타일시트를 구현하는 등을 통해 하나의 URL에서 컨텐츠를 볼 수 있게 하고,하나의 URL에서만 가능하게 해라. 모든 브라우저가 프린트 스타일시트를 지원하므로 프린팅을 위해 다른 페이지를 가져야될 이유는 없다.

For more info on URLs and the problems they can cause, see my article on duplicate content.
URL에 관한 더 많은 정보나 문제점을 위해서는, 나의 "duplicate content" 본문을 참고하며 된다.

 

Conclusion: work on your site structure
결론: 사이트 구조에 대한 작업

A good site structure is a requirement for Search Engine Optimization.
좋은 사이트 구조는 '검색 엔진 최적화'의 필요 조건이다.
It allows both your users and search engines to find content within your site more easily.
당신의 사이트에서 사용자들과 검색 엔진이 더 쉽게 컨텐츠를 찾을 수 있게 해준다.
A good structure is well categorized, and pages within it only link to other pages on the same topic.
좋은 구조는 잘 분류되어 있고, 그 안의 페이지들은 동일한 주제에 대해서만 링크를 가진다.

Using the right URLs for the pages within that site structure increases the chance that people will remember and link to your URL, and heavily increases your ability to rank in the search engines as well.
사이트 구조 내에서 페이지에 올바른 URL을 사용하는 것은 사람들이 링크를 기억하고 당신의 URL로 링크를 추가할 기회를 높여주고, 검색 엔진 내에서의 순위를 높이는 역할 또한 한다.




 

댓글을 달아 주세요

IT/Web Dev | Posted by 철규님(최규철) 2011. 2. 18. 01:54

HTML5의 시맨틱 태그(Semantic tag)가 가지는 의미


HTML5로 넘어오면서 많은 변화가 있었는데, 그 중 의미적으로는 가장 큰 변화이지만 와닿지 않는 것이 '시맨틱 태그(Semantic tag)'의 도입이 아닐까 생각한다.
어떤 변화가 있으면 그 변화 내용을 아는 것도 중요하지만, 그 변화의 의미를 알아야 실제로 그 의도에 맞게 변화된 내용을 받아들이고 사용할 수 있으므로, HTML5가 등장하면서 변화가 생긴 태그들에 대해서 한번 쯤은 알아 볼 필요가 있겠다.

HTML5에 시맨틱 태그가 도입됨으로써 사용자에게 보이는 화면 뿐만 아니라, 그 화면을 구성하는데 사용되는 소스 레벨에서도 의미를 가지게 된다. 어떻게 보면 사용자의 입장에서는 태그가 의미를 가진다는 것이 큰 차리를 나타내지는 않겠지만, 검색 엔진의 레벨에서는 전혀 다른 차원의 문제가 된다. 검색 엔진은 사용자에게 보이는 화면이 아니라 소스를 대상으로 정보를 검색하기 때문에, 소스가 의미를 가지게 되면 검색 엔진은 더 정확한 검색 결과를 내놓을 수 있을 것이다.

시맨틱 태그의 도입으로 HTML5의 태그에 어떤 변화가 있는지, 그리고 이것들의 의미가 무엇인지 간단하게 정리해보자.


1. 문서 구조를 정의하는 태그

HTML4에서는 문서를 구분할 때, <div></div>태그를 사용하고, 각 div 태그에 idclass 속성을 부여해서 CSS를 적용했다. 예를 들어, 헤더 부분에는 <div id='header'>, 푸터 부분에는 <div id='footer'>, 본문 부분에는 <div id='contents'>등을 사용하는 식이었다.

HTML5에서는 다음과 같은 태그가 추가되었다.

  • header : 헤더 부분. 사이트 소개, 로고, 메뉴, 머리글 등
  • footer : 푸터 부분. 사이트 제작자나 저작권 관련 정보 등
  • nav : 네비게이터 부분. 사이트내의 메뉴 등
  • section : 실제 문서 내용 등
  • article : 문서 내용이 많을 경우 하나의 section을 여러개의 article로 나눔
  • aside : 블로그 등에 있는 사이드 바와 같은 형태

위와 같은 태그들의 도입으로 검색 엔진은 실제로 필요한 부분만을 대상으로 검색을 실행할 수 있게 된다.

예를 들어 설명하면, HTML4에서는 메뉴에 있는 'HTML5'라는 단어와 본문에 있는 'HTML5'라는 단어의 중요도를 검색 엔진이 판단할 수 없었지만, HTML5에서는 메뉴에 있는 'HTML5'라는 단어는 <nav></nav>태그 사이에 존재하고, 본문에 있는 'HTML5'라는 단어는 <article></article> 또는 <section></section> 내에 존재하므로 어떤 단어가 더 중요한 의미를 가지는 지 알 수 있다. 즉, 검색 엔진은 필요에 따라 <nav></nav>태그 사이에 존재하는 'HTML5'라는 단어는 결과에서 제외할 수도 있다. 이와 같이 HTML5의 시맨틱 태그를 사용하면 검색 엔진의 입장에서는 불필요한 검색 결과를 걸러낼 수 있으므로, 더 정확한 검색 결과를 내놓을 수 있게 된다.


HTML5에는 제목, 부제목 등을 묶어주는 <hgroup> 태그도 있다. <header> 태그가 문서의 구조적인 면을 정의하는 태그라면, <hgroup> 태그는 문서의 내용적인 면을 정의하는 태그라고 할 수 있다.

즉, <header>태그는 그 내부에 메뉴를 나타내는 <nav>태그를 가지기도 하고, 문서의 제목, 부제목을 나타내는 <hgroup>태그를 가질 수도 있다. <hgroup>태그는 필요에 따라 <h1>,<h2> 태그를 이용해 주제목, 부제목을 나타내기도 한다.

물론 <hgroup>태그는 문서 뿐만 아니라 하나의 <section>이나 <article>의 제목, 부제목을 나타내기 위해 사용될 수 도 있다. 이처럼 <hgroup>태그를 이용하면 그 페이지나 본문이 나타내는 바를 명확하게 할 수 있으며, 활용하기에 따라서는 다수의 페이지나 본문을 대상으로 인덱스 페이지를 생성해 내도록 할 수도 있다.




2. 의미를 명확히 하는 태그

(1) <figure>, <figurecaption> 태그

HTML5에서는 이미지와 그 이미지에 해당하는 캡션을 묶어서 관리할 수 있는 태그가 제공된다. HTML4에서는 이미지를 첨부하고 그 상하단에 관련 설명을 첨부하여도 검색 엔진의 입장에서는 알아낼 수 없었지만, HTML5의 <figure> 태그와 <figurecaption>태그를 이용한 페이지에서는 검색 엔진이 포함된 이미지가 어떤 것인 가에 대해서 보다 정확하게 알 수 있다.



(2) <time>태그와 <address>태그
HTML5에서는 페이지나 본문을 작성한 시각을 나타낼 때에는 <time>태그를 사용하고, 사이트 제작자나 본문 작성자의 이메일 주소나 우편 주소 등을 나타낼 때에는 <address> 태그를 사용한다. 마찬가지로 검색 엔진은 페이지 내에서 <time>태그를 만나면 그 시각을 페이지 작성 시각 또는 본문 작성 시각으로 인식하고, <address> 태그를 만나면 그 이후를 우편 주소나 이메일 주소로 인식을 한다.


(3) 문자열 관련 태그 : <mark>, <b> & <strong>, <i> & <em>
위의 태그 모두 본문의 내용 중 일부분을 강조하는데 사용되지만, 약간씩 역할과 효과가 다르다. 우선 다음의 예제를 보자.


결과만을 놓고 본다면 간단하게 다음과 같이 분류 할 수 있다.

  • <storng>, <b> : 굵은 글씨
  • <i>, <em> : 기울어진 글씨
  • <mark> : CSS를 이용한 강조 표시

HTML5에서는 <strong> 태그는 의미적으로도 중요한 의미를 가진다는 것을 나타낼 때 사용되고, <i> 태그는 외국어, 전문 용어, 대명사, 인용문 등을 나타낼 때 사용된다. 즉, 사용자에게는 동일한 굵은 글씨, 기울어진 글씨로 보일지 모르지만 검색 엔진은 <strong>태그와 <i>태그로 둘러쌓인 내용을 더 비중있게 처리하게 된다.



더 많은 내용이 있지만, 기본적으로 가장 눈에 띄는 내용들은 위와 같다. 세부적인 예를 몇 가지 들었지만, 공통적인 흐름은 태그 자체가 의미를 가지게 되어서 문서 구조나 내용을 정확하게 분석할 수 있게 되었다는 점이다.

그동안 생성되는 정보의 양은 엄청나게 증가해왔지만, 이 정보들에서 유용한 정보를 추출해내는 기술은 상대적으로 발달이 더딘 것이 사실이었다. 하지만 HTML5가 적용되면 해당 문서에 대한 기계적 분류 작업이 훨씬 용이해 질 것이도, 잘 디자인(well designed)된 문서의 수가 늘어날 수록 잘 정련된(well refined) 정보의 수와 그의 질 또한 늘어날 것이다.

댓글을 달아 주세요

  1.  댓글주소  수정/삭제  댓글쓰기 YesDitto(twitter) 2011.10.26 10:58

    정말 감사히 잘 읽었습니다. 유익한 자료 감사합니다. ^_^
    Semantic Element가 무슨 목적으로 생겼는지 궁금해하고 있었는데 정말 명쾌한 답이 되었습니다.
    근데 CSS에서 디자인할때 시멘틱 엘리먼트 자체를 선택하는게 좋은 방법일까요? 아니면 div를 써서 선택하는게 좋은 방법일까요?

    •  댓글주소  수정/삭제 철규님(최규철) 2011.11.16 12:51 신고

      안녕하세요? 관심 가져주셔서 감사합니다.
      미약한 지식이나마 간단히 의견 남겨드릴께요..
      (아는게 없어서 답변이라고 하기엔 부끄럽네요..)

      HTML5로 넘어오면서 HTML 문서 자체의 구조를 정의하는 DIV 태그는 권장하지 않는 사용 방법이라는 것이 제 개인적인 생각입니다. 어쩔 수 없이 DIV 태그를 사용해야하는 경우라면 모르겠지만, 가능한 범위 내에서는 CSS에서 시멘틱 엘리먼트 자체에 대한 접근을 하는 것이 낫지 않을까 싶습니다.

      저도 공부 중이고 관련 업무 경험이 적어서 명확한 답변을 드리지는 못하는 점 양해 부탁드립니다. 참고 정도로 받아들여 주시면 감사하겠습니다.

  2.  댓글주소  수정/삭제  댓글쓰기 뱀이 2012.02.27 14:25

    잘 읽고 이해하고갑니다.^^
    html5 공부 이제 시작하려는데요..
    시맨틱태그가 먼가 검색하다가 여기까지왔네요.ㅎㅎ
    좋은하루되세요.