Whiteship's Note


[웹 사이트 속도 향상 베스트 프랙티스 10] 자바스크립트 CSS 크기 줄이기

모하니?/Coding : 2009.12.19 12:53


http://developer.yahoo.com/performance/rules.html#minify

Minify JavaScript and CSS

tag: javascript, css

크기줄이기는 로드 타임을 향상시키기 위해 코드에서 불필요한 문자를 제거하여 그 파일 크기를 줄이는 방법이다. 코드를 최소화하면 모든 주석이 제거되고 불필요한 공백(스페이스, 새줄, 탭)등이 제거된다. 그렇게 하면 자바스크립트의 경우 다운로드 할 파일 크기가 줄어들어 응답 시간 퍼포먼스를 향상시켜준다. 자바스크립트 코드를 최소화하는데 사용하는 유명한 도구 두개로 JSMin과 YUI 압축기(Compressor)가 있다. YUI 압축기는 CSS도 최소화해준다.

Obfuscation은 소스 코드에 적용할 수 있는 최적화 대체기술이다. 이것은 최소화보다 복잡하고 obfuscation 과정 자체에서 버그를 만들어 낼 가능성이 더 많다. 미국 웹 사이트 탑 10을 조사한 결과 최소화는 21% 정도 크기를 줄인 반면 obfuscation은 25%를 줄였다. 비록 obfuscation이 더 많으 크기를 줄였지만 자바스크립트 최소화를 사용하는 것이 덜 위험하다.

외부의 스크립트와 스타일시트를 최소화하는 것과 더불어 인라인 <script>와 <style> 블럭도 최소화 해야 하며 그렇게 할 수 있다.  gzip으로 스크립트와 스타일 시트를 압축하더라도, 그것들을 최소화하는 것이 5% 이상 크기를 줄일 수 있다. 자바스크립트와 CSS 사용과 크기가 증가하면서 코드 최소화로 얻을 수 있는 것도 많아지고 있다.

ps: 구글에서도 뭔가 압축기 나왔담서요?? 
top

  1. Favicon of http://blog.lckymn.com BlogIcon Kevin 2009.12.20 15:10 PERM. MOD/DEL REPLY

    구글꺼요? 혹시 Google Closure Compiler 말씀하시는건가요?
    http://code.google.com/closure/compiler/

    YUI Compressor 와의 비교 자료
    http://www.bloggingdeveloper.com/post/Closure-Compiler-vs-YUI-Compressor-Comparing-the-Javascript-Compression-Tools.aspx

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2009.12.21 07:55 신고 PERM MOD/DEL

    와우.. 저거로군요. 감사합니다.
    구글은 정말 좀 짱인듯;;

Write a comment.


[웹 사이트 속도 향상 베스트 프랙티스 9] DNS 룩업 줄이기

모하니?/Coding : 2009.12.01 13:50


http://developer.yahoo.com/performance/rules.html#dns_lookups

Reduce DNS Lookups

tag: content

도메인 네임 시스템(DNS)는 호스트네임을 IP 주소로 맵핑한다. 마치 전화부에서 사람의 이름을 그 사람의 전화번호로 맵핑하는 것처럼. www.yahoo.com을 브라우저에 입력하면, 브라우저에 연결된 DNS 리졸버(resolver) 해당 서버의 IP 주소를 룩업한다. DNS는 비용이 따른다. DNS가 해당 호스트네임으로 IP 주소를 찾는데 보통 20~120 밀리초가 소요된다. 브라우저는 DNS가 해당하는 것을 찾을 때까지 아무것도 다운로드 할 수가 없다.

