Как отключить кнопку назад в браузере

Обновлено: 07.01.2025

Примечание: статья посвящена обзору проблемы неработающей кнопки «назад» в браузере при использовании AJAX-методов для передачи содержания страниц от сервера к клиенту. В статье рассматриваются основные принципы работы AJAX и возможные пути решения заявленной проблемы. Курсивом даны мои комментарии.

Эта статья является первой из ряда материалов (вторая статья посвящена работе с закладками), направленных на устранение части критики, которую адресуют сейчас AJAX, и предоставляющих обзор полезных методов, которые помогут сделать ваши приложения и веб-страницы, использующие технику AJAX, немного лучше.

Суть проблемы

С самого начала в основе Веба лежала возможность поставить гиперссылку с одной страницы на другую. Ссылки между страницами была первично двунаправленными: это означало, что переход по ссылке со страницы А на страницу Б никаким образом не мог предотвратить ни переход по ссылке обратно на страницу А, ни использование кнопки «назад» в браузере. Цепочка таких страниц представляет собой историю посещения в браузере, с каждой из них связан уникальный URL. Если представить это с технической стороны, то такая цепочка реализуется в виде стека. В дальнейшем я буду использовать термин «горизонтальная» ссылка для обозначения связи между элементами такого стека.

Рисунок 1. Горизонтальные ссылки

Рисунок 2. Вертикальная ссылка между вторым URL'ом и сервером

Веб-сайт и веб-приложение

Подход, который стоит использовать для решения этой проблемы, напрямую зависит от того, что вы разрабатываете: веб-сайт или веб-приложение. Иногда тяжело разделить эти два понятия, но обычно веб-приложение можно отличить по следующим свойствам:

Перед использованием требуется авторизация
Серьезная работа с пользовательскими сессиями
Процесс взаимодействия пользователя с приложением имеет вполне определенное начало и конец

В качестве примера веб-сайта можно рассмотреть Yahoo! Finance и E*TRADE — в качестве веб-приложения. С точки зрения пользователя я могу сказать, что не всегда возможно провести четкую границу между этими двумя типами. Однако, веб-разработчикам стоит с самого начала определиться, что же они собираются разрабатывать: сайт или приложения? Если вам это понять, то можно задать простой вопрос: в отсутствии интернета чем лучше всего описывается ваша разработка: это набор Word'овых документов или же настольное приложение? Рассматривайте веб-приложения наравне с настольными с той лишь разницей, что первым еще требуется браузер для нормальной работы. Другой вопрос, который можно себе задать, звучит так: «Вашей главной целью будет предоставление информации или обеспечение функциональности?».

Первое решение: не злоупотребляйте вертикальными ссылками

Если вы собираетесь создать веб-сайт для публичного доступа, я бы советовал вам использовать AJAX только в случаях крайней необходимости (не злоупотреблять им). Возможно, будет требоваться изменение URL'а страницы, чтобы обновить ее всю, но при этом, я полагаю, иделогия правильной работы кнопки «назад» в браузере будет соблюдена. Помните, что не все вызовы AJAX сильно связаны с вертикальными ссылками (прим.: как я понимаю, автор имеет в виду прежде всего изменение каких-либо малых частей страницы при неизменном основном содержимом).

Легче всего просто не принимать во внимание неработоспособность кнопки «назад» в браузере, но полностью этим пренебрегать нельзя. Вместо того, чтобы создавать целостное приложение, использующее большое количество вертикальных ссылок и привязанное к единственному URL'у, создайте некоторое количество горизонтальных ссылок в тех местах, где это действительно требуется. Другими словами, используйте горизонтальные ссылки для разделения частей вашего приложения, например, таким образом, как это делается в бумажной литературе (книга делится на части и главы). Используя разумную комбинацию традиционных горизонтальных ссылок с вертикальными, можно добиться баланса мощи AJAX и возможности использовать функционал перемещения по истории браузера.

Прим.: в качестве примера, пожалуй, можно привести некоторое количество современных сайтов, на которых AJAX используется только для предоставления некоторых дополнительных возможностей, в частности, это Хабрахабр и механизм голосования/добавления комментариев.

Второе решение: используйте специальную AJAX-библиотеку

