Rhio.Kim's Blog - drawing Laputa Web -

Stoyan Stefanov씨는 Yahoo 엔지니어로 좀더 나은 예시를 찾기 위해 일해왔습니다.
그리고 새로운 결과를 아래 자료로 발표하였습니다.

그는 웹 페이지의 성능향상을 위한 14가지 기존 룰에 20가지 새로운 규칙을 찾아냈습니다.
우리는 다음 정보에 대해서 분류화 최적화를 하였습니다. :  서버, 컨텐츠, 쿠키, 자바스크립트, CSS, 이미지 그리고 모바일

아래의 새로운 목록입니다.  그리고 좀더 상세한 정보는 곧 발표할 예정입니다.

1. Flush the buffer early	[server]
2. Use GET for AJAX requests	[server]
3. Post-load components	[content]
4. Preload components	[content]
5. Reduce the number of DOM elements	[content]
6. Split components across domains	[content]
7. Minimize the number of iframes	[content]
8. No 404s	[content]
9. Reduce cookie size	[cookie]
10. Use cookie-free domains for components	[cookie]
11. Minimize DOM access	[javascript]
12. Develop smart event handlers	[javascript]
13. Choose <link> over @import	[css]
14. Avoid filters	[css]
15. Optimize images	[images]
16. Optimize CSS sprites	[images]
17. Don’t scale images in HTML	[images]
18. Make favicon.ico small and cacheable	[images]
19. Keep components under 25K	[mobile]
20. Pack components into a multipart document	[mobile]

Is it just me, or is performance getting a LOT of attention these days?

갈 수만 있다면... 가더라도 알아먹을 수 있다면 가고싶다.

Velocity: Optimizing Web Performance and Scalability.
Registration is now open!

Velocity is the new O'Reilly conference for people building at Internet scale, happening on June 23-24, 2008 at the San Francisco Airport Marriott in Burlingame, California.

Web companies, big and small, face many of the same challenges: sites must be faster, infrastructure needs to scale, and everything must be available to customers at all times, no matter what. Velocity is the place to obtain the crucial skills and knowledge to build successful web sites that are fast, scalable, resilient, and highly available.

Velocity is one of the few opportunities to learn from peers, exchange ideas with experts, and share best practices and lessons learned.

Velocity is designed to deliver the best information on building and operating web sites that are fast, reliable, and always up. We're bringing together people from around the world who are doing the best performance work, to improve the experience of web users worldwide. Pages will be faster. Sites will have higher up-time. Companies will achieve more with less. The next cool startup will be able to more quickly scale to serve a larger audience, globally. Velocity is the key for crossing over from cool Web 2.0 features to sustainable web sites.

Register by midnight, May 5 and save $350.

If you have ideas for speakers and topics that will make the conference a must attend event, send them to: velocity-idea@oreilly.com

원문 : http://en.oreilly.com/velocity2008/public/content/home

좀더 안정된 Ajax 개발 Pattern - Dynamic rendering with many HTTP Request
javascript 가 document rendering 에 미치는 영향 과는 다른 부분에서 접근했습니다.

정리하고 있는 문서중의 일부를 적어봅니다.

아래 이미지와 같은 UI를 동적으로 구현하려 할때에 Image를 포함(document component)한 Dynamic Rendering에 의해 발생하는 HTTP Requests 와 관련한 내용입니다.

좌측 이미지와 같이 "HD", "▲", "▼"는 이미지로 구성되어져 있습니다.

"HD" 이미지는 2개 하지만 정적인 페이지를 요청한 것이라면 첫번째 요청한 이미지만 Requst Result가 200(Headers and content returned)이 발생하고 그외의 이미지는 304(Content read from browser cache)가 발생하게 됩니다. Static 페이지의 경우에는 캐시를 사용하게 됩니다.

그렇기 때문에 불필요한 작은 이미지 하나 때문에 HTTP Request 를 발생하지 않습니다.

