Как Google использует «Виртуальные часы» и оптимизацию ресурсов для эффективного рендеринга JavaScript-сайтов в масштабах веба

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

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

Автоматизированный процесс, обрабатывающий большое количество данных одновременно (например, индексация веб-страниц), а не в реальном времени.

Blacklisted URL (URL в черном списке)

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

Fetch Server (Сервер выборки)

Компонент, отвечающий за получение встроенных ресурсов по запросу Rendering Engine. Управляет кэшированием, применением правил перезаписи и взаимодействием с краулером.

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

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

Mock Image (Мок-изображение / Заглушка)

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

Rendering Engine (Механизм рендеринга)

Компонент, эмулирующий ядро браузера, оптимизированный для пакетного рендеринга. Использует Virtual Clock.

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

Итоговый набор данных после рендеринга: финальный DOM, макет (Layout/Render Tree), изображение страницы, список загруженных ресурсов, ошибки JavaScript.

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

Набор правил, используемых Fetch Server для нормализации URL. Позволяют идентифицировать дублирующийся контент (например, из-за параметров сброса кэша — Cache-Busting URLs) или ресурсы в черном списке.

Stop Task (Задача остановки)

Финальная задача в Task List, запланированная на определенное время (например, 20 секунд). По достижении этого времени рендеринг завершается.

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

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

Virtual Clock (Виртуальные часы)

Механизм управления временем внутри Rendering Engine. Часы не идут в реальном времени: они стоят на месте во время ожидания выборки ресурсов и выполнения задач и перематываются (перескакивают) вперед во время простоя.

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

Claim 1 (Независимый пункт): Описывает систему пакетного рендеринга с оптимизацией выборки (дедупликацией) и использованием виртуальных часов.

1. Система получает запрос от пакетного процесса на рендеринг страницы.
2. Инициализируются Virtual Clock и Task List. В список добавляется Stop Task с заданным временем выполнения.
3. Выполняются задачи согласно Virtual Clock.
4. Механизм работы Virtual Clock: часы продвигаются вперед путем установки времени следующей задачи в списке; часы остаются неизменными (останавливаются), пока есть задачи, готовые к выполнению в текущее время (или, как указано в описании, ожидается ресурс).
5. Во время выполнения задач система идентифицирует встроенный ресурс.
6. Определяется (на основе Rewrite Rule), что контент этого ресурса дублирует контент ранее полученного ресурса.
7. В ответ предоставляется ранее полученный (кэшированный) контент из хранилища.
8. Генерируется Rendering Result, когда Virtual Clock достигает времени Stop Task.

Claim 7 (Независимый пункт): Описывает метод пакетного рендеринга с фокусом на механизме Virtual Clock (аналогично Claim 1, но без акцента на дедупликацию).

1. Получение запроса на рендеринг.
2. Инициализация Virtual Clock и Task List с добавлением Stop Task.
3. Выполнение задач с использованием механизма Virtual Clock (остановка во время выполнения/ожидания, перемотка во время простоя).
4. Генерация Rendering Result по достижении времени Stop Task.

Claim 4 (Зависимый от 1): Описывает механизм черных списков.

Система идентифицирует ресурс и определяет, находится ли он в черном списке (blacklisted). Если да, возвращается ошибка без выборки контента, и рендеринг продолжается без этого ресурса.

Claim 6 (Независимый пункт) и Claim 11 (Зависимый от 7): Описывают использование Mock Images.

Система идентифицирует встроенное изображение и получает в ответ Mock Image, который содержит размеры изображения (взятые из Dimension Table), но пустое содержимое. Этот Mock Image используется при генерации Rendering Result.

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

Изобретение является ключевой частью инфраструктуры сканирования и индексирования Google, обеспечивающей работу Web Rendering Service (WRS).

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

INDEXING – Индексирование и извлечение признаков
Основное применение патента. Indexing Engine запрашивает рендеринг у Render Server (WRS). Rendering Engine использует Virtual Clock для быстрого и детерминированного рендеринга страницы. Полученный Rendering Result (включая динамический контент, финальный DOM и Layout) используется индексатором для извлечения признаков и понимания структуры страницы.

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

