간단한 개발관련 내용

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 12. 중복되는 스크립트를 제거하라.

한 페이지에 같은 자바스크립트를 포함시키면 당연히 성능에 좋지 않다. 누가 그런 실수를 하겠냐마는 많은 팀의 많은 사람들이 같은 페이지를 작업하게 된다면 발생할 수 있는 일이다. 

1. 스크립트 중복이 성능에 주는 악영향.

페이지 안에 같은 스크립트가 여러 번 포함될 경우 페이지가 더 느려진다.

IE에서는 스크립트를 캐시에 저장할 수 없거나 페이지가 리로드 될 경우 추가적인 HTTP 요청을 보낸다.

파이어폭스와 IE에서 스크립트를 모두 여러 번 실행된다.

2. 중복스크립트를 피하는 방법.

시스템에 자바스크립트 관리 모듈을 만든다. ...

스크립트가 한 번만 포함되어 있는지 확인하라.

Chapter 11. 리다이렉트를 피하라.

 리다이렉트를 사용자를 한 URL에서 다른 URL로 다시 보내는 것을 말한다. HTML문서 모두 요청하기도 하며, 페이지 안에서 구성요소를 요청할 때도 사용된다. 그리고 리다이렉트를 사용하는 이유는 다양하다. 리다이렉트에 대해 기억해 두어야 할 중요한 점은 리다이렉트는 페이지를 더 느리게 만든다는 점이다.

1. 리다이렉트 타입.

 웹 서버가 브라우저로 리다이렉트를 반환할 경우 그 응답은 3xx 범위의 상태 코드를 갖게 된다. 이 값은 HTTP 요청을 완수하기 위해서는 user agent 가 추가적으로 무언가를 해야 한다는 것을 나타낸다. 301,302 가 주로 사용되며 307까지 정의되어 있다. meta tag 나 document.location을 이용하여 리다이렉트 할 수 있으며, 리다이렉트를 꼭 해야 한다면 HTTP 의 3xx 상태 코드를 이용하여 처리하는 방법을 추천한다.(뒤로가기 버튼의 비활성화를 위해서-)

 - Use standard redirects : http://www.w3.org/QA/Tips/reback

 - php 의 경우 header 로 처리하면 됨.

2. 리다이렉트가 성능에 미치는 영향.

 리다이렉트가 완료되고 HTML 문서가 다운로드되기 전까지는 브라우저 화면에 아무것도 보이지 않는다. 리다이렉트를 HTML 문서 자체의 다운로드를 지연시키기 때문에 가장 안 좋다고 할 수 있다.

3. 리다이렉트의 대안.

ㄱ. 주소 뒤에 슬래시(/)를 빼는 것.

 웹 사이트에 여러 하위 디렉토리가 있고 오토인덱싱 기능을 이용한다면 웹 사이트 사용자가 원하는 페이지로 이동하기 위해 리다이렉트를  거칠 가능성이 높다고 할 수 있다. 아파치 등의 웹서버에서 리다이렉트를 피하려면 Alias로 상대주소를 사용하면 된다.

ㄴ. 웹 사이트 연결.

 Alias, mod_rewrite, DirectorySlash 는 URL 안에 추가적으로 핸들러나 파일 이름과 같은 항목이 필요하지만 간단하게 구현할 수 있다. 도메인 이름이 다르다면 CNAME을 이용해서 두 개의 호스트 이름을 하나의 같은 서버로 보낼 수 있다.

ㄷ. 내부 트래픽 추적.

리다이렉트를 이용하여 트래픽 추적을 했던 부분을 REFERER 로그를 이용하여 바꿀 수 있다. 이를 이용해서 리다이렉트를 피할 수 있고, 응답시간을 개선할 수 있다. 같은 사이트 안에서 리다이렉트 대신 REFERER 로그를 이용하는 것은 내부 트래픽을 위해서 또 사용자 응답 시간을 개선하기 위해서 시간을 들일 가치가 있는 작업이다.

