늦게 켜진 것은 페이지의 시계였다. 브라우저는 영수증을 내밀었다.

Summary

• W3C가 2010년 10월 26일 낸 첫 공개 초안은 페이지 스크립트가 켠 시계로는 스크립트가 도착하기 전의 기다림을 잴 수 없다는 문제에서 출발했다.
• 2012년 12월 17일 권고안은 탐색 시작, DNS, 연결, 응답, 문서 준비의 시각을 정리했다. 무엇을 모아 비교하고 고칠지는 여전히 사이트가 결정했다.

호텔에 도착한 손님이 이미 지쳐 있다. 차를 기다리고, 주소를 찾고, 입구 앞에서 줄을 섰다. 프런트 직원은 손님이 눈앞에 나타난 뒤에야 초시계를 누른다. 삼십 초 만에 열쇠를 건네며 빠른 체크인을 자랑한다. 숫자는 틀리지 않았다. 다만 손님이 왜 한참 늦게 방에 들어왔는지는 설명하지 못한다. 페이지의 첫 스크립트에서 시작한 로딩 측정도 비슷했다.

W3C의 2010년 10월 26일 첫 공개 초안은 이를 짧은 코드 예로 보여 준다. 문서 머리 부분의 스크립트가 실행 시각을 적고, 나중에 로드 이벤트가 일어난 시각에서 뺀다. 그러나 그 스크립트를 담은 문서 자체가 오기까지의 시간은 빠진다. 브라우저가 주소를 찾고 연결을 만들고 응답을 기다리는 동안 이용자는 이미 기다리고 있었다. 스크립트만 아직 현장에 없었을 뿐이다.

초안의 해법은 처음부터 현장에 있던 브라우저에게 기록을 맡기는 것이었다. navigationStart가 탐색의 시작을 표시하고, performance.timing의 다른 값들이 다음 구간을 적는다. 페이지는 로딩 끝과 탐색 시작의 차이를 구할 수 있다. 뺄셈보다 중요한 것은 출발 시각의 주인이 바뀐 점이다. 늦게 실행된 스크립트가 과거를 추측하는 대신, 브라우저가 직접 본 시각을 건넸다.

영수증에는 합계만 쓰이지 않았다. fetchStart는 가져오기나 캐시 확인의 시작, domainLookupStart와 domainLookupEnd는 이름 조회, connectStart와 connectEnd는 연결 구간을 가리킨다. requestStart, responseStart, responseEnd는 요청과 첫 응답, 문서 수신의 끝을 나눈다. 문서가 로딩을 시작하고 상호작용할 수 있게 되며 DOM 관련 이벤트를 마치는 시각도 뒤따른다. 한 덩어리였던 “느린 페이지”를 주소 찾기, 문 열기, 음식 기다리기, 방 정리 중 어느 문제인지 물을 수 있게 된 셈이다.

2011년 6월 2일 후보 권고안을 거쳐 2012년 12월 17일 W3C 권고안은 PerformanceTiming의 항목과 해석 규칙을 확정했다. W3C의 발행 이력에는 2010년 초안부터 2011년 후보 단계, 2012년 권고안까지의 순서가 남아 있다. 영수증이 쓸모 있으려면 항목 이름만 나열해서는 안 된다. 모든 사람이 각 칸의 의미에 동의해야 한다.

어떤 칸은 같은 시각을 가리킬 수도 있다. 브라우저가 기존 연결을 재사용하면 새 연결을 기다릴 일이 없다. 캐시에 문서가 있다면 네트워크의 일부 단계도 달라진다. 시작과 끝이 같은 값을 가졌다고 무조건 계측기가 고장 났다고 말하면, 한 차에서 내리지도 않은 손님에게 두 번째 택시 요금을 청구하는 꼴이다. 권고안은 재사용과 캐시가 시간 필드에 어떻게 나타나는지 정했다.

시계 자체도 믿을 만해야 했다. 2012년 문서는 탐색 도중 시스템 시계가 조정돼도 연속된 사건 사이의 시간이 거꾸로 흐르지 않도록 단조 시계를 요구했다. 호텔 계산서에 승강기가 출발하기 삼 분 전에 도착했다고 쓰여 있다면, 승강기 속도를 논하기 전에 계산서부터 다시 봐야 한다. 촘촘한 숫자보다 사건의 순서가 먼저다.

보여 주지 않는 정보도 있었다. 다른 출처를 가로지르는 리디렉션에서는 자세한 리디렉션 시각을 0으로 만든다. 도착한 페이지가 이전 사이트의 움직임을 시간 단서로 엿보지 못하게 하려는 규칙이다. 권고안은 한 호스트 이름 아래 서로 다른 작성자의 페이지가 있어도 기술적으로 같은 출처로 취급될 수 있다는 점도 짚었다. 브라우저가 그은 경계와 실제 운영 주체의 경계가 늘 일치하지는 않는다.

Navigation Timing이 통계를 자동으로 모으거나 느린 페이지를 고쳐 준 것은 아니다. 2010년 초안부터 수집, 저장, 보고는 애플리케이션의 몫이었다. 2012년 권고안도 이 인터페이스를 브라우저 브랜드의 단순 속도 경연에 쓰는 도구로 보지 않았다. 한 번의 방문에는 기기, 네트워크, 캐시, 페이지 코드의 조건이 함께 들어간다. 영수증을 받는 것과 수리할 곳을 정하는 일은 다른 단계다.

그럼에도 질문은 달라졌다. “사이트가 느리다”는 말은 아무에게나 책임을 떠넘길 수 있다. “응답은 빨리 왔는데 문서가 상호작용 가능해지기까지 오래 걸렸다”는 말은 다음 조사 대상을 가리킨다. 브라우저는 페이지가 태어나기 전의 시간을 기억하고 있었다. 프런트 직원의 초시계만 보던 회의에 긴 영수증이 올라온 것이다.