DNS 룩업을 캐시해서 성능을 높인다. 이 캐싱은 사용자의 ISP 또는 LAN(로컬 지역 네트워크)에서 관리하는 별도의 캐싱 서버에서 할 수 있지만 사용자의 개인 컴퓨터에서도 캐싱할 수 있다. DNS 정보는 운영체제(OS)의 DNS 캐시에 남게된다. (마이크로소프트 윈도우는 "DNS Client service가 있다.) 대부분의 브라우저는 OS와는 별도로 그들만의 캐시를 가지고 있다. 브라우저가 DNS 기록은 자신의 캐시에 유지하는 이상, 기록을 뒤지기 위해 OS를 귀찮게 하지는 않는다.

인터넷 익스플로러(IE)는 DNS 룩업을 기본적으로 DnsCacaheTimeout 레지스트리 설정에 명시한데로, 30분간 캐시한다. 파이어폭스는 network.dnsCacheExpiration 설정에 의해 1분간 DNS 룩업을 캐시한다.(Fasterfox는 이것을 1시간으로 변경한다.)

클라이언트의 DNS 캐시가 (브라우저와 OS에서 모두) 비게되면, DNS 룩업 수가 웹 페이지에 있는 유일한 호스트네임의(unique hostname) 갯수와 동일하게 된다. 페이지의 URL, 이미지, 스크립트 파일, 스타일시트, 플래스 객체 등등에 포함되어 있는 모든걸 말한다. 따라서 호스트 네임 수를 줄이면 DNS 룩업의 수도 줄어든다.

호스트네임 수를 줄이면 잠재적으로 한 페이지에 있는 구성요소를 동시에 다운로드 할 수 있는 양이 줄어들게 된다. DNS 룩업 수는 줄어들지만, 동시 다운로드가 줄어들어 응답 시간이 증가할 수 있다. 개인적인 견해로는 2개 이상으로 컴포넌트를 나누되, 4개 이상의 호스트네임을 사용하지 말자는 것이다. 그런식으로 DNS 룩업 줄이기와 병렬 다운로드 사이의 균형을 맞출 수 있다.
top

Write a comment.


[웹 사이트 속도 향상 베스트 프랙티스 8] 자바스크립트와 CSS 외부화하기

모하니?/Coding : 2009.11.30 12:38


http://developer.yahoo.com/performance/rules.html#external

Make JavaScript and CSS External

tag: javascript, css

많은 성능관련 규칙들이 어떻게 관리중인 컴포넌트들을 외부화 하는지를 다루고 있다. 하지만, 그 전에 보다 기본적인 질문에대해 생각해봐야 한다. 자바스크립트와 CSS는 외부 파일에 들어있어야 하는가 아니면 페이지 자체에 포함되어 있어야 하는가?

실제로는 외부 파일을 사용함으로써, 브라우저가 자바스크립트와 CSS를 캐시하여 페이지 로딩 속도를 향상시킬 수 있다. HTML 문서에 들어있는 자바스크립트와 CSS는 매번 HTML 문서를 요청받을 때마다 다운로드 된다. 이렇게 하면 필요한 HTTP 요청을 줄일 수 있기는 하지만, HTML 문서 크기를 증가시킨다. 반면에, 만약 자바스크립트와 CSS를 외부 파일로 두고 브라우저가 캐시할 수 있게 하면 HTML 문서 사이즈도 줄이고 HTTP 요청 수의 증가도 없다.

그렇다면, 중요한 것은 요청되는 HTML 문서의 양에 비해 상대적으로 캐시 해야하는 자바스크립트와 CSS 컴포넌트 빈도이다. 수치화하기 어려울 수 있지만, 이 요소는 다양한 척도를 통해 계산할 수 있다. 만약 사이트의 사용자가 세션 당 여러 페이지를 요청하고 페이지의 대부분에서 동일한 스크립트와 스타일시트를 재사용한다면, 외부 파일 캐시를 통해 얻을 수 있는 잠재적인 장점이 더 크다.

대부분의 웹 사이트는 이러한 척도 중간에 놓여있다. 그러한 사이트에서 최선은 선택은 보통 자바스크립트와 CSS를 외부 파일로 배포하는 것이다. 페이지에 포함시키는 것이 더 좋을 수 있는 예외로 야후의 첫 페이지와 마이 야후 같은 홈 페이지가 있다. 홈 페이지는 세션당 페이지 뷰가 거의 없다. (대부분 하나다) 따라서 자바스크립트와 CSS를 페이지에 포함시키는 것이 최종 사용자 응답 시간을 줄일 수 있다.

여러 페이지 뷰로 연결되는 첫 페이지의 경우, 외부 파일을 통해 캐시 장점을 이용하는 것 말고도 HTTP 요청을 줄이는 기술들이 있다. 그런 기술 중 하나가 자바스크립트와 CSS를 첫 페이지에 두지만, 외부 파일을 페이지 로딩이 끝난 뒤에 동적으로 다운로드하는 것이다. 그 다음 연쇄적으로 호출되는 페이지들은 이미 브라우저의 캐시된 외부 파일을 참조할 것이다.

top

  1. Favicon of http://blog.outsider.ne.kr BlogIcon Outsider 2009.12.01 13:18 PERM. MOD/DEL REPLY

    이거 제목 잘못된듯... 지난번 제목 다시올라갔네... 8번이어야 되는데...
    css expression피하기인데 외부파일얘기나와서 먼가했는데.. ㅎㅎ

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2009.12.01 13:25 신고 PERM MOD/DEL

    호곡 감사합니다.
    제목이 넘 길어서 이전 글에서 복사해오다가 이런 일이;;
    C&P의 병폐로군요.ㅋ

    Favicon of http://blog.outsider.ne.kr BlogIcon Outsider 2009.12.01 13:37 PERM MOD/DEL

    C&P.. ㅎㅎ 은근 자주하게 되는 실수중 하나지.. ㅋ

Write a comment.


[웹 사이트 속도 향상 베스트 프랙티스 7] CSS expression 사용하지 않기

모하니?/Coding : 2009.11.25 10:56


http://developer.yahoo.com/performance/rules.html#css_expressions

Avoid CSS Expressions

tag: css

CSS expression은 CSS 속성을 동적으로 설정할 수 있는 강력(하면서도 위험)한 방법이다. IE 버전5 부터 지원되기 시작했다. 예를 들어, CSS 표현식을 사용하여 배경 색을 매 시마다 다르게 설정할 수 있다.

      background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );

여기 보시다시피, expression 메서드는 자바스크립트 표현식을 받아들인다. CSS 속성은 자바스크립트 표현식을 계산한 결과로 설정된다.. expression 메서드는 다른 브라우저에서는 무시된다. 따라서 여러 브라우저에 걸쳐 일관적인 경험을 제공하고자 할 때 IE에 속성을 설정하는 방법으로 유용하다.

expression의 문제는 사람들이 예상한 것보다 훨씬 빈번히 계산된다는 것이다. 페이지가 렌더링 되고 크기 조절이 될 때에만 계산되는 것이 아니라, 페이지를 스크롤 하거나 사용자가 페이지 위에서 마우스를 움직일떄에도 계산한다. CSS 표현식에 카운터를 추가하여 CSS expression을 얼마나 계산했는지 추적할 수 있다. 마우스를 페이지에서 움직이면 거의 10,000 번이 넘게 계산을 수행한다.

CSS expression 계산 횟수를 줄일 수 있는 방법은 딱 한 번만 expression를 수행하도록 하는 것이다. 처음 expressio을 계산할때 stype 속성을 CSS expression 대신 명시적인 값으로 교체한다. 만약 스타일 속성이 반드시 페이지가 살아있는 동안 동적으로 바뀌어야 한다면, CSS Css expression 대신 이벤트 핸들러를 사용하는것도 하나의 대안이다. 만약 반드시 Css expression을 사용해야 한다면,수 천번 계산될 거라는 것과 그로인해 페이지 성능에 영향을줄수 있다는 것을 염두하라.
top

Write a comment.


[웹 사이트 속도 향상 베스트 프랙티스 6] 스크립트를 바닦에 두기

모하니?/Coding : 2009.11.24 11:24


http://developer.yahoo.com/performance/rules.html#js_bottom

Put Scripts at the Bottom

tag: javascript

스크립트가 야기할 수 있는 문제는 병렬적인 다운로드를 막는다는 것이다. HTTP/1.1 표준은 브라우저가 호스트 이름당 두 개 이상의 컴포넌트를 병렬적으로 다운로지 하지 않도록 제안하고 있다. 만약 이미지를 여러 호스트 이름에서 제공한다면, 병렬적으로 두 개 이상의 다운로드가 발생하게 할 수 있다. 하지만, 어떤 스크립트를 하나 다운로드 할 때, 브라우저는 심지어 다른 호스트 이름에 있는 것이라 하더라도, 어떠한 다운로드도 시작하지 않는다.