ㄹ. 외부 트래픽 분석.

 사용자 트래픽을 분석할 경우, 웹 사이트 외부로 링크가 되었을 수도 있을 것이다. 이 상황에서 REFERER 를 이용하는 것은 실용적이지 못하다. 그래서 외부트래픽을 분석할 때 리다이렉트의 대안은 비콘(beacon)을 이용하는 것이다. 비콘을 사용할 때 어려운 점은 다른 페이지로 이동하려는 도중에 비콘의 요청을 보냄으로써 race condition 에 빠질 수 있다는 점이다. onload, XMLHttpRequest 를 사용하기도 하지만 target 속성을 활용하면 race condition 은 피할 수 있을 것이다.

ㅁ. 더 산뜻한 URL.

 리다이렉트 없이 좀 더 간단한 URL을 만드는 방법을 찾아야 한다. 사용자에게 추가적인 HTTP 요청을 보내게 하는 것보다 Alias, mod_rewrite, DirectorySlash 그리고 직접적인 링크코드를 이용해서 추가적인 리다이렉트를 피하는 것이 좋다.

리다이렉트를 피할 수 있는 방법을 찾아라.

Chapter10. 자바스크립트를 최소화하라.

1. 최소화(minification).

 최소화는 코드의 불필요한 문자를 줄여서 파일 크기를 줄여 로딩 시간을 개선하는 것을 말한다. 코드를 최소화하면 모든 주석뿐만 아니라 필요 없는 공백(스페이스, 개행, 탭)이 제거 된다. 자바스크립트의 경우 다운로드되는 파일의 용량이 줄어들기 때문에 응답 시간이 더 빨라진다.

2. 난독화(obfuscation).

 난독화는 소스 코드에 적용되는 최소화의 대안적인 기술이다. 난독화는 주석과공백 뿐만 아니라 코드 또한 변경하여 알아보기 힘들게 만든다. 코드 변경은 함수와 변수의 이름을 더 짧게 만들기 때문에 성능에는 도움이 되지만 읽기가 어려워지고 버그 발생 확률이 오르며, 유지보수 및 디버깅 또한 더 어렵다.

3. 얼마나 절약되는가?

 자바스크립트를 최소화하는 가장 대표적인 툴은 더글러스 크록퍼드가 개발한 JSMin 이다. 난독화의 경우 Dojo Compressor(ShrinkSafe)가 무난하며 선택의 폭이 좁다. 보통은 난독화의 위험을 감수할 만한 추가적인 이득은 없으며 100K이상의 큰 자바스크립트를 가지고 있을 경우 가끔 난독화를 적용하기도 한다. gzip을 추가할 경우 둘의 차이는 더 줄어든다.

4. 예제.

http://stevesouders.com/

5. 금상첨화.

ㄱ. 인라인스크립트.

 외부 파일 자바스크립트 뿐만 아니라 인라인스크립트 까지 최소화 하라.

ㄴ. Gzip의 최소화.

JSMin 이나  Dojo Compressor 이후 Gzip을 적용하면 큰 효과를 볼 수 있으며, 굳이 난독화 할 필요없이 최소화만으로 파일 크기의 절감의 효율성을 확인 할 수 있다.

ㄷ. CSS 의 최소화.

 CSS는 일반적으로 자바스크립트보다 공백이나 주석이 더 적기 때문에 큰 효과를 볼 수는 없지만 동일한 클래스는 합치고 사용하지 않는 것은 삭제하며 단축('#660066' 대신 '#606')을 이용하고 불필요한 문자를 제거('0px' 대신 '0')하여 최소화를 할 수 있다.

자바스크립트 코드를 최소화하라.

Chapter09. DNS 조회를 줄여라.

 DNS는 우리가 기억하기 어려운 호스트의 IP 주소를 쉽게 찾을 수 있도록 도와주고, 서버 IP가 바뀌더라도 도메인을 통해 호스트를 찾아갈 수 있도록 해 준다. 이러한 DNS 응답시간은  DNS 리졸버에 몰리는 사용량, 브라우저와 얼마나 가까이 있는가, 대역폭 속도는 얼마인 가에 따라서 달라진다. 

1. DNS 캐싱과 TTL.

 DNS 조회는 더 나은 성능을 위해서 캐시에 저장되는데 이 저장은 주기적으로 캐시에서 삭제되어야만 했고 얼마나 자주 삭제되는지는 여러 가지 설정에 의해 결정된다.

