Как Google учитывает объем трафика для загрузки страницы при ранжировании, особенно для пользователей с лимитированным интернетом

Описание

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

Патент решает проблему ухудшения пользовательского опыта у людей, использующих интернет в условиях ограничений трафика (например, лимитированные тарифные планы мобильной связи или низкая пропускная способность сети). Загрузка «тяжелых» веб-страниц приводит к излишнему расходу данных и увеличению времени ожидания. Цель изобретения — скорректировать ранжирование так, чтобы отдавать предпочтение более эффективным с точки зрения потребления данных ресурсам, когда это уместно.

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

Запатентована система, которая измеряет объем данных, необходимый для загрузки документа (data measure), и использует этот показатель как сигнал ранжирования. Ключевой особенностью является условное применение этого сигнала: он активируется или усиливается, когда система определяет, что запрос, вероятно, отправлен через limited data plan (лимитированный тарифный план), и/или когда запрос является не навигационным (non-navigational).

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

Система работает в два этапа:

• Индексирование: Модуль (Document Data Usage Module) во время сканирования определяет объем данных, необходимый для полной отрисовки документа (включая HTML и все связанные ресурсы: изображения, скрипты и т.д.). Этот показатель (data measure) сохраняется в индексе.
• Ранжирование: При получении запроса модуль анализа (Query Analysis Module) оценивает контекст (тип запроса, предполагаемый тип сети пользователя). Если условия соблюдены (например, обнаружен limited data plan), система корректирует ранжирование. Более «легкие» документы получают повышение. Если обнаруживаются документы с похожим контентом (similar content), предпочтение отдается тому, который требует меньше данных для загрузки.

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

Высокая. С ростом мобильного трафика и сохраняющейся актуальностью проблемы стоимости и скорости данных во многих регионах мира, эффективность загрузки остается критически важной. Этот патент напрямую связан с общим направлением Google на улучшение Page Experience и Core Web Vitals, поскольку объем передаваемых данных напрямую влияет на скорость загрузки в реальных условиях.

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

Влияние на SEO значительно, но специфично. Патент подчеркивает важность технической оптимизации и эффективности ресурсов (изображений, скриптов). Хотя сигнал применяется условно (в основном при обнаружении limited data plan), он критически важен для стратегий мобильного SEO и продвижения на международных рынках с дорогой или медленной мобильной связью. Оптимизация под этот патент синергична с оптимизацией под Core Web Vitals.

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

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

Data Measure (Показатель объема данных)

Метрика, связанная с документом, которая указывает на объем данных (трафика), необходимый для его загрузки и отрисовки. Может быть фактическим измеренным значением (в байтах, кБ, МБ) или нормализованной оценкой.

Document Data Usage Module (Модуль оценки объема данных документа)

Компонент системы индексирования, отвечающий за доступ к документу, измерение объема трафика при его загрузке и сохранение Data Measure.

Document Similarity Module (Модуль схожести документов)

Компонент системы ранжирования, который определяет, содержат ли два или более документа похожий контент (similar content).

Limited Data Plan (Лимитированный тарифный план)

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

Navigational Query (Навигационный запрос)

Запрос, указывающий на намерение найти конкретный веб-сайт или страницу (например, «facebook»). Для таких запросов алгоритм может отключаться.

Non-navigational Query (Не навигационный запрос)

Запрос (информационный или транзакционный), не имеющий целью конкретный сайт. Для таких запросов алгоритм применяется с большим весом.

Query Analysis Module (Модуль анализа запросов)

Компонент, определяющий характеристики запроса и контекст пользователя, в частности, является ли запрос навигационным и используется ли Limited Data Plan.

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

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

1. Система получает поисковый запрос.
2. Определяется, что запрос, вероятно, отправлен через limited data plan.
3. Идентифицируются релевантные документы.
4. Определяется first data measure для первого документа (на основе данных, полученных при предыдущем извлечении документа).
5. Первый документ ранжируется относительно других документов на основе (i) first data measure И (ii) факта определения limited data plan.

