Как Google использует реальные данные о скорости загрузки сайта (RUM), адаптированные под контекст пользователя, для корректировки ранжирования

Описание

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

Патент решает проблему улучшения пользовательского опыта (UX) путем учета скорости загрузки веб-страниц при ранжировании. Признается, что при одинаковой релевантности пользователи предпочитают ресурсы, которые загружаются быстрее. Изобретение предоставляет механизм для понижения в выдаче медленно загружающихся ресурсов (Resource Load Times), тем самым улучшая качество SERP и удовлетворенность пользователей.

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

Запатентована система корректировки ранжирования на основе времени загрузки ресурсов, измеренного на реальных устройствах пользователей (Real User Monitoring — RUM). Ключевой особенностью является использование сегментированных данных о скорости загрузки. Система корректирует исходные оценки релевантности (First Score) на основе Load Time Measure, специфичной для контекста пользователя (например, его местоположения и типа устройства), а не на основе общих или лабораторных данных о скорости сайта.

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

Система работает в двух режимах: офлайн и онлайн.

• Офлайн (Сбор и Агрегация): Load Time Data System непрерывно собирает анонимизированные RUM-данные. Эти данные агрегируются для получения статистической метрики (Load Time Measure) и сегментируются по атрибутам пользователей (местоположение, тип браузера/устройства). Также определяются глобальные пороговые значения (перцентили).
• Онлайн (Ранжирование): При получении запроса система определяет атрибуты пользователя. Search Results Adjusting Engine извлекает исходные оценки ранжирования и соответствующие сегментированные Load Time Measure для ресурсов-кандидатов.
• Онлайн (Корректировка): Load Time Measure сравнивается с пороговыми значениями (например, 95-й перцентиль). Если порог превышен, к исходной оценке применяется понижающий коэффициент (Multiplier Factor/Demotion Value). Результаты переранжируются.

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

Критически высокая. Этот патент заложил основу для всех последующих обновлений Google, связанных со скоростью, включая Page Experience Signal и Core Web Vitals (CWV). Описанный механизм использования RUM-данных (полевые данные) для оценки скорости точно соответствует текущему подходу Google, основанному на данных CrUX (Chrome User Experience Report).

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

Патент имеет критическое значение для технического SEO. Он определяет механизм, по которому скорость загрузки влияет на ранжирование. Он подчеркивает абсолютный приоритет полевых данных (RUM/CrUX) над лабораторными (синтетическими) тестами. Кроме того, он указывает на необходимость оптимизации скорости для различных сегментов аудитории (география, типы устройств), поскольку корректировка ранжирования контекстуальна.

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

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

Agent Type (Тип агента)

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

Demotion Value (Значение понижения)

Значение Multiplier Factor (обычно < 1), используемое для уменьшения исходной оценки ранжирования ресурса, если его время загрузки превышает определенный порог.

First Score / Initial Score (Исходная оценка)

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

Load Time (Время загрузки)

Время, прошедшее с момента запроса ресурса до момента его полной отрисовки на устройстве пользователя (RUM-данные).

Load Time Data System (Система данных о времени загрузки)

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

Load Time Measure (Мера времени загрузки)

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

Multiplier Factor (Коэффициент-множитель)

Фактор, применяемый к исходной оценке для ее корректировки на основе Load Time Measure.

Search Results Adjusting Engine (Механизм корректировки результатов поиска)

Компонент, который вычисляет Multiplier Factor и применяет его к исходным оценкам ранжирования на этапе Reranking.

Threshold Value (Пороговое значение)

Заранее определенные значения времени загрузки, используемые для определения необходимости и степени понижения. Определяются как перцентили (например, 85-й или 96-й перцентиль) от всех собранных времен загрузки в индексе.

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

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

