web - 반응형(responsive) 웹

Web/Common 2013. 9. 14. 11:55



NHN 오픈퍼블리싱팀 정찬명

안녕하세요? HelloWorld 블로그의 반응형 웹 개편을 담당했던 오픈퍼블리싱팀 정찬명입니다.

반응형 웹이란 사용자의 장치 특성에 따라 화면 배치가 유연하게 바뀌도록 구현하는 것을 말합니다. CSS3의 미디어쿼리 규칙을 사용하면 이것이 가능한데요, 하나의 HTML 파일이 모든 장치의 해상도 특성에 대응할 수 있도록 만들어 줍니다. 이 글에서는 HelloWorld 블로그를 반응형 웹으로 개편한 이야기를 전해 드리겠습니다.

왜 반응형인가?

HelloWorld 블로그는 XE라는 오픈소스 CMS를 사용해 개발했다. XE는 별도의 모바일 전용 페이지를 제공하는 기능을 이미 갖추고 있지만, 별도의 HTML과 CSS를 사용하기 때문에 데스크톱에서 보는 사이트와 모바일에서 보는 사이트의 디자인과 기능이 다르다.

이러한 기존 방식의 가장 큰 문제는 사용자 브라우저의 UA(User Agent) 정보를 감지하여 사용자 접속 시 데스크톱 전용 페이지에 머무르게 할지 모바일 전용 페이지로 이동시켜야 할지 판단했기 때문에 새로운 브라우저가 등장할 때마다 개발자는 늘 촉각을 곤두세워야 했다. 그리고 새로운 모바일 브라우저가 등장하면 개발자가 새로운 코드를 추가했다. 데스크톱과 모바일 이외에도 그 중간 정도 크기의 해상도인 태블릿 PC를 많이 사용하는 요즘과 같은 상황에는 유연하게 대응하지 못하는 방식이다. 만약 기존의 방식대로 대응한다면 태블릿 PC 전용 페이지를 추가로 개발하고 UA 정보를 추가한 다음 태블릿 PC 사용자 접속 시 태블릿 PC 전용 페이지로 이동하는 코드를 추가해야 한다.

이와 달리 반응형 웹은 사용자의 접속 해상도와 같은 장치 특성을 해석해서 단 하나의 HTML 페이지가 여러 패턴의 CSS 뷰를 갖도록 만들어 준다. 특정 해상도에 최적화된 페이지를 만드는 것이 아니라 모든 해상도에 대응하는 페이지를 만들기 때문에 현존하는 모든 장치의 해상도를 일일이 파악할 필요가 없다. CSS3 미디어쿼리 규칙이 등장하면서 서버 측 개발자가 해야만 했던 일을 이제는 클라이언트 개발자가 할 수 있게 된 것이다.

1ad5c7ba306737033ac520244102db14.png

그림 1 브라우저 크기에 따라 페이지의 레이아웃이 바뀌는 반응형 웹

고민했던 것들

반응형 웹으로 개편하기에 앞서 크게 고민했던 것들은 다음과 같다.

여러 가지 작은 고민들이 있었지만 결론적으로는 '하위 호환성', '성능', '내비게이션', '개발 편의' 이렇게 네 가지 분야의 고민으로 귀결된다.

하위 호환성

CSS3는 아직 W3C에서 개발 중이며 권고 표준안이 아닌 초안이다. 그러나 현재 사실상 표준으로 받아들일 수 있는데, 이는 Internet Exploer 9를 비롯한 최신 브라우저들이 이미 상당한 수준으로 CSS3 명세를 브라우저에 적용해 두었기 때이다. 미디어쿼리 규칙도 그 중 하나이다.

미디어쿼리는 CSS 코드 안에서 다음과 같은 방식으로 표현할 수 있다.

?
1
2
3
4
5
6
7
8
9
@media all and (min-width:768px) {
    /* 768px 이상 해상도에서 실행할 CSS 코드를 여기에 작성 */
}
@media all and (min-width:768px) and (max-width:1024px) {
    /* 768px 이상 1024px 이하 해상도에서 실행할 CSS 코드를 여기에 작성 */
}
@media all and (min-width:1025px) {
    /* 1025px 이상 해상도에서 실행할 CSS 코드를 여기에 작성 */
}

