Ускорение сайта давно стало обязательной гигиеной: картинки и блоки грузятся не сразу, а по мере того, как посетитель до них доходит. Пока человек читает первый экран, остальная страница существует в виде заглушек. Решение честное и полезное — до тех пор, пока на сайт не приходит трафик, который прокручивает страницу не так, как человек.
И вот здесь начинается тихая потеря. Сессия отработала, время набрано, прокрутка выполнена — но половина контента на странице так и не подгрузилась, события просмотра блоков не сработали, цель на дочитывание не засчиталась. В отчётах видно ровно то, что зафиксировалось, а зафиксировалось меньше, чем произошло. Разберём механику этой дыры, где она встречается чаще всего, как согласовать скорость прокрутки с подгрузкой и что проверять, чтобы убедиться, что сигнал действительно доходит.
Как устроена отложенная загрузка
Есть два основных механизма, и ведут они себя по-разному.
Встроенный атрибут браузера
Простейший вариант — указать изображению признак отложенной загрузки, и дальше браузер сам решает, когда его запросить. Решение принимается по расстоянию до видимой области, причём с запасом: браузер начинает подгружать заранее, а не в момент появления в кадре. Этот механизм самый устойчивый, потому что работает на уровне движка и не зависит от скриптов.
Скриптовое наблюдение за видимостью
Более гибкий и куда более распространённый вариант: на элементы вешается наблюдатель, который срабатывает, когда элемент попадает в видимую область или приближается к ней. По срабатыванию подставляется настоящий адрес картинки, инициализируется виджет, подгружается следующая порция карточек. Здесь всё зависит от настроек: насколько заранее срабатывает наблюдатель, какая часть элемента должна попасть в кадр, есть ли задержка.
Подгрузка порциями при прокрутке
Третий случай — бесконечные ленты и каталоги, где новая порция запрашивается с сервера при приближении к концу списка. Здесь к задержке отрисовки добавляется сетевая задержка, и разрыв между «прокрутил» и «увидел» становится максимальным.
Прокрутка и появление контента — два разных события, разнесённые во времени. Быстрая прокрутка проходит мимо блока раньше, чем блок успевает появиться, и с точки зрения измерения этот блок посетитель не видел.
Где именно теряется сигнал
Слишком быстрая прокрутка
Самая частая причина. Сценарий прокручивает страницу до низа за пару секунд, потому что задача формально звучит как «проскроллить до конца». Наблюдатели срабатывают, но браузер не успевает загрузить и отрисовать изображения, а порционная подгрузка вообще не успевает сходить на сервер. Формально прокрутка была, фактически страница осталась пустой.
Прокрутка мгновенным прыжком
Ещё хуже — перемещение в конец страницы одним скачком. Промежуточные положения не проходятся вовсе, значит наблюдатели на средних блоках не срабатывают ни разу. Такая прокрутка не только теряет контент, но и сама по себе выглядит нечеловечески: живой человек не перемещается по странице телепортацией, и характер движения анализируется, о чём говорилось в материале про эмуляцию мыши и прокрутки.
Прокрутки нет вообще
Бывает и обратная крайность: сценарий просто держит страницу открытой нужное время. Тогда подгружается только первый экран, а всё остальное остаётся заглушками. Время набрано, но никаких признаков изучения материала нет: ни просмотренных блоков, ни дочитывания.
Высота страницы меняется на ходу
Коварный технический нюанс. Пока картинки не загружены, заглушки могут занимать меньше места, чем настоящие изображения. Сценарий рассчитывает прокрутку от текущей высоты документа, доезжает до «низа» — а страница в этот момент вырастает, потому что подгрузились картинки. В результате бот останавливается в середине, будучи уверенным, что дошёл до конца. Цель на дочитывание при этом не срабатывает никогда.
Окно без реального размера
Если среда запуска даёт нестандартную или нулевую видимую область, наблюдатели могут вести себя непредсказуемо: либо не срабатывать вовсе, либо срабатывать сразу для всех элементов. Второе не менее вредно — вся страница «появляется» одномоментно, что тоже не похоже на человека.
Таблица: как ведёт себя сценарий и что в итоге фиксируется
| Поведение сценария | Что происходит с контентом | Что фиксируется |
|---|---|---|
| Прокрутка до низа за две секунды | картинки не успевают загрузиться | просмотр блоков не засчитан |
| Мгновенный прыжок в конец | средние блоки пропущены | ни одного срабатывания наблюдателя |
| Без прокрутки, только время | загружен первый экран | время есть, вовлечённости нет |
| Расчёт высоты до подгрузки | страница выросла в процессе | дочитывание не засчитано |
| Плавная прокрутка с паузами | контент успевает появиться | блоки и дочитывание засчитаны |
| Прокрутка вниз и частичный возврат | контент загружен, повтор просмотра | полная картина взаимодействия |
Почему это бьёт по поведенческим показателям
Потеря здесь не такая очевидная, как при полной блокировке трафика, но она системная.
Дочитывание не фиксируется
Цель, настроенная на достижение определённой доли страницы, — один из самых говорящих сигналов вовлечённости. Если бот останавливается на середине из-за выросшей высоты документа, эта цель не срабатывает никогда, и в отчётах видно визиты без единого признака глубокого чтения.
Время не подкреплено действиями
Долгий визит без взаимодействия выглядит слабее, чем визит той же длины, но с прокруткой, просмотром блоков и возвратами. Ровно тот случай, когда формальная цифра есть, а содержания за ней нет. Это тесно связано с тем, как вообще трактуются глубина и отказы, о чём подробно говорилось в материале про отказы и глубину просмотра.
Запись сессии выглядит странно
При просмотре записи визита видно пустую страницу с заглушками, по которой стремительно проезжает полоса прокрутки. Человеческая запись выглядит иначе: контент появляется, движение замедляется в местах, где есть что читать, встречаются возвраты. Как запись визитов используется для выявления неестественного поведения, разбиралось в статье про запись визитов как детектор.
Нет запросов за ресурсами
Ещё один малозаметный след. У живого визита к серверу уходит поток запросов за изображениями по мере прокрутки. У сессии, которая проехала страницу мгновенно, этих запросов почти нет. Разница видна в журналах сервера и создаёт отличимый рисунок, никак не связанный с отпечатком браузера.
Как согласовать прокрутку с подгрузкой
Измерить, а не угадать
Первый шаг — узнать реальные цифры своего сайта. Откройте страницу, прокрутите её медленно и посмотрите, с какой задержкой появляются изображения и через какое время приходит следующая порция карточек. Именно от этих значений, а не от абстрактных рекомендаций, надо строить темп.
Прокручивать шагами с паузами
Рабочая схема — короткие шаги по части высоты экрана с паузой между ними. Пауза должна превышать реальное время появления контента с запасом. Между шагами уместны небольшие остановки разной длительности: человек читает неравномерно.
Пересчитывать высоту документа
Обязательный пункт. Конечную точку прокрутки нельзя вычислять один раз в начале: высота документа растёт по мере подгрузки. Пересчитывать её надо на каждом шаге, а признаком достижения конца считать ситуацию, когда высота перестала меняться после нескольких шагов подряд.
Дожидаться появления контента, а не времени
Более надёжный подход, чем фиксированные паузы, — ждать признака появления содержимого: изображение перестало быть заглушкой, число карточек в списке выросло. Тогда сценарий подстраивается под реальную скорость сайта в каждый момент, а не под усреднённое значение.
Добавлять возвраты
Живой человек прокручивает вниз, что-то замечает, возвращается немного назад, перечитывает. Возвраты не только правдоподобны, но и полезны технически: они дают наблюдателям второй шанс сработать на блоках, которые в первый проход проскочили.
Учитывать тип устройства
На мобильном прокрутка инерционная, с рывками и затуханием, а видимая область меньше, значит блоков на страницу приходится больше и подгрузок тоже больше. Мобильный сценарий не может повторять десктопный по таймингам. Заодно проверьте, что сам профиль устройства согласован — типовые расхождения разбирались в материале про отпечаток железа.
Таблица: механизмы подгрузки и требования к сценарию
| Механизм | Что запускает загрузку | Что обязан делать сценарий |
|---|---|---|
| Встроенный признак у изображения | приближение к видимой области | прокручивать плавно, без прыжков |
| Наблюдатель видимости на блоке | попадание элемента в кадр | выдерживать паузу на отрисовку |
| Подгрузка порции с сервера | приближение к концу списка | ждать роста числа элементов |
| Отложенная инициализация виджета | первое появление контейнера | останавливаться на блоке дольше |
| Фоновая подмена адреса картинки | срабатывание наблюдателя | проверять, что заглушка исчезла |
| Ленты без конца | каждая новая прокрутка вниз | ограничивать число порций |
Проверка за один прогон
- Откройте страницу вручную и засеките, сколько времени проходит от появления блока в кадре до полной отрисовки изображения.
- Для лент и каталогов замерьте отдельно время прихода следующей порции элементов.
- Проверьте, меняется ли высота документа по ходу прокрутки, и насколько сильно.
- Запустите один сеанс сценария и посмотрите запись визита: появляется ли контент или полоса едет по заглушкам.
- Проверьте, срабатывает ли цель на дочитывание, и на какой доле страницы бот фактически останавливается.
- Посмотрите журналы сервера: должны быть видны запросы за изображениями по ходу сессии, а не только за первым экраном.
- Сравните число сработавших событий просмотра блоков с ожидаемым для полного прохода страницы.
- Повторите проверку отдельно для мобильного сценария — тайминги там будут другими.
- После настройки прогоните небольшую партию и сравните долю визитов с засчитанным дочитыванием до и после.
Разбор кейса: длинные статьи, которые никто не дочитывал
Контентный проект работал над поведенческими показателями по большим обзорным материалам. Тексты были длинные, с большим числом иллюстраций, и вся графика грузилась отложенно — так решали задачу скорости загрузки. Сессии заказывались с расчётом на глубокое чтение: длительное время, прокрутка до конца, переход на соседнюю статью. В отчётах картина выходила странная: время присутствия нормальное, а цель на дочитывание срабатывала у единиц, хотя сценарий формально предусматривал прокрутку до низа.
Разбор начали с записи визитов. На записи было видно, как полоса прокрутки едет вниз по странице, состоящей практически целиком из серых прямоугольников: изображения не успевали появиться. И, что важнее, движение останавливалось примерно на середине материала. Причина оказалась именно в высоте документа: сценарий вычислял конечную точку один раз на старте, когда картинки были заглушками и страница была заметно короче. Как только графика начинала подгружаться, документ вырастал, а бот уже считал, что доехал до конца, и переходил к следующему шагу.
Переделка свелась к трём изменениям: прокрутка шагами с паузой, превышающей реальное время отрисовки; пересчёт высоты документа на каждом шаге с условием остановки только после того, как высота стабилизировалась; добавление коротких возвратов назад в местах с иллюстрациями. Доля визитов с засчитанным дочитыванием выросла принципиально, записи сессий стали выглядеть как нормальное чтение, а в журналах сервера появился ожидаемый поток запросов за изображениями. Объём сессий при этом не менялся вообще — изменилось только то, сколько сигнала от каждой из них доходило. Планирование объёмов оставили прежним, по логике из материала про длительность цикла.
Частые ошибки
- Считать высоту документа один раз. Страница растёт по мере подгрузки, и конечная точка, вычисленная на старте, окажется серединой материала.
- Прокручивать мгновенным прыжком. Промежуточные блоки не проходятся, наблюдатели не срабатывают, и картина выглядит нечеловечески.
- Задавать одинаковые тайминги для десктопа и мобильного. На мобильном меньше видимая область, больше подгрузок и другая физика прокрутки.
- Ограничиваться временем без прокрутки. Долгий визит без взаимодействия даёт цифру, за которой нет признаков изучения материала.
- Не проверять результат по записи визита. Единственный способ увидеть своими глазами, что страница осталась пустой, — посмотреть запись, а не отчёт с цифрами.
Частые вопросы
Может, проще отключить отложенную загрузку на время работы? Не стоит. Скорость загрузки — самостоятельный фактор, который влияет и на живых посетителей, и на оценку страницы. Ухудшать реальное качество сайта ради удобства сценария — обмен в минус. Правильнее подстроить сценарий под сайт, а не наоборот.
Насколько медленно нужно прокручивать? Универсального числа нет, и подставлять чужие значения бессмысленно: скорость подгрузки зависит от вашего сервера, веса изображений и структуры страницы. Ориентируйтесь на собственный замер и закладывайте запас поверх него, а ещё лучше — ждите появления контента вместо фиксированной паузы.
Влияет ли это на живых посетителей? Косвенно да. Если высота страницы скачет из-за подгрузки, у реального человека тоже съезжает содержимое под пальцем, что раздражает. Резервирование места под изображения заранее решает обе задачи сразу: и человеку удобнее, и сценарию проще считать высоту.
Как понять, что проблема именно в отложенной загрузке? По трём признакам одновременно: цель на дочитывание почти не срабатывает при формально выполненной прокрутке, на записи визита видны заглушки вместо контента, в журналах сервера нет потока запросов за изображениями. Совпадение всех трёх — практически диагноз.
Вывод
Отложенная загрузка делает сайт быстрее, но превращает прокрутку в условие появления контента, а не в самостоятельное действие. Сценарий, который проезжает страницу за пару секунд, прыгает в конец одним движением или вычисляет высоту документа один раз на старте, оставляет половину материала неподгруженной: просмотры блоков не засчитываются, дочитывание не фиксируется, а время присутствия остаётся цифрой без содержания. Лечится это не отключением ускорения, а согласованием темпа: измерить реальную задержку появления контента на своём сайте, прокручивать короткими шагами с паузами больше этой задержки, пересчитывать высоту документа на каждом шаге и останавливаться только после её стабилизации, добавлять возвраты и разводить тайминги для десктопа и мобильного. Проверять результат нужно не по отчёту с цифрами, а по записи визита и журналам сервера — там сразу видно, читал бот страницу или ехал по серым прямоугольникам. Объём сессий при такой настройке не меняется, меняется доля сигнала, которая от них доходит, а это как раз то, за что вы платите.
Больше о поведенческом продвижении и других услугах — на главной странице ProfSEO24.
Закажите накрутку ПФ в ProfSEO24
Выводим сайты в ТОП-1 Яндекса за счёт поведенческих факторов на базе ИИ — без риска фильтров. Более 300 сайтов в ТОП-1, первые сдвиги по позициям за 3 дня. Рассчитаем стоимость под вашу нишу и регион.
Заказать накрутку ПФ Написать в TelegramКомментарии
Григорий Астафьев
Про высоту документа, которая растёт по ходу подгрузки, — я бы сам до этого не додумался никогда. Бот честно считает, что доехал до конца, а он на середине.
Admin
Это самая недооценённая ловушка в теме. Условие остановки надо формулировать не как «доехали до вычисленной отметки», а как «высота документа не менялась на протяжении нескольких шагов подряд». Тогда сценарий сам подстраивается под сайт любой длины и любую скорость подгрузки.
lazy_load_pro
Отсутствие запросов за картинками в журналах — отдельный след, о котором вообще нигде не пишут. Отпечаток идеальный, а сервер видит, что никто ничего не грузил.
Вера Кондратьева
Посмотрела запись визита после этой статьи. Полоса едет вниз по серым прямоугольникам, ровно как описано. Стыдно и полезно одновременно.
Матвей Синицын
А не проще на время работы просто выключить отложенную загрузку? Картинок у нас немного, скорость не критична.
Admin
Матвей, я бы не советовал. Во-первых, вы ухудшаете реальную скорость для живых посетителей ради удобства сценария — обмен явно не в вашу пользу. Во-вторых, это временное решение: рано или поздно загрузку вернут, и проблема всплывёт снова, только уже без вашего участия. Гораздо надёжнее один раз научить сценарий ждать появления контента. Если картинок правда мало и они лёгкие, посмотрите в сторону резервирования места под изображения: тогда высота страницы перестанет скакать, и половина проблемы исчезнет сама.
scroll_bot
Ждать появления контента вместо фиксированной паузы — принципиально другой уровень надёжности. Сайт тормозит в час пик, а сценарий подстраивается.
Жанна Тихомирова
Возвраты назад как способ дать наблюдателям второй шанс сработать — красивая мысль. И правдоподобно, и технически полезно.
Илья Барановский
У нас бесконечная лента в каталоге. Там же ещё сетевая задержка сверху, порция идёт с сервера. Тайминги совсем другие получаются.
Admin
Илья, для лент фиксированные паузы почти не работают, и ориентироваться надо на признак: считать количество карточек в списке и продолжать прокрутку только после того, как оно выросло. Если за разумное время новая порция не пришла, сценарий должен подождать ещё, а не ехать дальше. И обязательно заложите ограничение по числу порций — иначе бот будет листать бесконечную ленту бесконечно, что само по себе выглядит странно. Живой человек в каталоге обычно долистывает до нескольких экранов и переходит в карточку товара.
pixel_watch
Три признака диагноза в конце — прямо готовый чек-лист. Цель на дочитывание молчит, запись в заглушках, в журналах пусто. Всё сходится.
Регина Юсупова
Мобильный сценарий не может повторять десктопный по таймингам — а ведь у большинства он именно скопирован один в один.
Admin
Регина, различий там сразу несколько. Видимая область меньше, значит на ту же статью приходится в разы больше шагов прокрутки и в разы больше срабатываний подгрузки. Канал обычно медленнее, значит картинки появляются с большей задержкой. И сама физика движения другая: инерционный рывок с затуханием вместо равномерной прокрутки колесом. Копия десктопного сценария на мобильном даёт быстрый проезд по заглушкам и рисунок движения, которого на телефоне не бывает.
Влад Ситников
Объём сессий не менялся, изменилась доля доходящего сигнала. Вот это самое важное в кейсе: результат без увеличения бюджета.
observer_io
Про нулевую видимую область в среде запуска: у нас наблюдатели срабатывали сразу на всех элементах. Страница появлялась целиком за миг, тоже неестественно.
Admin
Классический признак запуска без нормального окна. Проверяется просто: выведите на странице фактические размеры видимой области прямо из сессии и сравните с тем, что заявляет профиль. Если они не совпадают или выглядят нестандартно, это проблема не только для отложенной загрузки — расхождение между заявленным разрешением и реальной областью отрисовки само по себе читается как признак автоматизации.
Эльвира Наумова
Резервирование места под изображения помогает и людям, и сценарию. Редкий случай, когда одно техническое улучшение закрывает сразу две задачи.
Тарас Мельниченко
Проверять надо по записи визита, а не по отчёту с цифрами — согласен полностью. Цифры красивые бывают при полностью сломанной картине.
speed_freak
По опыту работы с ProfSEO24: там не гонятся за красивым отчётом, а лезут смотреть записи сессий и журналы. Из-за этого находятся вещи, о которых сам бы не догадался. Эта статья ровно про такой подход.