페이지가 느렸다. 이미지마다 초시계를 쥐여 줬다.

요약

• W3C가 2011년 5월 24일 공개한 첫 Resource Timing 작업 초안은 이미지 같은 개별 자원의 이름, 시작점, 이름 조회, 연결, 요청, 응답 시간을 기록하는 방법을 제시했다.
• 2017년 3월 30일의 1단계 후보 권고안은 자원 기록을 성능 시간표에 놓고 유한한 버퍼를 설명했다. 외부 자원의 세부 시간은 서버가 Timing-Allow-Origin으로 공개 범위를 정했다.

페이지가 느려졌다. 대표 이미지는 스타일시트를 탓했고, 스타일시트는 스크립트를 지목했다. 스크립트는 서버를 흘겨봤다. 페이지 전체의 로딩 시간은 독자가 기다렸다는 사실을 알려 주지만, 어느 짐이 수하물 벨트를 막았는지는 가르쳐 주지 않는다. Resource Timing은 도착하는 파일마다 초시계를 하나씩 건넸다. 책임 떠넘기기 회의가 비로소 자료를 갖추게 된 셈이다.

W3C가 2011년 5월 24일 공개한 첫 Resource Timing 작업 초안은 페이지 안에서 생기는 지연을 문제로 삼았다. 예시는 이미지 한 장을 가져오는 데 걸린 시간을 보았다. 문서의 이동과 문서를 채우는 자원의 도착은 서로 다른 규모의 사건이다. 제목이 보인 뒤에도 사진은 오는 중일 수 있다. 이미지, 스타일, 스크립트를 하나의 총시간에 담으면 결과는 알 수 있어도 늦게 온 손님은 찾기 어렵다.

초안은 자원마다 이름, 가져오기를 시작한 요소의 종류, 단계별 시각을 남겼다. fetchStart, domainLookupStart, connectStart, requestStart, responseStart, responseEnd를 보면 이름 조회, 연결, 요청, 첫 응답과 수신 종료를 나눠 볼 수 있다. 느린 이미지가 발견되면 팀은 어느 구간에서 시간이 흘렀는지 물을 수 있다. “인터넷이 안 좋아서”라는 말 한마디로 보고서를 끝내기 어려워졌다.

시각이 서로 붙어 있어도 이상한 일만은 아니다. 브라우저가 이미 열린 연결을 재사용하거나 캐시에서 파일을 꺼내면 몇몇 네트워크 단계는 반복되지 않는다. 같은 값은 고장 난 시계가 아니라 이미 지나간 길을 다시 걷지 않았다는 뜻일 수 있다. 두 번의 방문을 비교할 때 한쪽은 캐시가 차 있고 다른 쪽은 비어 있는지도 밝혀야 한다. 기록은 그때 그 자원을 가져온 한 번의 여정이다.

W3C의 2017년 3월 30일 Resource Timing Level 1 후보 권고안에서는 자원 기록이 성능 시간표에 자리 잡았다. 예시는 performance.getEntriesByType('resource')로 항목을 꺼내고 initiatorType이 img인 것을 고른 뒤 responseEnd와 startTime을 비교한다. 이미지들을 나란히 놓아 늦은 파일을 찾고 세부 단계를 살필 수 있다. 스타일과 스크립트에도 같은 방식이 통한다. 페이지 전체가 이미지 한 장의 지각을 대신 변명할 필요가 줄었다.

기록장에는 장수 제한이 있다. 2017년 문서는 자원 시간 버퍼와 setResourceTimingBufferSize(), clearResourceTimings() 같은 관리 방법을 설명한다. 가져올 파일이 많은 페이지는 공간을 채울 수 있다. 기록을 수집하는 쪽이 얼마를 남기고 언제 비울지 결정해야 한다. 뒤쪽 항목이 빠졌다고 해서 그 파일들이 빛보다 빨리 도착한 것은 아니다. 기록장이 먼저 꽉 찼을 수 있다.

외부 서버는 별도의 열쇠를 쥔다. 다른 출처에서 온 자원도 시간표에 나타날 수 있지만, 브라우저는 기본적으로 세부 단계의 공개를 제한한다. 그 자원을 제공하는 서버가 Timing-Allow-Origin 응답 헤더를 보내면 지정한 출처가 자세한 시각을 읽을 수 있다. 남의 이미지를 페이지에 붙였다는 이유만으로 그 서버의 내부 초침까지 모두 볼 권리는 생기지 않는다. 작은 눈금의 공개는 제공자가 정한다.

이 때문에 제한된 칸을 읽는 법도 달라진다. 외부 이미지의 이름과 전체 시간이 보여도 DNS, 연결, 응답의 세부값은 가려질 수 있다. 빈칸을 “그 일은 0밀리초 만에 끝났다”로 해석하면 닫힌 문을 순간이동 기록으로 바꾸는 셈이다. 제공자가 공개하면 더 많은 단서를 얻고, 공개하지 않으면 보이는 범위에서 조사한다. 관측의 한계도 기록의 일부다.

W3C가 2026년 9월 1일 낸 후보 권고안 초안은 자원별 접근을 이어 가면서 초기 문서보다 많은 속성과 더 큰 버퍼를 기술한다. 2011년 작업 초안, 2017년 후보 권고안, 2026년 초안은 같은 시기의 같은 목록이 아니다. 시간에 따라 바뀐 내용을 구분해야 한다. 이어지는 생각은 단순하다. 브라우저가 각 자원의 도착 과정을 공통 형식으로 남기고 페이지가 그 내역을 살핀다.

가장 오래 걸린 이미지가 반드시 첫 수리 대상인 것은 아니다. 화면 아래 멀리 있어 독자의 첫 장면과 관계가 작을 수 있다. 조금 덜 느린 다른 파일이 정작 제목을 가로막을 수도 있다. Resource Timing은 파일의 운송장을 준다. 편집과 개발 팀은 그것을 화면 배치와 표시 순서에 맞춰 읽어야 한다. 그제야 이미지를 줄일지, 배달 방식을 바꿀지, 먼저 요청할지, 늦게 불러올지를 정할 수 있다.

회의실의 문장도 달라진다. “페이지가 느리다”는 불평이다. “이 이미지는 여기서 기다렸고, 스타일시트는 연결을 다시 썼고, 외부 제공자는 세부 시간을 열지 않았다”는 할 일 목록이다. 초시계가 직접 수리하지는 않는다. 그래도 대표 이미지가 스타일시트를 탓하려면 자기 출근 기록부터 내밀어야 한다.