Navigation Timing API(PerformanceTiming Interface)

발생일: 2011.10.27

문제:
window.performance.timing 객체에 대해 정리해보자.


해결책:

웹 애플리케이션의 성능이 이슈가 되면서,

W3C는 애플리케이션의 성능을 측정할 수 있는 방법을 만들어내는 것을 목적으로 Web Performance Working Group을 구성했다.

2011년 10월 현재, 여러 스펙이 Draft 상태로 구축되었으며,
지금 알아볼 네비게이션과 엘리먼트에 접근하는 타이밍과 관련된 Navigation Timing 스펙은 ED(Editor's Draft) 상태에 있다.

Navigation Timing API는 IE9~, FF7~, Chrome 등의 브라우저에 performance.timing 객체로 구현되어 있다.

(구현 상태: http://caniuse.com/#search=performance.timing 참조)

여기서는 performance.timing 객체와 관련된 PerformanceTiming 인터페이스의 속성에 대해 정리해보려고 한다.
(스펙에 기재된 내용을 이해하기 쉽게 번역한 정리본이다. 원문 링크) 

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    
    브라우저가 문서를 만들기 시작하는 시점. 문서 준비 상태(5)가 "loading"이 되었을 때. (6)

domInteractive    
    브라우저가 문서 준비 상태를 "interactive"로 변경하는 시점.

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) 문서 준비 상태의 각 단계(http://www.w3.org/TR/html5/dom.html#current-document-readiness)
     "loading": 문서를 생성하고 파싱하는 단계.
     "interactive": 파싱이 종료되고, 남은 리소스를 가져오는 단계.
     "complete": 로드가 완료된 상태. 

* Navigation Timing을 처음 접한 다면 도움이 될 만한 페이지:
  http://www.html5rocks.com/en/tutorials/webperformance/basics/