Ядро изобретения заключается в условном применении фактора объема данных: ранжирование корректируется только тогда (или сильнее), когда система считает, что пользователь ограничен в потреблении трафика.

Claim 2, 3, 4 (Зависимые): Детализируют сценарий с похожими документами.

1. Определяется, что второй документ похож на первый.
2. Определяется second data measure для второго документа.
3. Ранжирование первого документа относительно второго основывается на сравнении их data measures (Claim 3).
4. Если data measure первого документа указывает на меньшее потребление данных, чем у второго, первый документ ранжируется выше (Claim 4).

Если контент схож, система предпочитает более «легкую» версию.

Claim 5 (Зависимый): Добавляет дополнительное условие.

Ранжирование на основе data measure происходит, только если запрос определен как non-navigational.

Claim 6, 7, 8 (Зависимые): Описывают механизм корректировки оценки.

1. Определяется начальный рейтинг (initial ranking) документа, не зависящий от data measure (Claim 6).
2. Начальный рейтинг модифицируется на основе data measure.
3. Если data measure пропорционален объему данных, модификация может происходить путем умножения начальной оценки релевантности (initial relevance score) на величину, обратную data measure (1 / Data Measure) (Claim 8).

Это математически означает, что чем больше объем данных, тем ниже итоговая оценка.

Claim 13 (Зависимый): Уточняет механизм взвешивания.

Вес (weighting) фактора data measure в ранжировании зависит от степени вероятности (likelihood) того, что запрос отправлен через limited data plan.

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

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

INDEXING – Индексирование и извлечение признаков
На этом этапе работает Document Data Usage Module. Он загружает документ и все необходимые для его отрисовки ресурсы (изображения, JS, CSS) и измеряет общий объем потребленных данных. Полученный Data Measure сохраняется в индексе вместе с идентификатором документа.

QUNDERSTANDING – Понимание Запросов
На этом этапе работает Query Analysis Module. Он анализирует запрос и контекст пользователя в реальном времени, чтобы определить:

• Является ли запрос навигационным или нет.
• Какова вероятность того, что пользователь использует Limited Data Plan (на основе IP, типа сети и т.д.).

RANKING / RERANKING – Ранжирование и Переранжирование
Основное применение патента. Ranking Engine использует результаты этапа QUNDERSTANDING как триггеры.

1. Применение сигнала: Если обнаружен Limited Data Plan и/или запрос Non-navigational, Data Measure используется как сигнал ранжирования (например, для модификации initial relevance score).
2. Обработка схожести: Document Similarity Module может идентифицировать документы с похожим контентом. В этом случае их взаимное ранжирование определяется сравнением их Data Measures.

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

• Запрос пользователя и контекстные данные (сеть, устройство).
• Набор релевантных документов из индекса.
• Предварительно рассчитанные Data Measures для этих документов.
• Начальные оценки релевантности (Initial relevance scores).

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

• Скорректированный набор результатов поиска, где позиции документов изменены с учетом объема данных, необходимого для их загрузки.

На что влияет

• Конкретные типы контента: Сильнее всего влияет на страницы с большим количеством неоптимизированных медиафайлов (изображения, видео), избыточным кодом JavaScript и многочисленными сторонними скриптами (реклама, аналитика).
• Определенные форматы контента: Дает преимущество оптимизированным форматам (например, легким мобильным версиям) перед тяжелыми десктопными версиями при поиске с мобильных устройств.
• Географические факторы: Имеет критическое значение в регионах, где распространены медленные мобильные сети (например, 2G/3G) или дорогие тарифные планы с оплатой за трафик.

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

Алгоритм применяется выборочно, при выполнении определенных условий:

• Триггер активации 1 (Основной): Система определяет высокую вероятность того, что запрос отправлен пользователем, использующим limited data plan.
• Триггер активации 2 (Уточняющий): Запрос классифицирован как non-navigational. Для навигационных запросов фактор может игнорироваться, так как пользователь хочет попасть на конкретный сайт независимо от его размера.
• Условие сравнения: Когда в выдаче присутствуют два или более документа, идентифицированных как имеющие similar content.

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