• URL и/или сырой HTML контент страницы.
• URL Rewrite Rules, кэш ресурсов (Embedded Item Table), Image Dimension Table (используются Fetch Server).

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

• Rendering Result: Включает Image (снимок страницы), DOM Tree, Layout (Render Tree), Errors (ошибки JS), список загруженных ресурсов.

На что влияет

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

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

Алгоритм применяется всегда, когда поисковая система выполняет рендеринг страницы для индексации.

• Условия работы: Наличие встроенных ресурсов, особенно JavaScript, которые влияют на контент или макет.
• Ограничения (Stop Task): Рендеринг ограничен предопределенным лимитом виртуального времени. В патенте упоминаются примеры от 5 до 20 секунд, установленные через Stop Task.

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

Процесс А: Рендеринг страницы (Rendering Engine и Virtual Clock)

1. Инициализация: Получение запроса. Инициализация Virtual Clock (например, 0 секунд). Создание Task List. Добавление начальных задач и Stop Task (например, 20 секунд).
2. Цикл выполнения задач: Система повторяет следующие шаги:
   1. Проверка ожидающих загрузок (Fetch): Есть ли невыполненные запросы к Fetch Server? Если ДА, Virtual Clock не двигается (система ждет или выполняет другие готовые задачи).
   2. Выполнение готовых задач: Есть ли задачи, готовые к выполнению в текущее виртуальное время? Если ДА, они выполняются. Virtual Clock не двигается во время выполнения. Выполнение может порождать новые задачи (например, setTimeout) или запросы к Fetch Server.
   3. Перемотка времени (Warping): Если НЕТ ожидающих загрузок и НЕТ готовых задач, Virtual Clock перематывается ко времени следующей запланированной задачи.
3. Завершение: Если достигнуто время Stop Task, рендеринг завершается.
4. Финализация: Генерация итогового Rendering Result (DOM, Layout, Errors) и возврат его запрашивающему процессу.

Процесс Б: Обработка запроса ресурса (Fetch Server)

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

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

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

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

• Контентные факторы: HTML код страницы, содержимое встроенных ресурсов (JavaScript, CSS). Используются для построения DOM и выполнения скриптов.
• Технические факторы: URL ресурсов. Используются для выборки и применения URL Rewrite Rules.
• Мультимедиа факторы: Размеры изображений (ширина, высота). Используются для генерации Mock Images и расчета макета (Layout). Патент явно указывает, что реальные пиксельные данные изображений часто не используются для экономии ресурсов.

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

• Virtual Clock Time (Время виртуальных часов): Основная метрика для планирования задач. Измеряется в секундах, но не коррелирует с реальным временем. Продвигается скачкообразно на основе времени следующей задачи.
• Predetermined Time / Stop Task Time (Предопределенное время): Пороговое значение виртуального времени для завершения рендеринга (упоминаются примеры 5-20 секунд).
• Staleness (Устаревание): Метрика актуальности кэшированного контента. Определяется на основе частоты изменений ресурса (change rate), его типа или времени последнего сканирования.
• Dimensions (Размеры): Ширина и высота изображений, используемые для Mock Images.

1. Рендеринг для индексации (WRS) отличается от пользовательского: Google использует специализированную среду (Batch-Optimized Architecture), оптимизированную для скорости, масштаба и детерминизма, а не для визуальной точности или интерактивности.
2. Virtual Clock предотвращает таймауты загрузки: Механизм Virtual Clock специально разработан для скрытия сетевых задержек (fetch latency). Система будет ждать загрузки ресурсов, так как время останавливается во время ожидания. Это опровергает миф о том, что Googlebot может не дождаться загрузки медленных скриптов.
3. Virtual Clock ускоряет таймеры и анимации: Система не ждет в реальном времени. Если нет активных задач, время перескакивает к следующей задаче (например, setTimeout). Это позволяет завершить 20 виртуальных секунд за несколько реальных.
4. Существует жесткий лимит времени рендеринга (Stop Task): Рендеринг ограничен лимитом виртуального времени (Stop Task, например, 5-20 секунд). Если процесс не завершится к этому моменту, он будет прерван.
5. Google агрессивно оптимизирует сканирование ресурсов: Система активно избегает загрузки ненужного контента. Скрипты, не влияющие на отображение (например, аналитика), могут быть внесены в Blacklist. Дублирующиеся ресурсы (например, из-за cache-busting URL) дедуплицируются через URL Rewrite Rules.
6. Макет рассчитывается без реальных изображений: Для расчета Layout Google использует Mock Images (заглушки с нужными размерами), а не реальные пиксельные данные. Для оценки структуры страницы важны только размеры изображений.

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

