Как Google использует реальные данные о скорости загрузки страниц (RUM) для повышения быстрых и понижения медленных сайтов в выдаче

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

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

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

Central Tendency (Центральная тенденция)

Статистическая мера для расчета Load Time Measure. Упоминаются mean (среднее), trimmed mean, Winsorized mean, median (медиана).

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

Значение Multiplier Factor, применяемое для снижения рейтинга, если время загрузки превышает пороговое значение.

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

Первоначальная оценка ранжирования ресурса до учета времени загрузки.

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

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

Load Time Measure (Показатель времени загрузки)

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

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

Коэффициент, рассчитываемый на основе Load Time Measure и применяемый к Initial Score. Может быть понижающим (Demotion Value), повышающим (Promotion Value) или нейтральным.

Promotion Value (Значение повышения)

Значение Multiplier Factor, применяемое для повышения рейтинга очень быстрых ресурсов.

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

Компонент, отвечающий за расчет Multiplier Factor и корректировку оценок ранжирования.

Second Score / Load-adjusted Score (Итоговая оценка)

Оценка ранжирования после применения Multiplier Factor.

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

Предопределенное значение времени загрузки, основанное на процентилях распределения времени загрузки всех ресурсов в индексе. Используется для определения Multiplier Factor.

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

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

1. Система получает запрос и исходные оценки (First Score) для ресурсов.
2. Система получает доступ к Load Time Measure для каждого ресурса (статистическая мера выборки RUM-данных).
3. Система генерирует итоговую оценку (Second Score) путем корректировки First Score.
4. Механизм корректировки:
   • Сравнение Load Time Measure с первым пороговым значением (First Threshold Value). Этот порог представляет собой первый перцентиль времени загрузки в выборке собранных данных для ресурсов в индексе.
   • Если Load Time Measure превышает первый порог, к First Score применяется первый коэффициент-множитель (First Multiplier Factor).

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

Claim 9 (Зависимый от 1): Детализирует многоуровневую систему корректировки.

1. Если Load Time Measure НЕ превышает первый порог.
2. Система сравнивает его со вторым пороговым значением (Second Threshold Value), который представляет собой второй перцентиль.
3. Если Load Time Measure превышает второй порог, применяется второй коэффициент-множитель (Second Multiplier Factor).

Это описывает tiered-систему: очень медленные сайты получают сильное понижение, умеренно медленные — более слабое.

Claim 5, 7, 8 (Зависимые): Описывают возможность персонализации и сегментации.

Load Time Measure может быть рассчитан на основе данных только от тех пользователей, которые имеют общие атрибуты с текущим пользователем, такие как местоположение (Location, например, страна) или тип агента (Agent Type). Система может динамически рассчитывать новую метрику для нужного сегмента (Claim 8).

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

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

CRAWLING & INDEXING (Сканирование, Индексирование и Извлечение признаков)

• Сбор данных (Data Acquisition): Load Time Data Collector собирает данные RUM с пользовательских устройств (браузеры, тулбары). Это происходит асинхронно.
• Обработка и Агрегация (Feature Extraction): Load Time Data Aggregator обрабатывает эти данные офлайн, рассчитывает Load Time Measure (включая сегментированные метрики по географии/устройствам) и сохраняет их в Resource Index. Также на этом этапе определяются глобальные перцентили для установки Threshold Values.

RANKING / RERANKING (Ранжирование и Переранжирование)
Основное применение патента. Search Results Adjusting Engine выполняет корректировку.

• Получение исходных оценок: Генерация Initial Scores.
• Корректировка: Извлечение соответствующего (персонализированного) Load Time Measure из индекса.
• Применение фактора: Расчет и применение Multiplier Factor (повышение или понижение) для генерации Load-adjusted Score.
• Финальная сортировка: Результаты переупорядочиваются.

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

• Запрос и атрибуты пользователя (Agent Type, Location).
• Initial Scores для ресурсов.
• Агрегированные RUM данные (Load Time Data) из индекса.
• Глобальные Threshold Values (перцентили).

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

• Load-adjusted Scores и итоговый порядок SERP.

На что влияет

• Типы контента: Влияет на все типы ресурсов, для которых измеряется время загрузки (в первую очередь, веб-страницы).
• Географические и пользовательские факторы: Из-за сегментации метрик, сайт может ранжироваться по-разному в разных странах или на разных устройствах (Mobile/Desktop) в зависимости от его производительности в этом сегменте.
• Техническое состояние: Оказывает сильное влияние на сайты с медленным хостингом, неоптимизированным кодом или большим объемом ресурсов.

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