1. Система получает поисковый запрос от конкретного устройства и идентифицирует его атрибуты (например, местоположение, тип браузера).
2. Получаются исходные оценки (First Score) для релевантных ресурсов.
3. Система обращается к данным о времени загрузки. Критически важно: используется Load Time Measure, скомпилированная только из времен загрузки устройств, разделяющих хотя бы один атрибут с устройством пользователя.
4. Генерируется вторая оценка путем корректировки первой оценки на основе этой контекстной Load Time Measure.
5. Механизм корректировки:
   • Определяется, превышает ли Load Time Measure ресурса первый перцентиль времени загрузки в выборке всех собранных времен загрузки в индексе.
   • Если ДА, к исходной оценке применяется первый Multiplier Factor (понижение).
6. Предоставляется страница результатов поиска (SERP), упорядоченная по вторым оценкам.

Claims 4, 5, 6 (Зависимые): Уточняют, что атрибуты, используемые для сегментации данных о скорости, включают местоположение пользователя (например, страну) и Agent Type устройства.

Claim 7 (Зависимый): Уточняет механизм корректировки. Исходная оценка модифицируется путем умножения на Multiplier Factor, рассчитанный на основе Load Time Measure.

Claims 8, 9, 10 (Зависимые): Детализируют механизм многоуровневых пороговых значений (Thresholds).

1. Система проверяет, превышает ли Load Time Measure первое пороговое значение (Threshold 1, соответствующее первому перцентилю). Если ДА, устанавливается первый Multiplier Factor.
2. Если НЕТ, система проверяет, превышает ли Load Time Measure второе пороговое значение (Threshold 2, соответствующее второму перцентилю). Если ДА, устанавливается второй Multiplier Factor.

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

Изобретение затрагивает несколько этапов поиска, интегрируя данные о производительности в процесс ранжирования.

CRAWLING & INDEXING (Фоновый режим / Data Acquisition)
Load Time Data System работает непрерывно, собирая RUM-данные от пользователей (аналог современного CrUX). Она обрабатывает их, агрегирует в Load Time Measures, сегментирует по атрибутам (гео, устройство) и сохраняет эти данные в Resource Index, связывая их с соответствующими ресурсами.

RANKING / RERANKING (Этап корректировки)
Основное применение патента происходит после того, как базовые алгоритмы ранжирования определили исходные оценки (Initial Scores). Search Results Adjusting Engine активируется на этом этапе (работает как Twiddler):

1. Получение контекста: Определяются атрибуты пользователя, выполняющего запрос.
2. Извлечение данных: Для ресурсов-кандидатов извлекаются исходные оценки и соответствующие контексту пользователя сегментированные Load Time Measures.
3. Расчет и Применение: Вычисляется Multiplier Factor на основе сравнения Load Time Measure с пороговыми значениями (перцентилями). Исходные оценки корректируются.

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

• Атрибуты пользовательского устройства (Agent Type, Location).
• Исходные оценки ранжирования (Initial Scores).
• Сегментированные Load Time Measures.
• Глобальные пороговые значения (Threshold Values/Percentiles).

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

• Скорректированные оценки ранжирования (Load-adjusted Scores).

На что влияет

• Конкретные типы контента: Влияет на все типы веб-контента. Наибольшее влияние оказывается на «тяжелые» страницы: e-commerce листинги, статьи с большим количеством медиа или страницы, перегруженные JavaScript и рекламой.
• Специфические запросы: Влияние оказывается на большинство запросов. Однако в патенте упоминаются исключения: корректировка может не применяться для навигационных запросов или для ресурсов с чрезвычайно высокой оценкой релевантности.
• Языковые и географические ограничения: Применяется глобально, но эффект зависит от контекста. Система специально разработана для учета географических различий в скорости загрузки (например, из-за удаленности сервера, качества локальной сети или инфраструктуры CDN).

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

• Условия работы алгоритма: Алгоритм применяется при обработке запроса в реальном времени, на этапе переранжирования.
• Триггеры активации и пороговые значения: Корректировка (понижение) активируется только тогда, когда Load Time Measure ресурса превышает определенные пороговые значения. Патент предлагает использовать перцентили от всех измеренных времен загрузки в индексе. Примеры из описания патента:
  • Threshold 1 (Сильное понижение): 96-й – 99-й перцентиль.
  • Threshold 2 (Умеренное понижение): 85-й – 95-й перцентиль.
