Как Google использует итеративный офлайн-рендеринг для сбора всех ресурсов страницы перед индексацией

Описание

Какую задачу решает

Патент решает критическую проблему масштабирования процесса рендеринга. Веб-браузер запрашивает все вложенные ресурсы (JS, CSS, изображения) в реальном времени. Однако для поисковой системы, индексирующей миллиарды страниц, такой подход невозможен, так как привел бы к перегрузке (DDoS-эффекту) серверов, на которых размещены популярные ресурсы. Изобретение предлагает инфраструктуру для эффективного и безопасного офлайн-рендеринга, которая позволяет сканировать каждый уникальный ресурс оптимальным образом и не требует получения ресурсов в реальном времени.

Что запатентовано

Запатентована система итеративного офлайн-рендеринга (Iterative Off-Line Rendering). Она координирует взаимодействие между тремя основными компонентами: Web Crawling Engine (Краулер), Scheduling Engine (Планировщик) и Rendering Engine (Рендерер). Суть изобретения заключается в поэтапном процессе рендеринга, который может прерываться, если необходимые вложенные ресурсы еще не сканированы, и возобновляться позже, когда они станут доступны в репозитории.

Как это работает

Система работает итеративно:

• Сканирование HTML: Web Crawling Engine сканирует основную страницу и фиксирует время сканирования (Crawl Time).
• Попытка рендеринга: Scheduling Engine передает контент в Rendering Engine.
• Обнаружение и Нормализация: Рендерер обнаруживает вложенные объекты (Embedded Objects) и нормализует динамические URL (Cache-Busting URLs) для обеспечения их постоянства между итерациями.
• Запрос ресурсов: Рендерер запрашивает ресурсы у Планировщика.
• Проверка доступности: Если ресурс есть в базе данных, он возвращается.
• Обработка отсутствия: Если ресурса нет, рендеринг прерывается. Планировщик ставит ресурс в очередь на сканирование и переносит рендеринг основной страницы.
• Повторение: Процесс повторяется до тех пор, пока все необходимые ресурсы (включая вложенные) не будут собраны, после чего происходит финальный рендеринг.

Актуальность для SEO

Высокая. Рендеринг является центральной частью современного процесса индексации Google (Web Rendering Service — WRS). Описанные в патенте механизмы итеративного рендеринга и координации ресурсов лежат в основе того, как Google обрабатывает сложные веб-приложения и Javascript-зависимые сайты, обеспечивая масштабируемость системы индексации.

Важность для SEO

Влияние на SEO значительное (7/10), но косвенное. Это патент об инфраструктуре индексирования, а не о ранжировании. Он критически важен для технического SEO и Javascript SEO, поскольку описывает механизмы, которые определяют, сможет ли Google эффективно собрать и «увидеть» весь контент страницы. Если критические ресурсы недоступны, заблокированы или медленно загружаются, страница не будет полностью обработана системой, что задержит или предотвратит индексацию.

Детальный разбор

Термины и определения

Cache-Busting URLs (URL для обхода кэша)

Динамически генерируемые URL, которые могут включать метки времени или случайные числа, что делает URL уникальным при каждом просмотре страницы. Используются для трекинга или управления кэшированием.

Crawl Time (Время сканирования)

Метка времени, когда основной документ или ресурс был сканирован. Критически важна для обеспечения консистентности и нормализации динамических URL.

Embedded Object (Вложенный объект)

Внешний ресурс, на который ссылается веб-страница и который необходим для ее полного рендеринга. Примеры: CSS, Javascript, изображения, другие веб-страницы (iframe).

Image File (Файл образа)

Результат работы Rendering Engine, представляющий собой образ полностью отрендеренной веб-страницы.

Rendering Engine (Движок рендеринга)

Компонент системы, который обрабатывает HTML, выполняет Javascript и применяет CSS для создания финального образа страницы (Image File). Обнаруживает и запрашивает необходимые ресурсы.

Scheduling Engine (Движок планирования / Планировщик)

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

Web Crawling Engine (Движок сканирования / Краулер)

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

Ключевые утверждения (Анализ Claims)

Claim 1 (Независимый пункт): Описывает метод работы Scheduling Engine.