• Условия применения: Алгоритм применяется во время ранжирования при наличии статистически значимых данных.
• Триггеры активации: Корректировка активируется, когда Load Time Measure ресурса выходит за пределы установленных Threshold Values (как для понижения, так и для повышения).
• Исключения: Патент упоминает, что корректировка может не применяться:
  • Если недостаточно данных (например, менее 1000 замеров).
  • Для результатов с очень высокими оценками релевантности.
  • Для домашних страниц сайтов (Home pages).
  • Для навигационных ресурсов или запросов.
  • Для определенных типов запросов (например, новости, погода).

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

Процесс А: Офлайн-обработка данных (Сбор и Агрегация)

1. Сбор данных: Непрерывный сбор данных RUM (время загрузки + атрибуты пользователя) с пользовательских устройств. Данные анонимизируются.
2. Агрегация и Расчет метрик: Расчет Load Time Measure (например, медиана) для каждого ресурса. Расчет сегментированных метрик (например, скорость в США, скорость на Mobile).
3. Валидация данных: Проверка статистической значимости метрик.
4. Расчет порогов: Анализ глобального распределения времени загрузки и определение Threshold Values на основе перцентилей.
5. Сохранение: Запись Load Time Measures в Resource Index.

Процесс Б: Обработка запроса в реальном времени (Ранжирование)

1. Получение запроса и контекста: Получение запроса и атрибутов пользователя.
2. Генерация исходных оценок: Генерация Initial Scores.
3. Выбор метрики скорости: Извлечение наиболее подходящего Load Time Measure (общего или сегментированного под контекст пользователя).
4. Проверка исключений: Проверка, не попадает ли ресурс или запрос под исключения.
5. Расчет коэффициента (Multiplier Factor): Сравнение Load Time Measure с Threshold Values:
   • Если превышен Первый порог (например, >96-го перцентиля): Присвоить сильный Demotion Value.
   • Иначе, если превышен Второй порог (например, >85-го перцентиля): Присвоить слабый Demotion Value.
   • Иначе, если ниже Порога Повышения (например, <15-го перцентиля): Присвоить Promotion Value.
   • Иначе: Присвоить нейтральный коэффициент (1).
6. Корректировка оценок: Initial Score умножается на Multiplier Factor для получения Load-adjusted Score.
7. Переранжирование: Сортировка результатов по итоговым оценкам.

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

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

• Технические факторы (Производительность): Фактическое время загрузки ресурса (Load Time), собранное с реальных пользовательских устройств (RUM).
• Пользовательские факторы:
  • Agent Type (браузер, версия, тип устройства).
  • Тип сетевого соединения (упоминается как возможный атрибут).
• Географические факторы: Местоположение устройства (Location, например, страна).
• Источники данных: Веб-браузеры, дополнения (тулбары), ПО для мониторинга сети.

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

• Load Time Measure: Рассчитывается как статистическая мера (Central Tendency) собранных данных RUM. Упомянуты методы: mean, trimmed mean, Winsorized mean, median.
• Threshold Values (Пороги): Определяются на основе глобального распределения времени загрузки. Патент приводит конкретные примеры диапазонов перцентилей:
  • Первый порог (сильное понижение): 96-й — 99-й перцентиль.
  • Второй порог (слабое понижение): 85-й — 95-й перцентиль.
  • Порог повышения (Promotion): 1-й — 15-й перцентиль.
• Multiplier Factor (Коэффициент корректировки): Определяется путем сравнения Load Time Measure с порогами. Используется ступенчатая корректировка (дискретная функция), хотя упомянута возможность непрерывных функций.
• Агрегация по домену: Упоминается возможность расчета Load Time Measure на уровне домена или хоста и применения единого коэффициента ко всем страницам.
• Load-adjusted Score: Рассчитывается по формуле: $Load\_adjusted\_Score = Initial\_Score * Multiplier\_Factor$.

