SlideShare ist ein Scribd-Unternehmen logo
1 von 83
Best Practices for Speeding Up Your Web Site  디자인실UI Dev 이선실, 김수성
The important of Front-end Performance
Downloading (http://www.yahoo.com) in IE : empty cache Back-end =5% Front-end = 95%
Downloading (http://www.yahoo.com) in IE : primed cache Even here, front-end= 95%
Downloading percentage * Percentage of time spent downloading the HTML document for 10 top web site
Downloading percentage 보통 웹사이트에서 Html 문서를 웹 서버로부터 다운(Back-end) 받는데  소요되는 시간은 10~20%이다. 그 외 80~90%는 Html에서 사용되는 components를 다운(Front-end)받는데 소요된다. *단, cache된 상태의 Google은 제외된다.   Google은 오직 6개의 components만 가지고 있기 때문에 front-end에 소요되는 시간이 길지 않다.
How can response time be reduced? 첫 번째, Front-end에 Focus 하면 response time을 줄이는데 더욱 효과적 ,[object Object]
Front-end를 50% 줄일 경우 : 전체의 40~45% 감소두 번째, Front-end에서 작업할 경우, Back-end에서 작업할 때 보다더 적은 시간과 더 적은 resource가  필요. 세 번째, 여러 프로젝트 경험을 바탕으로, 보통 25% or 그 이상의 response time을 줄일 수 있다.
Rule 1. Make Fewer HTTP Requests
Minimize HTTP Requests End-userresponse time의 80%를 front-end단에서 차지한다. 이 response time의 대부분은 페이지내에서 사용되어지는 components -Images, Stylesheets, Scripts,  Flash 등- 를 다운로드 하는데 소요된다. 여기서 component의 수를 줄이는 것이 HTTP request를 줄이는 하나의방법이며, 빠른 웹 페이지 만들기의 중요 포인트라고 할 수 있다. Component의 수를 줄이기 위해 페이지 설계를 간단하게 할 수도 있지만 사용자가 필요로 하는  많은 양의 contents를 보여주면서 response time을 줄일 수 있는 방법을 사용하는 것이 더  효과적이라고 할 수 있다. 여기서 HTTP request 수를 줄이는 몇 가지 방법을 알아보자.
Combined files HTTP request 수를 줄이기 위해서사용되어진 모든 Script를 하나의 Script로 통합하고,  이와 같이 CSS도 하나의 Stylesheet로 통합한다. 이러한 방법은 각 페이지 마다 다르게 사용해야 할 때 문제가 될 수도 있겠지만 작업 시 하나의 과정으로  포함시킨다면 response time을 줄일 수 있을 것이다. ex) <link rel="stylesheet" type="text/css“ ref="http://i.kthimg.com/search/css/sch_layout.css"> <link rel="stylesheet" type="text/css“ ref="http://i.kthimg.com/search/css/sch_result.css">  <link rel="stylesheet" ype="text/css“ ref="http://i.kthimg.com/search/css/sch_prn.css"> <link rel="stylesheet" ype="text/css“ ref="http://i.kthimg.com/search/css/sch_1.0.css">
CSS Sprites 페이지 내에 사용된 Background image의 request 를 줄이기 위해 쓰이는 방법이다. 작고 간단하고 반복 되어 지지 않는 Background image들을 하나의 이미지로 합치고 css의background-image와 background-position 속성으로 필요한 부분만 보여준다. ex) .mre a{background:url(http://i.kthimg.com/search/img/bg_ic.gif) 0 1px no-repeat;}
Image Maps 여러 개의 연속적인 이미지에 링크를 걸어야 할 때 사용한다. 이미지의 전체 사이즈는 거의 같지만 HTTP request가 줄어들어 페이지 로딩 속도는 빨라지나좌표 지정이  쉽지 않고 에러를 유발하기 쉽다. 그리고 이미지맵은접근성이 부족하기 때문에 navigation bar에는 사용하지 않는 것이 좋다. ex) Example 1 - No Image Map이미지맵을 사용하지 않았을 때  Example 2 - Image Map이미지맵을 사용했을 때
Inline image (data:URL scheme) data:URL scheme를 이용해서 실제 페이지에 이미지를 넣는다. 이것은 HTML 문서의 크기를 증가시킬 수 있지만 HTTP request를 감소시키고 페이지 사이즈 증가를  막을 수 있다.  data:[<mediatype>][;base64],<data> 단, 이 방법은 글자수 제한이 있고 모든 브라우저에서 지원되지 않는다. ex) <IMG BORDER=1 SRC="data:image/gif;base64, R0lGODdhMQAiAPcAAP////f39+/……….">
Rule 2. Use a CDN(Content Delivery Network)
Use a CDN 일종의 캐시 역할을 할 수 있도록 전체 network 상에 동일한 contents 내용을 복제하여, 대규모 인트라넷  또는 인터넷상에 분산시켜 놓은 시스템. 인터넷 이용자의 증가와 멀티미디어 등 대용량 contents에 대한 수요의 증가로 인해 데이터 트래픽은  기하급수적으로 늘어나는 데 비해 Middle-Mile이라 불리는 네트워크간 연결구간에 대한 투자는 이에 미치지  못해 결과적으로 인터넷은 트래픽의 정체현상, 즉 병목현상이 발생하게 되었다. 이러한 현상을 해결하기 위한 방법이 Content Delivery Network이다. CDN은 기간망과 가입자망간의 연결을 물리적인 망의 증설을 통해 개선하는 것이 아니라 병목현상의 대상인  데이터 트래픽, 즉 Contents를 인터넷 네트워크의 주요지점으로 분산시킴으로써 해결하는 것이다. CDN은 사용자의 콘텐츠 요구에 가장 빠르게 연결이 가능한 네트워크를 중계해 주고 contents를 전송해 준다. Contents가 복제되어 특정 국가 또는 전세계에 걸쳐 분산 배치되면, 사용자들은 그것이 하나의 웹사이트에  있을 때보다 훨씬 더 빠르게 액세스할 수 있게 된다. Akamai와 같은 contents 전달 조직, 전국의 커버할 수 있는 대규모 ISP, 또는 대기업 등에 의해 제공 된다
Use a CDN ,[object Object],분산 노드와GLB를 통한 최적의 전송경로 제공 인터넷 사용자를 위한 최고의 전송속도 보장    ,[object Object],트래픽 폭주로 인한 성능 저하 방지 동기화를 통해 최신 콘텐츠를 안전하게 전송   ,[object Object],사용량을 기준으로 한 종량제 요금체계 초기 인프라 투자비용 및 IT 운영비용 절감    ,[object Object],예상치 못한 트래픽 증가 해결  전세계 40개 Server Farm, 300Gbps의 네트워크 인프라활용 (2007년 9월 기준)
Rule 3. Add an Expires or a Cache-Control Header
Add an Expires or a Cache-Control Header  브라우저 캐시를 위해 Expires Date 와 Cache Control 추가
Rule 4. Gzip Components
Gzip Components Gzip은 국제 표준으로 등록된 무료 압축 포맷이다.  브라우저는 자신이 압축을 해제할 수 있는 압축 포맷을 HTTP 헤더 Accept-Encoding의 속성을 이용해서  전달하는데이 때 서버는 이 속성을 확인하여 본문을 압축할 수 있다.  (RFC1952) 이 기술은 현재 가장 많이 사용하고 있고 그만큼 성능도 좋다. 이미지 등 이미 압축처리가 된 파일에는 효과가 없으므로  html, js, css같은 텍스트 파일에만 Gzip을 적용한다. 또한 용량이 적은 파일을 압축하면 전달되는 속도보다 압축을 적용하고 푸는 시간이 더 걸릴 수 있고 압축 적용 시 서버와 클라이언트의 CPU 리소스를 불필요하게 소비하게 된다. 기본적으로 웹 IIS서버는Gzip이나 deflate 압축을 지원하지 않으므로 따로 처리한다.
Rule 5. Put Stylesheets at the Top
Put Stylesheets at the Top  1 / 2 Stylesheet는 항상 head에 넣는다. 그렇게 되면 페이지 랜더링이 더 빨라지기 때문에 로딩속도가 향상 된다. 웹 페이지 내용에 상관없이 가능한 한 빨리 로딩이 되기를 원하기 때문에 많은 내용의 contents를 가진  페이지와 느린 인터넷을 사용하는 사용자에게 특히 중요하다. 문서의 아래에 stylesheet를 넣게 되면 요소를 다 불러온 후에 다시 위에서부터 style을 입히게 된다. 그 과정에서 IE등의 브라우저에서는 마지막 style이 로딩 될 때까지 랜더링을 멈추고 있다가 style이 로드 된 후 랜더링을 한다. 이 과정에서 사용자들은 아무것도 없는흰 페이지를 보게 되는 문제가 발생하게 된다. html 표준에서도 stylesheet를 페이지의 head에 넣기를 권장하고 있다.
Rule 6. Move Scripts to the Bottom
Move Scripts to the Bottom 1 / 2 스크립트 실행에 지연이 걸려 페이지가 늦게 오픈 되는 걸 방지하기 위해 하단에 두어야 한다.
Rule 7. Avoid CSS Expression
Avoid CSS Expression 1 / 2 CSS expression은 다이나믹한 css속성을 지원하는 것으로 강력하지만 위험한 방법이다. 예를 들어 CSS expression을 사용하여 background color를 매 시간 별로  번갈아 가며 보여지게 설정할 수 있다. background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" ); 여기서 보다시피, expression method로 JavaScript expression에 접근할 수 있다.  CSS 속성은 JavaScript  expression의 계산 결과로 설정된다.  Expression method는 IE -IE5부터 지원된다- 외 다른 브라우저에선 작동이 안되므로 IE에서 다른 브라우저와  일관된 기능을 지원하기 위해 사용한다. 이 expression의 문제는 예상보다 훨씬 자주 실행된다는 데 있다.  페이지가 rendering 되고 resize 될 때에만 실행되는 것이 아니라 스크롤을 움직일 때나 페이지 위에서 마우스를 움직일 때에도 실행 된다.
Avoid CSS Expression 1 / 2 Expression 카운터 http://stevesouders.com/hpws/expression-counter.php (CSS Expression이 동작  할 때마다 카운트 계산) 그 방법을 해결 하기 위한 방법 중 하나는 expression이 한번만 실행되게 제한하는 것이다. 만약 유동적인 페이지에 expresstion을 줘야 한다면 event handler로 대체하는 것도 좋은 방법이다. CSS expresstion을 사용해야 할때에는 이러한 문제들을 충분히 생각한 후에 꼭 필요한 경우에만  적용하도록 한다.
Rule 8. Make JS and CSS external
Make JS and CSS external 1 / 2 JavaScript와 CSS를 외부 파일로 불러오게 되면 browser에 의해 캐싱이 되기 때문에 일반적으로 더 빠르게  페이지를 출력한다. HTML 문서에 inline 형식으로 존재하는 JavaScript와 CSS는 HTML 문서가 요청될 때마다 매번 다운로드 하는데 그렇게 되면 HTTP request 수는 감소할지 모르겠지만 HTML 문서의 크기는 늘어나게 된다. 반면에, JavaScript와 CSS가 브라우저에 의해 외부 파일로 캐싱이 된다면 HTML 문서의 크기는 request 수를  증가시키지 않으면서 감소하게 된다. 여기서 중요한 점은 HTML 문서의 수와 외부 JavaScript, CSS의 요청 빈도이다. 어느 웹사이트에서 사용자들이 여러 페이지를 방문하고 그 페이지들이 동일한 JavaScript와 CSS를 사용하고  있다면 외부 파일로 캐싱 되게 하는 것이 좋다. 만약 페이지 뷰가 적거나 한정된 곳에만 적용이 되어야 하는 경우라면 JavaScript나 CSS를 inline화하는 것이  응답 속도가 더 빠르다.
Make JS and CSS external 1 / 2 많은 페이지로 연결되는 front page 같은 경우는 외부파일 캐싱 이라는 장점과 inline의 HTTP request 감소를  같이 사용할 수 있다.  Front page에서 사용할 JavaScript와 CSS는 inline으로 넣어 놓고 페이지가 로딩을 마친 후에 동적으로  외부 파일을 다운로드 한다.  그러면 그 후의 페이지들은 캐싱 되어 있는 외부 파일을 참조하게 되어 로딩 속도가 빨라질 것이다.
Rule 9. Reduce DNS Lookups
Reduce DNS Lookups 1 / 2 일반적으로 해당 호스트에 대한 IP 주소를 조회하려면 DNS에 20-120 micro sec 정도 걸리므로  Image/JS/CSS 링크의 Domain 수를 최소화해야 한다.
Rule 10. Minify JavaScript and CSS
Minify JavaScript and CSS 1 / 2 JavaScript와 CSS의 최소화는 모든 주석을 제거하고 불필요한 공백(space, newline, and tab)을 제거 함으로써  코드의 사이즈를 줄여 로딩 속도가  빨라지게 한다.  그렇게 되면 JavaScript의 경우 다운로드 되는 파일의 사이즈가 감소 하기 때문에 속도가 향상된다. 자바스크립트를 최소화 해주는 툴 중 잘 알려진 프로그램에는 JSMin와 YUI Compressor가 있는데,  그 중 YUI compressor로는 CSS 파일도 최소화 할 수 있다. Obfuscation(난독화,암호와)는 코드 압축에 최적화 된 대체 기술로써 소스 코드 중에서 가장 중요한 멤버나  메소드의 이름을 짧고 무의미한 것으로 대체해 다른 사람이 도용하거나 가져다 쓰는걸 막아준다.  미국 Top10 웹사이트 조사 결과를 보면 최소화 한 파일은 크기가 21% 감소한것에 비해 Obfuscation 한 파일은 25%가 감소하여 보다 뛰어난 성능을 보여주고 있다. 그러나 방법이 훨씬 복잡하고 압축도중 스크립트 오류를 발생시킬 위험이 있으며 사실상 응답속도에 별 영향을 미치지 못하므로 단순히 최소화 시키는 것이 더 효과적이라고 볼 수 있다. ex) varpserson; -> var AB
Minify JavaScript and CSS 1 / 2 외부 Script와 CSS파일과 마찬가지로 inline으로 들어가 있는 Script와 CSS도 최소화가 가능하다. Gzip (웹 서버에서 사용자 브라우저로 갈 때만 html파일을 압축해주는 서버모듈)을 통해서 압축한 후라도  Script와 CSS를 최소화를 하게 되면 적어도 5%이상 사이즈를 더 감소 시킬 수 있다.
Rule 11. Avoid Redirects
Avoid Redirects 1 / 2 Redirect 동안에는 다른 작업을 시작할 수 없다 http://www.paran.com/test ( 301 redirect 됨) http://www.paran.com/test/ 디렉토리일경우/ 까지 기입
Rule 12. Remove Duplicates Scripts
Remove Duplicates Scripts 1 / 2 request 를 줄이기 위해  개발자의 실수로 인한 중복 기술된 스크립트 줄인다. 실제 같은 external js를 여러번 호출하면 호출한 만큼 request 된다.
Rule 13. Configure ETag
Configure ETag Compare 1 / 2 웹서버와 브라우저가 캐시 된 구성요소들의 유효성을 확인하기 위해서 사용하는 메커니즘. 브라우저의 캐시된 파일의 유효하면 [304 Not Modified] 발생시킨다. 유효하지 않으면 서버에서 파일을 받아 [200 OK] 발생한다. HTTP Request Server Browser Disk Read Cache Download 200 OK 304 Not Modified Last-Modified ETag
Configure ETag 1 / 2 	GET /i/yahoo.gif HTTP/1.1 	Host: us.yimg.com 	-------------------------------------------------------> 	HTTP/1.1 200 OK Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT ETag: "10c24bc-4ab-457e1c1f" 	Content-Length: 12195 	-------------------------------------------------------> 	GET /i/yahoo.gif HTTP/1.1 	Host: us.yimg.com If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT If-None-Match: "10c24bc-4ab-457e1c1f" 	-------------------------------------------------------> 	HTTP/1.1 304 Not Modified Request Response Request Response
Configure ETag 1 / 2 출처 http://support.microsoft.com/kb/922703/ http://www.apacheweek.com/issues/02-01-18 http://firejune.com/1151
Rule 14. Make Ajax Cacheable
Make Ajax Cacheable 1 / 2 Ajax 통신시 캐쉬 기능을 구현
Rule 15. Flush the Buffer Early
Flush the Buffer Early 1 / 2 버퍼링을 사용함으로써 완료된 html 이 아닌 사용자가 원하는시점에 출력을 지정할 수 있으므로 브라우저의  대기 시간이 줄어든다.
Rule 16. Use Get for Ajax Requests
Use Get for Ajax Requests 1 / 2 Ajax 사용할때는GET Method 가 빠르다. POST 는 XMLHttpRequest사용시 header 를 보낸 후 data 를 보내는 두 가지 step 으로 되어있어서 GET 보다  느리다.
Rule 17. Post-load Components, Preload Components
Post-load Components, Preload Components 1 / 2 페이지가 열릴 때 필요한 구성요소와 onload후에 필요한 구성요소를 구분하여 페이지 렌더링을 빠르게  구현하기 위해 구조화 작업이 필요.
Rule 18. Reduce the Number of DOM Elements
Reduce the Number of DOM Elements 1 / 2 Dom 구조를 간략하게 해야 한다.
Rule 19. Split Components Across Domains
Split Components Across Domains 1 / 2 web페이지를 구성하는 요소들의 호스트를 분산하면 빨라질 수 있다. ex) css/js/img
Rule 20. Minimize the Number of Iframes
Minimize the Number of Iframes 1 / 2 Iframe은 html 문서를 다른 html문서에 삽입 하는 기능이다. Iframe은 광고나 배너등 외부 컨텐츠를 불러오거나, doc type등이 다른 html 문서를 한 화면에서 보여줘야  할 때 유용하다. 그러나 아무 내용이 없어도 트래픽이 발생하고 request가 증가하게 되므로 꼭 필요할 때만 사용하는 것이 좋다. iframe안에 css/js등이 parent 와 같이 있어도 다시 request 됨으로 주의해야 한다.
Rule 21. No 404s
No 404s 1 / 2 불필요한 404 not found 페이지를 제거한다.
Rule 22. Reduce Cookie Size
Reduce Cookie Size 1 / 2 불필요한 쿠키를 제거. 해당 도메인순 Expire 날짜 지정
Rule 23. Use Cookie-free Domains for Components
Rule 24. Minimize Dom Access
Minimize Dom Access 1 / 2 Javascript로 Dom요소에 접근하는 것은 페이지 응답속도를 느리게 한다. 그러므로 Dom Element 구조를 Cache 하여 사용하는 것이 좋다. 접근 할 때마다 Dom syntax 로 쓰지 말고 변수에 할당해서 쓰도록 한다.
Rule 25. Develop Smart Event Handlers
Develop Smart Event Handlers 1 / 2 각각의 Dom element 에 이벤트를 거는것 보다는 상위 Element 이벤트를 걸어 하나의 이벤트로 처리하고  하위 element 속성으로 처리 하는 게 좋다.
Rule 26. Choose <link> over @import
Choose <link> over @import 1 / 2 <link>는 하위 브라우저까지 모두 지원되고 @import는 최신 브라우저만 지원하기때문에 구 버전의 CSS 버그를 피하기 위해서 @import를 쓰기도 한다. 하지만 @import를 쓰면 <link>를 bottom에 둔 것과 같은 결과를 초래하기 때문에 사용하지 않는 것이 좋다. 또한 @import는 이미지보다 CSS를 늦게 불러오기 때문에 속도 향상에 좋지 않은 영향을 끼친다. 더 자세한 내용 http://seye2.egloos.com/2319809
Rule 27. Avoid Filters
Avoid Filters 1 / 2 IE 전용 filter인 AlphaImageLoader는 ie7 이하 버전에서 png반투명 이미지를 쓸 수 있도록 해준다. 그러나 이 filter를 사용하면 랜더링 되는 동안 이미지를 다운로드 하는 동안 브라우저가 멈추게 되고, 메모리를 증가시키는 등 여러 가지 단점이 있다. 가장 좋은 접근 방법은 AlphaImageLoader를 지양하고 좀 질이 떨어지더라도 png8로 지원하는 것이다. 그렇지만 만약 AlphaImageLoader를 정말 사용해야 한다면 ie6 전용 핵인 “_”을 사용하여 다른 브라우저  사용자들에게 피해가 가지 않게 한다. ex) div {_filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src=‘test.png', sizingMethod='image');}
Rule 28. Optimize Images
Optimize Images 1 / 2 웹사이트에 넣을 이미지를 웹 서버로 올리기 전에 이미지를 최적화 시켜주도록 한다. 먼저 Imagemagick을 이용하여 gif 이미지를 컬러 수에 맞게 사이즈를 조정해 주는 방법이 있다. 그리고 gif 파일을 png파일로 변환하여 저장하는 방법이 있는데 이렇게 되면 보통은 사이즈가 줄어든다. 개발자들은 보통 브라우저의 제한 때문에 png사용을 꺼려하지만 이렇게 사용하면 훨씬 빨라진다. 한가지 문제가 있다면 true color png이미지의 alpha-transparency 지원 문제인데 gif이미지는 사실 true color가 아니며 그 어떤 다양한 투명이미지도 지원하지 않는다. 그러므로 gif animation이 아닌 이상은 PNG-8로 저장하여 최적화 시키는 것이 좋다. 그 외에도pngcrush(PNG optimizer tool), jpegtran 등을 이용하여 최적화 할 수 있다.
Rule 29. Optimize CSS Sprites
Optimize CSS Sprites 1 / 2 Image Sprites 기법을 쓸 때 background image를 수직으로 나열하지 않고 수평으로 나열하면 파일 사이즈를  줄일 수 있다. 그리고 비슷한 색상의 image를 조합하면 컬러 수가 줄어 256 색상 미만의 PNG8 파일로 만들기에 좋다. 모바일 에 서비스 될 것도 고려해야 하며 각 이미지 사이에 큰 여백을 남기지 않도록 한다. 여백이 파일 용량에 크게 영향을 미치지는 않지만 사용자들이 이미지를 픽셀 맵으로 압축 푸는데 적은 메모리만을 필요로 하게 됩니다. 100x100 이미지는 10000개 픽셀,
Rule 30. Don’t Scale Images in HTML
Don’t Scale Image in HTML 1 / 2 Image에 지정된 width, height와 같은 크기의 image를 사용한다. 만약 <img width="100" height="100" src="mycat.jpg" alt="My Cat" />가 필요하다면 500x500px를 강제로 줄여 사용하는 것보다 100x100px의 이미지를 사용하는 것이 좋다.
Rule 31. Make favicon.ico Small and Cacheable
Make favicon.ico Small and Cacheable 1 / 2 favicon.ico(short for favorites icon)은 서버 루트에 있는 이미지 이다. IE에서는 Onload시 다른 component를 요청할 때 먼저 로딩됨으로써 해당 component 로딩 시 방해가 된다. 그러므로 favicon.ico를 만들 때는 1K로 이하로 작게 만들고, Expires header를 설정하여 사용하는 것이 좋다.
Rule 32. Keep Components under 25K
Keep Components under 25K 1 / 2 iPhone에서 25K보다 큰 크기의 component를 cache하지 못하기 때문에 생긴 제한이다. 압축전의 용량이며 Gzip으로는 충분치 압축이 되지 않을 수 있기 때문에처음부터 이미지 25K가 넘지 않도록 제작 하는 것이 좋다. 더 자세한 내용이 알고 싶다면 Wayne Shea & TenniTheurer의 "Performance Research, Part 5: iPhoneCacheability - Making it Stick“를 참조 할 것.
Rule 33. Pack Components into a Multipart Document
Pack Components into a Multipart Document 1 / 2 Email의 첨부파일과 같이 multipart(Content-Type 중 하나로 여러 개의 독립된 섹션으로 구성된 데이터를  하나의 메시지로 조합하여 전송) 문서로 component들을 묶는 것이 여러 개의 component를 하나의 HTTP request로 전송하는데 도움을 준다. 이 기술을 사용할 때는 먼저사용자 agent가 이 기술을 지원하는 지를 확인 하도록 한다. (iPhone은 지원하지 않는다.)

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (9)

Vue.js와 Firebase를 활용한 웹 서비스 개발
Vue.js와 Firebase를 활용한 웹 서비스 개발Vue.js와 Firebase를 활용한 웹 서비스 개발
Vue.js와 Firebase를 활용한 웹 서비스 개발
 
HTTP 완벽가이드 7장 캐시
HTTP 완벽가이드 7장 캐시HTTP 완벽가이드 7장 캐시
HTTP 완벽가이드 7장 캐시
 
HTTP/3 시대의 웹 성능 최적화 기술 이해하기
HTTP/3 시대의 웹 성능 최적화 기술 이해하기HTTP/3 시대의 웹 성능 최적화 기술 이해하기
HTTP/3 시대의 웹 성능 최적화 기술 이해하기
 
HTTP/2와 웹 성능 최적화 방안
HTTP/2와 웹 성능 최적화 방안HTTP/2와 웹 성능 최적화 방안
HTTP/2와 웹 성능 최적화 방안
 
FCGI, C++로 Restful 서버 개발
FCGI, C++로 Restful 서버 개발FCGI, C++로 Restful 서버 개발
FCGI, C++로 Restful 서버 개발
 
Web server
Web serverWeb server
Web server
 
[D2 CAMPUS]웹 개발자의 스펙 : HTTP
[D2 CAMPUS]웹 개발자의 스펙 : HTTP[D2 CAMPUS]웹 개발자의 스펙 : HTTP
[D2 CAMPUS]웹 개발자의 스펙 : HTTP
 
Web_01 HTML
Web_01 HTMLWeb_01 HTML
Web_01 HTML
 
[112]clova platform 인공지능을 엮는 기술
[112]clova platform 인공지능을 엮는 기술[112]clova platform 인공지능을 엮는 기술
[112]clova platform 인공지능을 엮는 기술
 

Andere mochten auch

KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주
KTH, 케이티하이텔
 
KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈
KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈
KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈
KTH, 케이티하이텔
 
Web publishing life
Web publishing lifeWeb publishing life
Web publishing life
clearboth
 
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기
KTH, 케이티하이텔
 
KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환
KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환
KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환
KTH, 케이티하이텔
 
[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221
[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221
[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221
KTH, 케이티하이텔
 
[2012널리세미나] Front-End 최적화의 끝판왕, CSM + Markup Complexity
[2012널리세미나]  Front-End 최적화의 끝판왕, CSM + Markup Complexity[2012널리세미나]  Front-End 최적화의 끝판왕, CSM + Markup Complexity
[2012널리세미나] Front-End 최적화의 끝판왕, CSM + Markup Complexity
Nts Nuli
 

Andere mochten auch (20)

KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(2)_디자인사례_정덕주
 
Web_03_Front-end Advance
Web_03_Front-end AdvanceWeb_03_Front-end Advance
Web_03_Front-end Advance
 
KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈
KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈
KTH_Detail day_안드로메다에서 온 디자이너이야기_1차_디자인용어_지훈
 
Web publishing life
Web publishing lifeWeb publishing life
Web publishing life
 
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기
KTH_Detail day_안드로메다에서 온 디자이너이야기_2차(1)_디자인프로세스,협업_한재기
 
Front-End Developer's work process
Front-End Developer's work processFront-End Developer's work process
Front-End Developer's work process
 
KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환
KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환
KTH_Detail day_안드로메다에서 온 디자이너이야기_3차_디자인기본요소_박지환
 
Web_05_ jQuery
Web_05_ jQueryWeb_05_ jQuery
Web_05_ jQuery
 
마크업개발자가 UX를 알아야 하는 이유
마크업개발자가 UX를 알아야 하는 이유마크업개발자가 UX를 알아야 하는 이유
마크업개발자가 UX를 알아야 하는 이유
 
Front end performance analysis v0.6
Front end performance analysis v0.6Front end performance analysis v0.6
Front end performance analysis v0.6
 
[별천지 세미나] 세션1 Sencha로 끝장내는 Front-End 개발과 Architect
[별천지 세미나] 세션1 Sencha로 끝장내는 Front-End 개발과 Architect[별천지 세미나] 세션1 Sencha로 끝장내는 Front-End 개발과 Architect
[별천지 세미나] 세션1 Sencha로 끝장내는 Front-End 개발과 Architect
 
[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221
[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221
[발표자료]안드로메다에서 온 디자이너이야기 5차 next_web_지훈_20130221
 
[2012널리세미나] Front-End 최적화의 끝판왕, CSM + Markup Complexity
[2012널리세미나]  Front-End 최적화의 끝판왕, CSM + Markup Complexity[2012널리세미나]  Front-End 최적화의 끝판왕, CSM + Markup Complexity
[2012널리세미나] Front-End 최적화의 끝판왕, CSM + Markup Complexity
 
[D2대학생세미나] frontend개발자가 들려주는 개발 이야기
[D2대학생세미나] frontend개발자가 들려주는 개발 이야기[D2대학생세미나] frontend개발자가 들려주는 개발 이야기
[D2대학생세미나] frontend개발자가 들려주는 개발 이야기
 
Front end dev 2016 & beyond
Front end dev 2016 & beyondFront end dev 2016 & beyond
Front end dev 2016 & beyond
 
How_to_choose_the_right_framework
How_to_choose_the_right_frameworkHow_to_choose_the_right_framework
How_to_choose_the_right_framework
 
개발자를 알아보자.
개발자를 알아보자.개발자를 알아보자.
개발자를 알아보자.
 
WEB Front-End 개발과정 살펴보기
WEB Front-End 개발과정 살펴보기WEB Front-End 개발과정 살펴보기
WEB Front-End 개발과정 살펴보기
 
코드스쿼드 마스터즈세미나 - UI개발자가돼보자
코드스쿼드 마스터즈세미나 - UI개발자가돼보자코드스쿼드 마스터즈세미나 - UI개발자가돼보자
코드스쿼드 마스터즈세미나 - UI개발자가돼보자
 
퍼블리셔, 프론트엔드개발을 시작하다
퍼블리셔, 프론트엔드개발을 시작하다퍼블리셔, 프론트엔드개발을 시작하다
퍼블리셔, 프론트엔드개발을 시작하다
 

Ähnlich wie High performance websites v1.0

Html5 앱과 웹사이트를 보다 빠르게 하는 50가지
Html5 앱과 웹사이트를 보다 빠르게 하는 50가지Html5 앱과 웹사이트를 보다 빠르게 하는 50가지
Html5 앱과 웹사이트를 보다 빠르게 하는 50가지
yongwoo Jeon
 
[2012널리세미나] 오빠~ 네이버 왜 이렇게 늦게 떠?
[2012널리세미나] 오빠~ 네이버 왜 이렇게 늦게 떠?[2012널리세미나] 오빠~ 네이버 왜 이렇게 늦게 떠?
[2012널리세미나] 오빠~ 네이버 왜 이렇게 늦게 떠?
Nts Nuli
 
HTML5 스펙 소개
HTML5 스펙 소개HTML5 스펙 소개
HTML5 스펙 소개
Toby Yun
 

Ähnlich wie High performance websites v1.0 (20)

응답하라 반응형웹 - 3. bootstrap
응답하라 반응형웹 - 3. bootstrap응답하라 반응형웹 - 3. bootstrap
응답하라 반응형웹 - 3. bootstrap
 
웹표준 교육
웹표준 교육웹표준 교육
웹표준 교육
 
Html5 앱과 웹사이트를 보다 빠르게 하는 50가지
Html5 앱과 웹사이트를 보다 빠르게 하는 50가지Html5 앱과 웹사이트를 보다 빠르게 하는 50가지
Html5 앱과 웹사이트를 보다 빠르게 하는 50가지
 
[2012널리세미나] 오빠~ 네이버 왜 이렇게 늦게 떠?
[2012널리세미나] 오빠~ 네이버 왜 이렇게 늦게 떠?[2012널리세미나] 오빠~ 네이버 왜 이렇게 늦게 떠?
[2012널리세미나] 오빠~ 네이버 왜 이렇게 늦게 떠?
 
효율적인 빅데이터 분석 및 처리를 위한 Glue, EMR 활용 - 김태현 솔루션즈 아키텍트, AWS :: AWS Summit Seoul 2019
효율적인 빅데이터 분석 및 처리를 위한 Glue, EMR 활용 - 김태현 솔루션즈 아키텍트, AWS :: AWS Summit Seoul 2019효율적인 빅데이터 분석 및 처리를 위한 Glue, EMR 활용 - 김태현 솔루션즈 아키텍트, AWS :: AWS Summit Seoul 2019
효율적인 빅데이터 분석 및 처리를 위한 Glue, EMR 활용 - 김태현 솔루션즈 아키텍트, AWS :: AWS Summit Seoul 2019
 
Front-end Development Process - 어디까지 개선할 수 있나
Front-end Development Process - 어디까지 개선할 수 있나Front-end Development Process - 어디까지 개선할 수 있나
Front-end Development Process - 어디까지 개선할 수 있나
 
Redis
RedisRedis
Redis
 
[2018] 프런트엔드 성능 최적화
[2018] 프런트엔드 성능 최적화[2018] 프런트엔드 성능 최적화
[2018] 프런트엔드 성능 최적화
 
Accelerate spring boot application with apache ignite
Accelerate spring boot application with apache igniteAccelerate spring boot application with apache ignite
Accelerate spring boot application with apache ignite
 
[오픈소스컨설팅] Atlassian webinar 기본 트러블슈팅(1 of 2)
[오픈소스컨설팅] Atlassian webinar 기본 트러블슈팅(1 of 2)[오픈소스컨설팅] Atlassian webinar 기본 트러블슈팅(1 of 2)
[오픈소스컨설팅] Atlassian webinar 기본 트러블슈팅(1 of 2)
 
처음부터 다시 배우는 HTML5 & CSS3 1일차
처음부터 다시 배우는 HTML5 & CSS3 1일차처음부터 다시 배우는 HTML5 & CSS3 1일차
처음부터 다시 배우는 HTML5 & CSS3 1일차
 
현실적 PWA
현실적 PWA현실적 PWA
현실적 PWA
 
웹에 빠른 날개를 달아주는 웹 성능 향상 이야기
웹에 빠른 날개를 달아주는 웹 성능 향상 이야기웹에 빠른 날개를 달아주는 웹 성능 향상 이야기
웹에 빠른 날개를 달아주는 웹 성능 향상 이야기
 
웹표준의 이해
웹표준의 이해웹표준의 이해
웹표준의 이해
 
Scalable web architecture and distributed systems
Scalable web architecture and distributed systemsScalable web architecture and distributed systems
Scalable web architecture and distributed systems
 
Scalable web architecture and distributed systems
Scalable web architecture and distributed systemsScalable web architecture and distributed systems
Scalable web architecture and distributed systems
 
웨일브라우저 성능 및 메모리 최적화
웨일브라우저 성능 및 메모리 최적화웨일브라우저 성능 및 메모리 최적화
웨일브라우저 성능 및 메모리 최적화
 
ecdevday3 효율적인 유지보수를 위한 개발 및 관리
ecdevday3 효율적인 유지보수를 위한 개발 및 관리ecdevday3 효율적인 유지보수를 위한 개발 및 관리
ecdevday3 효율적인 유지보수를 위한 개발 및 관리
 
HTML5 스펙 소개
HTML5 스펙 소개HTML5 스펙 소개
HTML5 스펙 소개
 
Social Tutorial Platform: Webbles
Social Tutorial Platform: Webbles Social Tutorial Platform: Webbles
Social Tutorial Platform: Webbles
 

High performance websites v1.0

  • 1. Best Practices for Speeding Up Your Web Site 디자인실UI Dev 이선실, 김수성
  • 2. The important of Front-end Performance
  • 3. Downloading (http://www.yahoo.com) in IE : empty cache Back-end =5% Front-end = 95%
  • 4. Downloading (http://www.yahoo.com) in IE : primed cache Even here, front-end= 95%
  • 5. Downloading percentage * Percentage of time spent downloading the HTML document for 10 top web site
  • 6. Downloading percentage 보통 웹사이트에서 Html 문서를 웹 서버로부터 다운(Back-end) 받는데 소요되는 시간은 10~20%이다. 그 외 80~90%는 Html에서 사용되는 components를 다운(Front-end)받는데 소요된다. *단, cache된 상태의 Google은 제외된다. Google은 오직 6개의 components만 가지고 있기 때문에 front-end에 소요되는 시간이 길지 않다.
  • 7.
  • 8. Front-end를 50% 줄일 경우 : 전체의 40~45% 감소두 번째, Front-end에서 작업할 경우, Back-end에서 작업할 때 보다더 적은 시간과 더 적은 resource가 필요. 세 번째, 여러 프로젝트 경험을 바탕으로, 보통 25% or 그 이상의 response time을 줄일 수 있다.
  • 9. Rule 1. Make Fewer HTTP Requests
  • 10. Minimize HTTP Requests End-userresponse time의 80%를 front-end단에서 차지한다. 이 response time의 대부분은 페이지내에서 사용되어지는 components -Images, Stylesheets, Scripts, Flash 등- 를 다운로드 하는데 소요된다. 여기서 component의 수를 줄이는 것이 HTTP request를 줄이는 하나의방법이며, 빠른 웹 페이지 만들기의 중요 포인트라고 할 수 있다. Component의 수를 줄이기 위해 페이지 설계를 간단하게 할 수도 있지만 사용자가 필요로 하는 많은 양의 contents를 보여주면서 response time을 줄일 수 있는 방법을 사용하는 것이 더 효과적이라고 할 수 있다. 여기서 HTTP request 수를 줄이는 몇 가지 방법을 알아보자.
  • 11. Combined files HTTP request 수를 줄이기 위해서사용되어진 모든 Script를 하나의 Script로 통합하고, 이와 같이 CSS도 하나의 Stylesheet로 통합한다. 이러한 방법은 각 페이지 마다 다르게 사용해야 할 때 문제가 될 수도 있겠지만 작업 시 하나의 과정으로 포함시킨다면 response time을 줄일 수 있을 것이다. ex) <link rel="stylesheet" type="text/css“ ref="http://i.kthimg.com/search/css/sch_layout.css"> <link rel="stylesheet" type="text/css“ ref="http://i.kthimg.com/search/css/sch_result.css"> <link rel="stylesheet" ype="text/css“ ref="http://i.kthimg.com/search/css/sch_prn.css"> <link rel="stylesheet" ype="text/css“ ref="http://i.kthimg.com/search/css/sch_1.0.css">
  • 12. CSS Sprites 페이지 내에 사용된 Background image의 request 를 줄이기 위해 쓰이는 방법이다. 작고 간단하고 반복 되어 지지 않는 Background image들을 하나의 이미지로 합치고 css의background-image와 background-position 속성으로 필요한 부분만 보여준다. ex) .mre a{background:url(http://i.kthimg.com/search/img/bg_ic.gif) 0 1px no-repeat;}
  • 13. Image Maps 여러 개의 연속적인 이미지에 링크를 걸어야 할 때 사용한다. 이미지의 전체 사이즈는 거의 같지만 HTTP request가 줄어들어 페이지 로딩 속도는 빨라지나좌표 지정이 쉽지 않고 에러를 유발하기 쉽다. 그리고 이미지맵은접근성이 부족하기 때문에 navigation bar에는 사용하지 않는 것이 좋다. ex) Example 1 - No Image Map이미지맵을 사용하지 않았을 때 Example 2 - Image Map이미지맵을 사용했을 때
  • 14. Inline image (data:URL scheme) data:URL scheme를 이용해서 실제 페이지에 이미지를 넣는다. 이것은 HTML 문서의 크기를 증가시킬 수 있지만 HTTP request를 감소시키고 페이지 사이즈 증가를 막을 수 있다. data:[<mediatype>][;base64],<data> 단, 이 방법은 글자수 제한이 있고 모든 브라우저에서 지원되지 않는다. ex) <IMG BORDER=1 SRC="data:image/gif;base64, R0lGODdhMQAiAPcAAP////f39+/……….">
  • 15. Rule 2. Use a CDN(Content Delivery Network)
  • 16. Use a CDN 일종의 캐시 역할을 할 수 있도록 전체 network 상에 동일한 contents 내용을 복제하여, 대규모 인트라넷 또는 인터넷상에 분산시켜 놓은 시스템. 인터넷 이용자의 증가와 멀티미디어 등 대용량 contents에 대한 수요의 증가로 인해 데이터 트래픽은 기하급수적으로 늘어나는 데 비해 Middle-Mile이라 불리는 네트워크간 연결구간에 대한 투자는 이에 미치지 못해 결과적으로 인터넷은 트래픽의 정체현상, 즉 병목현상이 발생하게 되었다. 이러한 현상을 해결하기 위한 방법이 Content Delivery Network이다. CDN은 기간망과 가입자망간의 연결을 물리적인 망의 증설을 통해 개선하는 것이 아니라 병목현상의 대상인 데이터 트래픽, 즉 Contents를 인터넷 네트워크의 주요지점으로 분산시킴으로써 해결하는 것이다. CDN은 사용자의 콘텐츠 요구에 가장 빠르게 연결이 가능한 네트워크를 중계해 주고 contents를 전송해 준다. Contents가 복제되어 특정 국가 또는 전세계에 걸쳐 분산 배치되면, 사용자들은 그것이 하나의 웹사이트에 있을 때보다 훨씬 더 빠르게 액세스할 수 있게 된다. Akamai와 같은 contents 전달 조직, 전국의 커버할 수 있는 대규모 ISP, 또는 대기업 등에 의해 제공 된다
  • 17.
  • 18. Rule 3. Add an Expires or a Cache-Control Header
  • 19. Add an Expires or a Cache-Control Header 브라우저 캐시를 위해 Expires Date 와 Cache Control 추가
  • 20. Rule 4. Gzip Components
  • 21. Gzip Components Gzip은 국제 표준으로 등록된 무료 압축 포맷이다. 브라우저는 자신이 압축을 해제할 수 있는 압축 포맷을 HTTP 헤더 Accept-Encoding의 속성을 이용해서 전달하는데이 때 서버는 이 속성을 확인하여 본문을 압축할 수 있다. (RFC1952) 이 기술은 현재 가장 많이 사용하고 있고 그만큼 성능도 좋다. 이미지 등 이미 압축처리가 된 파일에는 효과가 없으므로 html, js, css같은 텍스트 파일에만 Gzip을 적용한다. 또한 용량이 적은 파일을 압축하면 전달되는 속도보다 압축을 적용하고 푸는 시간이 더 걸릴 수 있고 압축 적용 시 서버와 클라이언트의 CPU 리소스를 불필요하게 소비하게 된다. 기본적으로 웹 IIS서버는Gzip이나 deflate 압축을 지원하지 않으므로 따로 처리한다.
  • 22. Rule 5. Put Stylesheets at the Top
  • 23. Put Stylesheets at the Top 1 / 2 Stylesheet는 항상 head에 넣는다. 그렇게 되면 페이지 랜더링이 더 빨라지기 때문에 로딩속도가 향상 된다. 웹 페이지 내용에 상관없이 가능한 한 빨리 로딩이 되기를 원하기 때문에 많은 내용의 contents를 가진 페이지와 느린 인터넷을 사용하는 사용자에게 특히 중요하다. 문서의 아래에 stylesheet를 넣게 되면 요소를 다 불러온 후에 다시 위에서부터 style을 입히게 된다. 그 과정에서 IE등의 브라우저에서는 마지막 style이 로딩 될 때까지 랜더링을 멈추고 있다가 style이 로드 된 후 랜더링을 한다. 이 과정에서 사용자들은 아무것도 없는흰 페이지를 보게 되는 문제가 발생하게 된다. html 표준에서도 stylesheet를 페이지의 head에 넣기를 권장하고 있다.
  • 24. Rule 6. Move Scripts to the Bottom
  • 25. Move Scripts to the Bottom 1 / 2 스크립트 실행에 지연이 걸려 페이지가 늦게 오픈 되는 걸 방지하기 위해 하단에 두어야 한다.
  • 26. Rule 7. Avoid CSS Expression
  • 27. Avoid CSS Expression 1 / 2 CSS expression은 다이나믹한 css속성을 지원하는 것으로 강력하지만 위험한 방법이다. 예를 들어 CSS expression을 사용하여 background color를 매 시간 별로 번갈아 가며 보여지게 설정할 수 있다. background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" ); 여기서 보다시피, expression method로 JavaScript expression에 접근할 수 있다. CSS 속성은 JavaScript expression의 계산 결과로 설정된다. Expression method는 IE -IE5부터 지원된다- 외 다른 브라우저에선 작동이 안되므로 IE에서 다른 브라우저와 일관된 기능을 지원하기 위해 사용한다. 이 expression의 문제는 예상보다 훨씬 자주 실행된다는 데 있다. 페이지가 rendering 되고 resize 될 때에만 실행되는 것이 아니라 스크롤을 움직일 때나 페이지 위에서 마우스를 움직일 때에도 실행 된다.
  • 28. Avoid CSS Expression 1 / 2 Expression 카운터 http://stevesouders.com/hpws/expression-counter.php (CSS Expression이 동작 할 때마다 카운트 계산) 그 방법을 해결 하기 위한 방법 중 하나는 expression이 한번만 실행되게 제한하는 것이다. 만약 유동적인 페이지에 expresstion을 줘야 한다면 event handler로 대체하는 것도 좋은 방법이다. CSS expresstion을 사용해야 할때에는 이러한 문제들을 충분히 생각한 후에 꼭 필요한 경우에만 적용하도록 한다.
  • 29. Rule 8. Make JS and CSS external
  • 30. Make JS and CSS external 1 / 2 JavaScript와 CSS를 외부 파일로 불러오게 되면 browser에 의해 캐싱이 되기 때문에 일반적으로 더 빠르게 페이지를 출력한다. HTML 문서에 inline 형식으로 존재하는 JavaScript와 CSS는 HTML 문서가 요청될 때마다 매번 다운로드 하는데 그렇게 되면 HTTP request 수는 감소할지 모르겠지만 HTML 문서의 크기는 늘어나게 된다. 반면에, JavaScript와 CSS가 브라우저에 의해 외부 파일로 캐싱이 된다면 HTML 문서의 크기는 request 수를 증가시키지 않으면서 감소하게 된다. 여기서 중요한 점은 HTML 문서의 수와 외부 JavaScript, CSS의 요청 빈도이다. 어느 웹사이트에서 사용자들이 여러 페이지를 방문하고 그 페이지들이 동일한 JavaScript와 CSS를 사용하고 있다면 외부 파일로 캐싱 되게 하는 것이 좋다. 만약 페이지 뷰가 적거나 한정된 곳에만 적용이 되어야 하는 경우라면 JavaScript나 CSS를 inline화하는 것이 응답 속도가 더 빠르다.
  • 31. Make JS and CSS external 1 / 2 많은 페이지로 연결되는 front page 같은 경우는 외부파일 캐싱 이라는 장점과 inline의 HTTP request 감소를 같이 사용할 수 있다. Front page에서 사용할 JavaScript와 CSS는 inline으로 넣어 놓고 페이지가 로딩을 마친 후에 동적으로 외부 파일을 다운로드 한다. 그러면 그 후의 페이지들은 캐싱 되어 있는 외부 파일을 참조하게 되어 로딩 속도가 빨라질 것이다.
  • 32. Rule 9. Reduce DNS Lookups
  • 33. Reduce DNS Lookups 1 / 2 일반적으로 해당 호스트에 대한 IP 주소를 조회하려면 DNS에 20-120 micro sec 정도 걸리므로 Image/JS/CSS 링크의 Domain 수를 최소화해야 한다.
  • 34. Rule 10. Minify JavaScript and CSS
  • 35. Minify JavaScript and CSS 1 / 2 JavaScript와 CSS의 최소화는 모든 주석을 제거하고 불필요한 공백(space, newline, and tab)을 제거 함으로써 코드의 사이즈를 줄여 로딩 속도가 빨라지게 한다. 그렇게 되면 JavaScript의 경우 다운로드 되는 파일의 사이즈가 감소 하기 때문에 속도가 향상된다. 자바스크립트를 최소화 해주는 툴 중 잘 알려진 프로그램에는 JSMin와 YUI Compressor가 있는데, 그 중 YUI compressor로는 CSS 파일도 최소화 할 수 있다. Obfuscation(난독화,암호와)는 코드 압축에 최적화 된 대체 기술로써 소스 코드 중에서 가장 중요한 멤버나 메소드의 이름을 짧고 무의미한 것으로 대체해 다른 사람이 도용하거나 가져다 쓰는걸 막아준다. 미국 Top10 웹사이트 조사 결과를 보면 최소화 한 파일은 크기가 21% 감소한것에 비해 Obfuscation 한 파일은 25%가 감소하여 보다 뛰어난 성능을 보여주고 있다. 그러나 방법이 훨씬 복잡하고 압축도중 스크립트 오류를 발생시킬 위험이 있으며 사실상 응답속도에 별 영향을 미치지 못하므로 단순히 최소화 시키는 것이 더 효과적이라고 볼 수 있다. ex) varpserson; -> var AB
  • 36. Minify JavaScript and CSS 1 / 2 외부 Script와 CSS파일과 마찬가지로 inline으로 들어가 있는 Script와 CSS도 최소화가 가능하다. Gzip (웹 서버에서 사용자 브라우저로 갈 때만 html파일을 압축해주는 서버모듈)을 통해서 압축한 후라도 Script와 CSS를 최소화를 하게 되면 적어도 5%이상 사이즈를 더 감소 시킬 수 있다.
  • 37. Rule 11. Avoid Redirects
  • 38. Avoid Redirects 1 / 2 Redirect 동안에는 다른 작업을 시작할 수 없다 http://www.paran.com/test ( 301 redirect 됨) http://www.paran.com/test/ 디렉토리일경우/ 까지 기입
  • 39. Rule 12. Remove Duplicates Scripts
  • 40. Remove Duplicates Scripts 1 / 2 request 를 줄이기 위해 개발자의 실수로 인한 중복 기술된 스크립트 줄인다. 실제 같은 external js를 여러번 호출하면 호출한 만큼 request 된다.
  • 42. Configure ETag Compare 1 / 2 웹서버와 브라우저가 캐시 된 구성요소들의 유효성을 확인하기 위해서 사용하는 메커니즘. 브라우저의 캐시된 파일의 유효하면 [304 Not Modified] 발생시킨다. 유효하지 않으면 서버에서 파일을 받아 [200 OK] 발생한다. HTTP Request Server Browser Disk Read Cache Download 200 OK 304 Not Modified Last-Modified ETag
  • 43. Configure ETag 1 / 2 GET /i/yahoo.gif HTTP/1.1 Host: us.yimg.com -------------------------------------------------------> HTTP/1.1 200 OK Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT ETag: "10c24bc-4ab-457e1c1f" Content-Length: 12195 -------------------------------------------------------> GET /i/yahoo.gif HTTP/1.1 Host: us.yimg.com If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT If-None-Match: "10c24bc-4ab-457e1c1f" -------------------------------------------------------> HTTP/1.1 304 Not Modified Request Response Request Response
  • 44. Configure ETag 1 / 2 출처 http://support.microsoft.com/kb/922703/ http://www.apacheweek.com/issues/02-01-18 http://firejune.com/1151
  • 45. Rule 14. Make Ajax Cacheable
  • 46. Make Ajax Cacheable 1 / 2 Ajax 통신시 캐쉬 기능을 구현
  • 47. Rule 15. Flush the Buffer Early
  • 48. Flush the Buffer Early 1 / 2 버퍼링을 사용함으로써 완료된 html 이 아닌 사용자가 원하는시점에 출력을 지정할 수 있으므로 브라우저의 대기 시간이 줄어든다.
  • 49. Rule 16. Use Get for Ajax Requests
  • 50. Use Get for Ajax Requests 1 / 2 Ajax 사용할때는GET Method 가 빠르다. POST 는 XMLHttpRequest사용시 header 를 보낸 후 data 를 보내는 두 가지 step 으로 되어있어서 GET 보다 느리다.
  • 51. Rule 17. Post-load Components, Preload Components
  • 52. Post-load Components, Preload Components 1 / 2 페이지가 열릴 때 필요한 구성요소와 onload후에 필요한 구성요소를 구분하여 페이지 렌더링을 빠르게 구현하기 위해 구조화 작업이 필요.
  • 53. Rule 18. Reduce the Number of DOM Elements
  • 54. Reduce the Number of DOM Elements 1 / 2 Dom 구조를 간략하게 해야 한다.
  • 55. Rule 19. Split Components Across Domains
  • 56. Split Components Across Domains 1 / 2 web페이지를 구성하는 요소들의 호스트를 분산하면 빨라질 수 있다. ex) css/js/img
  • 57. Rule 20. Minimize the Number of Iframes
  • 58. Minimize the Number of Iframes 1 / 2 Iframe은 html 문서를 다른 html문서에 삽입 하는 기능이다. Iframe은 광고나 배너등 외부 컨텐츠를 불러오거나, doc type등이 다른 html 문서를 한 화면에서 보여줘야 할 때 유용하다. 그러나 아무 내용이 없어도 트래픽이 발생하고 request가 증가하게 되므로 꼭 필요할 때만 사용하는 것이 좋다. iframe안에 css/js등이 parent 와 같이 있어도 다시 request 됨으로 주의해야 한다.
  • 59. Rule 21. No 404s
  • 60. No 404s 1 / 2 불필요한 404 not found 페이지를 제거한다.
  • 61. Rule 22. Reduce Cookie Size
  • 62. Reduce Cookie Size 1 / 2 불필요한 쿠키를 제거. 해당 도메인순 Expire 날짜 지정
  • 63. Rule 23. Use Cookie-free Domains for Components
  • 64. Rule 24. Minimize Dom Access
  • 65. Minimize Dom Access 1 / 2 Javascript로 Dom요소에 접근하는 것은 페이지 응답속도를 느리게 한다. 그러므로 Dom Element 구조를 Cache 하여 사용하는 것이 좋다. 접근 할 때마다 Dom syntax 로 쓰지 말고 변수에 할당해서 쓰도록 한다.
  • 66. Rule 25. Develop Smart Event Handlers
  • 67. Develop Smart Event Handlers 1 / 2 각각의 Dom element 에 이벤트를 거는것 보다는 상위 Element 이벤트를 걸어 하나의 이벤트로 처리하고 하위 element 속성으로 처리 하는 게 좋다.
  • 68. Rule 26. Choose <link> over @import
  • 69. Choose <link> over @import 1 / 2 <link>는 하위 브라우저까지 모두 지원되고 @import는 최신 브라우저만 지원하기때문에 구 버전의 CSS 버그를 피하기 위해서 @import를 쓰기도 한다. 하지만 @import를 쓰면 <link>를 bottom에 둔 것과 같은 결과를 초래하기 때문에 사용하지 않는 것이 좋다. 또한 @import는 이미지보다 CSS를 늦게 불러오기 때문에 속도 향상에 좋지 않은 영향을 끼친다. 더 자세한 내용 http://seye2.egloos.com/2319809
  • 70. Rule 27. Avoid Filters
  • 71. Avoid Filters 1 / 2 IE 전용 filter인 AlphaImageLoader는 ie7 이하 버전에서 png반투명 이미지를 쓸 수 있도록 해준다. 그러나 이 filter를 사용하면 랜더링 되는 동안 이미지를 다운로드 하는 동안 브라우저가 멈추게 되고, 메모리를 증가시키는 등 여러 가지 단점이 있다. 가장 좋은 접근 방법은 AlphaImageLoader를 지양하고 좀 질이 떨어지더라도 png8로 지원하는 것이다. 그렇지만 만약 AlphaImageLoader를 정말 사용해야 한다면 ie6 전용 핵인 “_”을 사용하여 다른 브라우저 사용자들에게 피해가 가지 않게 한다. ex) div {_filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src=‘test.png', sizingMethod='image');}
  • 73. Optimize Images 1 / 2 웹사이트에 넣을 이미지를 웹 서버로 올리기 전에 이미지를 최적화 시켜주도록 한다. 먼저 Imagemagick을 이용하여 gif 이미지를 컬러 수에 맞게 사이즈를 조정해 주는 방법이 있다. 그리고 gif 파일을 png파일로 변환하여 저장하는 방법이 있는데 이렇게 되면 보통은 사이즈가 줄어든다. 개발자들은 보통 브라우저의 제한 때문에 png사용을 꺼려하지만 이렇게 사용하면 훨씬 빨라진다. 한가지 문제가 있다면 true color png이미지의 alpha-transparency 지원 문제인데 gif이미지는 사실 true color가 아니며 그 어떤 다양한 투명이미지도 지원하지 않는다. 그러므로 gif animation이 아닌 이상은 PNG-8로 저장하여 최적화 시키는 것이 좋다. 그 외에도pngcrush(PNG optimizer tool), jpegtran 등을 이용하여 최적화 할 수 있다.
  • 74. Rule 29. Optimize CSS Sprites
  • 75. Optimize CSS Sprites 1 / 2 Image Sprites 기법을 쓸 때 background image를 수직으로 나열하지 않고 수평으로 나열하면 파일 사이즈를 줄일 수 있다. 그리고 비슷한 색상의 image를 조합하면 컬러 수가 줄어 256 색상 미만의 PNG8 파일로 만들기에 좋다. 모바일 에 서비스 될 것도 고려해야 하며 각 이미지 사이에 큰 여백을 남기지 않도록 한다. 여백이 파일 용량에 크게 영향을 미치지는 않지만 사용자들이 이미지를 픽셀 맵으로 압축 푸는데 적은 메모리만을 필요로 하게 됩니다. 100x100 이미지는 10000개 픽셀,
  • 76. Rule 30. Don’t Scale Images in HTML
  • 77. Don’t Scale Image in HTML 1 / 2 Image에 지정된 width, height와 같은 크기의 image를 사용한다. 만약 <img width="100" height="100" src="mycat.jpg" alt="My Cat" />가 필요하다면 500x500px를 강제로 줄여 사용하는 것보다 100x100px의 이미지를 사용하는 것이 좋다.
  • 78. Rule 31. Make favicon.ico Small and Cacheable
  • 79. Make favicon.ico Small and Cacheable 1 / 2 favicon.ico(short for favorites icon)은 서버 루트에 있는 이미지 이다. IE에서는 Onload시 다른 component를 요청할 때 먼저 로딩됨으로써 해당 component 로딩 시 방해가 된다. 그러므로 favicon.ico를 만들 때는 1K로 이하로 작게 만들고, Expires header를 설정하여 사용하는 것이 좋다.
  • 80. Rule 32. Keep Components under 25K
  • 81. Keep Components under 25K 1 / 2 iPhone에서 25K보다 큰 크기의 component를 cache하지 못하기 때문에 생긴 제한이다. 압축전의 용량이며 Gzip으로는 충분치 압축이 되지 않을 수 있기 때문에처음부터 이미지 25K가 넘지 않도록 제작 하는 것이 좋다. 더 자세한 내용이 알고 싶다면 Wayne Shea & TenniTheurer의 "Performance Research, Part 5: iPhoneCacheability - Making it Stick“를 참조 할 것.
  • 82. Rule 33. Pack Components into a Multipart Document
  • 83. Pack Components into a Multipart Document 1 / 2 Email의 첨부파일과 같이 multipart(Content-Type 중 하나로 여러 개의 독립된 섹션으로 구성된 데이터를 하나의 메시지로 조합하여 전송) 문서로 component들을 묶는 것이 여러 개의 component를 하나의 HTTP request로 전송하는데 도움을 준다. 이 기술을 사용할 때는 먼저사용자 agent가 이 기술을 지원하는 지를 확인 하도록 한다. (iPhone은 지원하지 않는다.)
  • 84. Reference 1 / 2 원문 http://developer.yahoo.com/performance/rules.html 참고문서 http://static.slideshare.net/swf/ssplayer2.swf?doc=high-performance-web-pages-20-new-best-practices-120577522992998-3