Как Google ускоряет сканирование и рендеринг, пропуская загрузку ресурсов, не влияющих на контент

Описание

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

Патент решает проблему неэффективности и медлительности процесса рендеринга веб-страниц, особенно в масштабах индексации интернета. Современные страницы часто содержат сотни встроенных ресурсов (скрипты, стили). Загрузка каждого из них требует времени и вычислительных мощностей. Многие из этих ресурсов (например, скрипты аналитики, трекеры, рекламные пиксели) не влияют на финальный видимый контент или структуру страницы (content neutral embedded items). Изобретение направлено на ускорение рендеринга и экономию ресурсов (Crawl Budget) за счет отказа от загрузки таких несущественных элементов.

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

Запатентована система для автоматической идентификации «необязательных ресурсов» (Optional Resources) и оптимизации процесса рендеринга путем пропуска их загрузки. Система анализирует журналы загрузок, выявляет общие шаблоны URL (URL Patterns), тестирует влияние этих ресурсов на контент путем сравнительного рендеринга и создает базу данных Optional Resource Patterns. В дальнейшем рендерер (например, Googlebot/WRS) использует эту базу, чтобы игнорировать загрузку совпадающих ресурсов.

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

Система функционирует в двух основных режимах:

• Офлайн-анализ (Идентификация): Система периодически анализирует логи загрузок (Fetch Records). URL группируются по шаблонам, часто путем удаления строк запроса (query strings). Для популярных шаблонов проводится тест: родительская страница рендерится с загрузкой ресурса и без него. Результаты рендеринга (DOM, Layout, текст) сравниваются. Если рассчитываемая оценка схожести (Similarity Score) высока, шаблон помечается как необязательный.
• Онлайн-применение (Оптимизация): Когда рендерер обрабатывает страницу и встречает встроенный ресурс, он проверяет его URL по базе Optional Resource Patterns. Если URL соответствует необязательному шаблону, система сообщает рендереру, что ресурс можно пропустить (например, симулируя ошибку «не найдено», как указано в Claim 1), и загрузка не производится.

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

Высокая. В условиях доминирования JavaScript-фреймворков и Mobile-First Indexing эффективность рендеринга является критическим фактором для скорости и полноты индексации интернета. Этот патент описывает ключевую инфраструктурную оптимизацию, позволяющую Google масштабировать свой Web Rendering Service (WRS) и более эффективно управлять глобальным краулинговым бюджетом.

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

Патент имеет высокое значение для технического SEO (7.5/10). Он не описывает факторы ранжирования, но критически важен для понимания процессов сканирования и индексации. Он объясняет механизм, с помощью которого Google экономит свои ресурсы, игнорируя несущественный код. Главный риск для SEO заключается в том, что критически важный для отображения контента ресурс может быть ошибочно классифицирован как необязательный и проигнорирован Googlebot’ом, что приведет к проблемам с индексацией.

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

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

Batch Rendering System (Система пакетного рендеринга)

Система, предназначенная для массового рендеринга веб-страниц, часто используемая в процессе индексации (например, WRS Google).

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

Объект, встроенный в веб-страницу (JS, CSS, изображение), который необходимо загрузить в процессе рендеринга. Если он не влияет на контент, он также называется Content Neutral Item.

Fetch Records (Журналы загрузок)

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

Group URL

Обобщенный URL, созданный из конкретного URL путем удаления части или всей строки запроса (query string). Используется для кластеризации.

Indeterminism (Индетерминизм)

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

Layout (Макет)

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

LCS (Longest Common Sequence) (Наибольшая общая подпоследовательность)

Метрика, используемая для определения степени схожести между двумя структурами, например, двумя DOM-деревьями или макетами.

Optional Resource (Необязательный ресурс)

Встроенный ресурс, отсутствие которого не оказывает существенного влияния на контент или внешний вид отрендеренной веб-страницы.

Optional Resource Patterns (Шаблоны необязательных ресурсов)

База данных, хранящая шаблоны URL, которые были идентифицированы системой как необязательные.

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

Выходные данные процесса рендеринга. Включают снимок страницы (Image), DOM-дерево (DOM Tree), Макет (Layout), видимый текст (Tokens), исходящие ссылки (Outlinks) и ошибки.

Similarity Score (Оценка схожести)

Числовая метрика, рассчитываемая путем сравнения двух результатов рендеринга (с загрузкой ресурса и без него).

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

Патент US10284623B2 является продолжением (Continuation) более ранних заявок (с 2014 года) и фокусируется на работе сервиса оптимизации.

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

