간단한 개발관련 내용

Chapter 13. ETag를 설정하라.

사용자가 경험을 향상시키기 위한 최선의 방법은 페이지 렌더링에 필요한 HTTP 요청수를 줄이는 것이다.

1. ETag란 무엇인가?

웹서버와 브라우저가 캐시된 구성요소의 유효성을 확인하기 위해서 사용하는 메커니즘이다.

ㄱ. 헤더의 Expires.

헤더 Expires에 설정된 만료기한이 지나지 않았다면 구성요소는 새로운 것이라 판단한다. 권고된 기간은 1년미만이지만 브라우저는 1년이상의 만료기한을 지원한다.

ㄴ. 조건부 GET 요청.

서버의 구성요소와 캐시된 구성요소가 같은 파일인지 결정하는 두 가지 방법이 있다. 

마지막 수정일을 비교한다.

ETag를 비교한다.

ㄷ. 마지막 수정일.

구성요소의 마지막 수저일은 서버에서 응답헤더의 Last-Modified 를 통하여 반환된다. 다음번에 다시 요청이 되면 브라우저는 If-Modified-Since 헤더를 이용해서 마지막 수정일을 서버로 전달한다.

ㄹ. ETag.

ETag(Entity Tag)는 브라우저의 캐시에 저장되어 있는 구성요소와 원본 서버의 구성요소가 일치하는지 판단하는 또 다른 방법이다. 구성요소를 나타내는 값을 따옴표의 고유한 문자열로 응답헤더의 ETag에 지정한다.

2. ETag 의 문제.

ETag의 문제점은 해당 값이 서버당 하나이기 때문에 여러 서버로 운영되는 서비스일 경우 값이 일치하지 않게 된다. 이러한 문제는 또한 프록시 캐시의 효율 또한 떨어뜨린다.

3. ETag 사용해야 하나 버려야 하나?

Last-Modified 헤더가 이미 동일한 정보를 담고 있기 때문에 Etag를 제거하면 요청이나 응답의 헤더 크기 또한 줄일 수 있다. 아파치에서는 "FileEtag none"을 사용하면 간단하게 제거할 수 있다.

ETag의 구조를 변경하거나 삭제하라.

Chapter 05. 스타일시트는 위에 넣어라.

 간혹 엔지니어들은 페이지 초기에 필요없는 CSS를 외부 스타일시트에 넣고 이를 페이지 하단에 넣으면 페이지가 좀 더 빨리 로드될 것이란 기대를 한다. 하지만 오히려 반대로 HEAD 영역으로 이동시켰더니 속도가 더 빨라짐을 알 수 있었다.

1. 점진적인 렌더링.

 브라우저는 브라우저 자신과 사용자가 페이지 하단의 스타일시트를 다 받을 때까지 기다리는 동안 페이지 렌더링을 지연시킨다. 스타일시트를 페이지 하단에 넣는 것의 문제는 여러 브라우저에서 점진적인 렌더링을 못하게 한다는 것이다.

2. sleep.cgi.

3. 빈 흰색 스크린.

 웹 페이지를 호출 한 후에 빈 흰색 스크린을 보지 않으려면 CSS를 페이지 아래에 넣거나 @import 를 이용해 첨부하지 말고 CSS를 HEAD 영역으로 이동시키고 LINK 태그를 이용해서 첨부해야 한다. 이는 성능에도 영향을 준다.

4. 스타일이 뒤늦게 적용되는 콘텐츠.

 빈 흰색 스크린 현상을 브라우저의 동작 방식 때문에 발생하는 현상이다. 페이지 안의 스타일시트 위치는 다운로드 시간에 영향을 주지 않지만 렌더링에는 영향을 준다. 마지막에 스타일시트가 다운된 후에 다시 렌더링되는 FOUC 현상은 반드시 피해야 한다.

5. 엔지니어는 무엇을 선택할 것인가.

 스펙을 위반하는 페이지는 여전히 렌더링되지만 사용자 경험면에서는 성능 저하를 감수해야 한다.  CSS는 HEAD 안에 LINK 태그를 이용해서 넣어라.

