Скорость сайта в 2026: Core Web Vitals, официальные пороги и наш кейс с мобильным блогом
Сервер отвечал за 0,23 секунды, а статьи на телефоне не появлялись вовсе. Разбираем официальные пороги Core Web Vitals, что Google говорит об их влиянии на поиск, и наш собственный кейс: как мы нашли причину, уменьшили обложки с ~2 МБ до 213 КБ и что проверить на вашем сайте.
Какие показатели скорости Google считает главными?
Core Web Vitals — три показателя. LCP (загрузка): самый крупный элемент страницы должен появиться за 2,5 секунды или быстрее. INP (отклик): страница должна реагировать на действия за 200 миллисекунд или быстрее. CLS (стабильность): сдвиг макета — 0,1 или меньше. Считают по 75-му процентилю загрузок, отдельно для мобильных и компьютеров, и страница «проходит», только если в норме все три. INP заменил FID в 2024 году. Web.dev прямо пишет, что стабильные показатели меняются не чаще раза в год, поэтому «новые пороги 2026», которые встречаются в блогах, Google не подтверждает.
Влияет ли скорость на позиции в поиске?
Google пишет, что Core Web Vitals вместе с другими аспектами удобства страницы соответствуют тому, что вознаграждают основные системы ранжирования, и настоятельно советует иметь хорошие показатели. Отдельного веса скорости в ранжировании Google не называет, поэтому это не волшебная кнопка, а одно из условий. Реальные данные пользователей видны в отчёте «Core Web Vitals» в Search Console.
Что мы нашли на собственном сайте?
11 ноября 2026 мы открыли блог Metriverra с телефона — и статьи «очень долго грузились». Замеры показали: сервер отвечал за 0,23 секунды, значит, дело было не в нём. Лента из 19 статей была одним блоком с анимацией появления, которая срабатывала, когда на экране видно 12% блока. На телефоне блок был высотой 8 509 пикселей, экран — 844, то есть 9,9%: порог не достигался, и статьи оставались невидимыми. К тому же обложки отдавались в полном размере — около 2 МБ на ленту. Мы убрали анимацию с ленты, сделали страницы по 10 и 9 статей и отдаём уменьшенные копии обложек: 12 обложек весили 213 КБ вместо примерно 2 МБ.
Что проверить на своём сайте?
Откройте отчёт «Core Web Vitals» в Search Console и начните с мобильных страниц. Проверьте страницу в настоящем мобильном окне, а не только скорость ответа сервера: контент, спрятанный до срабатывания скрипта, пользователь просто не увидит. Отдавайте изображения размером под экран (srcset), откладывайте загрузку картинок ниже первого экрана, но не главного изображения. Резервируйте место под картинки, чтобы макет не прыгал. И помните, что тяжёлые скрипты и теги ухудшают отклик — INP.
Что сделать сейчас
- Откройте отчёт «Core Web Vitals» в Search Console и начните с мобильных URL.
- Проверьте ключевые страницы в мобильном окне: виден ли контент без ожидания анимаций и скриптов.
- Отдавайте изображения под размер экрана и уменьшенные копии для списков и карточек.
- Не откладывайте загрузку главного изображения первого экрана — только те, что ниже.
- Проверяйте показатели после каждого крупного изменения сайта, а не раз в год.
В Metriverra поведение посетителей и конверсии видны ежедневно, поэтому после изменения скорости сайта легко сравнить отказы и продажи до и после.
Коротко
- Пороги Google: LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1 по 75-му процентилю.
- Стабильные показатели меняются не чаще раза в год; «новые пороги 2026» Google не подтверждает.
- Google: Core Web Vitals соответствуют тому, что вознаграждают системы ранжирования.
- Наш кейс: сервер 0,23 с, но статьи на телефоне были невидимы из-за анимации.
- Обложки ленты: ~2 МБ → 213 КБ.
Источники: web.dev — Web Vitals · Google Search Central — Understanding Core Web Vitals and Google search results
