간단한 개발관련 내용

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를 페이지에 포함시킨다. 그리고 이후에 보게 되는 페이지에서는 외부 파일을 이용하는 것이다. 이를 구현하는 방법은 첫 페이지가 완전히 로드된 후에 외부 파일을 동적으로 다운받는 것이다. 이 방법은 사용자가 추가 페이지를 볼 것이라고 예상하고 외부 파일을 브라우저의 캐시에 저장하는 것이다.

ㄴ. 동적 인라인.

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