티스토리 뷰
발생일: 2013.01.02
키워드: 크롬 개발자 도구, Chrome Developer Tools, 네트워크 패널, Network panel
문제:
노트 정리하다 오래 전에 정리해둔 문서를 발견했다.
크롬 개발자 도구의 네트워크 패널에 대한 정리인데,
패널의 각 요소에 대한 설명이 명확히 되어있지 않아 정리를 시작했던 걸로 기억한다.
2011년 말에 생성하고 마지막 업데이트 2013년 1월이라 나온다.
꽤 오래된 노트이지만, 아직도 내용은 유효한 것 같아 옮겨둔다.
해결책:
크롬 개발자 도구 네트워크 패널의 각 속성
Size : 실제 응답 사이즈(헤더를 포함한 사이즈이며, gzip으로 압축된 경우 압축된 사이즈를 나타낸다)
Content : 응답 컨텐츠(body) 사이즈, 압축하기 전 컨텐츠의 사이즈
Time : 요청부터 응답까지의 전체 소요된 시간.
Latency : 지연 시간. 요청한 이후 서버가 응답을 시작하기 전까지의 시간. 즉, 실질적인 다운로드 시간을 제외한 나머지 시간.
Blocking: 브라우저에서 요청을 지연한 시간. 호스트별 커넥션 개수 제한에 따른 블럭킹을 나타냄. (브라우저별 동일 호스트에 대한 커넥션 제한 http://www.browserscope.org/?category=network&v=top)
Connecting: DNS Lookup 시간 (브라우저는 새로고침 할 때마다 DNS Lookup을 시도하는 것 같다. But, 아마도 OS레벨에서 캐시하고 있을 것~ http://serverfault.com/questions/171216/how-often-does-a-browser-need-to-perform-a-dns-lookup-for-then-same-site)
Sending: 요청을 보내는 시간
Waiting: 서버에서 응답을 처리하는 시간
Receiving: 다운로드 시간
* 서버 성능이 문제인가, 리소스 크기가 문제인가?
예: XHR 요청인 경우, 서버에서 처리하는 시간이 긴 반면, 응답 시간은 짧다.
* 같은 호스트로 여러 요청이 병렬로 동시에 진행되는 경우, DNS Lookup이 동시에 진행된다.
# 참고.
High Performance Web Sites: Rule 9 - Reduce DNS lookups http://developer.yahoo.com/blogs/ydn/posts/2007/07/high_performanc_7/
HTTP Connection States
- Blocking :
(a.k.a. Blocked)
- DNS Lookup : 호스트에 해당하는 IP를 검색하는 시간
- Connection :
(Connect, Start, Initial Connection)
- Sending :
(Send)
- Waiting :
(Wait)
* Sending + Waiting = Request, Time to First Byte
- Receiving :
(Receive, Response, Content Download)
Load Events
- DomContent : DOM content가 로드된 상태
(DomContentLoaded, Render Start, Start Render)
- Load
(Page Load, Document Complete)
Block (gray) – because nothing is really happening
Lookup DNS (yellow) – like the Yellow Pages
Connect (red) – because this is the tricky negotiation part (red is caution)
Send (blue) – it’s a good color that contrasts well with red
Wait (light purple) – a mellow color while we wait
Receive (green) – because this is the payment that’s been received (green like money – sorry for the U.S. bias)
그럼 전체적인 흐름은 어떻게 될까?
navigationStart 이전 페이지에서 도큐먼트가 unload를 시작한 시점('prompt to unload a document'를 끝낸 시점). (1) 이전 페이지가 없을 경우 fetchStart와 동일하다.
unloadEventStart 이전 페이지와 현재 페이지가 동일 근원(same origin)일 때, unload 이벤트를 시작하는 시점. 이전 페이지가 없거나 동일 근원이 아닐 경우 0.
unloadEventEnd unload 이벤트가 끝나는 시점.
redirectStart HTTP 리다이렉트나 동일 근원 상의 리다이렉트가 수행되는 경우, 그 시작 시점을 의미하며 fetchStart와 동일하다. 없을 경우 0.
redirectEnd 위와 같은 조건에서 마지막으로 리다이렉트된 응답의 첫 번째 바이트를 받은 시점. 없을 경우 0.
fetchStart HTTP 요청으로 새로운 리소르를 불러오기 시작하는 시점. 애플리케이션 캐시가 있을 경우 캐시 존재 여부를 체크하기 시작하는 시점. 캐시가 없는 경우, 리소스를 받아오기 시작하는 시점.
domainLookupStart 도메인에 해당하는 IP를 검색(DNS Lookup)하기 시작하는 시점. 이미 연결되어 있거나(2), 캐시되어 있거나, 로컬 리소스일 경우, fetchStart와 동일한 값.
domainLookupEnd DNS Lookup이 종료되는 시점. 조건에 해당하지 않을 경우, fetchStart와 동일.
connectStart 브라우저(3)가 문서를 받기 위해 서버와 연결을 시도하는 시점. 이미 연결되어 있거나, 캐시되어 있거나, 로컬 리소스일 경우, domainLookupEnd와 동일한 값.
connectEnd 브라우저가 서버와 연결을 맺은 시점. 조건에 해당하지 않을 경우, domainLookupEnd와 동일.
requestStart 브라우저가 서버, 애플리케이션 캐시 또는 로컬 리소스에 현재 문서에 대한 요청을 시작하는 시점. (4)
responseStart 브라우저가 서버로부터 응답 데이터의 첫 번째 바이트를 받은 시점.
responseEnd 브라우저가 응답 데이터의 마지막 바이트를 받은 시점 또는 연결이 끊기 시점 중 빠른 값.
domLoading 브라우저가 문서를 만들기 시작하는 시점. 문서 준비 상태가 "loading"이 되었을 때. (5)
domInteractive 브라우저가 문서 준비 상태를 "interactive"로 변경하는 시점. (6)
domContentLoadedEventStart 문서에서 DOMContentLoaded 이벤트가 호출되는 시점.
domComplete 브라우저가 문서 준비 상태를 "complete"로 변경하는 시점.
loadEventStart 문서의 "load" 이벤트가 발생하는 시점. 이벤트가 호출되지 않았다면 0이다.
loadEventEnd 문서의 load 이벤트가 완료된 시점.
(1) prompt to unload a document : http://dev.w3.org/html5/spec/history.html#prompt-to-unload-a-document
(2) persistent connection : '영구적인 접속' 또는 '지속적인 접속'이지만 문맥상 '이미 연결되어 있다'고이라고 번역
(3) User Agent 이지만 여기서는 브라우저라고 번역
(4) requestEnd는 스펙에 포함되어 있지 않다. request 완료 시점이 정확한 네트워크 완료 시점과 일치하지 않는 경우가 있고, 몇몇 User Agent는 HTTP Layer 캡슐화 때문에 request 종료 시점을 파악하는데 비용이 들기 때문이다.
(5) 문서 준비 상태(current document readiness). 문서 상태가 변경될 때마다 readystatechange 이벤트가 호출되며, document.readyState 속성에서 확인할 수 있다.
(6) 렌더링 엔진에 따라 다르겠지만, DOM Tree를 작성하는 시점.
# 참고
- Network Panel Docs: http://code.google.com/intl/ko/chrome/devtools/docs/network.html
- Chromium Blog: http://blog.chromium.org/2011/02/chrome-developer-tools-back-to-basics.html
- 스티븐 사우더스의 워터풀 차트 UI 컨벤션에 대한 의견
http://www.stevesouders.com/blog/2011/08/26/waterfall-ui-conventions/
- HTML5Rocks, 웹 퍼포먼스
http://www.html5rocks.com/en/tutorials/webperformance/basics/
- IE9 Performance Timing Object API
http://msdn.microsoft.com/en-us/library/ff975075
- W3C Navitagion Timing Spec : http://www.w3.org/TR/navigation-timing/
- W3C Resource Timing Spec : http://w3c-test.org/webperf/specs/ResourceTiming/
- Chrome Demo : http://webtimingdemo.appspot.com/