요약

  • W3C가 2013년 10월 공개한 첫 Beacon 초안은 동기식 XMLHttpRequest, 이미지 불러오기, 빈 반복문으로 통계를 보내려다 페이지 이동을 늦추던 관행을 지적했다.
  • 2022년 8월 후보 권고안은 navigator.sendBeacon()으로 작은 단방향 보고를 브라우저에 맡기고, 독자의 이동을 막지 않은 채 전송을 계획하는 흐름을 설명했다.

카페를 나서는데 직원이 따라와 말한다. “손님이 나갔다고 본사에 보고해야 하니 잠깐만 기다려 주세요.” 보고서는 손바닥만 한데 손님의 발은 묶인다. 예전 웹에서도 이런 일이 일어났다. 새 페이지를 눌렀는데 옛 페이지의 통계 업무가 끝나지 않아 다음 화면이 늦게 열렸다.

2013년 10월 29일 W3C의 첫 공개 작업 초안은 문제를 숨기지 않았다. 분석과 진단 코드는 문서가 사라지기 직전에 마지막 자료를 보내고 싶어 했다. 비동기 요청은 페이지가 없어지며 취소될 수 있었다. 그래서 동기식 XMLHttpRequest로 나가는 동작을 붙잡거나, 이미지 로딩을 걸어 두거나, 아무 일도 하지 않는 반복문으로 시간을 벌었다. 다음 페이지가 느리다고 느껴진 원인이 이전 페이지의 장부일 수 있었다.

초안은 자료를 사용자 에이전트에 건네는 방향을 제시했다. 2013년의 메서드는 beacon이라는 이름과 다른 호출 형식을 썼다. 뒤에 나온 navigator.sendBeacon()을 초기 초안의 코드에 그대로 덧씌우면 역사 순서가 뒤섞인다. 계속 이어진 생각은 단순하다. 떠나는 페이지가 문을 붙잡는 대신 브라우저가 봉투를 받는다.

마지막 보고가 필요한 이유도 있다. 세션이 끝나야 알 수 있는 사건이 있다. 자잘한 일을 매번 즉시 보내면 네트워크와 배터리를 쓴다. 모두 쌓아 두었다가 맨 끝에 보내면 페이지와 함께 사라질 수 있다. 나쁜 해법은 그 사이의 불편을 독자의 대기 시간으로 결제했다. Beacon은 브라우저에게 작은 발송 업무를 넘기는 길을 만들었다.

2022년 8월 3일 W3C 후보 권고 초안은 navigator.sendBeacon(url, data)을 작은 단방향 자료를 위한 비동기 호출로 설명한다. 브라우저는 중요한 입력과 화면 작업에 방해되지 않게 전송 우선순위를 조정하고, 경우에 따라 요청을 묶어 자원을 아낄 수 있다. 독자의 다음 클릭과 화면 전환이 퇴근하는 페이지의 보고서 뒤에 줄 설 필요가 없다.

2022년 예시는 문서가 숨겨질 때 visibilitychange로 세션 보고를 건넨다. 휴대전화에서는 앱이 배경으로 간 뒤 운영체제가 프로세스를 종료할 수 있다. 그때 unload이 제대로 울리리라 기대하기 어렵다. 문이 닫히기 전에 꼭 작별 인사를 할 거라고 믿는 것보다, 보이지 않게 되는 순간 봉투를 넘기는 편이 실용적이다.

sendBeacon()이 돌려주는 true의 의미는 정확하다. 브라우저가 자료를 전송 대기열에 받아들였다. 서버에 도착했는지는 서버 기록을 봐야 한다. 이 인터페이스에는 페이지가 응답을 처리할 콜백도 없다. 우체부가 편지를 받았다는 말과 수취인이 서명했다는 말 사이에는 아직 길이 남아 있다.

봉투에는 크기 제한이 있다. 2022년 문서는 fetch의 keepalive와 연결된 요청을 설명하며 대기할 수 있는 자료의 양을 제한한다. 별도 헤더나 방법, 응답 확인이 필요한 업무라면 적절한 fetch 수단이 맞다. 작은 봉투를 실은 우체부를 이삿짐 차로 쓰면 본래 맡긴 일까지 어려워진다.

W3C 공개 이력에는 2013년 첫 공개 초안, 2017년 후보 권고 스냅샷, 2022년 후보 권고 초안이 차례로 놓인다. 이는 규격 문서의 시간표다. 그 아래의 질문은 변하지 않았다. 페이지의 마지막 말을 누가 들고 갈 것인가, 그 때문에 누가 출구에서 기다릴 것인가.

좋은 변화는 기다림이 사라지는 데서 보인다. 독자는 다음 페이지로 간다. 브라우저는 작은 보고를 자기 일감으로 받아든다. 옛 페이지의 장부 정리는 방문자의 발목을 잡지 않고도 계속된다.