1. Система получает URL встроенного ресурса от запрашивающей стороны (requestor, например, Googlebot или браузер).
2. Система определяет, является ли ресурс необязательным, путем проверки соответствия URL шаблону в базе данных необязательных ресурсов.
3. Если ресурс необязательный: система предоставляет индикацию, что ресурс «не найден» (indication that the embedded resource is not found).
4. Если ресурс обязательный: система загружает контент ресурса и предоставляет его запрашивающей стороне.

Система активно симулирует ошибку «не найдено» для необязательных ресурсов. Это заставляет рендерер немедленно прекратить попытки загрузки и продолжить обработку страницы без этого ресурса.

Claims 3 и 4 (Зависимые): Детализируют процесс сопоставления с шаблоном.

Перед проверкой URL может быть нормализован путем удаления всей строки запроса (Claim 3) или ее части (Claim 4). Это позволяет системе игнорировать динамические параметры (например, ID сессий, кэш-бастеры, UTM-метки) при определении необязательности ресурса.

Claim 19 (Зависимый от 11): Детализирует офлайн-процесс генерации базы данных шаблонов.

1. Идентификация шаблона URL (URL pattern), общего для множества URL в Fetch Records.
2. Выборка (sampling) URL, соответствующих этому шаблону.
3. Для каждого URL в выборке проводится тест: генерация рендеринга с ресурсом и без него, расчет Similarity Score. Ресурс признается необязательным, если оценка схожести превышает порог.
4. Если предопределенное количество (например, большинство или все) ресурсов в выборке признано необязательным, общий шаблон URL сохраняется в базе Optional Resource Patterns.

Claims 6 и 7 (Зависимые от 5): Описывают механизм учета индетерминизма рендеринга.

Для повышения точности система генерирует третий результат рендеринга, используя тот же контент, что и для первого. Различия между первым и третьим результатами считаются вызванными индетерминизмом. Эти различия (например, нестабильные DOM-узлы, как указано в Claim 7) игнорируются при расчете финального Similarity Score.

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

Изобретение является частью инфраструктуры сканирования и индексации Google.

CRAWLING – Сканирование и Сбор данных
На этом этапе происходит взаимодействие с Fetch Service. Если Fetch Service определяет, что запрашиваемый встроенный ресурс соответствует Optional Resource Pattern, загрузка отменяется (например, возвращается ошибка «не найдено»). Это напрямую экономит сетевые ресурсы краулера и оптимизирует Crawl Budget.

INDEXING – Индексирование и извлечение признаков
Основное применение происходит на подэтапе Рендеринга (WRS).

1. Рендеринг (Онлайн): Batch Rendering System (аналог WRS) обрабатывает страницу. Если ресурс помечен как необязательный, рендерер пропускает его и продолжает обработку страницы без него, что ускоряет процесс.
2. Анализ (Офлайн): Компонент Optional Resource Identification Engine периодически анализирует Fetch Records. Он использует Batch Rendering System для массового сравнительного рендеринга для идентификации новых необязательных шаблонов и валидации старых.

Входные данные (Онлайн):

• URL встроенного ресурса.
• База данных Optional Resource Patterns.

Выходные данные (Онлайн):

• Индикация «пропустить загрузку» (например, ошибка «не найдено») ИЛИ контент ресурса.

На что влияет

• Конкретные типы контента: Наиболее сильно влияет на страницы, использующие множество сторонних скриптов, систем аналитики (патент упоминает Google Analytics JavaScript code как пример), рекламных сетей и трекеров, которые не изменяют основной контент страницы.
• Технологии: Критически важно для сайтов, использующих JavaScript-фреймворки (SPA/PWA), где оптимизация рендеринга имеет первостепенное значение.
• Типы устройств: В патенте упоминается возможность раздельной классификации ресурсов для разных типов браузеров (например, мобильные и десктопные). Ресурс может быть обязательным для десктопной версии и необязательным для мобильной.

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

• Онлайн-процесс: В реальном времени при каждой попытке загрузки встроенного ресурса во время рендеринга страницы.
• Офлайн-процесс: Периодически (например, ежедневно или еженедельно) для обработки накопленных логов.
• Условия активации анализа: Система анализирует только те шаблоны URL, которые встречаются достаточно часто (превышают порог популярности, Size Threshold, в Fetch Records).
• Условия классификации как «Необязательный»: Только если Similarity Score между рендерингом с ресурсом и без него превышает высокий порог (например, 80% или выше), и это подтверждается на достаточной выборке страниц.

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

Процесс А: Оптимизированный Рендеринг (Онлайн)