또한 우측으로 보이는 "▲", "▼" 이미지 역시 "HD" 이미지와 동일합니다.

하지만 동적으로 rendering 하는 방식은 경우(innerHTML을 통하거나, 동적 element를 사용)에 따라 이미지 개수만큼 HTTP Request가 발생합니다.

첨부한 자료는 아래의 시나리오에 의해서 나타난 결과입니다.

시나리오

  1.    createElement 를 통해 수십개의 엘리먼트를 생성합니다.
  2.    CSS에 background : transparent url(‘image url’); 속성을 갖는 className을 생성해 놓는다.
  3.    해당 엘리먼트들에 생성해 놓은 className을 부여합니다.
  4.    생성된 엘리먼트를 appendChild로 document에 rendering 합니다.

Ajax 와 DOM 스크립팅에 현재 가장 이슈가 되는 것은 아무래도 고성능을 낼 수 있는 웹 어플리케이션을 만들 수 있느냐라고 생각합니다.

웹 자체는 가벼우면서 사용자들에게 손쉽게 다가갈 수 있고 사용자들에게 가장 쉽게 어필 할 수 있는 것 역시 웹(web) 입니다.

최근 RIA 개발에 Ajax가 가미되면서 Client-side 와 Server-side 가 완전히 분리되고 Client 에서는 UI에 전념할 수 있게 되었습니다.

하지만 이에 "대화형 웹 어플리케이션"을 위한 Ajax와 DOM 스크립팅이 그 만큼 중요하게 되었는데요.

크로스브라우징, 사용자 리소스 최적화 등의 이슈가 되고 있습니다. 그렇게 좀더 가볍고 저사양에서도
또한 글로벌 스탠다드가 되기 위하여 최고의 퍼포먼스를 낼 수 있는 RIA 설계가 중요하게 되었습니다.

우리는 IE, FF, Opera, Safari 의 크게 4가지의 브라우저를 기본으로 크로스 브라우저에 대응합니다.
이에 몇가지 브라우저별 퍼포먼스를 비교해봅니다.


DOM 스크립팅 퍼포먼스 (HTML DOM Operation Performance)

                                        IE7             FireFox            Safari       
HTML DOM Operation                   Time(ns)  %       Time(ns) %        Time(ns) %
Change text using innerHTML          469.0   9979%     234.0  6000%      109.0  7032%
Create a text node on HTML Dom       1093.0  23255%    156.0  4000%      110.0  7097%
Change the class name of an element  422.0   8979%     47.0   1205%      109.0  7032%
getElementById                       86.8    1846%     15.7   401%       3.9    252%
getElementsByTagName("div")          153.1   3257%     18.0   462%       5.5    352%
getElementsByName                    93.8    1995%     44.6   1142%      4.7    303%
placeDiv.getAttribute("id")          29.7    632%      46.8   1200%      5.5    352%
placeDiv.attributes["id"]            31.3    665%      225.0  5769%      6.3    403%

IE7의 결과는 UI 개발자의 손목에 수갑을 채우고 있습니다.  꼭 이런 문제뿐만 아닙니다.
IE8에는 많은 문제가 해결되고 표준에 의거하여 개발에 임했으면 합니다.



eval function의 수행 퍼포먼스(2번)
IE7       172ns and 94ns 
FireFox  546ns and 749ns
Safari    9.4ns and 22.7ns

과연 eval은 크로스 브라우징 대응에 있어서 사용을 줄여야합니다.


Object 생성 수행 퍼포먼스
“var myObject = new MyObject (17, 250);
“var slowCar = {m_tireSize:17, m_maxSpeed:250};”

IE7         11.7ns and 8.6ns
FireFox   23.4ns and 23.4ns
Safari      3.2ns  and 2.4ns

Ajax 개발 시 Server-side 에서 JSON 을 받아올 경우 Firefox의 경우 Object화 하여 사용할 경우
경우에 따라 퍼포먼스에 많은 영향을 미칩니다.


