Как Google оптимизирует рендеринг миллиардов страниц с помощью виртуального времени и блокировки ресурсов

Описание

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

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

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

Запатентована архитектура, состоящая из сервера рендеринга (Render Server) и сервера фетчинга (Fetch Server), оптимизированная для пакетного рендеринга. Ключевым элементом является использование «виртуального времени» (virtual clock) в движке рендеринга, которое останавливается во время ожидания ресурсов, устраняя таймауты. Fetch Server оптимизирует загрузку, используя правила перезаписи URL (URL Rewrite Rules) для дедупликации и блокировки ресурсов, а также механизм «mock-изображений» (mock images) для ускорения расчета макета.

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

Система работает следующим образом:

• Инициализация рендеринга: Движок рендеринга получает запрос (например, от индексатора), инициализирует virtual clock и создает список задач (task list), включая финальную задачу «Stop task» с заданным временем (например, +20 сек виртуального времени).
• Виртуальное время: Время не идет, пока система ждет загрузки ресурса или выполняет готовые задачи (например, исполняет JavaScript). Когда система простаивает, виртуальное время «перематывается» вперед к следующей запланированной задаче.
• Оптимизация фетчинга: При обнаружении внешнего ресурса запрос идет на Fetch Server.
• Перезапись и блокировка: Fetch Server применяет URL Rewrite Rules для выявления дубликатов или блокировки (blacklist) ненужных ресурсов.
• Mock-изображения: Для изображений Fetch Server может вернуть mock image — пустой файл с корректными размерами, достаточный для расчета макета.
• Завершение: Рендеринг завершается, когда virtual clock достигает времени «Stop task». Результат (DOM, layout, ошибки) передается индексатору.

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

Высокая. Патент описывает фундаментальную инфраструктуру, лежащую в основе Web Rendering Service (WRS) Google, которая используется для рендеринга и индексирования JavaScript-контента. Механизмы, описанные здесь, критичны для понимания того, как Googlebot взаимодействует с современными веб-сайтами, и остаются актуальными для Technical SEO и оптимизации под JS-фреймворки.

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

Патент имеет высокое значение (85/100) для Technical SEO и JavaScript SEO. Хотя он описывает внутреннюю инфраструктуру Google, он дает критически важное понимание среды, в которой Googlebot рендерит страницы. Понимание механизмов virtual clock, блокировки ресурсов и использования mock images позволяет специалистам точнее диагностировать проблемы рендеринга, оптимизировать загрузку ресурсов и Core Web Vitals (в частности CLS).

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

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

Batch Process (Пакетный процесс)

Процесс, обрабатывающий большие объемы данных автоматически, без взаимодействия с пользователем. В контексте патента — это, например, Indexing Engine (система индексирования).

Batch-Optimized Rendering Engine (Движок рендеринга, оптимизированный для пакетов)

Специализированный движок (часть Render Server), эмулирующий ядро браузера, но оптимизированный для эффективности и детерминизма, а не для отображения пользователю. Использует Virtual Clock.

Embedded Item/Resource (Встроенный ресурс)

Внешний ресурс, необходимый для рендеринга страницы (CSS, JavaScript, изображения, iframe).

Fetch Server (Сервер фетчинга)

Промежуточный сервер, обрабатывающий запросы на ресурсы от движков рендеринга. Кэширует контент, применяет правила перезаписи и может возвращать Mock Images.

Image Dimension Table (Таблица размеров изображений)

Хранилище, содержащее размеры (ширину и высоту) изображений, индексированное по URL.

Mock Image (Mock-изображение)

Файл изображения с пустым контентом (например, прозрачный), но с корректными размерами, соответствующими оригинальному изображению. Используется для расчета макета без загрузки пикселей.

Rendering Result (Результат рендеринга)

Выходные данные процесса рендеринга. Включают DOM Tree, Layout (геометрию элементов), список загруженных ресурсов, ошибки JavaScript и скриншот страницы.

Stop Task (Финальная задача)

Задача, добавляемая в Task List при инициализации рендеринга с заранее определенным временем выполнения (например, 20 секунд). Достижение этого времени означает завершение рендеринга.

Task List (Список задач)

Очередь задач, которые должен выполнить движок рендеринга (парсинг HTML, выполнение JS, изменение стилей). Каждая задача имеет время выполнения (Run Time).

URL Rewrite Rules (Правила перезаписи URL)

Набор правил, используемых Fetch Server для идентификации дублирующегося контента (например, cache-busting URLs) и перенаправления на каноническую версию (redirect URL), а также для блокировки (blacklisting) ненужных ресурсов.

Virtual Clock (Виртуальное время)