어떤 상황에서는 스크립트를 바닦으로 옮기는 것이 쉽지 않을 수 있다. 예를들어, 만약 스크립트가 document를 사용하여 페이지의 내용 중 일부를 채우는 것이라면 페이지 하단으로 옮길 수가 없다. 또한 스코프와 관련된 이슈도 있을 수 있다. 대부분의 경우, 이런 상황에 대한 차선책이 있기 마련이다.

보통 자주 사용하는 차선책으로 지연된(deffered) 스크립트를 사용하는 방법이 있다. DEFER 속성은 해당 스크립트가 document.write를 가지고 있지 않다고 알려주며 브라우저가 계속해서 랜더링을 할 수 있는 단서가 된다. 불행히도, 파이어폭스는 DEFER 속성을 지원하지 않는다. IE에서는 스크립트를 지연시킬 수 있지만, 원하는 만큼은 아니다. 만약 스크립트를 지연시킬 수 있다면, 페이지의 바닦으로 옮길 수도 있을 것이다. 그렇게 하면 웹 페이지의 로딩 속도가 더 빨라질 것이다.
top

Write a comment.


[웹 사이트 속도 향상 베스트 프랙티스 5] 스타일시트를 HEAD에 넣기

모하니?/Coding : 2009.11.23 15:53


http://developer.yahoo.com/performance/rules.html#css_top

Put Stylesheets at the Top

tag: css

야후에서 성능 조사를 하는 동안, 스타일 시트를 문서의 HEAD로 옮기는 것이 페이지 로딩을 더 빠르게 해준다는 것을 발견했다. 스타일 시트를 HEAD에 놓음으로써, 페이지 랜더링이 더 빨라지기 때문이다.

성능을 고려하는 화면 엔지니어는 페이지 로딩이 빨라지길 원한다. 즉, 브라우저가 어떤 내용이던지 가능한 빨리 보여주길 원한다. 이것은 느린 인터넷 연결을 사용하는 사용자와 보여줄 내용이 많은 페이지에서 특히 중요하다. 진행 상태 표시와 같은 시각적인 피드백을 주는 것의 중요함에 대해서는 설문조사가 잘 되어 있고 잘 문서화 되어 있다. 우리의 경우 HTML 페이지가 곧 진행 상태 표시기이다! 브라우저는 페이지 헤더를 빠르게 로딩할 때 네비게이션 바, 화면 윗 부분의 로고 등 모든 시각적인 피드백을 해당 페이지를 기다리는 사용자에게 제공한다. 그런식으로 전반적인 사용자 경험을 향상시킬 수 있다.

스타일시트를 문서의 바닥으로 넣는 것의 문제는 IE를 포함한 대부분의 브라우저에서 빠른 랜더링을 방해하기 때문이다. 이들 브라우저는 문서의 스타일이 바뀌면 페이지의 요소들을 다시 그려야 하는 것을 방지하기 위해 랜더링을 막아둔다. 그 때 사용자는 하얀색의 빈 화면에 머물러 있게 된다.

HTML 표준은 분명히 스타일시트를 페이지의 HEAD에 포함시킬 것을 기술하고 있다. "[LINK]는 얼마나 많이 있던 문서의 HEAD 부분에만 있어야 한다." 그 어떠한 대안도 비어있는 하얀 화면이나 스타일이 없는 내용으로 채워진 플래시 등의 위험을 감당할 만한 가치가 없다. 최적의 해결책은 HTML 표준을 따라 스타일시트를 문서 HEAD 안에서 로딩하는 것이다.
top

  1. 처루 2009.11.24 08:38 PERM. MOD/DEL REPLY

    반면 스크립트는 바닥으로 보내는 것이 유용하다는 말도 들었어요.

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2009.11.24 10:51 신고 PERM MOD/DEL

    네 맞습니다. 그 내용이 오늘 정리할 내용입니다.ㅋ

Write a comment.


[웹 사이트 속도 향상 베스트 프랙티스 4] 컴포넌트 압축하기(Gzip Components)

모하니?/Coding : 2009.11.19 13:02


http://developer.yahoo.com/performance/rules.html#gzip

Gzip Components

tag: server