1. Система сканирует веб-страницу и сохраняет контент.
2. Scheduling Engine отправляет контент в Rendering Engine.
3. Определяется наличие вложенных объектов (специально упомянуты style sheet и Javascript code object).
4. Запускается итеративный процесс, пока все эти объекты не будут отправлены рендереру:
   1. Получение запроса от рендерера на объект.
   2. Проверка наличия контента объекта в локальном репозитории.
   3. Если ДА: отправить контент рендереру.
   4. Если НЕТ: запланировать сканирование этого объекта с помощью Web Crawling Engine.
5. Планирование финального рендеринга страницы в image file.

Claim 5 (Независимый пункт): Описывает метод работы Rendering Engine и ключевое условие итерации.

1. Контент отправляется в Rendering Engine.
2. Запускается итеративный процесс, пока все style sheets и Javascript code objects не будут получены:
   1. Определение наличия вложенного объекта и отправка запроса в Scheduling Engine.
   2. Проверка, был ли получен контент.
   3. Ключевое действие: Если НЕТ, происходит выход из процесса рендеринга и планирование сканирования отсутствующего объекта.
3. Рендеринг веб-страницы в image file после получения всех ресурсов.

Claim 7 (Зависимый от 5): Детализирует обработку динамических URL (Cache-Busting URLs).

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

Claims 8 и 9 (Зависимые от 7): Описывают нормализацию URL, зависящих от времени.

Если URL генерируется на основе текущего времени, система генерирует его, используя время, основанное на Crawl Time основной страницы. Это время может быть получено путем округления Crawl Time вниз до ближайшего кратного предопределенного значения (например, до интервала в 2 дня).

Claim 10 (Зависимый от 7): Описывает нормализацию URL, зависящих от случайных чисел.

Если URL генерируется на основе числа от генератора случайных чисел (например, Math.random()), система генерирует URL, используя одно и то же фиксированное число (константу) вместо случайного.

Где и как применяется

Изобретение описывает инфраструктуру, которая связывает этапы сканирования и индексирования.

CRAWLING – Сканирование и Сбор данных
Web Crawling Engine выполняет первичное сканирование HTML. Он также выполняет сканирование вложенных ресурсов (JS, CSS, Images) по запросу от Scheduling Engine, когда эти ресурсы обнаруживаются как отсутствующие в процессе рендеринга.

INDEXING – Индексирование (Этап Рендеринга)
Это основная область применения патента. Процесс происходит после получения исходного HTML и перед финальным извлечением признаков.

• Оркестрация: Scheduling Engine управляет процессом, решая, когда начинать рендеринг и какие ресурсы нужно докачать.
• Исполнение: Rendering Engine выполняет итеративный рендеринг, интерпретируя код и запрашивая ресурсы. Если ресурсы отсутствуют, процесс индексирования приостанавливается и инициируется возврат к этапу CRAWLING для этих ресурсов.

Входные данные:

• Исходный HTML контент страницы.
• Crawl Time страницы.
• База данных уже сканированных ресурсов.

Выходные данные:

• Image file (образ полностью отрендеренной страницы).
• Список отсутствующих вложенных ресурсов, поставленных в очередь на сканирование.

На что влияет

• Типы контента и технологии: Критически важно для сайтов, полагающихся на Javascript (SPA, PWA) и CSS для отображения основного контента и структуры. Чем сложнее страница и чем больше у нее зависимостей (включая динамически подгружаемые через JS), тем вероятнее применение итеративного подхода.

Когда применяется

• Условия применения: Алгоритм применяется во время индексации любой страницы, содержащей ссылки на внешние ресурсы.
• Триггеры итерации: Итеративный механизм (остановка и перенос рендеринга) активируется в тот момент, когда Rendering Engine запрашивает ресурс, который еще не был сканирован и отсутствует в базе данных Google.

Пошаговый алгоритм

Итеративный Процесс Рендеринга