Механизм управления временем внутри движка рендеринга. Не зависит от реального времени. Останавливается во время ожидания фетчинга или выполнения задач и перематывается вперед во время простоя.

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

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

Claims, относящиеся к Virtual Clock и Рендерингу (например, Claim 1, 9): Описывают метод пакетного рендеринга с использованием виртуального времени.

1. Система получает запрос на рендеринг от пакетного процесса.
2. Инициализируется virtual clock и task list.
3. В task list добавляется Stop task с предопределенным временем (например, Т+20 сек).
4. Выполняются задачи из списка согласно virtual clock.
5. Критическое условие (описанное в патенте): virtual clock «стоит на месте» (stands still), когда (a) ожидается ответ на запрос встроенного ресурса (fetch request) ИЛИ (b) есть задача, готовая к выполнению (task is ready to run).
6. Rendering result генерируется, когда virtual clock достигает времени Stop task.

Система спроектирована так, что virtual clock продвигается независимо от реального времени. Оно продвигается (перематывается вперед) к времени следующей задачи только тогда, когда нет активных задач и нет ожидающих запросов. Это означает, что загрузка ресурсов и выполнение JavaScript занимают ноль виртуального времени. Это устраняет ошибки таймаутов, связанные с медленной загрузкой, и делает рендеринг детерминированным.

Claims, относящиеся к оптимизации фетчинга (De-duplication) (В этом патенте US11328114B2 они не являются основными, но описаны в тексте): Описывают метод обработки запросов ресурсов с дедупликацией.

1. При рендеринге идентифицируется встроенный ресурс (URL).
2. Система определяет, на основе rewrite rule, что контент этого ресурса дублирует контент ранее загруженного ресурса.
3. Правило перезаписи (rewrite rule) может включать шаблон (template) и идентификатор перенаправления (redirect identifier). Например, шаблон может соответствовать URL без строки запроса.
4. Вместо нового фетчинга система предоставляет контент ранее загруженного ресурса из хранилища данных (data store).

Это позволяет обрабатывать cache-busting URLs (например, с временными метками или случайными строками), не загружая один и тот же файл многократно.

Claims, относящиеся к Mock Images (Также описаны в тексте): Описывают использование размеров изображений вместо пикселей.

1. Идентифицируется встроенное изображение.
2. Система определяет размеры изображения из таблицы (dimension table).
3. Генерируется mock image с этими размерами (но пустым контентом).
4. Rendering result генерируется с использованием mock image.

Это позволяет корректно рассчитать макет (Layout) страницы, минимизируя объем передаваемых данных.

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

Это инфраструктурный патент, описывающий работу Web Rendering Service (WRS) Google. Он применяется на стыке сканирования и индексирования.

CRAWLING – Сканирование и Сбор данных
Web-Crawling Engine используется для первоначального сканирования HTML и для загрузки ресурсов по запросу Fetch Server, если их нет в кэше или они устарели.

INDEXING – Индексирование и извлечение признаков
Это основной этап применения патента. Indexing Engine (пакетный процесс) запрашивает рендеринг у Render Server для понимания динамического контента и макета страницы.

1. Рендеринг (WRS): Render Server и Fetch Server выполняют оптимизированный пакетный рендеринг, как описано в патенте.
2. Извлечение признаков: Indexing Engine использует полученный Rendering Result (включая DOM Tree и Layout) для индексации динамического контента, определения важности контента на основе его положения/размера на странице (например, above-the-fold) и игнорирования невидимого контента.

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

• URL страницы для рендеринга (иногда с исходным HTML).
• Кэш встроенных ресурсов (Embedded Item Table).
• Таблица размеров изображений (Image Dimension Table).
• Правила перезаписи URL (URL Rewrite Rules).

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

• Rendering Result (DOM, Layout, Errors, Скриншот).

На что влияет

• Конкретные типы контента: Наибольшее влияние оказывается на страницы, интенсивно использующие JavaScript для генерации контента и управления макетом (SPA, PWA), а также на страницы с большим количеством внешних ресурсов.
• Определенные форматы контента: Влияет на то, как Google воспринимает макет страницы, что критично для оценки Core Web Vitals (особенно CLS) и визуальной значимости элементов.

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

• Условия работы: Применяется, когда системе индексирования необходимо выполнить рендеринг страницы для полного понимания ее содержимого.
• Триггеры активации: Активация механизмов оптимизации (Virtual Clock, Rewrite Rules, Mock Images) происходит при каждом запросе на пакетный рендеринг.
• Ограничения: Рендеринг ограничен по времени задачей Stop task.

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

Процесс А: Рендеринг с виртуальным временем (Render Engine)