HTTP 요청과 응답을 네트워크로 전송하는데 걸리는 시간을 화면 개발자들과의 논의를 통해 극적으로 줄일 수 있다. 물론 최종 사용자의 인터넷 속도는 개발 팀과 관계없는 인터넷 서비스 제공처와 접근하려는 곳과의 거리에 따라 달라지기는 한다. 하지만 그 외밖에도 응답 시간에 영향을 주는 변수들이 있다. 압축을 기용하면 HTTP 응답의 크기를 줄여서 응답 시간을 빠르게 할 수 있다.

HTTP/1.1 부터, 웹 클라이언트는 HTTP 요청의 Accept-Encoding 헤더를 사용하여 압축 형태를 지원한다는 것을 알려줄 수 있게 되었다.

      Accept-Encoding: gzip, deflate

만약에 웹서버가 요청에 들어있는 이 헤더를 본다면, 응답을 클라이언트가 나열한 방법으로 압축할 수가 있다. 웹 서버는 웹 클라이언트에게 응답의 Content-Encoding 헤더를 사용하여 사용한 방법을 알려준다.

      Content-Encoding: gzip

Gzip은 근래 가장 유명하고 효율적인 압축 기술로, GNU 프로젝트에 의해 만들어졌으며 RFC 1952로 표준화 되었다. 다른 압축 기술중 여러분이 보고 싶어하는 것으로 deflate가 있지만 Gzip에 비해서 덜 효율적이며 덜 알려져있다.

Gzip 압축은 응답의 크기를 약 70% 가량 쥴여준다. 아마도 근래의 브라우저를 떠돌고 있는 인터넷 트래픽 중 90%는 gzip을 지원한다고 선언해 두었을 것이다. 만약 아파치를 사용하고 있다면, gzip 모듈 설정 방법은 버전에 따라 다르다. 아차피 1.3은 mod_gzip을 사용하고 아파치 2는 mod_deflate를 사용한다.

브라우저와 프록시를 사용할 때 브라우저가 예상한 것과 실제로 압축하여 받은 내용이 일치하지 않는 이슈가 있다. 다행히도, 구 버전 브라우저 사용이 점차 줄어듬에 따라 그런 이슈도 줄어들고 있다. 아파치 모듈은 Vary 응답 헤더를 사용하여 자동으로 적절한 타입을 찾도록 도와준다.

서버는 파일 타입에 따라 무엇을 gzip으로 압축할지 선택하지만, 실제로 무엇을 압축할지 결정한 것을 보면 매우 제한적이다. 대부분의 웹 사이트는 그들의 HTML 문서를 gzip으로 압축한다. 스크립트와 스타일시트도 압축할 만한 가치가 있는데 대부분의 사이트는 이것을 간과한다. 사실, 응답에 들어가는 모든 XML, JSON, 이미지, PDF 파일 등은 압축하지 말아야 한다. 이미 압축되어있는 형태기 때문이다. 그것들을 압축하는 것은 CPU를 낭비하는 것일 뿐 아니라 잠재적으로 파일 사이즈를 늘리는거나 마찬가지다.

Gzip으로 가능한 많은 타입을 압축하는 것은 페이지의 무게를 줄이고 사용자 경험을 가속화하는 쉬운 방법이다.


top

Write a comment.


[웹 사이트 속도 향상 베스트 프랙티스 3] Expires 또는 Cache-Control 헤더 추가하기

모하니?/Coding : 2009.11.18 16:34


http://developer.yahoo.com/performance/rules.html#expires

Add an Expires or a Cache-Control Header

tag: server

이 규칙에는 두 가지가 있다.

* 정적 컴포넌트인 경우: 아주 긴 시간으로 Expires 헤더를 설정하여 "Neber expire" 정책을 구현한다.
* 동적 컴포넌트인 경우: 적절한 Cache-Control 헤더를 사용하여 브라우저를 도와준다.

웹 페이지 디자인은 점점 더 풍부해지고 있다. 즉 보다 많은 스크립트, 스타일시트, 이미지, 플래시가 페이지에 들어간다는 것이다. 여러분 페이지를 처음 방문하는 사용자는 아마도 몇 개의 HTTP 요청을 보내야 할 것이다. 하지만 Expires 헤더를 사용하여 그런 컴포넌트들을 캐시가 가능하도록 설정할 수 있다. 이렇게 하면 연속하여 페이지를 참조할 때 불필요한 HTTP 요청을 줄일 수 있다. Expires 헤더는 대부분 이미지에 자주 사용하지만, 스크립트, 스타일시트, 플래시 컴포넌트를 포함한 모든 컴포넌트에도 활용할 수 있다.