1. Инициализация: Scheduling Engine (SE) получает контент и Crawl Time страницы от Web Crawling Engine. SE сохраняет этот снимок и передает его в Rendering Engine (RE).
2. Обнаружение ресурсов: RE анализирует контент (парсинг HTML, выполнение JS) и определяет вложенные объекты (JS, CSS).
3. Нормализация URL (Критический шаг): Для каждого объекта RE проверяет, является ли его URL динамическим (Cache-Busting URL).
   • Если зависит от времени: RE генерирует URL, используя округленное Crawl Time страницы.
   • Если зависит от случайного числа: RE генерирует URL, используя фиксированную константу.
4. Запрос ресурсов: RE запрашивает нормализованные URL у SE.
5. Проверка доступности: SE ищет контент запрошенных объектов в базе данных.
6. Обработка отсутствия (Триггер итерации):
   • Если объект НЕ найден: SE ставит его в очередь на сканирование. SE инструктирует RE остановить процесс (или RE останавливается по таймауту). Рендеринг откладывается. Переход к Шагу 10.
7. Обработка наличия:
   • Если объект найден: SE передает контент объекта в RE.
8. Рекурсивный анализ: RE проверяет полученные ресурсы на наличие дальнейших вложений (например, CSS импортирует изображение).
   • Если ДА: Процесс повторяется с шага 3 для новых вложений.
   • Если НЕТ: Переход к следующему шагу.
9. Финальный рендеринг: Когда все рекурсивные зависимости разрешены, RE выполняет финальный рендеринг страницы в Image File и сохраняет результат. Процесс завершен.
10. Перезапуск (Итерация): После того как отсутствующий ресурс (из шага 6) был просканирован, SE перезапускает процесс для этой страницы с Шага 1.

Какие данные и как использует

Данные на входе

• Контентные факторы: HTML код основной страницы. Контент всех вложенных объектов (Javascript, CSS, изображения, шрифты и т.д.).
• Технические факторы: URL-структура (используется для идентификации и запроса ресурсов).
• Временные факторы: Crawl Time (время сканирования основной страницы). Это критически важный фактор, используемый как стабильная точка отсчета для нормализации динамических URL, зависящих от времени.

Какие метрики используются и как они считаются

Патент фокусируется на инфраструктуре и нормализации данных. Основные вычисления связаны с обеспечением детерминизма рендеринга:

• Нормализация времени: Для динамических URL, включающих метку времени, система модифицирует стандартное поведение (например, функции Date() в JS). Используется Crawl Time основной страницы, округленное вниз до ближайшего кратного предопределенного значения. В патенте приведен пример интервала в 172,800 секунд (2 дня).
• Нормализация случайных чисел: Для динамических URL, включающих результат работы генератора случайных чисел (например, Math.random() в JS), система заменяет его на фиксированную константу. В патенте приведен пример константы 0.27832434.
• Таймауты: Rendering Engine может прекратить процесс, если не получает запрошенный ресурс в течение предопределенного периода времени.

Выводы

1. Рендеринг Google — это многоэтапный итеративный офлайн-процесс. Он не происходит мгновенно после сканирования HTML. Система построена так, чтобы собирать все необходимые ресурсы поэтапно, что может вызывать задержки («две волны индексации»).
2. Рендеринг может быть отложен из-за отсутствия ресурсов. Если критически важный JS или CSS файл еще не сканирован или недоступен, финальный рендеринг и полная индексация контента будут отложены. Доступность ресурсов (Crawlability) критична.
3. Google модифицирует стандартное поведение JavaScript во время рендеринга. Для обеспечения консистентности и нормализации Cache-Busting URLs, система вмешивается в работу функций времени (Date()) и случайных чисел (Math.random()), заменяя их результаты на фиксированные значения (Crawl Time или константы).
4. Выполнение Javascript критично для обнаружения ресурсов. Rendering Engine активно выполняет JS не только для отображения контента, но и для обнаружения зависимостей и динамически подгружаемых ресурсов.
5. Приоритет эффективности инфраструктуры над скоростью. Google предпочитает отложить рендеринг отдельной страницы, чтобы оптимизировать общее потребление ресурсов и избежать перегрузки внешних серверов запросами в реальном времени.

Практика

Best practices (это мы делаем)

