RSS구독하기:SUBSCRIBE TO RSS FEED
즐겨찾기추가:ADD FAVORITE
글쓰기:POST
관리자:ADMINISTRATOR
Fronteers 2008 컨퍼런스 가 암스테르담에서 2008.9월 11일~12일 양일간 있었다.

Fornt-end 개발자들이 모여서 Javascript 와 CSS에 대해서 컨퍼런스를 가졌다.


그중에 Chris Heilmann 이 발표했던 "Maintainable Script" 비디오가 공개 됐다.

Chris Heilmann: Maintainable JavaScript, part 1 from Bachelor-ict.nl on Vimeo.



Christian Heilmann: Maintainable JavaScript, part 2 from Bachelor-ict.nl on Vimeo.


본문에 관한 PDF 가 있었는데 -_-..하드가 날라가면서 삭제된듯 싶다 ..orz...젝젝일슨 ;ㅂ;..
대신 slideshare.com 에 올라간 슬라이드로 대신한다!


2009/01/20 16:31 2009/01/20 16:31
이 글에는 트랙백을 보낼 수 없습니다
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다

재미있는 실험내용이 있어서 이렇게 펌질!~

전송속도 와 대기시간에 따른 페이지 로딩 시간에 관한 실험!

요즘은 너무 광대역폭 빠른 응답속도를 자랑하는 네트워크 망을 가져버린 상황인 지금은 크게 문제가 안되는듯 보이지만.

외국에선 아직도 회선 상태가 좋지 않다보니 이런 테스트도 아직도(?) 하는가보다.
(사실 -_-;; 가장 중요한것 아닌가!!!!!...이런 무개념을!! *쿨럭~*)

Time_to_load_wsj


월스트리트 저널의 홈페이지를 기준으로 테스트를 했는데.

여기서 한가지 재미있는 사실은..
대역폭의 감소보다 대기시간이 길어질 수록 로딩 시간이 더욱더 크게 벌어졌다는것이다.

대기시간이 길어지면서 패킷을 잃게 되고 다시 재전송을 하는데 소비되는 시간이 생각보다 크다는 것이다.

하지만 요즘 사용하는 대부분의 브라우저는 페이지 구성에 필요한 요소들을 다중으로 전송이 가능하다. 그렇다면 그와 연관된 모든 요소들을 한번에 땡겨오면 크게 차이가 나지 않아야 정상이 아닌가?

그렇다면 왜 저런 결과가 나왔을까?

본문에서는 기본적으로 HTML 소스를 읽어 오면서 그와 연관된 소스들을 다운로드
할 수 있어야 하는데, 문제는 "연관된 모든 요소들" 을 브라우저는 모르기 때문이다! 라고 이야기 한다.
HTML 을 모두 해석한 뒤 DOM tree 를 해석하고, 그 다음에 <img> 태그와 같은 외부 소스를 요청하는 것들을 처리하기 시작한다.

문제는 외부 Javascript 파일을 로딩하면서 발생한다.
Script 가 호출이 되기 전까진 HTML 을 해석하는 과정이 모두 중지된다. 여기에 document.write() 와 같은 부분이 끝 마치기 전까진 말이다.
이런것들이 대기시간을 더욱더 길게 만드는 것이다.

여기에 document.write 등으로 외부 소스를 호출하게 되면 더욱더 심각해져간다.


그래서 이 아저씨들이 수정을 살짝쿵 하였는데!
Time_to_load_wsj_preloading

스크립트 로딩하는 동안  메인 해석기( Main Parser) 가 멈춰져 있는 동안.
별도의 해석기 ( Side parser )기 가 나머지 HTML 소스를 기반으로 다른 외부 파일들(이미지,CSS,JS등 )을 호출을 하게 하여 대기시간에 따른 로딩시간 저하 현상을 최소화 하게 한다.

그 차이를 좀더 명확하게 보여주자면 다음 그래프를 보아라!
사용자 삽입 이미지

괜찮은 구조인거 같다..
사실 대역폭과 대기시간은 물리적인 문제라 S/W 적으로 해결하는데는
많은 어려움이 따르기 마련이지만 저정도 수준이면 상당히 의미있는것이 아닌가 한다.

모 CF 광고 처럼.. 미묘한 차이가 명품(?)을 만드는...?

참고 : Webkit - Optimizing Page Loading in the Web Browser
         Ajaxian.com - The importance of bandwidth versus latency
2008/03/29 03:37 2008/03/29 03:37
이 글에는 트랙백을 보낼 수 없습니다
peecky  | 2008/03/29 23:04
innerHTML 콘텐츠 삽입은 지원하면서 document.write 때문에 파싱을 멈추는 건가요~_~?
Dot  | 2008/03/30 12:49
그렇다기 보단 <script></script> 블럭의 연산중에 다른 부분에 대한 로딩이 제한이 된다고 봐야 할듯.
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다

연속 펌질 포스팅!!
(언젠...펌질 안했다고 ㅡㅡ;;...)

재미있는 글이 있어서 역시 또 펌질...

