요약

  • 2013년 W3C Performance Timeline 권고안은 이름, 종류, 시작 시각, 길이를 가진 PerformanceEntry와 getEntriesByType() 같은 조회 방법을 정했다.
  • 2015년 Level 2 초안은 새 기록이 작성될 때 콜백으로 알려 주는 PerformanceObserver를 추가했다. 2016년 후보 권고안과 현재 문서는 전달과 버퍼 규칙을 다듬었다.

"페이지가 느리다"는 말은 쉽다. 왜 느린지 찾으려면 항해의 시작, 자료의 도착, 사이트가 직접 표시한 순간들을 살펴야 한다. 2013년 W3C Performance Timeline 권고안은 기록마다 이름, 종류, 시작 시각, 걸린 시간을 붙였다. getEntries()와 getEntriesByType()으로 이미 모인 기록을 꺼낼 수 있었다. 기록실은 훌륭했지만, 새 카드가 들어왔는지 알아보려면 매번 직접 문을 열어야 했다.

한 번 확인한 뒤에도 페이지의 일은 계속된다. 이미지가 도착하고, 스크립트가 표식을 남기고, 또 다른 자료가 로드된다. 프로그램은 몇 초마다 서랍을 뒤질 수 있다. 그러나 카드를 쓰는 쪽은 브라우저다. 기록원이 새 카드를 넣을 때 벨을 울리면 조사원이 복도만 오가다 하루를 보내지 않아도 된다.

2015년 9월 Performance Timeline Level 2 작업 초안은 두 예를 나란히 놓았다. 하나는 저장된 기록을 읽는다. 다른 하나는 PerformanceObserver를 만들고 콜백과 관찰할 종류를 지정한다. 브라우저가 해당 종류의 새 측정을 남기면 목록이 전달된다. 여러 기록을 묶어 처리하고 일이 끝나면 관찰을 끊을 수 있다. 새 카드가 들어온 시간을 아는 쪽이 알림도 맡게 된 셈이다.

W3C 발행 이력은 Level 2 첫 공개 초안을 2015년 7월 16일로 기록한다. 2016년 12월 8일 후보 권고안은 관찰자 등록, 기록 종류, 콜백 전달을 더 자세히 정했다. 그 과정에서 페이지가 저절로 빨라진 것은 아니다. 성능 기록을 알아채는 담당자가 서랍 앞에 서 있을 이유가 줄었다.

벨을 울릴 일을 정하는 것은 사이트다. 첫 화면의 이미지가 늦는다고 생각하면 자료 기록을 보고, 어떤 조작이 버벅인다면 그 앞뒤에 작성자 표식을 놓는다. 브라우저는 공통 기록 양식과 알림 경로를 제공한다. 팀은 어떤 기록이 독자의 기다림과 관련 있는지 판단한다. 모든 카드가 올 때마다 벨을 울리게 해 놓고 읽지 않는다면 사무실만 시끄러워진다.

현재 Performance Timeline 명세는 새 기록과 종류에 따라 저장된 과거 기록을 다룬다. 종류별 버퍼에는 크기가 있고, 넘쳐서 버린 기록의 수도 규정한다. 서랍은 무한하지 않다. 관찰을 시작한 시점과 누락된 카드 수를 확인해야 손에 든 목록을 제대로 읽을 수 있다.

브라우저가 측정하고 도착을 알린다. 사이트 담당자는 그 숫자가 독자에게 어떤 기다림이었는지 따지고 고칠 일을 고른다. 초시계는 사진이 언제 왔는지 알려 준다. 그 사진을 화면 절반에 올린 선택은 편집부가 설명해야 한다.