Процесс А: Измерение объема данных (Этап Индексирования)

1. Идентификация документа: Система обнаруживает документ для индексации.
2. Доступ и загрузка: Document Data Usage Module загружает документ, эмулируя поведение браузера (загрузка HTML и всех связанных ресурсов для отрисовки).
3. Измерение: Определяется общий объем данных (трафика), использованный для загрузки. Это может быть среднее значение по нескольким загрузкам, если контент динамический (например, реклама).
4. Сохранение: Идентификатор документа ассоциируется с рассчитанным Data Measure в индексе.

Процесс Б: Ранжирование (Real-time)

1. Получение запроса.
2. Анализ контекста (QUNDERSTANDING): Query Analysis Module определяет вероятность использования Limited Data Plan и классифицирует запрос (Navigational/Non-navigational).
3. Определение веса фактора: На основе анализа контекста определяется вес (weighting) для Data Measure. Если вероятность Limited Data Plan низкая, вес может быть нулевым или минимальным.
4. Идентификация и начальное ранжирование: Система находит релевантные документы и рассчитывает initial relevance scores.
5. Анализ схожести (Опционально): Document Similarity Module проверяет наличие документов с похожим контентом среди кандидатов.
6. Корректировка ранжирования:
   • Сценарий 1 (Общий): Если вес фактора > 0, initial relevance scores модифицируются с учетом Data Measure (например, делением на Data Measure).
   • Сценарий 2 (Схожий контент): Если найдены похожие документы, их взаимное ранжирование корректируется так, чтобы документ с меньшим Data Measure получил более высокую позицию.
7. Предоставление результатов: Формируется финальная выдача.

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

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

• Технические факторы: Общий объем байтов, загруженных при доступе к документу. Это включает размер HTML-кода, CSS, JavaScript, изображений, шрифтов, видео и других ресурсов, необходимых для отрисовки страницы.
• Пользовательские факторы: Данные об устройстве и подключении пользователя (например, IP-адрес, User-Agent, информация о сети, MAC-адрес, cookies), которые используются для определения вероятности использования Limited Data Plan.
• Поведенческие факторы (косвенно): История кликов (selection rate) по запросу может использоваться для определения, является ли запрос Navigational (например, если один результат получает подавляющее большинство кликов).
• Контентные факторы: Текст, метаданные, ключевые слова, сущности (entities) используются для определения схожести контента между документами.

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

• Data Measure: Измеряется путем фактической загрузки документа и подсчета использованного трафика на этапе индексирования.
• Likelihood of Limited Data Plan: Вероятностная оценка, основанная на контексте пользователя.
• Формулы и алгоритмы расчета: Патент предлагает несколько вариантов корректировки рейтинга:
  • Умножение начальной оценки на обратную величину Data Measure (Claim 8):

Выводы

1. Эффективность использования данных как фактор ранжирования: Google запатентовал механизм, позволяющий использовать объем трафика, необходимый для загрузки страницы, в качестве прямого сигнала ранжирования. Более «легкие» страницы имеют преимущество.
2. Условное применение сигнала (Контекст пользователя): Это не универсальный фактор ранжирования. Согласно основному пункту формулы (Claim 1), он активируется или усиливается, когда система определяет, что пользователь, вероятно, использует limited data plan. Это делает фактор критически важным для мобильного SEO и определенных географических регионов.
3. Приоритет для не навигационных запросов: Система спроектирована так, чтобы не мешать пользователям находить конкретные сайты (navigational queries), даже если они «тяжелые». Фактор применяется в основном к информационным и транзакционным запросам.
4. Конкурентное преимущество при схожем контенте: Если несколько сайтов предлагают одинаковый или очень похожий контент (например, новостные агрегаторы, синдицированный контент, стандартные описания товаров), система предпочтет ту версию, которая требует меньше данных для загрузки.
5. Измерение на этапе индексирования: Data Measure рассчитывается заранее, что позволяет использовать его в ранжировании в реальном времени без задержек на измерение. Измеряется общий объем данных для отрисовки, а не только размер HTML.