괄호(( )) 안쪽에 작성된 구문은 조건문이라고 이해하면 된다. 조건에 맞는 경우에만 미디어쿼리 구문의 중괄호({ }) 안쪽 구문을 해석한다. 그러나 Internet Exploer 6~8 버전 브라우저와 낡은 모바일 브라우저는 미디어쿼리 규칙을 해석하지 못하기 때문에 미디어쿼리 구문 안쪽의 코드를 아예 해석하지 않는 특징이 있고 이 문제를 해결해야 했다.

Internet Exploer 6~8 버전 브라우저 문제 해결

다행스럽게도 Internet Exploer 6~8 버전 브라우저에서도 미디어쿼리를 해석할 수 있도록 만들어 주는 JavaScript 라이브러리가 있었다. respond.min.js라고 부르는 이 파일은 약 4KB 정도의 용량이다. 어떤 용도로 사용해도 제한이 없는 MIT 또는 BSD 라이선스를 가지고 있기 때문에 소스 코드에 포함된 라이선스 명시 조항만 지우지 않으면 github에서 언제든 내려받아 사용할 수 있다.

respond.min.js 파일을 HTML 문서의 <head> 태그 부분에 다음과 같은 방식으로 삽입하면 Internet Exploer 6~8 버전 브라우저가 미디어쿼리 규칙을 해석할 수 있게 된다.

<!--[if lt IE 9]>
<script type="text/javascript" src="http://helloworld.naver.com/respond.min.js"></script>
<![endif]-->

Internet Explorer 브라우저만 해석할 수 있는 조건부 주석을 사용했기 때문에 다른 표준 브라우저들은 이 코드를 무시하고 JS 파일을 요청하지 않는다. 조건부 주석에서 [if lt IE 9]의 의미는 '[if less than IE 9]'이다. 즉, Internet Exploer 9 미만의 브라우저에서만 해석하라는 의미이다.

낡은 모바일 브라우저 문제 해결

respond.min.js 파일이 미디어쿼리를 지원하지 않는 낡은 모바일 브라우저의 문제까지 해결해 주지는 못한다. 그러나 모바일 퍼스트 CSS 전략으로 이 문제를 해결할 수 있다.

모바일 퍼스트의 핵심은 낡은 모바일 브라우저가 미디어쿼리 구문을 해석하지 못하기 때문에 모바일을 위한 CSS 코드를 미디어쿼리 구문 밖에 작성하는 것이다. 모바일 퍼스트 코드 예제는 다음과 같이 작성할 수 있다.

?
1
2
3
4
5
/* 모바일용 CSS 코드를 여기에 작성 */
  
@media all and (min-width:768px) {
    /* 모바일용이 아닌 CSS 코드를 여기에 작성 */
}

모바일용 CSS 코드가 미디어쿼리 밖에 작성됐기 때문에 모든 장치가 모바일용 CSS 코드를 해석한다. 모바일이 아닌 장치도 모바일용 코드를 해석하는 것은 문제가 되나 미디어쿼리 안쪽에 모바일이 아닌 장치를 위한 CSS가 거듭 선언되어 있기 때문에 모바일용 코드를 덮어쓰게 된다.

결국 모든 모바일 장치는 미디어쿼리 지원 여부에 관계 없이 모바일용 CSS 코드를 해석할 수 있게 되고 미디어쿼리 구문 안쪽의 코드는 조건에 맞지 않거나 또는 미디어쿼리 규칙을 지원하지 않기 때문에 아예 해석하지 않는다. 모바일이 아닌 장치는 미디어쿼리 구문 안쪽을 해석함으로써 모바일과 모바일이 아닌 장치의 뷰를 분기할 수 있게 됐다.