Chapter04 Gzip 컴포넌트.

 이번 장에서는 gzip 인코딩을 이용해서 HTTP 응답을 압축하여 응답의 크기를 줄여 속도를 개선하는 방법을 보여준다. 

1. 압축을 적용하는 방법.

HTTP/1.1 에서부터 웹 클라이언트는 HTTP 요청의 Accept-Encoding 헤더를 이용해 압축의 지원 여부를 보내주게 된다. 웹 서버는 응답 헤더 안의 Content-Encoding 속성을 통하여 웹 클라이언트에게 사용된 압축 방식을 알려준다. gzip 과 deflate 포맷을 사용할 수 있는데 주로 gzip을 사용한다.

2. 무엇을 압축해야 하는가?

Gzip은 HTML문서, 스크립트와 스타일시트를 압축할 수 있지만 이미지와 PDF는 이미 압축된 파일이기 때문에 gzip 압축을 적용해서는 안 된다. 일반적으로 gzip은 1~2KB 보다 큰 파일일 경우에 적용해 볼 만한 가치가 있다.

3. 압축률.

 gzip이 적용된 파일은 일반적으로 약 70% 정도의 압축 효과를 가지며 deflate 보다 평균적으로 높은 압축률을 가지고 있다.

4. 설정.

gzip 설정은 Apache 버전에 따라 다른데 Apache 1.3 에서는 mod_gzip 이라는 모듈이 제공되고 있고, Apache 2.x 에서는 mod_deflate 모듈을 사용한다. 자세한 내용은 Apache 문서를 참고 할 것.!

5. 프록시 캐싱.

 프록시가 캐시에 압축된 정보를 가지고 있고 브라우저의 압축 지원 여부에 상관없이 압축된 버전의 콘텐츠를 전달하게 될 경우에 문제가 발생하는데 이럴 경우에는 서버의 헤더에 Vary: Accept-Encoding을  추가한다. 

6. 예외적인 경우.

브라우저가 지원하지 않을 경우를 고려하여 안전성이 보장된 브라우저에만 압축을 전달해야 하는데 이런 접근 방식을 Browser Whitelist 라고 한다. Apache 설정을 통하여 User-Agent 에 대해 화이트리스트 설정을 할 수 있다. 이러한 설정들은 각 사이트의 상황에 맞추어 내려져야 한다.

7. Gzip 의 효과.

스크립트와 스타일시트도 gzip 압축을 하자.

Chapter03. 헤더에 만료기간을 추가하라.

 사이트에 처음 방문한 사용자일 경우 여러 번의 HTTP 요청을 하게 될지도 모르지만 헤더 만료기한(Expires)을 이용함으로써 그 구성요소를 캐시에 저장할 수 있다.

1. 헤더의 만료기간.

 브라우저 캐시를 이용하여 HTTP의 요청 수를 줄일 수 있다. Expires헤더에서 지정한 시간 이후에는 해당 응답의 내용이 더 이상 유효하지 않다는 것이다. 

2. max-age 와 mod_expires 속성.

 Expires는 지정된 날짜를 이용하기 때문에 서버와 클라이언트가 시간을 맞추어 사용해야며 만료일에 대해 갱신해야 한다는 단점이 있다. 그리하여 HTTP/1.1 에서 소개된 Cache-Control은 Expires 의 한계를 보완하고자 max-age 속성을 설정하여 얼마 동안 캐시에 보관할지를 설정한다. 하지만 HTTP/1.1 을 지원하지 않는 브라우저에서는 Expires를 사용해야 하는데 기존의 단점이 문제가 된다.

 그 단점을 보완하고자 아파치에서 mod_expires 라는 모듈을 제공하고 있고 이 기능은 Expires 를 max-age 와 비슷하게 상대적인 시간으로 지정할 수 있게 해 준다. 

 둘 다 설정되어 있을 경우 우선순위는 Cache-Control 이 높으며 시간을 재설정하는 수고를 덜 수 있을 것이다.