일단 본문 을 보쟈스랴..!

원문: A Study of Ajax Performance Issues


글의 전반적인 내용은 Web 2.0 , RIA 등 이전에는
(뻥을 약간 보태서) 상상도 못할 만큼의 웹 플랫홈의 변화가 왔었다.

Web 2.0 을 가장 단순하게 말하자면..
일반 클라이언트 프로그램과 같은 인터페이스가 웹에서도 구현이 된다는것이겠다..

거기엔 필연적으로 DOM 연산 이나 Javascript 실행속도 가 이전과 다르게 다루는 데이터량도 늘었고
또 그 빈도수도 늘어나면서
미묘한 차이가 전반적인 성능의 영향을 끼치게 되었다.

브라우저별 (IE7, Firefox , safari 를 마루타로!?) 취약한 부분들을 정리한 글이다..

글에서 제기한 Ajax 성능의 이슈를 정리하자면..

  1. Array ( 배열 ) 연산
  2. 일반적인 HTML DOM 연산
  3. 연산된 모달창 과 스타일
  4. Firefox 의 eval() 과 오브젝트 생성과 `IN` 연산
  5. IE7 의 문자열 연산
  6. Safari 의 `pop` 연산.


이런것들을 해결하기 위해서..
글쓴이가 내놓은 해결책은..

첫번째로 .. 브라우저 밴더들에게 진상을 부리자(응??...글쓴이가 정말 그런건..아니고..ㅡㅡ;;;)
두번째로 .. Ajax 연합을 만들어서 Ajax Runtime 환경을 만들어서 채용을 시키자는 내용이다..

영어실력이 일취월장하지 못해서 ㅡㅡ;; 여전히 개판같은 번역(?) 이지만..

당장은 Ajax Application 을 개발하면서 저런 부분을 감안하여 개발하는게
좋을것이지만. 역시 궁극적인 해결책은 ...'진.상.' 짓을 하면서..개발 밴더들을 압박하는게 나을지도.. ㅡㅡ;;


참고할만한 URL 을 하나 더 올린다.
참고 : The Great Browser JavaScript Showdown
         SunSpider JavaScript Benchmark

2008/01/29 01:12 2008/01/29 01:12
이 글에는 트랙백을 보낼 수 없습니다
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다
IE 에서 메모리 누수현상에 대해서 말들이 많았다.
물론 그에 대한 패치가 이루어졌다고 하나 ( IE JScript Memory Leak 패치 ! 참고)..
그에 대한 패치를 진행 되었음에도 그렇지 못하다는 내용의 글( IE6 main memory hot fixed ) 도 있었다.


거기에 M$ 개발팀이 메모리 누수 탐지기 ( --) 를 제공하였으니!
일단 보자스랴!

설치 방법은 스샷까지 첨부되어 아주 멋지게 정리 되어있으니.
본문을 참조하시면 좋겠지만...

( --) 너무 개념없는 포스팅이 될 것을 우려하여 정리해서 넣는다.

# 1 . 설치하기
1. Javascript Memory Leak Detector 를 다운 받아서 압축을 푼다.
2. 실행중인 모든 Internet Explorer 창을 종료한다.(중요)
3. 압축을 푼 설치 프로그램 ( jsleaksdetector.msi ) 을 실행한다.
4. Internet Explorer 탐색 창 에서 js memory leak detectors 를 활성화 시킨다.
ENABLE_JS_Memory_Leak_Detector


5. 도구 -> 인터넷 옵션 -> 고급 스크립트 에 '검색' 목록에서 디버거 비활성화 부분의 체크박스를 해제한다.

Enable_Debugger_options

# 2 . 실행하기

여기 까지 설정하였으면 Internet Exploere 하단에
다음과 같은 창을 볼 수 있으며 활성화 되고 다음 페이지 로딩때 부터 정보가 디스플레이 된다.
Leak_detector_window

참고 : GPDE Team Blog - Javascript Memory Leak Detector
         Ajaxian - Microsoft Javascript Memory Leak Detector
         IE JScript Memory Leak 패치 !
2008/01/28 09:05 2008/01/28 09:05
이 글에는 트랙백을 보낼 수 없습니다
[로그인][오픈아이디란?]
오픈아이디로만 댓글을 남길 수 있습니다
Dot:Where is ......
byDot
Where is ......
전체 (176)
주절거림 (60)
윈도우벽지 (2)
Shoveling.. (9)
주워들은것들.. (48)
요집이 괜찮더라!! (0)
찍사놀이 (7)
관심꺼리~ (4)
«   2018/08   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
  1. 내 맘대로 보는 세상  2009
    맘에 안드는 Internet Explorer 업데이트 방침!
  2. 시리니  2008
    브라우저 업데이트, 작지만 큰 실천입니다.
  3. Dinosur와 KM의 Blog  2007
    저도 보통 사람
  1. 2018/07 (1)
  2. 2018/01 (11)
  3. 2017/12 (10)
  4. 2017/10 (1)
  5. 2017/05 (13)