Практика

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

• Оптимизация медиа-ресурсов: Это самый важный аспект. Необходимо использовать современные форматы изображений (WebP, AVIF), применять адаптивное сжатие и гарантировать, что размеры изображений соответствуют размерам области просмотра. Это напрямую уменьшает Data Measure.
• Эффективное использование кода и минимизация ресурсов: Применять минификацию и сжатие (Gzip, Brotli) для CSS и JavaScript. Удалять неиспользуемый код (Tree Shaking). Это уменьшает объем передаваемых текстовых данных.
• Оптимизация сторонних скриптов: Аудит и минимизация использования тяжелых сторонних скриптов (рекламные сети, чаты, аналитика), которые значительно увеличивают общий объем загрузки страницы.
• Использование Lazy Loading: Применять отложенную загрузку для изображений и видео, которые находятся за пределами первой области просмотра. Это уменьшает объем данных, необходимых для начальной отрисовки страницы, что вероятно учитывается при расчете Data Measure.
• Фокус на мобильной оптимизации и International SEO: Учитывать, что этот фактор ранжирования наиболее активен для пользователей в сетях с ограничениями. Если целевая аудитория находится в регионах с дорогой мобильной связью, оптимизация объема данных становится приоритетом.

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

• Игнорирование оптимизации изображений: Загрузка изображений высокого разрешения без сжатия и масштабирования для мобильных устройств приведет к высокому Data Measure и потенциальному понижению в ранжировании.
• Раздутый (Bloated) код и фреймворки: Использование избыточно тяжелых CSS/JS фреймворков без очистки от неиспользуемых компонентов увеличивает объем загрузки.
• Агрессивная загрузка рекламы и трекеров: Перегрузка страниц многочисленными рекламными блоками и скриптами отслеживания, которые потребляют значительный объем трафика. Патент явно указывает, что реклама учитывается при измерении.
• Автовоспроизведение тяжелого контента: Автоматический запуск видео или анимаций при загрузке страницы значительно увеличивает потребление данных.

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

Патент подтверждает важность технического SEO и производительности не только с точки зрения скорости, но и с точки зрения эффективности использования данных. Он демонстрирует, что Google учитывает экономические и инфраструктурные ограничения пользователей при ранжировании. Стратегически это означает, что оптимизация Page Experience и Core Web Vitals дает преимущество не только за счет улучшения метрик скорости, но и за счет снижения Data Measure, что может быть решающим фактором в конкурентных нишах, особенно при работе с мобильным трафиком.

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

Сценарий 1: Выбор между сайтами с одинаковым товаром (Схожий контент)

1. Контекст: Пользователь в Индии ищет «купить кроссовки Nike Air Max» с мобильного телефона через сеть 3G. Google определяет это как limited data plan и non-navigational query.
2. Кандидаты: Сайт A и Сайт B продают одну и ту же модель по схожей цене. Document Similarity Module определяет, что описания товара очень похожи.
3. Измерение: Сайт A использует неоптимизированные JPG и много сторонних скриптов (Data Measure = 2.5 MB). Сайт B использует WebP и оптимизированный код (Data Measure = 800 KB).
4. Результат: Система активирует алгоритм и ранжирует Сайт B выше Сайта A, основываясь на сравнении их Data Measures, чтобы сэкономить трафик пользователя.

Сценарий 2: Общее понижение тяжелого сайта (Модификация оценки)

1. Контекст: Пользователь ищет информационный запрос в условиях ограниченной сети.
2. Кандидаты: Сайт C имеет релевантный контент, но его Data Measure составляет 5 MB из-за автовоспроизводимого видео и большого количества рекламы.
3. Результат: Система применяет корректировку к начальной оценке релевантности Сайта C (например, используя формулу

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