3. 빈 캐시와 꽉 찬 캐시.

 서비스의 형태와 함께 PV, UV 를 고려하여 Expires를 생각하여야 한다.

4. 이미지 그 이상으로.

 헤더의 Expires는 이미지에 보통 사용하지만 이미지에 국한되어서는 최고의 성능을 발휘할 수 없다. 헤더의 Expires 속성은 스크립트나 스타일시트, 플래시와 같이 자주 변하지 않는 것에도 포함시켜야 한다.

5. 파일 이름의 활용.

 Expires가 설정된 상태에서 서버의 구성요소를 변경하였을 경우 사용자가 최신 정보를 받아보기 위해서 가장 좋은 방법은 구성요소의 주소를 변경하는 것이다. 그렇게 해서 서버로부터 완전히 새로운 구성요소를 로드하게 만드는 것이다.(ex.구성요소의 파일에 버전을 붙임)

Chapter02. 콘텐츠 전송 네트워크를 이용하라.

 서비스의 이용자가 늘게 되어 서버를 증설하게 되면 서버의 콘텐츠를 지리적으로 분산된 여러 개의 서버에 나누어 놓아야 할 필요가 생긴다. 콘텐츠를 지리적으로 분산시킬 때 먼저 웹 애플리케이션을을 분산 구조에 맞게 재설계하는 작업을 피하고, 웹 페이지 구성요소가 저장되어 있는 웹 서버를 먼저 분산시켜 놓는 것이 더 좋은 선택일 수 있고 이는 CDN(Contents Delivery Network)를 이용하면 더 쉽게 구현할 수 있다.

 CDN은  사용자에게 효율적으로 콘텐츠를 전달하기 위해서 여러 지역에 웹 서버를 분산시켜 놓는 기술인다. 이는 응답시간을 줄이며, 백업, 저장용량의 확대, 캐싱기능을 갖고 이미지, 스크립트, 스타일시트, 플래시와 같은 정적 콘텐츠를 전달할 때 이용된다. 

 대신에 조심해야 할 점으로는 HTTP 리다이렉트를 이용해 로컬 서버를 이용하도록 하는 방식의 CDN은 일단 조심하는 것이 좋다. 웹 페이지를 느리게 하는 원인이 되기 때문이다. 또한 단점으로는 다른 웹 사이트의 트래픽에 내 사이트가 영향을 받을 수 있다는 점, 콘텐츠를 담고 있는 서버를 직접적으로 제어하지 못해 가끔 불편한 점이 있다.

결론 : CDN을 실 서비스에 적용했을 때 야후쇼핑 사이트의 응답 시간은 전체적으로 20%가 향상되었다. 단지 정적인 구성요소를 CDN으로 옮겼을 뿐인데 말이다. --> CDN을 이용하라.!

Chapter 01. HTTP 요청을 줄여라.

1. 이미지 맵(Image map).

 이미지 맵 을 이용하면 웹 페이지 UI 변경 없이 HTTP 요청 수를 줄일 수 있다. 그 이유는 한 개의 이미지로 여러 개의 URL 을 연결 할 수 있기 때문이다. 이미지 맵을 사용하면 장점으로는 보통 50% 빠른 속도를 보이는데, 단점으로는 클라이언트 측 맵으로 코드를 작성 할 경우 맵의 영역 좌표를 수동으로 하는 경우 지루하고 실수하기 쉽다. 그리고 네모가 아닌 다른 모양을 만드는 것을 거의 불가능하며 연속적인 이미지여야 하는 안 좋은 점이 있다.

2. CSS Sprite.

 CSS Sprite 는 이미지 맵처럼 여러 이미지를 결합할 수 있지만 이미지 맵보다 훨씬 유연하다. 보통 CSS 의 background-position 속성을 이용해서 배경으로 사용할 부분을 잘라서 위치시킨다.  역시 분리된 이미지를 사용할 때보다 50% 빠르고 다운로드 크기가 줄어들 수 있으며(합쳐진 이미지가 컬러테이블이나 포맷정보를 하나로 가지고 있기 때문), 이미지 맵처럼 연속적인 이미지여야 한다는 제약사항도 없는 장점이 있다.