이렇게 모든 장치의 하위 호환성을 우선 고려하여 개발하는 방식을 점진적 향상 개발이라 부른다. 모바일 퍼스트는 반응형 웹의 점진적 향상 개발 기법으로 반응형 웹의 필수적인 고려 사항이다.

성능

HelloWorld 블로그는 데스크톱에 최적화된 뷰와 성능이었기 때문에 Wi-Fi와 3G망을 사용하는 모바일 환경에 맞춰 성능 최적화가 필요했다. 일반적으로 성능을 최적화하려면 다음과 같은 기법들이 고려된다.

이런 방법이 적은 노력으로도 클라이언트 측 성능을 극대화 할 수 있는 방법이다.

JS/CSS 파일 병합

모듈화를 지향하는 XE 제품의 CMS 특성상 코어, 모듈, 애드온에 포함되어 있는 다양한 JS/CSS 파일의 병합은 한계가 있었다. XE는 한동안 여러 JS 파일과 CSS 파일을 하나의 파일로 병합해 주는 병합 최적화 기능이 있었는데, 코드의 작은 변경 사항이 발생해도 새로운 파일로 갱신하여 병합하기 때문에 브라우저 캐시의 장점을 전혀 취하지 못하는 점이 오히려 문제로 부각이 됐다. 결국 병합 최적화 기능은 XE에서 제거되었고 JS/CSS 파일 병합을 통한 성능 개선은 이번에는 거의 이루어 지지 않았다. 하지만 비교적 단순한 웹 사이트에서 JS/CSS 파일 병합은 강력하게 권장할만한 개선 포인트이다.

이미지 파일 병합

여러 개의 잘게 쪼개진 이미지도 많은 요청을 유발하여 성능에 나쁜 영향을 주기 때문에 이미지 스프라이트(image sprite) 기법을 사용해 단 하나의 이미지로 병합했다.

fc53b96ebeddbe2e7326a16abb505bcb.png

그림 2 한 장의 이미지로 병합한 HelloWorld 블로그의 아이콘

JS 파일 지연 로딩

웹 브라우저는 HTML 파일을 1번 라인부터 순서대로 해석하면서 즉시 화면에 출력하는 특성이 있다. 이런 특성 때문에 JS 파일을 HTML의 <head> 태그 부분 안에서 참조하면 브라우저가 JS 파일을 해석하는 동안 HTML의 <body> 태그 부분의 콘텐츠는 전혀 해석되지 않는다. 결국 참조된 JS 구문을 브라우저가 해석하는 동안 화면에 아무것도 보여주지 않기 때문에 체감 성능이 떨어지는 요인이 된다.

HelloWorld 블로그는 개발자의 글이 많은 특성상 소스 코드를 보기 좋게 표현하기 위해서 SyntaxHightlighter 애드온을 사용하고 있었는데, 13개나 되는 JS 파일을 HTML의 <head> 태그 부분 안쪽에서 참조하고 있었다. 데스크톱 환경에서는 이 파일의 존재 여부가 사람이 느낄 수 있을 만큼 크지 않으나 모바일 환경에서는 이야기가 달라진다. 결국 <head> 태그 부분 안쪽에서 참조하던 JS 파일은 <body> 태그의 종료 태그 앞쪽으로 옮겨서 JS 파일이 <body> 태그 부분의 콘텐츠보다 나중에 해석되도록 개선했다.

개선 전

<head>
      <script type="text/javascript" src="shCore.js">
</head>

개선 후

<body>      
       bla bla bla …
      <script type="text/javascript" src="shCore.js">
</body>

한편 <body> 태그 부분을 해석하기 이전에 먼저 해석해야 하는 JS 파일도 있기 때문에 모든 JS 파일을 <body> 태그의 종료 지점으로 옮길 수는 없었다.

웹 폰트 요청 분기

웹 폰트는 사용자 시스템에 없는 글꼴을 웹 서버로부터 직접 내려받아 화면에 표시하는 방식이다. Internet Exploer 6~8 버전 브라우저는 eot(embeded open type) 형식의 비표준 글꼴을 지원하고 다른 표준 브라우저들은 woff(web open font format) 형식의 표준 글꼴을 지원한다.