1. Начало рендеринга: Рендерер начинает обработку веб-страницы.
2. Идентификация ресурса: Обнаружение встроенного ресурса, требующего загрузки.
3. Запрос к Сервису и Нормализация: Рендерер отправляет URL ресурса в сервис оптимизации. Сервис может нормализовать URL, например, удалив строку запроса.
4. Проверка шаблона: Сервис проверяет, соответствует ли нормализованный URL какому-либо шаблону в базе Optional Resource Patterns.
5. Принятие решения и ответ:
   • Если совпадает (Необязательный): Сервис возвращает индикацию, что ресурс не требуется или не найден. Рендерер пропускает загрузку.
   • Если не совпадает (Обязательный): Ресурс загружается, и его контент передается рендереру.
6. Завершение рендеринга: Рендерер завершает построение страницы, игнорируя необязательные ресурсы.

Процесс Б: Идентификация Необязательных Шаблонов (Офлайн)

1. Сбор данных и Кластеризация: Анализ Fetch Records. Генерация потенциальных шаблонов (Group URL) путем удаления строк запроса. Кластеризация URL по этим шаблонам.
2. Фильтрация по популярности: Выбор шаблонов, количество загрузок по которым превышает установленный порог (Size Threshold).
3. Сэмплирование: Из популярного кластера выбирается образец (sample) уникальных URL и их родительских страниц.
4. Тестирование (для каждого элемента выборки):
   • Генерация Рендеринга 1: Рендеринг родительской страницы С загрузкой ресурса.
   • Генерация Рендеринга 2: Рендеринг той же страницы БЕЗ загрузки ресурса.
   • (Опционально) Генерация Рендеринга 3: Повторный рендеринг С загрузкой ресурса для выявления индетерминизма.
5. Сравнение и Расчет Метрик: Расчет Similarity Score между Рендерингом 1 и 2 (с поправкой на индетерминизм, если он измерялся). Сравниваются токены (текст), исходящие ссылки (Outlinks), DOM-дерево (например, через LCS) и Layout.
6. Принятие решения о шаблоне: Если значительное большинство протестированных URL в выборке показали высокий Similarity Score (выше порога), весь шаблон признается необязательным.
7. Обновление базы данных: Шаблон добавляется в Optional Resource Patterns.

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

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

• Технические факторы: URL встроенных ресурсов, URL родительских страниц (embedder URLs). Строки запроса (query strings) используются для генерации шаблонов. Данные о типе браузера (User-Agent: мобильный/десктоп).
• Системные данные: Fetch Records (исторические логи загрузок).

Во время офлайн-анализа система использует данные, полученные в результате рендеринга (Rendering Result):

• Контентные факторы: Видимый текст (Tokens), исходящие ссылки (Outlinks).
• Структурные факторы: DOM-дерево (DOM Tree).
• Визуальные факторы (Layout): Геометрическое расположение и размеры элементов на странице (boxes). Снимок страницы (Image).

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

Ключевой метрикой является Similarity Score. Патент описывает несколько методов ее расчета:

• Сравнение токенов (Tokens): Сравнение видимого текста. Небольшие различия (ниже Token Threshold, например, менее 5 токенов) могут игнорироваться.
• Сравнение исходящих ссылок (Outlinks): Сравнение набора ссылок, ведущих на другие страницы.
• Структурное сравнение (LCS): Расчет Longest Common Sequence для DOM-дерева или Layout для определения процента совпадения.
• Визуальное сравнение (Layout/Overlapping Score): Идентификация основных компонентов (Major Components — самых больших блоков на странице) и расчет площади их перекрытия. Патент упоминает использование гармонического среднего площади перекрытия для расчета оценки схожести.

Пороговые значения:

• Similarity Threshold (Порог схожести): Минимальное значение Similarity Score (например, 80%), при котором ресурс признается необязательным.
• Size Threshold (Порог популярности): Минимальное количество загрузок ресурса по шаблону, необходимое для его анализа.

Учет индетерминизма: Система использует тройной рендеринг для выявления нестабильности. Различия, вызванные индетерминизмом, исключаются из расчета финального Similarity Score.

Выводы