ㄱ. DNS 캐싱에 영향을 주는 요소.

 OS와 브라우저의 캐싱 그리고 HTTP 의  Kepp-Alive 의 우선순위를 고려해야 하며, DNS의 TTL값도 함께 캐싱에 영향을 주는 요소이다.

ㄴ. TTL 값.

 클라이언트가 받은 한 호스트 이름에 대한 DNS 기록의 평균 TTL값은 최대 TTL값의 반이다.

2. 브라우저 입장에서 본 DNS 조회.

ㄱ. 인터넷 익스플로어.

 ipconfig/displaydns, ipconfig/flushdns 를 통해 조회 및 초기화 할 수 있다. DnsCacheTimeout, KeepAliveTimeOut, ServerInfoTimeOut 속성이 있고 레지스트리 설정을 통해 제어 가능하며, Keep-Alive 의 역할이 중요함.

ㄴ. 파이어폭스.

network.dnsCacheExpiration, network.dnsCacheEntries, network.http.keep-alive.timeout 의 세 속성으로 제어할 수 있다.

3. DNS 조회를 줄이자.

 클라이언트의 DNS 캐시가 비어 있을 때(브라우저와 OS 둘 다), DNS조회 횟수는 해당 페이지 안에 존재하는 고유한 호스트 이름의 개수와 동일하다. 고유한 호스트 이름의 수를 줄이면 한 페이지 내에서 동시에 다운로드될 수 있는 구성요소도 줄어든다. DNS 조회를 줄이는 것과 동시 다운로드를 최대한 활용하고자 하는 좋은 절충안을 찾아야 할 것이다.

Kepp-Alive를 사용하고 도메인 수를 줄여 DNS 조회 수를 줄여라.

Chapter 08. 자바스크립트와 CSS를 외부 파일에 넣어라.

1. 외부파일 vs 인라인코드.

ㄱ. 쉽게 말하자면 인라인이 더 빠르다.

단순한 경우에 인라인이 빠르지만 중요한 포인트는 외부 자바스크립트와 CSS 구성요소가 HTML 요청 수에 비해서 얼마만큼 자주 캐시되느냐는 것이다.

ㄴ. 페이지 뷰.

사용자당 페이지 뷰가 적을 경우 인라인 자바스크립트와 CSS를 이용하는 것이 더 좋다. 반면에 사용자의 페이지 뷰가 많다면 브라우저는 캐시 안에 외부 구성요소를 보관하고 있을 경우가 많기 때문에 외부파일로 사용하는 것이 좋다.

ㄷ. 빈 캐시와 꽉 찬 캐시.

외부 파일을 사용하는 것이 좋을지 아니면 인라인으로 포함시키는 것이 좋을지 결정하기 위해서는 사용자가 얼마나 많은 외부 구성요소를 캐시에서 읽어 사용하는지를 아는 것이 중요하다. 사이트의 측정 결과 사용자가 캐시를 이용하는 비율이 더 높다면 외부 파일을 이용하는 것이 훨씬 좋다. 반면에 캐시를 사용하지 않는다면 인라인을 이용하는 것이 더 좋은 선택이 될 것이다.

ㅁ. 구성요소 재사용.

동일한 자바스크립트 또는 CSS 파일이 모든 페이지에 걸쳐 사용되는 경우도 없거니와 모든 페이지가 서로 다른 자바스크립트, CSS를 사용하는 경우도 없다는 것이다. 어느 선에서 자바스크립트오 CSS를 외부 파일로 분리하느냐에 대한 결정은 구성요소의 재사용률에도 영향을 미친다. 높은 재사용률이 가능하도록 알맞은 균형점을 찾을 수 있다면 자바스크립트와 CSS를 외부 파일로 분리하는 것이 좋다. 재사용률이 낮다면 인라인이 더 좋을 것이다.

2. 실 서비스 현장에서의 일반적인 선택.

페이지뷰, 빈 캐시와 꽉 찬 캐시, 구성요소 재사용에 의거한다면 좋은 결과를 얻을 것이다. 페이지 로딩이 반복될 때의 결과를 '인라인JS와 CSS'와 비교해 보면 헤더 만료 기간이 지나지 않은 외부 파일을 이용하는 것이 훨씬 성능이 좋음을 알 수 있다.

