이 문서는 초안이며 언제든지 업데이트, 대체 또는 폐기될 수 있습니다. 진행 중인 작업이 아닌 다른 것으로 본 문서를 인용하는 것은 적절하지 않습니다.
본 문서는
W3C
특허 정책에 따라 운영되는 그룹에 의해 제작되었습니다.
W3C는
공개 특허 공개 목록을 유지하고 있으며,
그룹의 산출물과 관련된 특허 공개가 있을 경우 해당 페이지에 안내와 함께 공개됩니다. 실제로 특허를 알고 있는 개인은
필수 청구가 포함되어 있다고 생각하는 경우
W3C 특허 정책 6절에 따라 정보를 공개해야 합니다.
웹 애플리케이션의 성능 특성을 정확하게 측정하는 것은 웹 애플리케이션을 더 빠르게 만드는 중요한 요소입니다.
[JSMEASURE]에 설명된 것과 같은
JavaScript 기반 메커니즘은 사용자 지연 측정을 위한 포괄적인 인스트루먼테이션을 제공할 수 있지만,
많은 경우 완전하거나 상세한 종단 간(latency) 지연 정보를 제공하지 못합니다.
예를 들어 아래 JavaScript는 페이지가 완전히 로드되는 데 걸리는 시간을 측정하려는
단순한 시도를 보여줍니다:
<html><head><scripttype="text/javascript">var start = newDate().getTime();
functiononLoad() {
var now = newDate().getTime();
var latency = now - start;
alert("page loading time: " + latency);
}
</script></head><bodyonload="onLoad()">
<!- Main page body goes from here. -->
</body></html>
위의 스크립트는 head의 첫 JavaScript가 실행된 이후 페이지가 로드되는 데 걸리는 시간을 계산하지만,
서버에서 페이지를 가져오는 데 걸리는 시간이나 페이지의 초기화 라이프사이클에 대한 정보는 제공하지 않습니다.
<script>functionshowNavigationDetails() {
// 첫 번째 entry 가져오기const [entry] = performance.getEntriesByType("navigation");
// 개발자 콘솔에 보기 좋게 테이블로 출력console.table(entry.toJSON());
}
</script><bodyonload="showNavigationDetails()">
2.
용어
실제로 인터페이스인 Foo를 지칭할 때, "an object implementing the interface Foo" 대신에
"a Foo object"라는 표현을 사용하는 경우가 있습니다.
전체적으로 모든 시간 값은 문서의 네비게이션 시작 시점부터 경과된 밀리초 단위로 측정됩니다. 예를 들어, 문서의 네비게이션 시작은 0 시점에 발생합니다.
현재 시간이라는 용어는 문서의 네비게이션 시작 후 현재 시점까지 경과한 밀리초를 의미합니다.
이러한 시간의 정의는 [HR-TIME] 명세를 기반으로 합니다.
workerStart는 PerformanceResourceTiming에서
노출되지만, 네비게이션 타이밍에서는 서브리소스와 달리 네비게이션이 서비스 워커의 활성화 또는 실행을 트리거할 수 있습니다.
네비게이션 타이밍 컨텍스트에서는 workerStart가 워커가 활성화되거나 시작되기 직전의 타임스탬프를 반환합니다.
더 정확한 정의는 [service-workers]를 참고하세요.
네비게이션에 서비스 워커가 사용될 때,
fetchStart 오버로드는
PerformanceResourceTiming의 의미와 다릅니다.
서비스 워커에 대해 FetchEvent가
디스패치 되기 직전의 타임스탬프를 반환합니다.
네비게이션 타이밍 엔트리의 workerStart와 fetchStart의 시간 차이를 통해 워커가 초기화 또는 활성화되는
데 걸린 대략적인 시간을 알 수 있습니다.
더 정확한 정의는 [service-workers]를 참고하세요.
정교하게 설계된 타이밍 공격을 통해 최종 사용자의 브라우징 및 활동 이력이 노출될 가능성이 있습니다. 예를 들어, 언로드 시간으로 이전 페이지의 unload 핸들러가 실행된 시간을 알 수
있으며, 이를 통해 사용자의 로그인 상태를 추론할 수 있습니다. 이러한 공격은 문서 언로드 시 동일 출처 검사 알고리즘을 강제 적용함으로써
완화되었습니다. 자세한 내용은 HTML
명세를 참고하세요.
동일한 호스트명을 공유하는 서로 다른 페이지(예: 사용자 생성 콘텐츠가 있는 사이트의 서로 다른 작성자 콘텐츠)는 경로(pathname)로 접근을 제한하는 기능이 없으므로 동일 출처로
간주됩니다. 이러한 페이지 간 네비게이션을 통해 이후의 페이지가 이전 페이지의 타이밍 정보(리디렉션 및 언로드 이벤트 타이밍 등)에 접근할 수 있습니다.
사용자 에이전트와 웹 서버 사이에 프록시가 배치된 경우,
connectStart
와 connectEnd
속성 사이의 시간 간격은 사용자 에이전트와 프록시 사이의 지연을 나타내며, 웹 서버가 프록시의 존재를 추론할 수 있습니다.
SOCKS 프록시의 경우 이 시간 간격은 프록시 인증 시간과 프록시가 웹 서버에 연결하는 데 걸리는 시간도 포함되어 프록시 감지를 어렵게 합니다.
HTTP 프록시의 경우 사용자 에이전트가 프록시 서버에 대해 아무런 정보를 알지 못할 수도 있으므로, 이런 공격을 항상 완화하는 것은 불가능할 수 있습니다.
이 속성은 선택 사항입니다. 이 속성을 사용할 수 없는 사용자 에이전트는 undefined로 설정해야 합니다. 이 속성을 사용할 수 있고,
현재 페이지의 scheme [URL]이 "https"인 경우,
이 속성은 사용자 에이전트가 현재 연결을 보안 처리하기 위해 핸드셰이크를 시작하기 직전의 시간을 반환해야 합니다. 이 속성이 있지만 HTTPS가 사용되지 않는 경우 0을
반환해야 합니다.
requestStart
이 속성은 사용자 에이전트가 서버, HTTP 캐시 또는 로컬 리소스에서
현재 문서를 요청하기 직전의 시간을 반환해야 합니다.
요청이 전송된 후 트랜스포트 연결이 실패하고 사용자 에이전트가 연결을 재설정하여 요청을 다시 보내는 경우,
PerformanceTiming.requestStart는 새로운 요청에
해당하는 값을 반환해야 합니다.
참고
이 인터페이스에는 요청 전송 완료(예: requestEnd)를 나타내는 속성이 포함되어 있지 않습니다.
사용자 에이전트가 요청 전송을 완료했다는 사실이 네트워크 트랜스포트에서의 실제 완료 시간을 항상 의미하지는 않으므로, 그런 속성의 장점이 크지
않습니다.
일부 사용자 에이전트는 HTTP 계층 캡슐화로 인해 실제 요청 전송 완료 시간을 결정하는 데 높은 비용이 발생합니다.
responseStart
이 속성은 사용자 에이전트가 서버, HTTP 캐시 또는 로컬 리소스에서
응답의 첫 바이트를 받은 직후의 시간을 반환해야 합니다.
responseEnd
이 속성은 사용자 에이전트가 현재 문서의 마지막 바이트를 받거나, 트랜스포트 연결이 종료되기 직전(둘 중 먼저 발생)을 반환해야 합니다. 문서는 서버, HTTP 캐시 또는 로컬 리소스에서
받을 수 있습니다.
이 속성은 현재 브라우징 컨텍스트에서 마지막 비-리디렉션 네비게이션의 타입을
반환합니다. 반드시 아래 네비게이션 타입 값 중 하나를 가져야 합니다.
참고
Refresh
pragma 지시문과 같은 클라이언트 측 리디렉션은 이 명세에서 HTTP 리디렉션으로 간주되지 않습니다.
이런 경우 type
속성은 현재 페이지를 리로드하면 TYPE_RELOAD, 새 URL로 네비게이션하면 TYPE_NAVIGATE와 같이
적절한 값을 반환해야 합니다.
redirectCount
이 속성은 현재 브라우징 컨텍스트에서 마지막 비-리디렉션 네비게이션 이후의 리디렉션 횟수를 반환해야 합니다. 리디렉션이 없거나 목적지 문서와 동일 출처가 아닌 리디렉션이
있는 경우 0을 반환해야 합니다.
timing 속성은 마지막 비-리디렉션 네비게이션 이후 브라우징 컨텍스트와 관련된 타이밍 정보를 나타냅니다. 이 속성은
PerformanceTiming 인터페이스에 의해 정의됩니다.
navigation
navigation 속성은 PerformanceNavigation 인터페이스에 의해 정의됩니다.
9. 적합성
비규범적으로 표시된 섹션뿐만 아니라, 이 명세에서 작성 지침, 다이어그램, 예시 및 참고 사항도 모두 비규범적입니다. 명세의 나머지 부분은 모두 규범적입니다.
이 문서에서 SHOULD라는 키워드는
BCP 14
[RFC2119] [RFC8174]에서 설명한 대로,
오직 대문자로 나타날 때만 해당 의미로 해석됩니다.
A.
감사의 글
Anne Van Kesteren, Arvind Jain, Boris Zbarsky, Jason Weber,
Jonas Sicking, James Simonsen, Karen Anderson, Nic Jansma, Philippe Le
Hegaret, Steve Souders, Todd Reifsteck, Tony Gentilcore, William Chan
그리고 Zhiheng Wang에게 본 작업에 대한 기여에 감사를 표합니다.