• Исключения и особые случаи: Алгоритм не применяется, если для ресурса собрано недостаточно данных (too few data points) для формирования статистически значимой Load Time Measure в данном сегменте. Также упоминается возможность агрегации на уровне домена/хоста.

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

Процесс А: Сбор и агрегация данных (Офлайн/Фоновый режим)

1. Сбор данных: Непрерывный сбор RUM-данных о времени загрузки ресурсов и атрибутов пользователей (агент, местоположение) с реальных устройств.
2. Агрегация и Сегментация: Вычисление Load Time Measure (например, медианы) для каждого ресурса, разделенное на сегменты на основе атрибутов (например, Load Time Measure для [Ресурс X, США, Chrome Mobile]).
3. Валидация данных: Проверка достаточности данных в каждом сегменте.
4. Индексирование: Сохранение сегментированных Load Time Measures в базе данных.
5. Расчет порогов: Определение глобальных пороговых значений (Threshold Values) на основе перцентилей всех собранных данных о времени загрузки.

Процесс Б: Корректировка ранжирования (Онлайн)

1. Получение запроса и контекста: Система получает запрос и определяет атрибуты пользователя (например, Индия, Firefox Desktop).
2. Получение исходных оценок: Получение списка релевантных ресурсов и их Initial Scores.
3. Извлечение Load Time Measure: Для каждого ресурса извлекается Load Time Measure, соответствующая сегменту пользователя (Индия, Firefox Desktop).
4. Сравнение с порогом 1: Проверка, превышает ли Load Time Measure ресурса Threshold 1 (например, 96-й перцентиль).
5. Применение понижения 1: Если ДА, Initial Score умножается на первый (сильный) Demotion Value. Переход к следующему ресурсу.
6. Сравнение с порогом 2: Если НЕТ, проверка, превышает ли Load Time Measure ресурса Threshold 2 (например, 85-й перцентиль).
7. Применение понижения 2: Если ДА, Initial Score умножается на второй (умеренный) Demotion Value.
8. Без изменений: Если НЕТ, Initial Score остается без изменений (или применяется Promotion Value, если система настроена на повышение быстрых сайтов).
9. Переранжирование: Ресурсы сортируются по итоговым скорректированным оценкам.

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

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

Патент фокусируется исключительно на данных о производительности и контексте пользователя.

• Технические факторы (Производительность): Resource Load Times. Это реальные данные времени загрузки (RUM), собранные с устройств пользователей.
• Пользовательские и Географические факторы:
  • Agent Type: Тип устройства и версия браузера.
  • Location: Местоположение пользователя (например, страна).
  • Network Connection: Тип сетевого соединения (упоминается как возможный атрибут для сегментации).

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

• Load Time Measure: Статистическая мера (центральная тенденция, например, среднее, медиана) времени загрузки для определенного ресурса в определенном сегменте пользователей.
• Threshold Values (Пороговые значения): Рассчитываются на основе распределения всех собранных времен загрузки в индексе. Патент предлагает использовать перцентили для определения порогов (например, 85-й, 96-й перцентили). Это динамические значения, которые адаптируются к общей скорости интернета.
• Multiplier Factor / Demotion Value: Фиксированные или динамические коэффициенты, применяемые при превышении порогов. Первый коэффициент сильнее понижает оценку, чем второй.

Выводы

1. Скорость загрузки как контекстный фактор ранжирования: Время загрузки используется для корректировки ранжирования. Важно, что это не универсальная оценка скорости, а контекстная. Система использует Load Time Measure, собранную именно от пользователей с такими же атрибутами (браузер, страна), как у пользователя, выполняющего запрос.
2. Приоритет RUM (Field Data): Система основана исключительно на данных реальных пользователей (RUM), а не на лабораторных тестах. Это подтверждает, что для SEO важны именно полевые данные (сегодня это Core Web Vitals из CrUX).
3. Механизм Понижения (Demotion), а не Повышения (Boost): Основной описанный механизм направлен на пессимизацию медленных сайтов, а не на поощрение быстрых. Если сайт «достаточно быстр» (не превышает пороговые значения), он не получает значительного преимущества перед другими «достаточно быстрыми» сайтами по этому фактору.
4. Пороговые значения на основе перцентилей: Система использует динамические пороги, основанные на сравнении с общей производительностью веба. Чтобы избежать понижения, сайт должен быть быстрее, чем определенный процент других сайтов (например, быстрее 85% сайтов).
5. Требование достаточности данных: Сигнал применяется только при наличии статистически значимого объема данных для конкретного ресурса и сегмента пользователей. Новые или низкопосещаемые сайты могут не подвергаться этой корректировке.