웹 폰트 명세는 오래전부터 Microsoft사에서 Internt Exploer 6~8 버전 브라우저에 적용해서 지원했지만 W3C에 제안하여 CSS3 명세에 추가됐다. 그러나 글꼴은 하나의 크기가 보통 1MB 미만이라 적지 않은 용량의 웹 폰트를 서버에서 내려받아야 하기 때문에 성능을 떨어뜨리는 요인이 되기도 한다.

HelloWorld 블로그는 나눔고딕 글꼴을 사용하고 있는데, 기본적으로 나눔고딕 글꼴이 사용자 시스템에 존재하면 시스템 글꼴을 사용하여 나눔고딕을 표시한다. 그러나 시스템 글꼴에 나눔고딕이 없으면 웹 서버로부터 웹 폰트를 내려받아 표시한다. 이런 방법으로 가능한 모든 장치에서 나눔고딕을 표시할 수 있다. 그러나 Wi-Fi와 3G 회선을 사용하는 모바일 장치의 사용자가 웹 폰트를 내려받는 일은 합리적인 방식이 아니다.

CSS3 미디어쿼리 규칙을 이용하면 장치 해상도가 큰 경우에만 웹 폰트를 내려받도록 처리하고 해상도가 작은 경우에는 시스템 글꼴을 사용하거나 아예 웹 폰트를 내려받지 않도록 처리할 수 있다. 모바일 장치의 웹 페이지 로딩 성능이 떨어지지 않도록 고려하는 방법이다.

?
1
2
3
4
5
6
7
8
9
10
/* 모든 해상도 공용 글꼴 - 시스템 글꼴만 선언 */
body, input, textarea, button, select, table {
    font-family: 나눔고딕, NanumGothic, Tahoma, Sans-serif;
    font-size: 12px
}
/* 태블릿 PC와 데스크톱용 글꼴 - 시스템 글꼴 다음으로 웹 폰트를 참조하도록 선언 */
@media all and (min-width: 768px) {
    @font-face{font-family:ng; src:url(NanumGothic.eot); src:local('※'), url(NanumGothic.woff) format('woff');}
    body,input,textarea,button,select,table{font-family:나눔고딕,NanumGothic,ng,Tahoma,Sans-serif}
}

'ng'라고 정의된 글꼴이 웹 폰트이다. 해상도가 768px 이상이면서 시스템 글꼴에 나눔고딕이 없을 때만 웹 폰트를 내려받아 표시하도록 코드를 작성했다. 글꼴은 선언된 순서대로 먼저 참조하기 때문에 시스템 글꼴 이름을 웹 폰트 글꼴 이름보다 먼저 작성하는 것이 중요하다. 해상도가 768px 이상이라도 사용자 시스템에 나눔고딕 글꼴이 존재한다면 웹 폰트를 요청하지 않을 것이다.

내비게이션

HelloWorld 블로그의 주 내비게이션은 카테고리 목록이다. 데스크톱 화면에서는 오른쪽 컬럼 위에 나타나지만 모바일 화면에서는 오른쪽 컬럼이 본문 아래로 밀려 내려가기 때문에 주 내비게이션의 표시 위치와 모양을 다시 디자인해야 했다.

986448da2d24824cfb82794ff693d34a.png

그림 3 데스크톱과 큰 화면의 태블릿 PC용 내비게이션: 오른쪽 컬럼 위에 배치됨

반응형 웹에서 좁은 화면의 내비게이션을 구현하는 UI 패턴에는 잘 알려진 몇 가지 방법이 있다. 손쉬운 방법으로는 <select> 태그를 사용한 콤보박스 형태가 있다. 그러나 이 방식은 운영체제 또는 브라우저마다 다르게 보여 문제가 될 수 있다. 처음에는 이 방식을 사용했지만 Mac OS/Safari 브라우저에서 CSS의 height 속성이 적용되지 않아 다른 방법을 찾아야만 했다.

