Как Google итеративно рендерит веб-страницы, собирая недостающие ресурсы (JS, CSS, изображения) для индексации

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

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

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

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

Временная метка, когда контент веб-страницы или объекта был сканирован. Критически важен для обеспечения консистентности рендеринга и для обработки динамических URL.

Embedded Object (Встроенный объект)

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

Iterative Off-line Rendering (Итеративный офлайн-рендеринг)

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

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

Компонент, который визуализирует страницу в образ (image file), аналогично веб-браузеру. Он обнаруживает и запрашивает встроенные объекты и нормализует динамические URL.

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

Оркестратор процесса. Он передает контент между сканером и рендерером, обрабатывает запросы на встроенные объекты, управляет итеративным процессом и инициирует сканирование отсутствующих объектов.

Web Crawling Engine (Движок веб-сканирования)

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

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

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

1. Web Crawling Engine сканирует страницу и сохраняет контент и Crawl Time в репозиторий.
2. Rendering Engine рендерит страницу в файл изображения, когда все объекты получены.
3. Scheduling Engine координирует процесс:
   • Получает запрос от Rendering Engine на встроенный объект.
   • Определяет, хранится ли контент объекта в репозитории.
   • Если ДА: отправляет контент в Rendering Engine.
   • Если НЕТ: планирует сканирование объекта с помощью Web Crawling Engine.

Система разделяет сканирование и рендеринг. Рендеринг зависит от наличия данных в репозитории. Если данных нет, инициируется сканирование, а не запрос в реальном времени.

Claim 5 (Зависимый от 1): Уточняет действие при отсутствии ресурса.

Если контент встроенного объекта не хранится в репозитории, Scheduling Engine инструктирует Rendering Engine прервать (exit) процесс рендеринга веб-страницы.

Подтверждается, что рендеринг полностью останавливается, если ресурс недоступен в базе.

Claim 10 (Независимый пункт): Описывает метод рендеринга с точки зрения итеративного процесса.

1. Итеративно, пока все объекты не получены Rendering Engine:
   • Отправляется запрос на контент объекта от Rendering Engine к Scheduling Engine.
   • Проверяется, получил ли Rendering Engine контент.
   • Если НЕТ: процесс рендеринга прерывается (exiting the rendering process), и планируется сканирование объекта.
2. Веб-страница рендерится в файл изображения только после того, как контент всех объектов получен.

Фокус на итеративной природе: процесс повторяется до тех пор, пока не будут удовлетворены все зависимости.

Claim 12 (Зависимый от 10): Описывает обработку динамических URL (Cache-Busting).

Система определяет, генерируется ли URL объекта динамически (возвращая разный URL при каждом обнаружении). Если ДА: система генерирует один и тот же URL (generating the same URL) для этого объекта каждый раз.

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

Claim 13 и 14 (Зависимые от 12): Уточняют метод нормализации для URL, зависящих от времени.

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

Claim 15 (Зависимый от 12): Уточняет метод нормализации для URL, зависящих от случайных чисел.

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

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

Изобретение является инфраструктурным и охватывает два ключевых этапа поиска.

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

INDEXING – Индексирование и извлечение признаков
Основное применение патента. Описанный процесс является реализацией этапа Рендеринга (Web Rendering Service или WRS) внутри конвейера индексирования. Rendering Engine исполняет код и создает визуальное представление страницы, которое затем используется для анализа контента и извлечения признаков.

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

• Контент (HTML) просканированной веб-страницы.
• Время сканирования (Crawl Time) веб-страницы.
• База данных ранее просканированных встроенных объектов.

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

• Файл изображения (Image File) — полностью отрендеренная версия веб-страницы.
• Запросы на сканирование отсутствующих встроенных объектов.

На что влияет

• Типы контента и форматы: Особенно критичен для страниц, которые сильно зависят от внешних ресурсов для своего отображения — например, страниц, использующих JavaScript для загрузки контента (SPA/PWA), или страниц со сложным дизайном, зависящим от CSS.
• Встроенные объекты: Напрямую влияет на обработку JavaScript, CSS, изображений, iframe, API-запросов и других внешних ресурсов.
• Технические аспекты: Влияет на то, как система обрабатывает динамически генерируемые URL (Cache-Busting URLs).

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

Алгоритм применяется во время процесса индексирования для любой веб-страницы, которую система решает отрендерить.

• Триггеры активации итерации: Повторно активируется для той же страницы, если предыдущая попытка рендеринга была прервана из-за отсутствия ресурсов, и эти ресурсы были впоследствии просканированы.
• Условия работы: Рендеринг завершается только при условии, что 100% необходимых встроенных объектов доступны в базе данных сканирования. В противном случае он прерывается.

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