1. Эффективность рендеринга — приоритет инфраструктуры Google: Патент демонстрирует, что Google активно ищет способы ускорить и удешевить процесс индексации. Экономия на загрузке несущественных скриптов позволяет эффективнее использовать Crawl Budget.
2. Автоматическое игнорирование «балластного» кода: Ресурсы (JS, CSS, пиксели), которые не влияют на видимый контент (Tokens), структуру (DOM), ссылки (Outlinks) или макет (Layout), автоматически классифицируются как Optional Resources и игнорируются при рендеринге.
3. Идентификация основана на шаблонах URL и тестировании: Система выявляет Optional Resource Patterns путем анализа популярности URL и проведения сравнительного тестирования рендеринга. Удаление строк запроса (query strings) является ключевым методом генерации этих шаблонов.
4. Комплексное сравнение результатов рендеринга: Для определения влияния ресурса используется сложный анализ, включающий структурное (LCS) и визуальное (Overlapping Score) сравнение, а также механизмы учета индетерминизма.
5. Риск ложной классификации для SEO: Существует риск того, что ресурс, критически важный для отображения контента, может быть ошибочно классифицирован как необязательный, если его URL похож на популярный необязательный шаблон или если его влияние на контент не было выявлено в процессе тестирования (особенно из-за удаления query strings).
6. Учет специфики устройств: Система может по-разному классифицировать ресурсы для мобильных и десктопных версий.

Практика

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

• Мониторинг загрузки ресурсов в GSC: Регулярно используйте инструмент проверки URL в Google Search Console. Анализируйте отрендеренную страницу (Снимок экрана и HTML) и список запрошенных ресурсов («Запросы страниц»). Если критический ресурс не был загружен (и это не связано с блокировкой в robots.txt), возможно, он был классифицирован как Optional Resource.
• Использование чистых и семантичных URL для критических ресурсов: Убедитесь, что URL скриптов и стилей, необходимых для отображения основного контента (MC) и навигации, четко отражают их назначение и не похожи на URL систем аналитики или трекеров.
• Разделение функциональности: Не смешивайте критически важный функционал (загрузка контента) и второстепенный (трекинг, аналитика) в одном JS-файле. Это снижает риск того, что весь файл будет проигнорирован из-за наличия в нем некритичного кода.
• Тестирование рендеринга в изоляции: Проверяйте (например, с помощью инструментов разработчика в браузере), как сайт рендерится без загрузки сторонних скриптов (аналитика, реклама, виджеты). Основной контент должен оставаться доступным и корректно отформатированным.
• Обеспечение стабильности рендеринга: Минимизируйте индетерминизм (например, случайное расположение блоков или разные ответы API при каждой загрузке), так как это может повлиять на то, как Google оценивает схожесть страниц и влияние ресурсов.

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

• Маскировка URL критических ресурсов: Не называйте скрипты, отвечающие за загрузку контента, именами вроде tracker.js, ads.js или pixel.gif. Это увеличивает риск того, что система классифицирует их как необязательные по шаблону и проигнорирует.
• Использование Query Strings для дифференциации критического функционала: Это самый большой риск. Если разные параметры в строке запроса одного и того же JS-файла критически меняют его функцию (например, script.js?action=load_content и script.js?action=track_view), это крайне опасно. Система может сгенерировать шаблон, удалив query string (script.js), и классифицировать весь шаблон как необязательный.
• Чрезмерная зависимость от сложных цепочек JavaScript: Построение основного контента через длинные цепочки динамически загружаемых скриптов увеличивает риск сбоя рендеринга, в том числе из-за того, что один из скриптов в цепочке может быть классифицирован как необязательный.

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

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

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

Сценарий 1: Успешная оптимизация (Как это работает в идеале)

1. Анализ: Google обнаруживает, что ресурс https://www.google-analytics.com/analytics.js загружается миллиарды раз.
2. Шаблон: Система использует этот URL как шаблон.
3. Тестирование: Рендеринг страниц с этим ресурсом и без него показывает идентичный контент (Similarity Score > 99%).
4. Результат: Шаблон добавляется в Optional Resource Patterns. Googlebot перестает загружать analytics.js при индексации, экономя огромные ресурсы.

Сценарий 2: Риск для SEO (Ложное срабатывание из-за Query String)

1. Ситуация: Интернет-магазин использует скрипт https://api.example.com/v1/loader.js. С параметром ?action=track_view он отслеживает просмотры (необязательный). С параметром ?action=load_reviews&product_id=555 он загружает отзывы (критически важный контент).
2. Анализ Google: Система генерирует шаблон, удаляя query string: https://api.example.com/v1/loader.js.
3. Тестирование: При тестировании на выборке страниц (где, возможно, доминирует action=track_view или страницы без отзывов) скрипт не влияет на основной контент.
4. Результат: Шаблон loader.js классифицируется как необязательный.
5. Проблема: При сканировании карточки товара Googlebot игнорирует скрипт с параметром action=load_reviews из-за совпадения с базовым шаблоном. Отзывы не рендерятся и не индексируются.
6. Решение SEO: Разделить функционал на разные URL: /v1/tracker.js и /v1/reviews_loader.js.

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