Прим.: ниже сгруппированы основные методы создание псевдо-горизонтальных ссылок, я постарался дополнить их известными мне примерами, расширив список статьи-первоистоника.

Прим.: суть решения: при каждом вызове AJAX к URL'у страницы в качестве якоря добавляется текущий номер элемента в стеке «истории», фактически, просто увеличивающиеся числа. При нажатии кнопки «назад» в браузере, URL страницы меняется на предыдущий. Каждые 100 (200, 400, 1000) миллисекунд страница проверяет, не изменился ли у нее якорь в URL'е, если якорь изменился, то осуществляется подгрузка данных, соответствующих текущему якорю (=элементу в стеке «истории»).

Подход Brad Neuberg'а, эта библиотека пытается быть максимально кроссбраузерной без лишнего усложнения кода. Хорошо, что она доступна под BSD opensource лицензией. Brad опубликовал пошаговую инструкцию создания этой библиотеки, равно как и онлайн-демо.

Plex — AJAX framework с открытым кодом, который поддерживает очень много возможностей, в том числе, и эмуляцию кнопки «назад» в браузере.

Dojo — еще один AJAX framework с открытым кодом, обеспечивающий некоторую AJAX функциональность и эмуляцию кнопки «назад» в браузере.

Не могу также не упомянуть про неплохую обзорную статью Vladimira Kelmana, в которой обсуждаются часть вышеупомянутых решений.

Решение третье: обеспечьте пользователям удобную альтернативу кнопки «назад»

Традиционно, кнопка «назад» служила для реализации концепции: «Верните меня туда, откуда я пришел» Однако, при нажатии на нее многие пользователи, на самом деле, подразумевают «отмените то, что я только что сделал». Чтобы избавить их от сооблазна воспользоваться кнопкой «обратно» не по назначению, можно создать кнопки с функциями «Отменить» или «Шаг назад» в вашем веб-приложении, использующем AJAX. Например, если вы разрабатываете в Вебе расширенный текстовый редактор, создайте кнопку «Отменить», которая предотвратит потерю пользователями целого документа при неверном нажатии кнопки «назад» в браузере.

Однако, самим плохим решением из всех, которые я видел, является создание альтернативной кнопки «назад» в пределах самой веб-страницы, используя AJAX-методы. Многие пользователи с трудом смогли привыкнуть к границе между браузером и веб-страницей, смогли понять, где кончается браузер и начинается, собственно, сама страница. Нет никакой необходимости усиливать их неудобства. Ведь вы не можете гарантировать, что те пользователи, которые легко с этим справились, смогут привыкнуть еще к одной «инновации» и изменят свои привычки ради вашего сайта. Обеспечить пользователей альтернативной навигацией и функционалом будет вполне достаточно, но никак не создавать эту кнопку заново.

В заключении, если вы все же ограничиваете функционал стандартной истории в браузере при создании веб-приложения, пожалуйста, поставьте пользователей об этом в известность тем или иным способом. AJAX не является первым методом, который ограничивает этот функционал, и, скорее всего, пользователи впервые узнают об этом тоже не от вас. (Есть еще апплеты, Flash и eCommerce приложения, которые могут снять с кредитной карточки сумму еще раз, если нажать кнопку «назад» в браузере.) Вес ответственности, который вы, в конечном счете, возложите на пользователя за его действия на сайте, будет зависеть от вашей корпоративной культуры, но почему бы не сделать его чуточку легче?

Спасибо всем, что читал, читает и будет читать мои переводы и статьи. Заранее хочу поблагодарить всех тех, что укажет на фактические неточности или ошибки в статье, а может быть, даст ссылки на дополнительную информацию.

Вероятно, каждый современный SEO-специалист находится в постоянном поиске методов улучшения поведенческих факторов своего сайта. Мы думаем как увеличить конверсию страниц или хотя бы получать «долгие клики».

Google, спасибо за идею

В процессе такого поиска находился и я, когда наткнулся на один интересный комментарий Джона Мюллера из Google. В переводе на русский он звучит примерно так: “те, кто настраивает у себя на сайте отключение кнопки «назад» браузера, не получат ни выгоды, ни проблем при ранжировании в поиске Google. То есть, манипулирование кнопкой возврата в браузере не влечет за собой санкции Google.”, ссылка на саму речь.

