Навигация: переходы и ожидание загрузки

chromedp.Navigate отправляет браузеру команду смены адреса и возвращает управление тогда, когда страница загрузилась — то есть дождалась события load: основная разметка приехала, отработали синхронные скрипты, браузер объявил загрузку завершённой. Это важная гарантия: после Navigate дерево документа уже содержит то, что сервер отдал, — заголовки, шапку, статический каркас. Но она же и граница: всё, что появляется после load, Navigate не дожидается. Данные, подтянутые XHR-запросами, элементы, собранные React или Vue, счётчики и виджеты — к моменту возврата из Navigate их ещё нет. Отсюда правило чтения страниц: Navigate отвечает за смену адреса, а за появление контента отвечают действия с условиями — запросы, которые переспрашивают документ, пока селектор не совпадёт. Эти два уровня часто путают в одну кучу и потом недоумевают, почему «Navigate уже вернулся, а заголовка нет». Разделение простое: переход — синхронный про load, контент — асинхронный про DOM. Полезно знать и механику: Navigate шлёт браузеру команду навигации, а затем ждёт события о завершении загрузки, поэтому «вернулся из Navigate» — факт, подтверждённый браузером, а не догадка по таймеру. Каждый переход в одном контексте заменяет текущую страницу: по сути это то, что делает человек в адресной строке, только из кода.

WaitReady и WaitVisible выглядят как близнецы, но проверяют разное, и разница эта стоит часов отладки. WaitReady ждёт, пока узел по селектору появится в дереве документа: запрос переспрашивает DOM с интервалом в несколько миллисекунд, и как только элемент найден — действие исполняется. Это готовность структурная: элемент существует, с ним можно работать через DOM. WaitVisible добавляет второе условие: узел не просто есть, он виден — у него есть реальные размеры и прямоугольник на странице, то есть offsetWidth или offsetHeight отличны от нуля и CSS его не спрятал через display или visibility. Элемент может существовать в DOM и при этом быть невидимым: скрытый шаблон, вкладка, которую никто не открывал, спиннер с нулевыми габаритами. Для чтения текста хватает WaitReady, для клика нужен WaitVisible — клик идёт по координатам, а у невидимого узла координат нет. В хвосте цепочки стоит и третий нюанс: все Query-действия в chromedp уже содержат ожидание готовности по умолчанию, поэтому Text без предварительного WaitVisible всё равно дождётся узла — явное ожидание в примерах ставят ради читаемости и контроля условия. Сам поллинг дешёвый: один переспрос — это оценка крошечной функции в живой странице, а не сетевой запрос, поэтому интервал в несколько миллисекунд не грузит ни сеть, ни процессор.

Самая человеческая идея при работе с динамической страницей — «подождать чуть-чуть и потом читать»: вставить Sleep на пару секунд и надеяться, что контент успеет. На одном ноутбуке это даже работает — и закрепляется как привычка. Дальше начинается то, что делает ожидание загрузки инженерной темой, а не кулинарной. Фиксированный сон не связан с фактом готовности: он либо короткий, и парсер падает на медленных страницах, либо длинный, и программа тратит секунды жизни на каждом из тысяч переходов. Хуже того — режим лотереи: на границе таймингов парсер работает через раз, и такие плавающие падения ловятся хуже всего. Правильная альтернатива — событийное ожидание: условия WaitReady, WaitVisible и компании проверяются повторно с малым интервалом, пока факт не случится, поэтому страница готова ровно тогда, когда это реально так, — ни раньше, ни позже. У chromedp есть и собственный chromedp.Sleep — действие, которое уважает отмену контекста, в отличие от голого time.Sleep, но назначение у него то же ограниченное: паузы между действиями, а не ожидание готовности. Для тонких сценариев — поллинг по своему условию — существует отдельный механизм, который разбирается в уроке про умные ожидания.

Контекст chromedp — это сессия, а не одиночный переход: Navigate можно вызывать сколько угодно раз, страница заменяется, а вкладка и подключение живут дальше. На этом строится обход с пагинацией: переход на первую страницу, сбор, переход на вторую — тот же ctx, тот же браузер, история переходов копится штатно. Для движения по истории есть отдельные действия возврата и обновления страницы — Reload перезагружает текущий адрес, NavigateBack шагает назад, как кнопка в браузере, — они пригодятся, когда нужное состояние проще получить повторным открытием, чем репетицией кликов. Практический смысл держать один контекст экономический: браузер уже запущен и прогрет, повторный переход стоит в разы меньше, чем старт новой сессии. Единственное, за чем стоит следить, — состояние между переходами: куки и localStorage живут в сессии, поэтому переходы в одном контексте ведут себя как работа одного человека, а не отдельные визиты. Внутри одного Run действия исполняются строго по порядку, поэтому Navigate, затем ожидание, затем чтение образуют надёжный сценарий. Если же страниц десятки и сотни, последовательность упирается в скорость одного браузера — там начинается архитектура вкладок и пула, но это уже уровень, до которого нужно дойти с работающими ожиданиями.

Ожидание в chromedp опирается на контекст: пока условие не выполнено, запрос переспрашивает документ, а когда контекст отменён — всё останавливается с ошибкой дедлайна. Это делает context.WithTimeout честным предохранителем всей программы: не «подожду три секунды и хватит», а «у прогона есть бюджет времени, и любое висящее ожидание его израсходует». Дедлайн вешают на сессию целиком — переходы, ожидания, чтение; при превышении Run вернёт context deadline exceeded, и chromedp остановит браузер, потому что таймаут накрывает и его жизненный цикл. Отсюда два практических правила. Первое: бюджет закладывайте с запасом на старт браузера — истёкший в момент запуска дедлайн убивает весь процесс, а не только текущее действие. Второе: ошибку дедлайна стоит различать явно — она означает «страница или сайт не готовы», а не баг вашего кода, и обрабатывается ретраем или записью в проблемный список. Грамотная обработка таймаутов и повторов — тема отдельного урока про таймауты и устойчивость, здесь же важно само умение читать эту ошибку как сигнал о сети, а не как случайность.