c826121c0f8a34a9d425b93cc44d78c5.png

그림 4 작은 화면을 위한 콤보박스 내비게이션: 운영체제 또는 브라우저 특성에 따라 다르게 보인다

결국 JavaScript를 이용하여 카테고리 목록의 HTML 코드를 복사한 다음 본문 위쪽 영역에 붙여 넣고 CSS로 디자인만 다르게 보이도록 처리했다. 초기 값으로는 내비게이션이 보이지 않게 한 다음 '분류 열기' 버튼을 누르면 열거나 닫을 수 있게 해서 최근 게시물 본문이 가장 먼저 눈에 들어오도록 고려했다.

681962e3a67c17abd74a669548ec3063.png

그림 5 작은 화면을 위한 토글 내비게이션: 본문 위쪽과 아래쪽에 반복해서 배치함

개발 편의

HelloWorld 블로그를 반응형 웹으로 개편해야 한다는 미션을 받았지만 디자인을 변경하는 것은 아니었고 기존의 코드를 리펙토링하는 것도 아니었다. 데스크톱에 최적화되어 있는 기존의 디자인과 코드는 그대로 사용했고 단지 모바일과 태블릿 PC를 위한 몇 줄의 CSS 코드를 덧붙이기로 했다.

CSS 파일의 미디어쿼리 구문 안쪽에 약 50라인 정도를 새롭게 추가하는 것으로 반응형 웹 개편을 마무리 했다. 새로 추가된 코드의 양은 적지만 반응형 웹을 위해 기존의 코드를 'All', 'Mobile', 'Tablet & Desktop #1', 'Tablet & Desktop #2', 'Desktop' 이렇게 5단계 레이블을 붙여 주석으로 분리한 다음 적당한 위치로 옮기는 작업에 비교적 많은 시간이 걸렸다.

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
@charset "utf-8";
  
/* All - 모든 해상도 공용 스타일 */
...
  
/* Mobile - 모바일 해상도 전용 스타일 */
...
  
/* Tablet & Desktop #1 - 태블릿 PC와 데스크톱 공용 스타일 #1 */
@media all and (min-width:481px) {
...
}
  
/* Tablet & Desktop #2 - 태블릿 PC와 데스크톱 공용 스타일 #2 */
@media all and (min-width:768px) {
...
}
  
/* Desktop - 데스크톱 전용 스타일 */
@media all and (min-width:990px) {
...
}

코드는 이런 방식으로 작성되어 있지만 일반적으로 간단하게 설명할 때는 모바일, 태블릿 PC, 데스크톱 해상도에 모두 대응할 수 있도록 반응형으로 개편했다고 말한다.

마치며

HelloWorld 블로그 개편은 기존의 코드를 최대한 유지하면서 반응형으로 개편하는 것이었기 때문에 추가할 코드의 양은 적은 대신 손 쉬운 유지 보수를 위해 하나의 UI 컴포넌트 코드를 해상도별로 분리된 지점에 따로 작성 하는 일이 다소 고된 일이기는 했다. 하지만 이런 고됨은 반응형 웹 구현 시 피할 수 없는 일이고 사용자에게는 편익이 되니 클라이언트 개발자가 감수할 가치가 있었다.



출처 - http://helloworld.naver.com/helloworld/81480






반응형웹은 데스크탑, 노트북, 넷북, 태블릿, 스마트폰, 스마트TV 등 N-Screen의 Multi Device에 어떠한 사용자도 제약없이 접근할 수 있도록 제공하는 웹을 말한다.
반응형웹에서 가장 중시되어야 할 것은 모바일을 우선순위로 해야한다.
최적화된 반응형웹 접근방식으로서 모바일을 우선에 두고 CSS를 작성하는 방법으로 가장 단순한 기기, 최소성능의 Device에 우선을 두고 작업을 하며, 이렇게 작업을 하면 기준치 이하의 Device에 과도한 짐을 지우지 않으면서, 최신 브라우저를 사용하는 사용자에게 풍부한 경험을 제공한다.
또한 웹의 창시자 팀 버너스 리 경(Tim Berners - Lee , W3C Director and inventor of the World Wide Web)은 이렇게 이야기 했다.
웹의 힘은 그것의 보편성에 있다. 장애에 구애없이 모든 사람이 접근할 수 있는 것이 필수적인 요소이다.
(The power of the Web is in its universality, Access by everyone regardless of disability is an essential aspect.)