Сопоставив дату этой речи Мюллера (10 февраля 2017) с датой выхода патента о поведенческих факторах в Google (12 марта 2019) я крепко усомнился в том что такая техника всё ещё не влияет на ранжирование. Настало время экспериментировать.

Описанный в статье метод относится к категории black hat SEO (черные методы продвижения). Ведь он вредит пользователям вашего сайта и пытается влиять на алгоритмы поисковых систем. Кейс выполнялся исключительно в академических целях.

Ожидаемое влияние блокировки

При этом в Google ситуация обратная, сайты из результатов поиска тут открываются в той же вкладке, что и сам поиск. То есть заблокировав кнопку «назад» мы запрещаем пользователю возвращаться в поиск. У такого пользователя есть три варианта дальнейшего действия.

Действие	Возможная причина
Остаться на сайте	Лучше поискать на сайте интересующую информацию.
Закрыть сайт и не вернуться в поиск	На нашем или другом сайте пользователь уже нашел ответ на свой вопрос, либо вопрос не настолько важный.
Закрыть сайт и вернуться в поиск	Пользователь всё ещё не нашел ответ на свой запрос.

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

закрыть вкладку,
заново открыть поисковую систему,
повторно ввести поисковый запрос.

Если всё это сработает, то в результате мы должны увидеть рост позиций по целевым запросам в Google.

Скрипт блокировки

Для блокировки будем использовать небольшую функцию, выполненную на чистом JavaScript. Вот её код:

var str = document.referrer;
if(str.indexOf('google.') + 1) function preventBack()
setTimeout("preventBack()", 0);
window.onunload = function () ;
>;

В функции мы считываем значение переменной referrer (она показывает откуда пришел пользователь к нам на сайт) и если она содержит подстроку «google.», то запускаем постоянное нажатие на кнопки «вперед» браузера.

У данного скрипта есть и недостаток - при переходе между страницами сайта он может возвращать нас при клике на кнопку «назад» на страницу входа, но после этого произойдет переход «вперед» к внутренней странице на которую мы забрели.

Результат

Для исследования я взял две площадки - статейный сайт и агрегатор, на обоих сайтах до этого уже давно ничего не делалось. После внедрения блокировщика на них также ничего не делалось.

Пример использования скрипта на одном из сайтов:

В результате спустя 4 месяца поисковый трафик Google для агрегатора вырос на 74,4%, а для статейного сайта на 77,6%.

Данные показаны в относительных величинах (по просьбе моих партнеров), но речь идет о росте на несколько тысяч переходов с Google в месяц.

Так как оба сайта монетизируются через AdSense, от роста трафика вырос и доход. Но, приятным бонусом ещё является то что пока пользователь пытается вернуться назад у нас на сайте - он смотрит кучу рекламных объявлений.

В итоге средний расчетный доход по обоим сайтам в AdSense вырос на какие-то нереальные 216%. Правда из-за того что на одном сайте как-то слишком резко вырос доход на тысячу показов, мне кажется правильнее привязываться не к доходу, а к количеству показов рекламы. А количество показов рекламы выросло на 135%!

Что с этим делать

Пожалуй, ничего. Метод, конечно, очень интересный, но перед его использованием стоит крепко подумать: стоит ли выжигать лояльность посетителей своего сайта ради сомнительных результатов в SEO и роста дохода? Думаю, нет.

Остаётся вопрос к представителям Google, почему за такое сайт не получает наложение санкций. Может всё-таки пора их внедрять?

И на этом моменте статья должна была закончиться, но пока я её размещал наткнулся на тестирование в Google чекбокса «Открывать результаты в новой вкладке».

Значит, поисковая система уже знает проблему и собирается исключить возможность такой манипуляции. Будем надеяться что это тестирование покажет положительный результат и Google все-таки сделает бессмысленной блокировку кнопки «назад» в браузере.

Как отключить кнопку НАЗАД в браузере (во всех браузерах)?