in 수행 퍼포먼스
IE7         10.3ns
FireFox   62.8ns
Safari      7.6ns


  Firefox 도 Ajax 개발 시 경우에 따라 상당히 느려지는 부분을 보이고 있습니다.
하지만 IE6의 경우보다는 매우 양호합니다. IE6의 경우는 대부분의 Ajax 개발 관련 Performance 테스트에서 
몇 백 퍼센트의 차이를 보이고 있습니다. 
  특히 IE의 경우 String 퍼포먼스에서 매우 낮은 결과를 보입니다.  

DOM 스크립팅시에 우리는 DOM 구조를 일일이 생성하는 것 보다 String innerHTML을 자주하게 활용하는데요. 
IE의 경우 퍼포먼스에 지대한 영향을 미칩니다. 
그래서 우리는 Array 를 이용 string buffer 기능을 사용하여 효율적으로 처리하고 있지만 전체적으로 IE의
경우 String에 낮은 퍼포먼스를 보입니다.

마지막으로 Safari 의 경우 다른 브라우저들에 비해 상당히 안정되고 최고의 퍼포먼스를 자랑하고 있습니다.
역시 아직까지 다른 브라우저에 비해 기능 차이가 있기 때문입니다.

체감하는 렌더링 속도도 상당히 차이가 있음을 느낍니다.

	Internet Explorer 7		FireFox		Safari
Description	Time (ns)	% of base	Time (ns)	% of base	Time (ns)	% of base
Normal Empty function call (Base Operation)	4.7	100%	3.9	100%	1.6	100%
Basic Function Calls
Function call using function.call(this)	5.5	116%	2.4	60%	1.6	100%
Normal Empty function using apply	5.5	117%	7.0	179%	2.4	152%
Normal Empty function using apply with 3 parameters	7.0	149%	7.1	181%	2.4	152%
Eval a function	172.0	3660%	546.0	14000%	9.4	603%
Eval an object	94.0	2000%	749.0	19205%	22.7	1461%
Basic Operations
Access Properties through a getter	13.3	282%	6.3	160%	5.5	352%
Access Properties directly	4.7	100%	3.2	81%	2.4	152%
Simple string concatenation	4.7	100%	2.3	59%	1.6	100%
Simple string compare	3.9	83%	2.4	60%	0.8	48%
Change string to upper case	11.7	249%	3.9	100%	4.7	303%
Replace string reg expression	12.5	266%	7.1	181%	9.4	603%
String concat with integer	7.1	150%	4.7	119%	2.4	152%
String concat with float	6.3	133%	4.7	121%	2.4	152%
Index of Bob in string, not found, length = 71	6.3	133%	6.3	160%	2.4	152%
Match of Bob in string, not found, length = 71	14.9	316%	25.0	640%	3.9	252%
charAt(10) in string	11.7	249%	6.3	160%	3.1	200%
Create object constructor initialized	11.7	249%	23.4	600%	3.2	203%
create simple object	8.6	182%	23.4	600%	2.4	152%
		0%
Variable declaration	4.0	84%	2.3	59%	0.8	48%
Multiple variable declaration, multiple var	3.9	83%	2.4	60%	2.4	152%
Multiple variable declaration single var	3.9	83%	2.4	60%	1.6	100%
Variable declaration set to null	3.9	83%	2.4	60%	1.6	100%
		0%
Variable assignment++	4.7	100%	5.5	140%	1.6	103%
Variable assignment + 1	5.5	116%	7.1	181%	1.6	100%
Four levels of property access	5.5	116%	5.5	140%	1.6	100%
Three levels of property access	4.7	100%	4.7	121%	2.4	152%
Two levels of property access	4.7	100%	4.7	119%	1.6	100%
One level of property access	3.9	83%	4.7	121%	1.6	103%
		0%