반응형웹의 등장배경

현재 다양한 IT Device 등장함에 따라 N-Screen 욕구가 생겨나게 되고, 이에따라 Multi Device환경에 최적화된 디자인과 기능을 보여주어야 한다. 기존에는 이를 위해 사용자 브라우저 UA(User Agent) 정보를 감지하여 사용자 접속시 모바일 전용페이지로 이동할지 데스크탑 전용 페이지에 머무르게 해야 할지 판단했기에 새로운 Device가 등장할 때마다 개발자는 고민해야 했다.
그리고 새로운 모바일 브라우저가 등장하면 개발자가 새로운 코드를 추가했다. 데스크톱과 모바일 이외에도 그 중간 정도 크기의 해상도인 태블릿 PC를 많이 사용하는 요즘과 같은 상황에는 유연하게 대응하지 못하는 방식이다. 만약 기존의 방식대로 대응한다면 태블릿 PC 전용 페이지를 추가로 개발하고 UA 정보를 추가한 다음 태블릿 PC 사용자 접속 시 태블릿 PC 전용 페이지로 이동하는 코드를 추가해야 한다.

이와 달리 반응형 웹은 사용자의 해상도와 같은 장치 특성을 해석해서 단 하나의 HTML 페이지가 여러 패턴의 CSS 뷰를 갖도록 만들어 준다. 특정 해상도에 최적화된 페이지를 만드는 것이 아니라 모든 해상도에 대응하는 페이지를 만들기 때문에 현존하는 모든 장치의 해상도를 일일이 파악할 필요가 없다. CSS3 미디어쿼리 규칙이 등장하면서 서버 측 개발자가 해야만 했던 일을 이제는 클라이언트 개발자가 할 수 있게 된 것이다. 이렇듯 웹은 데스크탑의 차원을 넘어서야 했다.

반응형웹 마크업 가이드 제작 전 고민사항

  • 1. 미디어쿼리 해상도 분기문제
  • 2. IE8 브라우저의 하위 호환성
  • 3. 모바일 환경에서의 성능문제
  • 4. 가변적 그리드 기반의 레이아웃
  • 5. 웹폰트를 기본글꼴로 사용시 브라우저 호환성 및 모바일 성능저하 문제

고민사항1 : 미디어쿼리 해상도 분기문제 해결방법

다양한 Device를 어떻게 미디어쿼리로 분기 할 것인가에 대한 고민은 반응형웹 프로젝트를 진행하는 개발자라면 누구나 고민할 것이다.
모바일 페이지를 기본CSS로 작성하고 미디어쿼리를 사용하여 데스크탑 페이지, 테블릿페이지로 개발하면 된다.

  • 1. 데스크탑 페이지
    최근 고해상도 사용자가 많아짐에 따라 1280px 이상(데스크탑 페이지 가운데 정렬 디자인이 대부분이므로 CSS는 컨텐츠 영역을 PX로 고정한다.)으로 미디어쿼리 작성한다.
  • 2. 노트북 및 태블릿 페이지
    태블릿과 노트북은 가로사이즈가 1024px로 동일하다. 태블릿에서는 틸팅(화면회전)이 되므로 가로사이즈를 width="auto"로 CSS를 작성한다.
    미디어쿼리의 해상도는 768px 이상 ~ 1025px 이하로 작성한다.
  • 3. 모바일 페이지
    미디어쿼리를 적용하지 않고 기본 CSS로 작성한다.
    태블릿과 같이 틸팅(화면회전)이 되므로 가로사이즈를 width="auto"로 CSS를 작성한다.