A. Логика Scheduling Engine (Планировщик)

1. Получение данных: Получение контента и Crawl Time веб-страницы.
2. Сохранение состояния (Опционально): Сохранение контента и Crawl Time в локальную базу данных планировщика (Scheduling Database) для обеспечения консистентности версии.
3. Инициация рендеринга: Отправка контента и Crawl Time в Rendering Engine.
4. Обработка запросов ресурсов: Ожидание запросов на встроенные объекты от Rendering Engine.
5. Проверка наличия ресурса: Поиск контента запрошенного объекта в базе данных сканирования.
6. Ответ на запрос:
   • Если найдено: Отправка контента объекта в Rendering Engine. Переход к шагу 4.
   • Если не найдено:
     • Инструкция Rendering Engine прервать процесс (или ожидание тайм-аута).
     • Планирование сканирования отсутствующего объекта с помощью Web Crawling Engine.
7. Перезапуск (Итерация): После получения уведомления о том, что объект просканирован, возврат к шагу 3 для повторной попытки рендеринга исходной страницы.
8. Завершение: Если Rendering Engine завершает работу успешно, процесс планирования завершен.

B. Логика Rendering Engine (Рендерер)

1. Получение данных: Получение контента и Crawl Time страницы от Scheduling Engine.
2. Анализ и обнаружение объектов: Парсинг контента и определение наличия встроенных объектов.
3. Обработка объектов: Для каждого обнаруженного объекта:
   • Нормализация URL: Проверка, является ли URL динамически генерируемым (Cache-Busting).
     • Если ДА (зависит от времени): Генерация URL с использованием округленного Crawl Time страницы.
     • Если ДА (зависит от случайного числа): Генерация URL с использованием предопределенной константы.
   • Запрос объекта: Отправка запроса на нормализованный URL объекта в Scheduling Engine.
4. Ожидание ресурсов:
   • Если ресурс не получен (тайм-аут или инструкция от планировщика): Прерывание процесса рендеринга.
   • Если ресурс получен: Переход к шагу 5.
5. Анализ вложенности: Проверка, содержат ли только что полученные объекты свои собственные встроенные объекты (например, CSS ссылается на изображение).
   • Если ДА: Возврат к шагу 3 для обработки вложенных объектов.
6. Финальный рендеринг: Когда все объекты (включая вложенные) получены, рендеринг веб-страницы в файл изображения.
7. Сохранение: Сохранение файла изображения в Image Indexing Database.

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

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

Патент фокусируется на инфраструктуре рендеринга и использует следующие типы данных:

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

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

Патент не описывает метрики ранжирования, но описывает конкретные методы обработки данных для рендеринга:

• Нормализация времени: Для URL, зависящих от времени, используется формула округления Crawl Time страницы. $Time_{normalized} = RoundDown(CrawlTime_{page}, PredefinedValue)$. В описании патента приведен пример PredefinedValue равный 2 дням (172,800 секунд).
• Нормализация случайных чисел: Для URL, зависящих от случайных чисел, используется замена случайного значения на константу. $RandomNumber \rightarrow Constant$ (в описании приведен пример 0.27832434).
• Условия завершения: Рендеринг завершается только тогда, когда 100% запрошенных ресурсов получены. Отсутствие хотя бы одного ресурса приводит к прерыванию процесса.

1. Итеративный подход к рендерингу: Google не обязательно рендерит страницу за один раз. Процесс является итеративным: если ресурсы отсутствуют, рендеринг прерывается, ресурсы ставятся в очередь на сканирование, и попытка повторяется позже. Это объясняет задержки в индексации.
2. Критичность доступности ресурсов: Для полного рендеринга страницы абсолютно все встроенные ресурсы (JS, CSS, изображения, запросы API, описанные как Embedded Objects) должны быть доступны для сканирования. Отсутствие даже одного ресурса остановит текущую попытку рендеринга (Claim 5).
3. Разделение сканирования и рендеринга: Рендеринг использует только те ресурсы, которые уже находятся в базе данных Google. Система не выполняет внешние запросы в реальном времени во время рендеринга, чтобы избежать перегрузки внешних серверов.
4. Обработка динамических URL (Cache-Busting): Google активно нормализует динамически генерируемые URL (Claim 12). Система заменяет случайные числа на константы и текущее время на фиксированное время, основанное на Crawl Time HTML-документа. Это обеспечивает детерминированный и консистентный рендеринг.
5. Консистентность версии страницы: Система стремится отрендерить страницу в том состоянии, в котором она была на момент сканирования (Crawl Time), используя Scheduling Database для сохранения этой версии, даже если страница часто обновляется.

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