• Обеспечение доступности всех ресурсов. Убедитесь, что все критические ресурсы (JS, CSS, изображения, шрифты, XHR/Fetch запросы) доступны для сканирования Googlebot. Проверяйте robots.txt и коды ответов сервера. Недоступность ресурса гарантированно отложит или нарушит рендеринг.
• Оптимизация краулингового бюджета ресурсов. Поскольку сканирование ресурсов и рендеринг взаимосвязаны, важно, чтобы Googlebot мог быстро сканировать файлы JS/CSS. Используйте эффективное кэширование (Cache-Control headers), CDN и оптимизируйте скорость отдачи ресурсов.
• Упрощение обнаружения ресурсов. Используйте стандартные HTML-методы для встраивания ресурсов (<link>, <script src>). Избегайте длинных цепочек зависимостей (например, JS загружает другой JS, который загружает CSS), так как каждая ступень может потребовать отдельной итерации рендеринга.
• Использование статических URL с версионированием (Fingerprinting). Для основных JS/CSS бандлов предпочтительнее использовать статические URL с уникальными идентификаторами версий, а не динамические Cache-Busting URLs. Это упрощает кэширование и обработку для поисковой системы.

Worst practices (это делать не надо)

• Блокировка JS или CSS в robots.txt. Это предотвратит полный рендеринг страницы. Система проиндексирует неполный контент или значительно задержит индексацию.
• Медленная отдача ресурсов. Если сервер отдает JS/CSS файлы слишком медленно, Rendering Engine может прекратить работу по таймауту, что приведет к переносу рендеринга и дополнительным итерациям.
• Генерация непредсказуемых URL для критического контента. Использование сложных или нестандартных схем генерации URL для критических ресурсов может помешать механизмам нормализации Google, что приведет к ошибкам индексации.
• Зависимость от состояния или порядка выполнения. Полагаться на то, что ресурсы будут запрошены в строго определенном порядке или в рамках одной сессии. Итеративный характер процесса означает, что рендеринг может быть разбит на несколько отдельных асинхронных сессий.

Стратегическое значение

Патент детально объясняет, почему рендеринг в Google является ресурсоемким и не мгновенным процессом. Это подтверждает концепцию «двух волн индексации» (сначала HTML, затем отрендеренный контент). Для сложных Javascript-сайтов (SPA/PWA) это означает неизбежные задержки в индексации. Стратегическое значение для SEO заключается в необходимости максимально ускорять и упрощать процесс сбора всех компонентов страницы для Google. Использование технологий пре-рендеринга (SSR, Dynamic Rendering) становится важным инструментом для снижения зависимости от сложностей итеративного рендеринга Google.

Практические примеры

Сценарий 1: Задержка индексации контента в SPA (Single Page Application)

1. Событие: Запускается новый сайт на React (SPA). Googlebot сканирует HTML-оболочку.
2. Процесс (по патенту): Scheduling Engine инициирует рендеринг. Rendering Engine обнаруживает 5 основных JS-бандлов. 3 из них еще не сканированы Google.
3. Результат: Рендеринг прерывается. 3 бандла ставятся в очередь на сканирование (это может занять время).
4. Итерация: После сканирования бандлов Scheduling Engine повторно инициирует рендеринг. Теперь Rendering Engine выполняет JS и обнаруживает, что контент загружается через API-запрос, который также еще не был выполнен.
5. Результат: Рендеринг снова может быть прерван или отложен, пока API-запрос не будет обработан.
6. Вывод для SEO: Задержка между запуском сайта и полной индексацией контента является прямым следствием этого итеративного процесса сбора ресурсов.

Сценарий 2: Нормализация трекингового пикселя

1. Событие: На странице есть трекинговый пиксель с URL вида: /track.gif?time=1712345678&rand=0.987654321.
2. Процесс (по патенту): Rendering Engine обнаруживает этот Cache-Busting URL.
3. Нормализация: Система применяет правила. Время заменяется на округленное Crawl Time основной страницы (например, 1712300000), а случайное число заменяется на константу (например, 0.27832434).
4. Результат: Rendering Engine запрашивает у Scheduling Engine нормализованный URL: /track.gif?time=1712300000&rand=0.27832434. Это гарантирует, что при последующих итерациях будет запрошен тот же самый ресурс, предотвращая бесконечный цикл.

Вопросы и ответы