Логи отрендеренного HTML фиксируют: часы Гуглобота...

Логи отрендеренного HTML фиксируют: часы Гуглобота останавливаются, пока страница подгружает ресурсы

Гуглобот рендерит по собственным часам, а не по реальному времени, и эти часы останавливаются, пока выполняется JavaScript или висят сетевые запросы.

В простое он гонит: 5-секундный таймер сработал всего через 455 мс реального серверного времени.

15 ресурсов в цепочке по 500 мс каждый сожгли 9 986 мс реального времени, тогда как часы Гуглобота доползли лишь до 162 мс.

API времени работают как счетчики, а не часы — каждый вызов Date.now() или performance.now() двигает собственный счетчик на 1 мс, и оба идут независимо: 10 000 вызовов Date.now() довели его значение до 10001, тогда как performance.now() остался нетронутым.

Снапшот срабатывает по внутреннему времени, а не по реальному.

После 5 секунд по собственным часам размер вьюпорта меняется, и страница получает последний шанс загрузить контент; отрендеренный HTML фиксируется примерно на отметке 5 250 мс этих часов, а 6-секундный таймаут так и не наступает.

Реальное время задает лишь внешнюю границу.

При цепочке 5-секундных серверных задержек сетевые запросы обрывались на 52 132 мс реального времени, в то время как внутренние часы показывали 112 мс — после чего они спокойно летели к своей отметке в 5 250 мс и завершали рендер.

Детерминизм зашит в эти же часы.

performance.timeOrigin у реального Гуглобота сброшен на полночь по UTC, стирая время суток.

Math.random() выдает идентичную последовательность при каждом краулинге (0.6393021999392658, затем 0.5943970666266978) во всех средах: реальном Гуглоботе, Google-InspectionTool и Rich Result Test, в разное время суток, причем криптографические случайные значения тоже совпадают.

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

Завязанные на рандом сбросы кеша не работают, и всё, что варьируется от времени суток, сводится для краулера к одному замороженному варианту.

Срабатывают два события изменения размера, оба привязаны ко времени Гуглобота:

1. На 5 000 мс: внешние габариты окна схлопываются до 1px, а масштаб вьюпорта прыгает 0.42 → 1.

2. На 5 299.9 мс: window.innerHeight отдает 1 251 074px на странице, которая добавляет блоки по 1000px каждую миллисекунду Гуглобота.

Никаких событий скролла не происходит.

Бесконечный скролл на IntersectionObserver продвигается только при этих двух изменениях размера — первая секция грузится на первом, вторая на втором, а затем время останавливается.

Три секции, независимо от длины страницы.

Весь лог пишется хелпером htmlLog(), который добавляет текстовые ноды в тег <script type="text/plain">, и этот тег доживает до отрендеренного HTML, который возвращают инструменты тестирования.

Побочный эффект такого длинного вьюпорта: главное изображение с высотой 100vh искажает превью в URL Inspection, потому что видимый контент всегда оказывается за пределами области рендера.

На индексацию это не влияет, судя по ответам на эту находку, и ограничение через max-height служит решением; сказывается ли такая структура на позициях — не проверено.

https://bigcommerce.websiteadvantage.com.au/tonys-theory-of-googlebot-relativity/

@MikeBlazerX

⚠️ Закрытый канал: @MikeBlazerPRO