Вы не владеете компьютерами своих пользователей или их браузерами. Почему мы настроены враждебно к этому вопросу? Насколько нам известно, человек, задающий этот вопрос, уже знает, что это плохая юзабилити-практика, но он просто выполняет требования или, может быть, просто хочет чему-то научиться. Почему бы нам просто не притвориться, что это гипотетический вопрос, и не ответить, как бы мы это сделали, ЕСЛИ бы нам пришлось поступить так? Некоторые вещи никогда не следует делать, независимо от желания их делать. Наличие необязательного требования для этого сразу говорит о том, что требования были установлены людьми, не имеющими отношения к бизнесу, а это гораздо более серьезная проблема. тьфу, я написал самый классный комментарий, но потерял его, когда случайно нажал кнопку возврата.

Этот вопрос очень похож на этот один .

Чтобы это работало, вам нужно принудительно истечь срок действия кеша. Поместите следующий код на свою страницу с кодом позади.

Не отключайте ожидаемое поведение браузера.

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

Я был бы согласен с Джонатаном, особенно с потоком перенаправляющей рекламы вредоносных программ, которая в настоящее время наводняет Интернет, они уже злоупотребляют системой предупреждений, чтобы затруднить уход со своих страниц, не давая им возможности фактически заблокировать вас на своей странице обратите внимание, что URL-адрес изменяется дважды: мы делаем это только для того, чтобы замаскировать реализацию, чтобы никто не увидел, что мы добавили «1». Так что на самом деле, когда пользователь щелкает назад, страница на мгновение повторно добавляет "№1" и снова удаляет его. Кстати, это не обязательно должно быть «1», это может быть любая строка. Проблема в том, что страница прокручивается вверх каждые 50 мс. Если у вас форма больше высоты окна, это сделает невозможным заполнение значений формы. Огромное спасибо. Это очень полезно для моей особенно интерактивной страницы на основе JavaScript, где прокрутка влево и вправо является частью механизма. Это помогает устранить проблему, связанную с жестом прокрутки в Mac OS X, когда пользователи случайно «возвращаются» на страницу (все это легко сделать, если они уже полностью прокручены).

Другие использовали подход, чтобы сказать «не делай этого», но на самом деле это не отвечает на вопрос автора. Давайте просто предположим, что все знают, что это плохая идея, но нам все равно интересно, как это делается .

Один из подходов, которые я видел для этого, - это передача токена по каждому URL-адресу в приложении и в каждой форме. Маркер повторно создается на каждой странице, и как только пользователь загружает новую страницу, все маркеры с предыдущих страниц становятся недействительными.

Когда пользователь загружает страницу, страница будет отображаться только в том случае, если ей был передан правильный токен (который был предоставлен всем ссылкам / формам на предыдущей странице).

Вы можете прикрепить какой-нибудь скрипт к событию onbeforeunload страницы и подтвердить пользователю, что это то, что он хочет сделать; и вы можете пойти немного дальше и попытаться отключить его , но, конечно, это будет работать только для пользователей, у которых включен javascript. Вместо этого посмотрите на переписывание приложения, чтобы вы не совершали транзакции на каждой странице отправки, а только в конце процесса.

Я настоятельно призываю вас пойти на героические меры, чтобы не сломать кнопку "назад", это верный способ оттолкнуть ваших пользователей и даже сделать это до No.1 в топ-10 ошибок веб-дизайна Джейкоба Нильсена в 1999 году .

Если ответ Скотта близок к цели, подумайте о том, чтобы изменить свой поток на модель PRG. Если это что-то другое, то дайте немного больше деталей и посмотрите, как мы можем помочь.

Лучший вариант - не зависеть от постбэков для управления потоком, однако если вы застряли с ним (на данный момент)

вы можете использовать что-то вроде этого:

Вскоре вы обнаружите, что он будет работать не во всех браузерах, но тогда вы можете ввести проверку в свой код, например:

Это в какой-то степени решит проблему, код не проверен-только для примеров..

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

Это правда, следует добавить правильную проверку, чтобы убедиться, что дубликаты данных не испортят ситуацию. Однако, как и в моем случае, я не полностью контролирую данные, так как использую какую-то стороннюю API после моей формы. Поэтому я использовал это

Это отправит пользователя вперед на "receipt", который должен появиться после "payment" страницы, если он попытается вернуться на "payment" страницу (например, просто заплатив). Используйте экономно, хотя

Я смог добиться этого, используя:

Найти ссылку ниже