3. 인라인이미지.

 data:라는 URL 스키마를 이용함으로써 어떤 추가적인 HTTP 요청 없이 웹 페이지 안에 이미지를 포함할 수 있다. data:[<mediatype>][;base64],<data> 처럼 데이터를 첨부할 수 있으며 SCRIPT나 A 태그와 같이 URL을 지정하는 모든 곳에 사용할 수 있다. 단점은 IE 지원이 안된다는 것과 크기에 제한이 있고 base64로 인코딩을 하게 되면 이미지 크기가 커진다. 

 data:를 사용하는 좋은 방법으로는 CSS를 이용해서 배경으로 인라인 이미지를 사용하는 것이다.

4. 스크립트와 스타일시트의 결합.

 가장 이상적인 상황은 각 페이지에 하나의 스크립트와 한 개의 스타일시트가 있는 것이다. 그러나 현실은 모듈 방식의 코드를 사용하기 때문에 자바스크립트 파일을 모듈화하여 여러 파일로 나누어 놓되 이렇게 모듈화된 스크립트 파일을 사용하는 페이지에 맞게 재구성하는 빌드 과정을 두는 것이다.

chapter 0A. 앞단성능의 중요성.

성능 황금률(performance golden rule).

 최종 사용자의 응답 시간의 10~20% 만이 HTML 문서를 다운받는 데 사용되고 80~90%는 페이지 안의 모든 구성요소를 다운받는 데 사용된다.

chapter 0B. HTTP의 이해.

 http 를 통해 서버와 클라이언트가 서로 요청과 응답을 주고 받을 때 GET, POST, HEAD, PUT, DELETE, OPTION, TRACE 타입을 사용한다. 이러한 타입과 함께 http 헤더를 통해서 데이터를 압축하거나 조건부GET요청, 만료기간 설정 등으로 웹사이트 성능에 영향을 줄 수 있다.

1. Ajax 의 성능 제대로 이해하기.

  개발자들은 브라우저가 응용프로그램을 위한 플랫폼이 아니라 Script 언어와 Dom 을 사용하는 간단한 Form 으로 구성된 응용프로그램을 만드는데 사용하도록 고안되어져 있다는 것을 인지해야 한다. 웹 사이트의 응답시간을 줄이기 위해서 Ajax 를 사용하기도 하는데 흔하게 하는 실수가 응용프로그램의 모든 데이터를 브라우저로 내려 보내는 것이다. Ajax 와 Javascript, Dom 을 사용하면서 Javascript 가 bottleneck 이라고들 하지만 일반적으로 성능 저하의 원인은 Dom 에 있다. 브라우저가 Javascript 를 실행하는데 들이는 시간은 대체로 적다. 대부분의 시간은 Dom 과 관련된 곳에서 소비된다. Ajax 는 페이지를 갱신하는 데 매우 효과적이지만 브라우저와 서버 간의 올바른균형을 이루어 내도록 해야 합니다.

2. 빠른 웹 응용프로그램 만들기.

 웹페이지가 충분한 성능을 내지 못할 경우 프로파일러를 사용해 지연 시간을 측정하거나 수동으로 측정하기도 합니다. 만약 충분한 성능을 내지 못하는 부분을 찾았다면 이를 최적화 해야 하는데요. 전통적인 해결방벙으로 멀티스레드를 사용합니다. 하지만 현재 Javascript 에는 스레드가 없으며 이러한 제약에 변경도 없을 것입니다. 이런 단점을 극복하기 위해 Web Worker API, Web Worker API 를 지원하지 않는 브라우저는 구글의 Gears 를 사용하기도 합니다. XMLHttpRequest 의 비동기 모드 또한 Web Worker API 를 사용하는 것과 비슷하며 주의할 점은 XMLHttpRequest 의 동기 모드는 사용하지 않는 것이 좋습니다.

 Javascript 의 빠른 화면 렌더링도 중요하지만 메모리 사용 또한 이에 못지 않게 중요합니다. Javascript 런타임들은 GC(garbage collection)을 구현하고 있지만 이로 인해 브라우저가 주기적으로 얼어버릴 수 있습니다. 현재로서는 메모리에서 더 이상 사용되지 않은 Javascript 객체를 delete 키워드를 사용하여 해제하는 것과 DOM 에서 더 이상 필요하지 않는 노드들을 부모 노드로 removeChild() 를 호출하는 방법을 추천합니다.