• Указание размеров изображений (Критично для CLS): Всегда указывайте атрибуты width и height для изображений в HTML или CSS. Поскольку Google использует Mock Images на основе этих размеров для расчета Layout, это критично для стабильности макета (Cumulative Layout Shift) во время рендеринга Googlebot.
• Обеспечение доступности критических ресурсов: Убедитесь, что все JS и CSS файлы, необходимые для отображения основного контента и макета, доступны для сканирования (не заблокированы в robots.txt). Virtual Clock гарантирует, что Googlebot дождется их загрузки, если они доступны.
• Оптимизация эффективности выполнения JavaScript: Необходимо оптимизировать код, чтобы основной контент формировался быстро и не превышал лимит Stop Task. Хотя ожидание загрузки не тратит виртуальное время, сложный JS-код может замедлить процесс рендеринга.
• Использование Graceful Degradation/Enhancement: Функционал, который может быть классифицирован как ненужный (например, трекинг, чат-боты), должен быть реализован так, чтобы его блокировка (попадание в Blacklist) не нарушала отображение основного контента.

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

• Изображения без указания размеров: Это затрудняет расчет макета с использованием Mock Images и может привести к некорректной оценке структуры страницы и высокому CLS.
• Зависимость от сторонних скриптов для отображения контента: Размещение критически важного контента в зависимость от скриптов, которые могут быть расценены как ненужные и попасть в Blacklist (например, системы персонализации или A/B тестирования).
• Использование длительных анимаций или отложенных задач: Полагаться на длительные таймауты в JavaScript (setTimeout) для отображения контента. Хотя Virtual Clock ускоряет время простоя, это увеличивает риск достижения Stop Task до появления контента.
• Игнорирование ошибок JavaScript: Rendering Result включает в себя ошибки (Errors). Наличие критических ошибок может прервать выполнение скриптов и привести к неполному рендерингу.

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

Патент подтверждает стратегическую важность технического SEO и понимания процесса рендеринга. Google разработал инфраструктуру, устойчивую к медленной загрузке ресурсов, но ориентированную на быстрое извлечение структуры и контента. Для SEO это означает, что оптимизация Critical Rendering Path, обеспечение стабильности макета (CLS) и эффективное выполнение JavaScript являются приоритетами для обеспечения полной индексации современных веб-сайтов.

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

Сценарий: Обеспечение стабильности макета для Googlebot (CLS)

1. Проблема: При анализе страницы инструментами Google наблюдается смещение макета (CLS).
2. Причина (на основе патента): Google WRS заменил реальные изображения на Mock Images. Если размеры изображений не были указаны в HTML, WRS не смог зарезервировать место и рассчитал Layout некорректно.
3. Действие: Прописать атрибуты width и height для всех тегов <img> и убедиться, что CSS корректно управляет адаптивностью (например, height: auto;).
4. Ожидаемый результат: Googlebot корректно рассчитывает Layout с зарезервированным пространством под изображения с самого начала рендеринга. Это улучшает оценку визуальной стабильности страницы.

Сценарий: Оптимизация рендеринга JavaScript-приложения (SPA)

1. Проблема: Контент загружается асинхронно через API. Есть риск, что Googlebot достигнет Stop Task до того, как контент появится в DOM.
2. Действия согласно патенту:
   • Убедиться, что запросы к API не блокируются (Googlebot их дождется благодаря Virtual Clock).
   • Оптимизировать код JavaScript, отвечающий за обработку ответа API и обновление DOM, чтобы ускорить появление контента.
   • Избегать использования искусственных задержек (setTimeout) перед запросом к API.
3. Ожидаемый результат: Рендеринг завершается быстрее, обеспечивая полную индексацию динамического контента до достижения Stop Task.