• Обеспечение доступности всех ресурсов для сканирования: Убедитесь, что все критически важные для отображения контента ресурсы (JavaScript, CSS, изображения, шрифты, API-запросы) не заблокированы в robots.txt. Блокировка приведет к тому, что Google не увидит страницу корректно.
• Оптимизация краулингового бюджета и скорости ресурсов: Поскольку отсутствующие ресурсы ставятся в отдельную очередь на сканирование (Claim 1), важно, чтобы сервер отдавал их быстро. Это ускорит их попадание в базу данных Google и, следовательно, ускорит финальный рендеринг страницы.
• Оптимизация цепочек запросов (Request Chains): Сокращайте количество и сложность вложенных зависимостей ресурсов. Чем сложнее цепочка (HTML -> JS -> CSS -> Image), тем больше вероятность задержек индексации из-за необходимости нескольких итераций рендеринга.
• Использование консистентных URL (Content Fingerprinting): Хотя система умеет нормализовывать динамические URL (Claim 12), лучше полагаться на стабильные URL для основных файлов JS/CSS. Предпочтительнее использовать отпечатки контента в имени файла (например, app.a1b2c3.js), а не динамические параметры запроса (app.js?v=12345).
• Мониторинг ошибок сканирования ресурсов: Регулярно проверяйте отчеты GSC и логи сервера на предмет ошибок сканирования JavaScript, CSS или изображений. Каждая такая ошибка означает, что рендеринг страниц, использующих этот ресурс, был прерван.

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

• Блокировка JS и CSS в robots.txt: Это напрямую противоречит механизму. Система не сможет собрать необходимые Embedded Objects и не завершит рендеринг.
• Использование случайных чисел или текущего времени в URL основных ресурсов: Это создает Cache-Busting URLs. Хотя Google пытается их нормализовать (Claims 13-15), это усложняет процесс и может привести к ошибкам сопоставления ресурсов, если логика генерации слишком сложна.
• Игнорирование скорости загрузки ресурсов: Медленная отдача ресурсов замедлит их сканирование Web Crawling Engine, что задержит их попадание в базу данных и, как следствие, отложит успешный рендеринг страницы из-за итеративной природы процесса.
• Размещение критического контента в нестабильных внешних источниках: Если контент загружается через JS с внешнего API, этот API рассматривается как Embedded Object. Если он недоступен или медленно отвечает, рендеринг будет прерван.

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

Этот патент подчеркивает фундаментальные инфраструктурные вызовы, с которыми сталкивается Google при индексировании современного интернета, особенно с учетом распространения JavaScript-фреймворков. Для SEO-специалистов это подтверждает, что техническая оптимизация доступности и скорости загрузки ресурсов — это необходимое условие для корректной индексации. Понимание итеративного процесса рендеринга помогает диагностировать проблемы: контент может быть не проиндексирован не потому, что он некачественный, а потому, что Google буквально не смог его "увидеть" из-за отсутствия необходимых ресурсов во время попытки рендеринга.

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

Сценарий: Диагностика проблем с индексацией JavaScript-контента (SPA)

1. Проблема: Основной контент товара на сайте электронной коммерции (SPA) не индексируется. Контент загружается через JavaScript, делающий запрос к внутреннему API.
2. Анализ по патенту: Rendering Engine пытается исполнить JavaScript. Запрос к API рассматривается как запрос на Embedded Object. Если ответ API отсутствует в базе, Scheduling Engine прерывает рендеринг и ставит URL API в очередь на сканирование.
3. Действия SEO-специалиста:
   • Проверить, доступен ли URL API для сканирования (не заблокирован ли в robots.txt).
   • Проверить логи сервера, чтобы убедиться, что Googlebot успешно сканирует URL API (HTTP статус 200) и скорость ответа высокая.
4. Ожидаемый результат: После обеспечения доступности и быстрой загрузки API, Web Crawling Engine просканирует его. При следующей итерации рендеринга Rendering Engine успешно получит данные и контент будет проиндексирован.

Сценарий: Обработка скриптов аналитики с динамическими URL

1. Проблема: Сайт использует сторонний скрипт отслеживания, который генерирует запросы с временной меткой в URL (например, /track?t=1727197271) для обхода кэша.
2. Анализ по патенту: Rendering Engine обнаруживает этот Cache-Busting URL (Claim 12). Чтобы не сканировать его как новый ресурс при каждом рендеринге, он применяет нормализацию (Claim 13). Он заменяет текущее время t на округленное время сканирования основного HTML документа.
3. Действия SEO-специалиста: Понимать, что такие скрипты не должны мешать рендерингу, так как Google имеет механизмы для их обработки. Не нужно предпринимать специальных действий, но важно убедиться, что эти скрипты не блокируют основной поток рендеринга.