ua
/вхід
Koval SEO

Сторінка містить шаблон обробника unload

У звітіUnload/beforeunload handler pattern in first-party script

unload_handler_detected · Потребує перегляду

Коротка відповідь

Це з’являється, коли текст скрипта сторінки чи атрибут <body> відповідає шаблону обробника unload або beforeunload, як-от addEventListener('unload', …). Текстовим збігом може бути й код, що прибирає обробник, як-от onunload = null; він не доводить, що обробник зареєстровано. У настільних Chrome і Firefox слухач unload не пускає сторінку в кеш переходів назад і вперед, тож перевірте, чи слухач справді зареєстровано, і використовуйте натомість pagehide.

Серйозність: До уваги. На перегляд: це текстовий збіг, який може знайти також коментарі чи код, що ніколи не виконується.

Чому це важливо

Стаття web.dev про кеш переходів назад і вперед каже, що найважливіший спосіб оптимізувати під нього в усіх браузерах — ніколи не використовувати подію unload, що настільні Chrome і Firefox роблять сторінки зі слухачем unload непридатними, і радить натомість використовувати pagehide, а слухачі beforeunload додавати лише за умови.

Що зробити

  1. Перегляньте знахідку: вона показує обмежену кількість прикладів збігів у тексті скриптів чи атрибутах body, з номерами рядків і навколишнім текстом, коли їх збережено. Додаткові приклади можуть не потрапити до звіту, тому перед змінами перегляньте оригінальні скрипти.
  2. Перевірте, чи виконується код на сторінці: збіги в коментарях, рядках чи невикористаних бібліотеках не шкодять.
  3. Замініть обробники unload на pagehide, а beforeunload додавайте, лише поки є незбережені зміни.

Коли залишити як є: якщо збіг — у коментарі чи коді, який ніколи не виконується, або він прибирає обробник, як-от onunload = null, можна залишити як є.

Що ми читаємо

Ми читаємо текст вбудованих класичних і модульних скриптів кожної просканованої сторінки, до 128 КіБ кожен, атрибути onunload і onbeforeunload елемента <body> та скрипти з власного джерела сторінки, які завантажує аудит. Блоки даних, як-от JSON, і скрипти з інших джерел, зокрема з вашого субдомену CDN, пропускаються.

Сторінка фіксується, коли текст відповідає addEventListener з unload чи beforeunload або присвоєнню onunload чи onbeforeunload або коли <body> має такий атрибут. Нічого не виконується.

Сторінка позначається як неперевірена, коли її HTML не вдалося прочитати повністю, її вбудовані скрипти перевищують ліміти розміру або скрипт із її власного джерела не завантажено, він не відповів кодом 200, перевищує 1 МіБ, його не вдалося декодувати або він містить нульові символи.

Приклад і докази

Ілюстративний приклад — один рядок одного скрипта, а не реальний аудит.

https://bakery.example/js/cart.js, який завантажує https://bakery.example/cart/, містить:

window.addEventListener('unload', saveCart);

Збережений рядок відповідає шаблону слухача unload, тому сторінка фіксується з уривком скрипта й номером рядка. Перевірка не встановлює, чи виконується цей рядок і чи реєструє він слухача.

window.addEventListener('pagehide', saveCart);

Можливе виправлення: зберігайте кошик за подією pagehide.

Підтвердити й перевірити знову

Перевірте самі: відкрийте сторінку в Chrome, перейдіть на іншу сторінку й назад і подивіться в інструментах розробника, у розділі Application, Back/forward cache, причину, з якої її не відновлено.

Повторна перевірка: Повний аудит — запустіть новий аудит сайту. Знахідка закривається, коли сторінку знову проскановано, кожен скрипт, який вона читає, прочитано повністю і жоден не дає збігу. Скрипт із власного джерела сторінки, якого не було серед завантажених файлів, залишає знахідку відкритою.

Обмеження та джерела

Це текстовий збіг, а не виконання: він знаходить також коментарі, рядки й мертвий код і пропускає обробники, задані через бібліотеки, як-от .on('unload') у jQuery, або з назвами подій у змінних. Збіг beforeunload сам собою не показує, що сторінку не пускають у кеш, і жодного тесту кешу не робиться.

Упевненість: Низька, бо текстовий збіг не може визначити, чи зареєстровано обробник, коли сторінка виконується.

Джерела

  • web.dev, Кеш переходів назад і вперед — каже, що найважливіша оптимізація для bfcache — ніколи не використовувати подію unload, що настільні Chrome і Firefox роблять сторінки зі слухачем unload непридатними, і радить натомість pagehide. Перевірено 28 вересня 2026.

Редакційна перевірка: 1 листопада 2026