Что это
Средний вес HTML — это усреднённый размер HTML-документов на сайте, измеряемый в килобайтах. Речь идёт именно о «голом» HTML-коде страницы: разметке, тексте, атрибутах, инлайн-стилях и скриптах, встроенных прямо в документ — без учёта внешних CSS, JS-файлов, изображений и шрифтов. Показатель рассчитывается краулером по выборке страниц: суммарный объём HTML-ответов делится на количество проверенных URL.
---
Почему это важно для SEO
Размер HTML напрямую влияет на скорость загрузки страницы — а это сигнал ранжирования и в Google (Core Web Vitals: LCP, FID/INP), и в Яндексе. Браузер не начнёт рендеринг, пока не получит достаточно HTML для построения DOM. Если документ весит 500+ КБ, время до первого байта (TTFB) растёт, парсинг затягивается, и PageSpeed Insights зафиксирует просадку по всем метрикам. Google рекомендует держать размер HTML-ответа в пределах 15 МБ (технический лимит), но на практике оптимальным считается диапазон 30–150 КБ на страницу.
Для Яндекса тяжёлый HTML создаёт проблемы при сканировании. Краулер Яндекса ограничивает время на загрузку одной страницы, и раздутые документы снижают crawl budget — особенно критично для крупных интернет-магазинов с тысячами SKU. Кроме того, Яндекс.Нейро и Турбо-страницы работают с облегчённым контентом: если базовый HTML перегружен мусором, автоматическая генерация Турбо-версий ломается или выдаёт артефакты. ИКС (индекс качества сайта) не считается по этому параметру напрямую, но поведенческие факторы деградируют при медленной загрузке — а ИКС от них зависит.
---
Как проверить вручную
- PageSpeed Insights (pagespeed.web.dev): введи URL, в разделе «Диагностика» найди «Избегайте огромных полезных нагрузок сети». HTML-документ показывается отдельной строкой с точным весом.
- Screaming Frog SEO Spider: запусти краулинг, перейди во вкладку
Response→ столбецSize (bytes). Отсортируй по убыванию — сразу видно, какие страницы отдают раздутый HTML. Экспортируй в CSV и рассчитай среднее по колонке.
- Google Search Console: вкладка «Основные интернет-показатели» покажет страницы с низким LCP — коррелируй их с весом HTML из Screaming Frog.
- Яндекс.Вебмастер: раздел «Индексирование» → «Статистика обхода» → скорость загрузки страниц. Если средняя скорость падает, проверяй размер документов.
- Curl в терминале — быстрая проверка конкретной страницы:
curl -so /dev/null -w "%{size_download}" https://example.com/page/ | awk '{print $1/1024 " KB"}'---
Как исправить
Шаг 1: найди источник раздутости. Чаще всего это инлайн-CSS/JS, дублированные данные в разметке (например, JSON-LD с полным каталогом), Base64-изображения прямо в HTML, или мусор от CMS (комментарии, пустые теги).
Шаг 2: вынеси стили и скрипты во внешние файлы.
<!-- Плохо -->
<style>body { margin: 0; } .btn { background: red; } /* ещё 200 строк */ </style>
<!-- Хорошо -->
<link rel="stylesheet" href="/css/main.min.css">Шаг 3: включи gzip/Brotli на сервере. Это снижает вес передаваемого HTML в 3–5 раз без изменения кода.
# Nginx
gzip on;
gzip_types text/html;
gzip_min_length 1024;Шаг 4: убери лишнее из разметки.
- JSON-LD с объёмными данными — оставляй только необходимые поля Schema.org.
- Закомментированный код — удаляй.
- Инлайн-изображения (Base64) — выноси в CDN.
Решения по CMS:
- WordPress: плагин WP Rocket или Autoptimize — включи «Объединить CSS/JS» и «Минифицировать HTML».
- Tilda: в настройках сайта включи «Минификация кода» (пункт в SEO-настройках).
- 1C-Bitrix: компонент «Автообъединение CSS и JS» в настройках главного модуля + включи сжатие в
.htaccess. - Webflow: Webflow автоматически минифицирует HTML при публикации; следи за Custom Code в настройках страниц — туда часто вставляют тяжёлые инлайн-блоки.
---
Типичные ошибки
- Встраивать весь JSON-LD каталога на страницу категории. Разметка Schema.org должна описывать только текущую страницу — не весь ассортимент.
- Оставлять Base64-изображения в HTML. Одна иконка в Base64 добавляет 10–30 КБ к документу. Используй внешние URL.
- Не проверять HTML после рендеринга. Краулер видит страницу с JavaScript — проверяй вес не только исходника, но и отрендеренного DOM через Screaming Frog с включённым рендерингом JS.
- Путать вес HTML с весом страницы. 150 КБ HTML — это много. 150 КБ всей страницы (с картинками) — отлично. Следи именно за документом.
- Включать gzip и считать задачу решённой. Сжатие помогает при передаче, но не ускоряет парсинг DOM. Физически раздутый HTML всё равно замедляет рендеринг.
---
Влияние на разные типы сайтов
Для интернет-магазинов на 1C-Bitrix или Wordpress критично: страницы категорий с фильтрами часто генерируют HTML на 300–600 КБ из-за скрытых фильтров, инлайн-данных для JS-компонентов и дублированной разметки. Это прямо бьёт по crawl budget и конверсии: каждые 100 КБ лишнего HTML добавляют ~50–150 мс к LCP на мобильном соединении.
Для контентных сайтов и блогов проблема чаще в виджетах и рекламных блоках, встроенных инлайн. Лендинги на Tilda или Webflow, как правило, имеют умеренный вес HTML, но рискуют при добавлении кастомного кода через «вставки». SaaS-сервисы с динамическим интерфейсом должны разделять приложение и маркетинговые страницы: первое рендерится в браузере, вторые — желательно SSR с минимальным HTML для быстрой индексации и отображения в AI Overviews Google.