1. Инициализация: Получить запрос на рендеринг. Инициализировать Virtual Clock (T=0). Создать Task List.
2. Установка лимита: Добавить в Task List задачу «Stop task» с временем выполнения T=20 сек (предопределенное время).
3. Выполнение задач: Начать обработку задач. Если задача готова к выполнению (ее время ≤ T), выполнить ее. (Например, парсинг HTML, выполнение синхронного JS).
4. Обнаружение ресурсов: При обнаружении встроенного ресурса отправить запрос на Fetch Server и отметить, что ожидается ответ (Waiting=True).
5. Управление временем (Цикл):
   • Если Waiting=True ИЛИ есть готовые задачи: Virtual Clock стоит на месте. Продолжать выполнять готовые задачи или ждать ответа.
   • Если Waiting=False И нет готовых задач: Перемотать Virtual Clock вперед до времени следующей запланированной задачи в Task List.
6. Обработка ответа: Получить ответ от Fetch Server (контент, mock image или ошибку). Установить Waiting=False. Добавить новые задачи в Task List (например, парсинг CSS, выполнение асинхронного JS).
7. Завершение: Когда Virtual Clock достигает времени «Stop task» (T=20 сек), финализировать Rendering Result (сгенерировать финальный Layout, DOM) и вернуть его индексатору.

Процесс Б: Оптимизированный фетчинг (Fetch Server)

1. Получение запроса: Получить URL ресурса от Render Engine.
2. Применение правил: Применить URL Rewrite Rules для нормализации URL (например, удаление параметров для дедупликации) или идентификации блокировки.
3. Проверка блокировки: Если URL в Blacklist, немедленно вернуть ошибку.
4. Проверка кэша: Искать нормализованный URL в Embedded Item Table (кэш).
5. Обработка изображений (Опционально): Если ресурс — изображение, искать его размеры в Image Dimension Table. Если найдено и не устарело, сгенерировать и вернуть Mock Image.
6. Проверка актуальности: Если ресурс найден в кэше, проверить, не устарел ли он (Stale Check).
7. Возврат из кэша: Если найден и актуален, вернуть кэшированный контент.
8. Сканирование: Если не найден или устарел, запросить сканирование у Web-Crawling Engine. Получив контент, обновить кэш (и размеры изображения) и вернуть его Render Engine.

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

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

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

• Контентные факторы: Исходный HTML страницы, а также контент встроенных ресурсов (CSS, JavaScript файлы).
• Технические факторы: URL ресурсов, включая cache-busting URLs (URL с динамическими параметрами для предотвращения кэширования браузером).
• Мультимедиа факторы: Размеры изображений (ширина и высота), хранящиеся в Image Dimension Table. Фактические пиксели изображений часто игнорируются в пользу Mock Images.
• Системные данные: URL Rewrite Rules, включая шаблоны для дедупликации и списки блокировки (Blacklists). Данные кэша (Embedded Item Table) и время последнего сканирования (Crawl Time).

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

• Virtual Clock Time: Метрика прогресса рендеринга. Увеличивается только путем перемотки вперед во время простоя системы.
• Predetermined Time (Предопределенное время): Пороговое значение для Stop task (например, 20 секунд). Определяет максимальное окно симуляции активности на странице.
• Staleness (Устаревание): Метрика актуальности кэшированного ресурса. Рассчитывается на основе времени последнего сканирования (Crawl Time) и, возможно, частоты изменения ресурса (Change Rate).
• URL Matching: Сопоставление URL с шаблонами в URL Rewrite Rules для определения дубликатов или блокировок.

Выводы

1. Google использует «Виртуальное время» для надежного рендеринга: Механизм Virtual Clock позволяет Googlebot ждать загрузки ресурсов, не вызывая традиционных таймаутов. Время останавливается на время загрузки и выполнения скриптов. Это обеспечивает детерминизм и надежность рендеринга даже медленных страниц.
2. Существует лимит симуляции активности (Rendering Budget): Хотя таймаутов загрузки нет, существует лимит виртуального времени (Stop task, например, 20 секунд). Google симулирует только ту активность (анимации, асинхронные задачи), которая успевает произойти в это виртуальное окно. Активность за пределами этого окна может быть проигнорирована.
3. Google активно блокирует ненужные ресурсы: Система рендеринга спроектирована так, чтобы игнорировать (Blacklist) ресурсы, не влияющие на индексацию (например, скрипты аналитики, трекеры). Это экономит ресурсы Google.
4. Дедупликация ресурсов агрессивна: Fetch Server использует URL Rewrite Rules для борьбы с cache-busting URLs. Google стремится не загружать один и тот же контент дважды, даже если URL отличаются.
5. Для расчета макета пиксели не нужны: Google использует Mock Images — пустышки с правильными размерами. Это подтверждает, что для расчета геометрии страницы (и метрик типа CLS) важны только размеры элемента, а не его содержимое.
6. Цель архитектуры — индексация динамического контента: Вся эта сложная инфраструктура создана для того, чтобы Indexing Engine мог получить доступ к контенту, сгенерированному JavaScript, и понять макет страницы.

