Что Google рассказывает нам о своих алгоритмах

Что Google рассказывает нам о своих алгоритмах. Как учитывается «вес страницы» и стоимость её загрузки при ранжировании, применяется на уровне документа и кластера результатов, влияет на отбор и порядок выдачи (Патент US9201929 — Ranking search results based on resource load / document cost).

Что я увидела в патенте и какие выводы сделала:

1. Google описывает модель, где учитывается стоимость обработки страницы — сколько ресурсов нужно, чтобы её загрузить и обработать.
2. Речь не только о скорости, а о ресурсоёмкости документа:
   — размер
   — сложность
   — объём данных
   — стоимость рендеринга.
3. Вводится понятие document cost / resource cost.
4. Система может учитывать этот cost при выборе, какие результаты показывать выше.
5. Если два результата сопоставимы по релевантности — предпочтение может отдаваться менее «дорогому».
6. Это особенно актуально для:
   — мобильной выдачи
   — слабых устройств
   — медленных соединений.
7. Тяжёлые страницы могут получать понижающий коэффициент при прочих равных.
8. В расчёт может входить:
   — размер HTML
   — число ресурсов
   — объём скриптов
   — глубина рендеринга.
9. Это не прямой «page speed фактор», а стоимостная модель обработки.
10. Google оптимизирует не только качество, но и цену показа результата.
11. Для гэмблы это болезненно:
    многие витрины перегружены:
    — трекерами
    — скриптами
    — виджетами
    — тяжёлыми таблицами.
12. Лендинги с 5–10 внешними скриптами — кандидаты на повышенный cost.
13. Избыточные JS-конструкторы увеличивают стоимость обработки.
14. Простые HTML-страницы с чистой структурой — дешевле для системы.
15. Патент логически поддерживает тренд:
    простые страницы выигрывают у «комбайнов».
16. Особенно на мобильном трафике.
17. Это усиливает ценность:
    — серверного рендера
    — чистой верстки
    — контроля зависимостей.
18. Не всё «красиво и интерактивно» выгодно для ранжирования.
19. При равной пользе выигрывает менее тяжёлый документ.
20. Патент подтверждает:
    стоимость обработки результата — часть алгоритмического решения, а не только UX-метрика.