Страница может технически «грузиться» всего несколько секунд, но для человека эти секунды выглядят совершенно по-разному. На одном сайте заголовок, фотография товара и кнопка заказа появляются почти сразу. На другом сначала две секунды сияет белый экран, потом приезжает меню, ещё через секунду — картинка, а кнопка появляется последней, словно курьер, который забыл номер квартиры.
Speed Index как раз помогает увидеть эту разницу. Он оценивает, насколько быстро видимая область страницы заполняется содержимым в процессе загрузки. Чем меньше показатель, тем раньше посетитель получает ощущение, что страница уже перед ним, а не где-то ещё собирается по частям.
Speed Index смотрит не на один момент, а на весь «фильм» загрузки
Большинство показателей производительности фиксируют конкретное событие. FCP отвечает примерно на вопрос «когда на экране вообще появилось что-то полезное?». LCP — «когда появился крупнейший значимый элемент первого экрана?». Speed Index смотрит шире: как менялась визуальная заполненность экрана на всём протяжении загрузки.
Представьте открытие магазина утром. FCP — включили свет. LCP — подняли рольставни и открыли главную витрину. Speed Index оценивает, как быстро после этого появились ценники, товар на полках, касса и продавец. Формально магазин уже открыт, но покупать в нём ещё немного рано.
| Метрика | Что показывает |
|---|---|
| FCP | когда появился первый видимый контент |
| LCP | когда отрисовался крупнейший заметный элемент |
| Speed Index | насколько быстро заполнялась вся видимая область |
| CLS | насколько сильно элементы прыгали при загрузке |
| INP | насколько быстро страница реагирует на действия пользователя |
Lighthouse получает Speed Index, анализируя визуальный прогресс страницы во время тестовой загрузки. Поэтому это прежде всего диагностический лабораторный показатель, а не статистика всех реальных посетителей сайта.
Какие значения считать нормальными
В мобильном тесте Lighthouse значение до 3,4 секунды относится к зелёной зоне. Диапазон от 3,4 до 5,8 секунды считается промежуточным, выше 5,8 секунды — медленным. Для десктопного теста ориентиры жёстче: до 1,3 секунды, от 1,3 до 2,3 и выше 2,3 секунды.
Но воспринимать эти границы как ГОСТ на сайт не стоит. Speed Index зависит от условий тестирования. Если сегодня проверить страницу на одном компьютере, завтра — на другом, а послезавтра добавить рекламный виджет, сравнение получится примерно как замер расхода автомобиля сначала по трассе, потом в пробке, а потом с прицепом.
Speed Index и SEO: полезная метрика, но не отдельный билет в топ
Здесь важно не превратить технический показатель в магический SEO-амулет. Speed Index не входит в набор Core Web Vitals. Для Google такими показателями сейчас являются LCP, INP и CLS.
Это не означает, что плохой Speed Index можно спокойно игнорировать. Обычно он выступает как симптом. Если первый экран долго остаётся пустым из-за тяжёлого изображения, блокирующего CSS или большого объёма JavaScript, проблема вполне реальна — просто лечить нужно её причину, а не число в отчёте.
У сайта может стать лучше Speed Index одновременно с LCP и общим ощущением скорости. Но из этого нельзя сделать обратный вывод: «уменьшили SI на секунду — позиции должны вырасти». Поисковая система так не обещает.
Если технические проблемы скорости идут вместе с индексацией, архитектурой, контентом и другими SEO-задачами, их разумнее рассматривать в рамках комплексного SEO-продвижения сайта, а не заказывать погоню за одной цифрой PageSpeed. Иногда бизнесу выгоднее исправить три действительно тормозящие страницы, чем неделю полировать показатель со 96 до 100.
Как проверить Speed Index и не обмануть самого себя
Самый доступный вариант — PageSpeed Insights. В лабораторной части отчёта используется Lighthouse, где среди показателей производительности отображается Speed Index. Его также можно получить непосредственно в Lighthouse через инструменты разработчика Chrome.
При проверке важнее не нажать кнопку один раз, а создать сравнимые условия. Проверяйте один URL на одном типе устройства и делайте несколько прогонов. Если результаты получились 3,1, 4,8 и 3,3 секунды, делать вывод только по среднему тесту на 4,8 — всё равно что оценивать работу ресторана исключительно по вечеру, когда туда одновременно вошёл автобус туристов.
Полезно смотреть на три уровня:
- само значение Speed Index;
- последовательность визуального появления первого экрана;
- диагностику Lighthouse — какие ресурсы задерживают отрисовку.
В Search Console отдельного отчёта по Speed Index нет. Там для производительности важнее Core Web Vitals на основе данных реальных пользователей.
Что чаще всего портит Speed Index
Первый кандидат — содержимое первого экрана. Огромная фотография размером в несколько мегабайт способна испортить впечатление даже на сайте с быстрым сервером. Пользователь уже получил HTML, браузер уже знает структуру страницы, но вместо товара или услуги перед ним всё ещё пустой прямоугольник.
Вторая распространённая причина — CSS, без которого браузер не может нормально нарисовать страницу. Поэтому минификация CSS может быть полезной частью оптимизации, но сама по себе она не является волшебной кнопкой. Важнее понять объём стилей, порядок их загрузки и действительно ли браузер ждёт ненужный код перед отображением первого экрана.
Третья группа — JavaScript и сторонние сервисы: чат, аналитика, рекламные системы, карты, отзывы, виджеты обратного звонка. Каждый из них по отдельности может выглядеть безобидно. Вместе они иногда напоминают пятнадцать человек, которые одновременно пытаются пройти в одну дверь.
Отдельная история — шрифты. Если браузер ждёт файл шрифта и до этого момента скрывает текст, посетитель получает красивую типографику чуть позже, но сначала некоторое время рассматривает дизайнерскую пустоту. Для коммерческого сайта это сомнительный обмен.
| Симптом | Что проверить сначала |
|---|---|
| долго пустой первый экран | сервер, CSS, шрифты |
| текст появился, крупная картинка задержалась | размер и приоритет главного изображения |
| страница проявляется рывками | JavaScript и сторонние виджеты |
| мобильная версия заметно хуже | вес первого экрана и объём выполняемого кода |
| результат сильно скачет между тестами | реклама, сторонние запросы, состояние сервера и условия теста |
Пример: интернет-магазин загружается, но выглядит пустым
Представим типичную карточку товара. Сервер отвечает достаточно быстро, заголовок появляется почти сразу, но главным элементом страницы служит большая фотография товара. Она загружается поздно, одновременно запускаются чат, система аналитики, блок рекомендаций и несколько файлов шрифтов.
Владелец сайта смотрит на ситуацию и вполне логично говорит: «Но страница же открылась». Технически — да. Визуально пользователь секунду или две видит каркас будущего магазина.
В такой ситуации нет смысла начинать с установки очередного плагина «ускорить всё». Сначала нужно определить, какой элемент задерживает заполнение экрана. Если проблема в главном изображении — проверить его реальный размер, формат и момент начала загрузки. Если браузер ждёт стили — разобрать CSS. Если главный поток занят JavaScript — выяснить, какой код действительно нужен до первого взаимодействия.
После изменения повторяют тот же тест в тех же условиях. Хороший результат — не просто зелёный Speed Index. Первый экран должен появляться заметно раньше, LCP не должен ухудшиться, интерфейс должен оставаться стабильным, а формы, корзина, цели аналитики и другие бизнес-функции — работать как раньше.
Иначе получится классическая оптимизация ради отчёта: PageSpeed счастлив, покупатель — уже не очень.
Когда работу со Speed Index можно считать законченной
Speed Index полезен как диагностический термометр. Если он плохой, есть смысл выяснить причину. Но лечить сайт до тех пор, пока конкретная лабораторная цифра не станет идеальной, не нужно.
Для бизнеса важнее, чтобы страница быстро показывала основное предложение, пользователь мог нормально взаимодействовать с ней, а реальные показатели производительности не ухудшались. Особенно это важно после установки рекламы, аналитики, онлайн-чата или нового дизайна: внешне изменение может казаться мелочью, а первый экран начинает собираться заметно дольше.
Поэтому правильный критерий простой: одинаковые тесты показывают устойчивое улучшение, визуальная загрузка действительно стала быстрее, Core Web Vitals не ухудшились и сайт не потерял рабочие функции. Если ради ещё двух баллов приходится ломать аналитику или откладывать загрузку нужной кнопки — это уже не ускорение сайта, а спортивная дисциплина, которую клиент почему-то оплачивает.
FAQ
Когда плохой Speed Index действительно становится проблемой сайта
Это показатель того, насколько быстро пользователь визуально получает содержимое страницы. Он оценивает весь процесс заполнения видимой области, а не появление одного конкретного элемента. Чем меньше значение, тем быстрее страница выглядит загруженной.
Google не называет Speed Index отдельным фактором ранжирования и не включает его в Core Web Vitals. При этом причины плохого Speed Index — тяжёлый первый экран, медленная отрисовка, перегруженный JavaScript — могут одновременно ухудшать пользовательский опыт и другие показатели производительности.
В документации Lighthouse для мобильного теста зелёной зоной считается значение до 3,4 секунды, для десктопа — до 1,3 секунды. Но это ориентиры лабораторного теста, а не универсальный норматив для бизнеса. Важнее сравнивать одну и ту же страницу в одинаковых условиях.
На результат влияют условия тестирования, производительность устройства, сеть, сторонние скрипты, реклама, A/B-тесты и текущее состояние сервера. Поэтому один замер — это фотография ситуации, а не медицинская карта сайта.
Сначала посмотрите, что именно задерживает визуальное заполнение первого экрана: изображения, CSS, шрифты, JavaScript или сторонние сервисы. Исправляйте найденную причину, повторяйте тест в тех же условиях и параллельно проверяйте Core Web Vitals и работу бизнес-функций сайта.
Рейтинг статьи
Материал был полезен?
Оценка помогает понимать, какие материалы стоит обновлять и расширять.