브라우저(와 프록시)는 캐시를 사용하여 HTTP 요청과 사이즈를 줄이고, 웹 페이지 로딩 속도를 높인다. 웹 서버는 Expires 헤더를 HTTP 응답에 사용하여 클라이언트가 얼마나 오래 컴포넌트를 캐시할지 알려준다. 다음은 아주 오래동안 캐시를 보관하도록 설정한 Expires 헤더이다. 브라우저에게 이 응답은 2010년 4월 15일까지 변하지 않을꺼라고 알려준다.

      Expires: Thu, 15 Apr 2010 20:00:00 GMT

만약 여러분의 서버가 아파치라면, ExpiresDefault 지시자를 사용하여 현재 시간 기준으로 상대적인 만료 날자를 설정하라. 다음 예제는 만료 날짜를 요청을 받은 시점 부터 10년 뒤로 설정하는 ExpiresDefault 지시어다.

      ExpiresDefault "access plus 10 years"

명심해야 할 것이 있다. 만약 아주 오래 살도록 Expried 헤더를 사용한 경우에는 컴포넌트를 변경할 때 마다 반드시 컴포넌트의 파일이름을 변경해 주어야 한다. 야후에서는 이런 작업을 빌드 과정 중 하나로 만들어 사용한다. 컴포넌트의 파일 이름에 버전 넘버를 명시해주는 것이다. 예를 들어 yahoo_2.0.6.js 처럼.

아주 오래 캐시를 유지하도록 설정한 Expires 헤더는 이미 여러분의 사이트를 방문했던 사용자가 보는 페이지에만 적용된다. 사이트를 처음 방문하는 사용자의 HTTP 요청이거나 브라우저의 캐시가 비어있는 경우에는 아무런 영향이 없다. 따라서 이런 성능 개선의 효과는 사용자가 어느정도 '준비된 캐시'를 가지고 페이지를 얼마나 자주 방문하느냐에 달려있다. ('준비된 캐시'에는 페이지의 모든 컴포넌트를 이미 가지고 있다.) 우리는 야후에서 이것을 측정했고 그 결과 준비된 캐시를 가지고 방문하는 페이지 뷰의 수가 75~85%에 달한다는 것을 발견했다. 아주 왜 캐시를 유지하는 Expires 헤더를 사용함으로써, 브라우저가 캐시할 컴포넌트 수를 늘리고 연쇄적으로 페이지를 볼 때 사용자 인터넷 연결에 한 바이트로 보내지 않을 수 있다.

참조: http://www.mnot.net/cache_docs/
top

Write a comment.


[웹 사이트 속도 향상 베스트 프랙티스 1] HTTP 요청 최소화 하기

모하니?/Coding : 2009.11.16 18:46


참조: http://developer.yahoo.com/performance/rules.html#num_http

HTTP 요청 최소화하기(Minimize HTTP Requests)

tag: content

사용자 응답 시간 중 80%가 브라우저 단(front-end)에서 소요된다. 이 시간 중 대부분이 페이지의 모든 컴포넌트들(이미지, 스타일시트, 스크립트, 플래시 등)을 다운로드 하는데 소요된다. 컴포넌트의 갯수를 줄이면 페이지를 랜더링하는데 필요한 HTTP 요청의 수도 줄어들게 된다. 바로 이것이 페이지 로딩 속도를 높이는 핵심이다.

화면에 있는 컴포넌트의 수를 줄이는 한가지 방법은 페이지의 디자인을 단순하게 만드는 것이다. 하지만 꽤 복잡한 컨텐츠로 구성되어 있는 페이지를 만들 때도 빠른 응답 속도를 보장할 수 있는 방법은 없을까? 이제부터 풍요롭게 디자인된 페이지를 지원하면서도 HTTP 요청을 줄이는 기술을 몇 가지 살펴보자.