1. RUM как основа оценки скорости: Google использует данные, собранные с реальных устройств пользователей (Real User Monitoring), а не синтетические тесты, для оценки скорости в целях ранжирования.
2. Относительная скорость и пороговая система: Ключевым является не абсолютное время загрузки, а сравнение с глобальными порогами, основанными на процентилях. Если сайт медленнее определенного процента других сайтов (например, 85% или 96%), он будет понижен.
3. Многоуровневая корректировка (Tiered System): Система использует несколько порогов. Очень медленные сайты получают сильное понижение, умеренно медленные — более слабое. Также предусмотрена возможность повышения (Promotion) для самых быстрых сайтов (например, топ 1-15%).
4. Контекстуальная скорость (Сегментация): Load Time Measure рассчитывается и применяется с учетом контекста пользователя (география, тип устройства). Производительность сайта в одном регионе влияет на ранжирование именно в этом регионе.
5. Статистический подход и значимость: Скорость оценивается через агрегированные статистические метрики (например, медиану). Система требует достаточного объема данных для применения корректировки.
6. Исключения из правил: Скорость может игнорироваться для высокорелевантных результатов, навигационных запросов и домашних страниц, что предотвращает вытеснение критически важного контента из-за проблем с производительностью.

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

• Фокус на Real User Monitoring (RUM): Приоритет отдается оптимизации метрик, отражающих реальный пользовательский опыт. Необходимо анализировать данные RUM (например, через CrUX или собственные системы мониторинга), так как именно эти данные использует Google.
• Оптимизация Core Web Vitals: Метрики CWV (LCP, INP, CLS) являются современным воплощением Load Time Measure. Достижение порогов «Good» коррелирует с избеганием Demotion Values, описанных в патенте.
• Цель — быть в числе лучших: Стратегия должна быть направлена на то, чтобы сайт был быстрее большинства других. Цель — быть быстрее 85% сайтов, чтобы избежать понижения, а в идеале — попасть в топ 15% для получения возможного повышения (Promotion Value).
• Сегментированный анализ производительности: Анализируйте скорость в разрезе ключевых географических регионов и типов устройств (Mobile/Desktop). Патент подчеркивает использование сегментированных метрик, поэтому производительность должна быть высокой во всех целевых сегментах.
• Комплексная техническая оптимизация: Внедряйте лучшие практики по ускорению: оптимизация critical rendering path, использование CDN, оптимизация TTFB, эффективное кэширование, оптимизация JavaScript и медиа.

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

• Игнорирование скорости загрузки: Рассматривать производительность как второстепенную задачу. Патент доказывает наличие прямого механизма понижения медленных сайтов.
• Ориентация только на лабораторные тесты (Lighthouse): Использование только синтетических тестов недостаточно. Система Google полагается на полевые данные (RUM).
• Игнорирование производительности в отдельных регионах/устройствах: Оптимизация только для десктопа или только для домашнего региона приведет к потере позиций в других сегментах из-за контекстуальной оценки скорости.
• Перегрузка страниц тяжелыми элементами: Использование большого количества неоптимизированных изображений и сторонних скриптов (реклама, аналитика) увеличивает Load Time и риск превышения пороговых значений.

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

Этот патент является одним из основополагающих документов, подтверждающих интеграцию технических факторов производительности в ядро алгоритмов ранжирования Google. Он демонстрирует переход к оценке сайтов на основе реального пользовательского опыта. Стратегически, инвестиции в техническое SEO и производительность (особенно Core Web Vitals) являются обязательными для поддержания конкурентоспособности в поиске. Производительность — это не просто «tie-breaker», а фактор, способный значительно изменить выдачу.

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

Сценарий: Оптимизация интернет-магазина для международного рынка (Учет сегментации)

1. Анализ данных: SEO-команда анализирует данные CrUX и обнаруживает, что в Бразилии метрики скорости значительно хуже, чем в США. Load Time Measure для Бразилии, вероятно, превышает 85-й перцентиль.
2. Гипотеза (на основе патента): Google использует сегментированный Load Time Measure для пользователей из Бразилии (Claim 5) и применяет Second Demotion Value (Claim 9), что приводит к потере позиций в этом регионе.
3. Действия:
   • Внедрение CDN с узлами в Латинской Америке.
   • Оптимизация TTFB за счет улучшения инфраструктуры, обслуживающей этот регион.
   • Адаптация фронтенда для условий медленного соединения.
4. Ожидаемый результат: Улучшение RUM-метрик в Бразилии, снижение Load Time Measure ниже пороговых значений, отмена понижающего коэффициента и рост позиций в целевом регионе.