@media all and (min-width:768px) and (max-width:1024px){
/* 태블릿 및 노트북 CSS 작성 */
}

@media all and (min-width:1025px){
/* 데스크탑 CSS 작성 */
}

고민사항2 : IE8 브라우저의 하위 호환성 해결방법

반응형웹이란 IT Device에 반응하는 것이지 화면을 Resize해서 반응하는 것이 아니며, 그것이 본질이다. 그렇기에 데스크탑 페이지에서 Resize 해도 반응하지 않아도 무방하다.
그러나 클라이언트는 반응형웹의 본질에 대해서 모르는 경우가 대부분이다. 무조건 Resize되어야 반응형이라고 생각한다. 그렇기 때문에 논리적으로 설득하는것이 가장 좋은 방법이나, 안될 경우에는 Internet Exploer 6~8 버전 브라우저에서도 미디어쿼리를 해석할 수 있도록 만들어 주는 JavaScript 라이브러리가 있다.
respond.min.js라고 부르는 이 파일은 약 4KB 정도의 용량이다. 어떤 용도로 사용해도 제한이 없는 MIT 또는 BSD 라이선스를 가지고 있기 때문에 소스 코드에 포함된 라이선스 명시 조항만 지우지 않으면 github에서 언제든 내려받아 사용할 수 있다.

respond.min.js 내려받기 : https://github.com/scottjehl/Respond

respond.min.js 파일을 HTML 문서의 <head> 태그 부분에 다음과 같은 방식으로 삽입하면 Internet Exploer 6~8 버전 브라우저가 미디어쿼리를 해석할 수 있게 된다. 로컬(local)에서는 확인이 불가능 하며, 서버에 올린 후 적용된 것을 확인할 수 있다.

<!--[if lt IE 9]>
<script type="text/javascript" src="/js/respond.min.js"></script>
<![endif]-->

Internet Explorer 브라우저만 해석할 수 있는 조건부 주석을 사용했기 때문에 다른 표준 브라우저들은 이 코드를 무시하고 JS 파일을 요청하지 않으며 IE9 미만인 IE6 ~ IE8 에서만 사용된다.

고민사항3 : 모바일 환경에서의 성능문제 해결방법

데스크탑은 성능이 좋아 속도에 문제가 없지만, 모바일 Device 경우 낮은성능으로 인하여 최적화를 고려해야 한다.

  • 1. 모바일 CSS
    모바일 CSS를 기본으로 작성하고, 태블릿과 데스크탑 페이지를 미디어쿼리로 작성하여 모바일에 불필요한 CSS는 요청하지 않게 한다. 미디어쿼리의 경우 해당 해상도가 아닐경우 CSS를 요청하지 않아 성능을 최적화 할 수 있다.
  • 2. Sprite 기법 사용
    여러개의 잘개 쪼개진 이미지는 서버에 많은 요청을 유발하므로 의미가 비슷한 이미지의 경우 병합하여 사용함으로서 서버측에 이미지 요청 횟수를 줄여 성능을 최적화 한다.
  • 3. 들여쓰기 및 띄워쓰기 최소화
    CSS 및 마크업 들여쓰기 및 띄워쓰기를 최소화하여 성능을 높여준다.

    NHN Markup Coding Convention : http://html.nhncorp.com/

  • 4. 웹폰트 요청분기
    웹폰트사용 시 기본 CSS로 작성하지 않고 해당 데스크탑 미디어쿼리부분에 작성하여 모바일 Device의 성능을 올려준다.

고민사항4 : 가변적 그리드 기반의 레이아웃 해결방법

  • 1. 컨텓츠 레이아웃 시 em, %를 사용하여 개발할 경우 아직 출시되지 않은 device에 대비한다.
  • 2. 이미지와 미디어들도 감까고 있는 그리드에 맞게 max-width:100% 넣어준다.

고민사항5 : 웹폰트를 기본글꼴로 사용시 브라우저 호환성 및 모바일 성능저하 문제 해결방법