Практика

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

• Обеспечивать быструю отдачу критических ресурсов: Хотя Virtual Clock скрывает задержки, быстрая загрузка позволяет выполнить больше задач в рамках отведенного виртуального окна (Stop task). Приоритезируйте ресурсы, необходимые для построения DOM и Layout.
• Указывать размеры изображений: Поскольку Google использует Mock Images на основе известных размеров для расчета макета, критически важно указывать атрибуты width и height для всех изображений и iframe. Это стабилизирует макет и помогает предотвратить CLS (Cumulative Layout Shift).
• Обеспечивать детерминизм рендеринга: Убедитесь, что страница рендерится одинаково при каждом посещении. Избегайте зависимости от случайных чисел, текущего времени пользователя или неконсистентных API для генерации критического контента.
• Мониторить ошибки JavaScript: Rendering Result включает ошибки консоли. Наличие ошибок может прервать выполнение скриптов и помешать индексации динамического контента.
• Проверять рендеринг в инструментах Google (GSC, MFT): Используйте инструменты Google для проверки того, как WRS видит страницу. Обращайте внимание на список загруженных ресурсов и ошибки. Если критический ресурс заблокирован (Blocked) или не загружен (Other error), Google не увидит контент.

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

• Использовать Cache-Busting для критических ресурсов без необходимости: Использование постоянно меняющихся URL (например, с временной меткой) для основного JS/CSS без изменения контента создает дополнительную нагрузку на систему дедупликации Google. Используйте версионирование файлов (fingerprinting) при изменении контента.
• Задерживать выполнение критического кода: Не откладывайте выполнение JavaScript, отвечающего за основной контент (например, через setTimeout на долгий срок). Он может не успеть выполниться до срабатывания Stop task.
• Блокировать критические ресурсы в robots.txt: Блокировка JS или CSS, необходимых для построения основного контента, приведет к некорректному рендерингу. Блокировать можно только то, что Google и так игнорирует (аналитика, трекеры).
• Полагаться на загрузку тяжелых изображений для построения макета: Не допускайте «прыжков» макета из-за загрузки изображений без указанных размеров. Google рассчитает макет с Mock Image, и любые сдвиги будут зафиксированы.

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

Патент подтверждает, что рендеринг является сложным и ресурсоемким процессом, который Google стремится максимально оптимизировать. Для SEO-стратегии это означает, что техническая оптимизация скорости загрузки и стабильности макета (Core Web Vitals) напрямую соответствует целям архитектуры Google. Понимание того, что Googlebot работает в среде с «виртуальным временем» и агрессивной экономией ресурсов, должно лежать в основе любой стратегии JavaScript SEO. Приоритет отдается контенту, который может быть отрендерен быстро, стабильно и детерминированно.

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

Сценарий 1: Диагностика проблем с CLS и Mock Images

1. Проблема: Сайт имеет высокий показатель CLS в отчетах Google.
2. Анализ (на основе патента): Google использует Mock Images для расчета макета. CLS возникает, если браузер (или WRS) не знает размеров изображения до его загрузки, что вызывает сдвиг контента.
3. Действие: Проверить все теги <img> на странице. Убедиться, что у каждого есть атрибуты width и height, и задано свойство CSS aspect-ratio.
4. Ожидаемый результат: WRS сможет корректно зарезервировать место под Mock Image при расчете Layout, устраняя сдвиг и снижая CLS.

Сценарий 2: Оптимизация бюджета рендеринга (Virtual Clock)

1. Проблема: Динамический контент (например, список товаров, подгружаемый через API) иногда не индексируется.
2. Анализ (на основе патента): Рендеринг ограничен виртуальным окном (Stop task). Если запрос к API и последующий рендеринг занимают слишком много времени или зависят от слишком большого числа последовательных задач, они могут не успеть выполниться.
3. Действие: Оптимизировать скорость ответа API. Убедиться, что JavaScript, отвечающий за рендеринг этого контента, выполняется сразу после получения данных, а не откладывается другими задачами. Рассмотреть возможность использования SSR или Dynamic Rendering для критического контента.
4. Ожидаемый результат: Контент успевает появиться в DOM до завершения виртуального времени рендеринга и попадает в индекс.

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