Практика

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

• Мониторинг и оптимизация Field Data (CrUX): Основной фокус должен быть на мониторинге данных Chrome User Experience Report (CrUX), так как они напрямую отражают Load Time Measures, описанные в патенте. Используйте Google Search Console (отчет Core Web Vitals) и публичные данные CrUX.
• Сегментированная оптимизация производительности: Анализируйте скорость загрузки в разрезе ключевых географических рынков и типов устройств (мобильные/десктопные). Убедитесь, что сайт работает быстро не только в вашем регионе, но и там, где находится ваша целевая аудитория.
• Оптимизация высоких перцентилей (P75, P95): Поскольку пороги для понижения находятся в диапазоне 85-99%, критически важно оптимизировать опыт для самых медленных пользователей. Необходимо анализировать «хвост» распределения производительности и устранять причины медленной загрузки в этих сегментах.
• Использование CDN и оптимизация инфраструктуры: Для обеспечения быстрой загрузки в разных географических точках критически важно использовать сети доставки контента (CDN) и оптимизировать серверную инфраструктуру (Time to First Byte).
• Кросс-браузерная оптимизация: Так как данные сегментируются по Agent Type, необходимо убедиться, что сайт быстро работает во всех популярных браузерных движках (Blink, WebKit, Gecko).

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

• Ориентация только на лабораторные тесты (Lighthouse): Использование только синтетических тестов для оценки скорости. Эти данные не отражают реальный пользовательский опыт (RUM), который используется в ранжировании.
• Игнорирование мобильной производительности: Мобильные устройства часто имеют более сложные условия загрузки. Игнорирование оптимизации для мобильных сегментов гарантированно приведет к понижению позиций в мобильной выдаче из-за сегментации по Agent Type.
• Игнорирование международной производительности: Для международных проектов недопустимо оценивать скорость только из одной локации. Плохая инфраструктура или отсутствие CDN может привести к пессимизации в ключевых регионах из-за сегментации по Location.
• Перегрузка страниц сторонними скриптами: Неконтролируемое добавление маркетинговых тегов, рекламных блоков и виджетов часто является основной причиной медленной загрузки у реальных пользователей и превышения пороговых значений.

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

Этот патент является фундаментальным подтверждением того, что скорость и техническое совершенство сайта являются неотъемлемой частью SEO-стратегии. Он демонстрирует, что Google рассматривает производительность не абстрактно, а в контексте реального пользовательского опыта. Стратегически это означает, что инвестиции в инфраструктуру, технический стек и постоянный мониторинг производительности (особенно RUM-данных) критически важны для поддержания и улучшения позиций в поиске.

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

Сценарий: Оптимизация международного E-commerce сайта

Сайт компании базируется в США и запускает версию для Индии. Необходимо обеспечить конкурентоспособное ранжирование на новом рынке.

1. Анализ (Что делать): Проанализировать текущие RUM-данные (CrUX) для сегмента «Индия, Мобильные устройства». Сравнить показатели с конкурентами на индийском рынке.
2. Выявленная проблема: Обнаружено, что из-за удаленности серверов и качества местных сетей время загрузки (LCP) значительно превышает порог в 2.5 секунды и попадает в 90-й перцентиль.
3. Действия (Как делать): Принимается решение о подключении локального CDN-провайдера в Индии, оптимизации изображений в формат WebP и отложенной загрузке некритичного JavaScript.
4. Ожидаемый результат: После внедрения RUM-данные для индийского сегмента улучшаются и опускаются ниже пороговых значений. Search Results Adjusting Engine перестает применять Demotion Value к страницам сайта для пользователей из Индии, что улучшает ранжирование на этом рынке.

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