IE9은 @media 규칙 내부에 @font-face 허용 안하기 때문에 @media 구문 안쪽에 @font-face 규칙을 선언하는 경우 IE9 브라우저는 외부 글꼴을 요청하지 않기 때문에 표시하지 못합니다.
그렇기 때문에 웹폰트 사용 시 IE9 조건부 주석을 사용하여 IE9에서만 해석할 수 있도록 개발해야 한다.

<!--[if IE 9]>
<link rel="stylesheet" type="text/css" href="iefont9.css">
<![endif]-->

반응형웹 기본가이드 다운로드

필자가 만든 반응형웹 기본가이드는 미디어쿼리 및 자바스크립트로 분기하는 방법 2가지 자료는 첨부하였습니다.
사용 시 작성자 주석부분 지우지 말고 사용해 주세요.


반응형웹_1_미디어쿼리.zip


반응형웹_2_자바스크립트.zip

출처 - http://biew.co.kr/m/post/view/id/26











저작자표시

'Web > Common' 카테고리의 다른 글

해상도  (0) 2013.11.19
ie - 저장된 페이지의 새 버전 확인 > 자동 설정 상태에서 클라이언트 캐싱 제어  (0) 2013.10.09
web - deep link(딥링크)  (0) 2013.07.28
압축 - DEFLATE, SDCH 알고리즘  (0) 2013.06.27
web - BOM, DOM  (0) 2013.06.26
Posted by linuxism
,

db - jdbc vs jpa

DB/Common 2013. 9. 14. 11:31


JPA or JDBC, how are they different?


Layman's terms:

  • JDBC is a standard for Database Access
  • JPA is a standard for OR/M

JDBC is a standard for connecting to a DB directly and running SQL against it - e.g SELECT * FROM USERS, etc. Datasets can be returned which you can handle in your app, and you can do all the usual things like INSERTS, DELETES, run stored procedures, etc. It is one of the underlying technologies behind most java database access (including JPA providers).

One of the issues with traditional JDBC apps is that you can often have some crappy code where lots of mapping between datasets and objects occur, logic is mixed in with SQL, etc.

JPA is a standard for Object Relational Mapping. This is a technology which allows you to map between objects in code and database tables. This can "hide" the SQL from the developer so that all they deal with are java classes, and the provider allows you to save them and load them magically. Mostly, XML mapping files or annotations on getters, setters can be used to tell the JPA provider which fields on your object map to which fields in the DB. The most famous JPA provider is Hibernate, so is a good place to start for concrete examples.

http://www.hibernate.org/

Other examples include OpenJPA, toplink, etc.

Under the hood, hibernate and all the other providers for JPA write SQL and use JDBC to read and write to the DB.


iBatis (nowadays MyBatis) is not an JPA implementation. If you take a look to it, you will notice that it does have very different concept. – Mikko Maunu Aug 9 '12 at 11:30



출처 - http://stackoverflow.com/questions/11881548/jpa-or-jdbc-how-are-they-different

저작자표시

'DB > Common' 카테고리의 다른 글

search - Elasticsearch  (0) 2014.04.24
db - ACID  (0) 2013.06.22
Sharding & Query Off Loading  (0) 2013.04.29
SELECT문 순서와 처리순서  (0) 2012.08.29
데이터 입력과 db insert 사이에 버퍼링 방법  (0) 2012.07.13
Posted by linuxism
,

apache - 파일 크기 제한을 초과함 $HTTPD

Web/HTTP 2013. 9. 9. 09:46


./apachectl start 시 다음과 같은 에러 발생 시 

파일 크기 제한을 초과함 $HTTPD 


access, error, mod_jk 로그 파일이 2G가 넘는지 확인한다.

저작자표시

'Web > HTTP' 카테고리의 다른 글

http - compression  (0) 2013.06.27
http - cache(web cache)  (0) 2013.06.24
http - request, response header  (0) 2013.06.20
http - accept header field  (0) 2013.06.19
http - List of HTTP status codes  (0) 2011.12.16
Posted by linuxism
,

티스토리툴바