Кратко

  • Первый публичный проект Beacon, выпущенный W3C в октябре 2013 года, перечислял способы задержать уход ради статистики: синхронный XMLHttpRequest, загрузку изображения и пустые циклы ожидания.
  • Проект кандидатской рекомендации от августа 2022 года описывал navigator.sendBeacon(): небольшие односторонние данные принимает браузер, а читатель продолжает движение.

Представьте администратора кафе, который догоняет вас у двери. «Прежде чем вы уйдете, я должен сообщить руководству, что вы ушли». Бумажка помещается в ладони; процедура занимает ваше время. На веб-странице такую сцену создавал скрипт аналитики. Новая страница казалась медленной потому, что старая не закончила свои дела.

Первый публичный рабочий проект W3C от 29 октября 2013 года описывал конфликт. Аналитике и диагностике нужно было передать последние данные во время выгрузки документа. Асинхронный запрос мог исчезнуть вместе со страницей. Разработчики порой использовали синхронный XMLHttpRequest, незавершенную загрузку картинки или цикл, который только тратил секунды. Проект прямо связывал эти приемы с задержкой следующей навигации.

Раннее предложение передавало обязанность отправки пользовательскому агенту. Метод в документе 2013 года назывался beacon и отличался по форме от позднейшего navigator.sendBeacon(). Важна последовательность: первый документ показывает исходную боль и направление решения, поздний — подробно описывает знакомый вызов. Общее у них одно: страницу освободили от роли человека, который держит дверь, пока уходит письмо.

Последний отчет бывает нужен. Событие может стать известно только в конце сеанса. Отправлять каждый сигнал немедленно — расходовать сеть и заряд; копить до последнего момента — рисковать потерей. Плохой компромисс заставлял посетителя расплачиваться ожиданием. Beacon нашла другого распорядителя очереди: браузер принимает маленькую посылку и работает с ней в собственном темпе.

Проект кандидатской рекомендации W3C от 3 августа 2022 года определяет navigator.sendBeacon(url, data) для асинхронной, неблокирующей передачи небольших данных в одну сторону. Браузер может согласовать ее с более срочной сетевой работой и группировать запросы для экономии ресурсов. Нажатие, анимация и следующая страница не обязаны стоять за окошком старой аналитики.

Пример 2022 года обращает внимание на visibilitychange: когда документ становится скрытым, можно передать отчет о сеансе. На телефоне приложение нередко уходит в фон, а позднее система завершает процесс без надежного события unload. Ждать торжественной команды «выгрузка» там, где дверь может закрыться без звонка, — сомнительное расписание. Момент скрытия дает более практичный сигнал.

Результат sendBeacon() говорит лишь о приеме данных в очередь. Значение true означает, что браузер взял конверт. Доставку проверяют по записям сервера; обратного вызова для обработки ответа у этого метода нет. Можно узнать, что курьер принял письмо, и не выдавать это за подпись адресата.

Объем письма ограничен. Документ 2022 года связывает запрос с fetch и флагом keepalive, с пределом для данных, ожидающих передачи. Если нужны особые заголовки, другой метод или ответ, следует использовать подходящие возможности fetch. У почтальона есть сумка, но он не грузовик для переезда.

История публикаций W3C ведет от первого проекта 2013 года через кандидатскую версию 2017-го к проекту 2022-го. Эти даты относятся к спецификации. Суть истории остается человеческой: у страницы есть последняя записка, а у читателя уже есть другие планы.

Хороший результат почти незаметен. Следующий адрес открывается без задержки, выдуманной ради отчета предыдущей страницы. Браузер берет маленькое поручение, сайт получает более приличный способ вести учет. У выхода больше не требуют дождаться звонка из бухгалтерии.