3. 초반 다운로드를 분산시키기.

 Javascript 를 다운 받을 때 blocking 되니 코드를 쪼개서 다운받을 수 있도록 하며 MS 연구소에서 개발한 Doloto를 참고 하고 쪼개는데 있어서 undefined symbol(다른 함수나 변수를 참조하는 symbol) 이 없어야 할 것입니다.

 CSS 또한 Javascript 처럼 쪼개서 다운될 수 있도록 하는데 Javascript 처럼 blocking 현상은 없지만 Javascript 를 쪼갰을 때만큼 얻는 이득은 덜합니다.

4. 블로킹 없이 스크립트 로드하기.

 대부분의 브라우저들은 여러 script 들을 동시에 다운 받을 수 없었으나 최근에는 동시에 다운로드를 할 수 있게 되었습니다.(몇몇을 빼고) 그러나 script 는 동시에 다운로드 하지만 그 후에 오는리소스들은 여전히 blocking  됩니다.

ex) http://stevesouders.com/cuzillion/?ex=10008&title=Scripts+Block+Downloads

그래서 blocking 을 피하기 위한 몇 가지 방법들이 있으며 다음과 같습니다.

- XHR Eval

  - http://stevesouders.com/cuzillion/?ex=10009&title=Load+Scripts+using+XHR+Eval

- XHR Injection

  - http://stevesouders.com/cuzillion/?ex=10015&title=XHR+Injection

- Iframe 에 스크립트 넣기.

  - http://stevesouders.com/cuzillion/?ex=10012&title=Script+in+Iframe

- Script DOM Element

  - http://stevesouders.com/cuzillion/?ex=10010&title=Script+Dom+Elements

- Script Defer

  - http://stevesouders.com/cuzillion/?ex=10013&title=Script+Defer

- document.write Tag

  - http://stevesouders.com/cuzillion/?ex=10014&title=document.write+Script+Tag

위의 방법들로 blocking 을 없앴으나 scrpit 들을 순서대로 실행하고 싶거나 그 반대일 경우 문제가 발생합니다. ie 의 경우 Script Defer 기법과 document.write Script Tag 기법들을 사용하면 다운로드 순서에 상관없이 스크립트가 순서대로 실행됨을 보장받을 수 있습니다.

 - IE 실행 순서 보장.

   - http://stevesouders.com/cuzillion/?ex=10017&title=IE+Ensure+Ordered+Execution

 Firefox 의 경우에는 Script Dom Element 기법을 사용하면 됩니다. 모두 첫 번째 스크립트가 가장 마지막으로 다운로드 되지만 가장 먼저 실행됩니다.

 - Firefox 실행 순서 보장.

   - http://stevesouders.com/cuzillion/?ex=10018&title=FF+Ensure+Ordered+Execution

 다운로드 되는 대로 실행하게 하려면 XHR Eval 과 XHR Injection 기법을 사용하면 됩니다.

 - 순차 실행 피하기.

   - http://stevesouders.com/cuzillion/?ex=10019&title=Avoid+Ordered+Execution

지금 까지의 내용을 요약해 보면 하나의 최적 솔루션은 없으며 상황에 맞게 사용해야 한다는 결론을 낼 수 있습니다.

5. 비동기 스크립트와 결합시키기.

6. 인라인 스크립트를 올바르게 배치하기.

7. 효율적인 자바스크립트 작성하기.

8. 코멧을 이용한 확장.