묶음 파일(Combined files)이란 모든 스크립트를 하나의 스크립트로 묶고, 그와 비슷하게 모든 CSS를 하나의 스타일시트로 묶어서 HTTP 요청을 요청을 줄이는 방법이다. 묶음 파일은 페이지 마다 필요한 스크립트와 스타일시트가 다를 때 좀 더 도전적인 과제가 될 수 있지만, 이러한 것을 배포 절차 중 하나로 만든다면 응답 시간을 줄일 수 있다.

CSS Sprites는 이미지 요청 수를 줄일 때 선호하는 방법이다. 배경 이미지들을 하나의 단일 이미지로 묶고 background-image와 background-position 속성을 사용해서 이미지의 일부를 보여주는 것이다.

Image map은 여러 개의 이미지 파일을 하나의 이미지로 만든다. 전체 사이즈는 거의 같겠지만, HTTP 요청의 수가 줄어들어 페이지 로딩 속도가 빨라진다. 이미지 맵은 네비게이션 바와 같이 연속적으로 나타나는 이미지 일 때 적합하다. 이미지 맵의 좌표를 정의하는 것은 매우 지루하고 오류를 범하기 쉬울 것이다. 이미지 맵을 사용하여 네비게이션을 하는 것 또한 적용하기 쉽지 않다. 따라서 권장하는 방법은 아니다.

인라인 이미지(inline image)는 data: URL 스키마를 사용하여 이미지 데이타를 실제 페이지에 첨부한다. 이렇게 하면 HTML 문서의 크기가 늘어난다. 인라인 이미지를 (캐싱을 사용하는) 스타일시트에 넣는 방법으로 HTTP 요청을 줄이고 문서 크기가 늘어나는 것을 방지할 수 있다. 하지만 아직 인라인 이미지를 모든 주요 브라우저에서 지원하고 있지는 않다.

페이지에 필요한 HTTP 요청을 줄이는 것부터가 시작이다. 특히 이것은 첫 방문자를 위한 성능 향상에서 가장 중요한 가이드라인이다.  Tenni Theurer의 블로그 글 Browser Cache Usage - Exposed!에 따르면, 매일 여러분의 사이트 방문자 중 40~60%는 캐시가 비어있는 상태에서 찾아온다. 처음 방문하는 유저를 위해 페이지 로딩 속도를 높이는 것은 더 나은 사용자 경험에 있어서 핵심이다.
top

  1. Favicon of http://blog.lckymn.com BlogIcon Kevin 2009.11.17 12:35 PERM. MOD/DEL REPLY

    아니면 아예 HTTP 프로토콜을
    웹환경에서 더 빠른 속도를 낼수 있는 다른 프로토콜로
    바꿔 버리는 방법도 있겠죠... :)

    http://blog.chromium.org/2009/11/2x-faster-web.html

    http://dev.chromium.org/spdy/spdy-whitepaper

    http://dev.chromium.org/spdy/spdy-protocol

    Favicon of http://whiteship.me BlogIcon 기선 2009.11.17 13:11 PERM MOD/DEL

    허곡;; 이건 또 뭔가요.
    SPeeDY~ 구글에서 만든 '빠른' 프로토콜 인가 보군요.

    Favicon of http://blog.lckymn.com BlogIcon Kevin 2009.11.17 13:36 PERM MOD/DEL

    네, 구글에서 HTTP를 대체할 프로토콜로 내놓은 녀석이죠.
    HTTP는 큰 파일 하나를 전송하기에는 좋은데, 현재의 웹처럼 작은 파일들을 여러개 보내는데는 성능이 형편없다는걸 감안해서 이에 적합한 프로토콜을 만드는 모양입니다.
    표준으로 체택이 될지 안 될지는 모르겠지만, 더 나은걸 사용할수 있다면 좋지 않을까 합니다.

    그나저나 구글은 최근에 GO 라는 프로그래밍 언어도 만들고,
    (보니까 거의 C++과 Python 을 대체할 언어로 만든거 같습니다).
    OS도 만들고, 프로토콜도 만들고...

    하드웨어 제조 빼고는 안 하는게 없는거 같네요. :)

    Favicon of http://whiteship.me BlogIcon 기선 2009.11.17 15:13 PERM MOD/DEL

    그러네요. 정말 세계 정복을 하려는 듯;;

Write a comment.