3. 홈페이지.

모든 홈페이지에 적용할 수 있는 한 가지 모범답안은 존재하지 않는다. 앞서 나열한 요점들은 적용할 대상 홈페이지에 맞게 평가되어야 한다. 인라인 방법이 올바른 해결방안일 경우, 외부 파일의 장점을 활용하면서도 인라인 방법을 사용할 수 있는 두 가지 기술에 대해 설명하는 다음 절이 도움이 될 것이다.

4. 두 가지 방법의 장점만을 모아서.

ㄱ. Post-Onload 다운로드.

페이지 뷰가 여럿인 홈페이지에서 가장 처음 보게 되는 페이지에는 인라인을 이용하여 자바스크립트와 CSS를 페이지에 포함시킨다. 그리고 이후에 보게 되는 페이지에서는 외부 파일을 이용하는 것이다. 이를 구현하는 방법은 첫 페이지가 완전히 로드된 후에 외부 파일을 동적으로 다운받는 것이다. 이 방법은 사용자가 추가 페이지를 볼 것이라고 예상하고 외부 파일을 브라우저의 캐시에 저장하는 것이다.

ㄴ. 동적 인라인.

홈페이지 서버가 브라우저 캐시에 구성요소가 있는지 없는지 알고 있다면 서버는 인라인을 이용할지 외부 파일을 이용할지 좀 더 최적의 선택을 내릴 수 있을 것이다. 쿠키값의 유무를 사용하여 이를 처리할 수 있으며 브라우저 캐시 상태가 일치하지 않는 경우에도 제대로 작동한다.

Chapter 07. CSS Expression 을 피하라.

CSS Expression 은 CSS 속성을 동적으로 설정하는 강력하면서 위험한 기능으로 IE5와 그 이후의 버전에서 지원된다.

1. Expression 의 업데이트.

 Expression 의 문제는 생각보다 자주 실행되어 페이지가 렌더링되거나 페이지 이벤트가 있을 때마다 동작하게 된다.

2. 이 문제를 피해서 적용하는 방법.

 CSS Expression이 한 번만 동작되도록 하는 방법과, CSS Expression 대신에 이벤트 핸들링을 이용하여 관련 있는 이벤트 시에만 동작하도록 하는 방법이 있다.

3. 결론.

 CSS Expression 과 그 영향을 명확하게 이해하지 못한 채 CSS Expression을 사용하는 것은 매우 위험한 일이다.

Chapter 06. 스크립트는 아래에 넣어라.

1. 스크립트 문제.

 스크립트의 경우 스크립트 아래에 있는 모든 구성요소의 점진적 렌더링을 막게 된다.

2. 동시 다운로드.

 응답 시간에 가장 큰 영향을 주는 것은 페이지 안에 있는 구성요속의 개수이다. HTTP/1.1 스펙에서는 한 호스트당 동시에 2개의 구성요소를 다운로드하는 것을 제안하고 있다. IE는 레지스트리에 이 값을 저장하고 있고, 파이어폭스는 about:config 페이지 안의 network.http.max-persistent-connections-per-server 설정을 통해 가지고 있다. 야후가 조사한 결과에서는 2개의 호스트 이름을 이용할 때 가장 좋은 성능을 낸다는 것을 알 수 있었다.

3. 동시 다운로드를 막는 스크립트.

 스크립트가 다운되는 동안에는 동시 다운로드가 불가능하다. 첫째로 스크립트가 document.write를 사용하면 브라우저는 응답을 기다린다. 둘째로 페이지에서 적당한 순서로 스크립트가 실행될 수 있게 하기 위해서이다.

4. 최악의 경우: 스크립트를 위에 넣는 경우.

스크립트 아래에 잇는 콘텐츠의 렌더링을 막는다.

스크립트 아래에 있는 구성요소의 다운로드를 막는다.

5. 최상의 경우: 스크립트를 아래에 넣을 경우.

 스크립트를 페이지 아래에 넣는 것이 가장 좋다. 페이지는 렌더링의 방해를 받지 않고 페이지 안에서 눈에 보이는 구성요소는 가능한 한 일찍 다운로드된다.

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요청, 만료기간 설정 등으로 웹사이트 성능에 영향을 줄 수 있다.