Скорость сайта — это не про «пользователям приятно». Это про ранжирование. Яндекс и Google напрямую учитывают скорость при формировании выдачи. Медленный сайт ранжируется ниже, даже если контент лучше.
Почему так: поисковик хочет показать пользователю лучший результат. Если две страницы одинаково релевантны, но одна грузится за 1.5 секунды, а другая за 5 — поисковик выберет первую. Потому что пользователь не ждёт.
Кроме того, скорость влияет на краулинг. Медленный сайт робот сканирует медленнее — меньше страниц попадает в индекс. Это особенно критично для больших сайтов: интернет-магазинов, порталов, агрегаторов.
Я видел сайты, где после ускорения с 5 до 2 секунд трафик вырастал на 20–30% без каких-либо других изменений. Только скорость. Это не магия — это алгоритм.
Core Web Vitals — это три ключевые метрики, по которым Google и Яндекс оценивают скорость и стабильность страницы. Их три:
Время до отрисовки самого большого элемента на экране. Обычно это изображение, баннер или заголовок. Показывает, через сколько секунд пользователь видит основной контент. Норма: до 2.5 секунд. Плохо: больше 4.
Сумма сдвигов элементов макета за время загрузки. Когда страница «прыгает» — кнопка уезжает, текст сдвигается вниз — это CLS. Норма: до 0.1. Плохо: больше 0.25. Высокий CLS раздражает пользователей: они кликают не туда, перечитывают текст.
Время от взаимодействия пользователя (клик, тап, ввод) до отрисовки результата. Заменил FID в 2024 году. Показывает, насколько быстро страница реагирует на действия. Норма: до 200 мс. Плохо: больше 500 мс.
Эти три метрики — основа. Если все три в зелёной зоне — страница считается быстрой. Если хотя бы одна в красной — сайт в группе риска.
Инструменты, которыми я пользуюсь:
Важно: лабораторные данные (Lighthouse) и реальные данные (CrUX) могут отличаться. Lighthouse симулирует загрузку на эталонном устройстве. CrUX показывает, как реально грузится страница у пользователей. Если Lighthouse показывает зелёный, а CrUX — красный, значит, у реальных пользователей устройство слабее или сеть хуже. Нужно оптимизировать именно под реальный профиль.
LCP — самая важная метрика. Если она красная — позиции страдают. Что чаще всего тормозит LCP:
Если LCP-элемент — картинка (баннер, hero-image, фото товара), и она весит 2 МБ — это проблема. Решения:
<img>. Это позволяет браузеру зарезервировать место и не ждать layout.fetchpriority="high" для LCP-изображения. Браузер загрузит его первым.TTFB (Time to First Byte) — время до первого байта. Если сервер отвечает 1.5 секунды — LCP не будет меньше 1.5. Решения:
Если в <head> подключены 5 CSS-файлов и 10 JS — браузер ждёт их загрузки, прежде чем отрисовать страницу. Решения:
defer или async.<head>, остальное — перед </body>.Если шрифт грузится 2 секунды, а текст ждёт шрифт — пользователь видит пустую страницу. Решения:
font-display: swap — браузер показывает текст системным шрифтом, потом меняет на ваш.<link rel="preload" as="font">.CLS — метрика, которую проще всего исправить, но которую чаще всего игнорируют. Причины сдвигов:
Если у <img> нет атрибутов width и height, браузер не знает, сколько места reserves. Картинка грузится — контент сдвигается. Решение: указывайте размеры для всех изображений.
Если рекламный блок вставляется после загрузки — контент сдвигается. Решение: резервируйте место через CSS (min-height для контейнера).
Cookie-баннеры, чат-виджеты, всплывающие формы — появляются после загрузки и сдвигают контент. Решение: фиксируйте их позицию (position: fixed) или резервируйте место заранее.
Системный шрифт узкий, ваш — широкий. При замене — контент сдвигается. Решение: font-display: swap и подбор fallback-шрифта с похожей шириной.
INP заменил FID в 2024 году. Он измеряет задержку между действием пользователя и отрисовкой результата. Высокий INP — страница «тормозит» при кликах, скролле, вводе. Причины:
requestIdleCallback или с задержкой.В 80% случаев, которые я аудитаю, изображения — главная причина медленной загрузки. Что делаю:
loading="lazy". Браузер не грузит их, пока не доскроллит. Экономия 50–70% трафика при первой загрузке.<img> — это устраняет сдвиги (CLS) и ускоряет рендер.<img> с lazy load. CSS background не поддерживает lazy loading. Если hero-изображение в CSS — оно блокирует рендер.React, Vue, Angular — отличные фреймворки, но они добавляют вес. Бандл React + ReactDOM — 40 КБ gzipped. Плюс библиотеки — 100–200 КБ. Это замедляет первую загрузку. Что делаю:
requestIdleCallback.Cache-Control: public, max-age=31536000 для статики.Сайт: интернет-магазин стройматериалов, 3 200 товаров.
Проблема: LCP 6.2 с, CLS 0.18, INP 480 мс. Трафик стагнировал, конверсия 0.8%.
Что сделано:
Результат:
Сайт: лендинг на Tilda, 10 экранов, много анимаций.
Проблема: LCP 4.5 с, CLS 0.15. Tilda по умолчанию грузит все скрипты и картинки сразу.
Что сделано:
Результат:
Tilda можно ускорить, если убрать лишнее. Но есть предел: Tilda — конструктор, и её ядро нельзя оптимизировать полностью. Если нужна максимальная скорость — нужен кастомный сайт.
Как разработчик, я автоматизирую проверку скорости, чтобы ловить регрессии до релиза:
Пример конфигурации Lighthouse CI:
js // lighthouserc.js module.exports = { ci: { collect: {
url: ['https://staging.example.com/'], numberOfRuns: 3,
},
assert: { assertions: { 'largest-contentful-paint': ['error', { max: 2500 }],
'cumulative-layout-shift': ['error', { max: 0.1 }],
'interaction-to-next-paint': ['warn', { max: 200 }],
}, }, },
};
Такой конфиг гоняется в CI и блокирует релиз, если скорость просела. Подробнее про автоматизацию SEO-проверок — в статье автоматизация SEO-тестов.
LCP:
fetchpriority="high" на LCP-изображенииdeferfont-display: swap, preloadCLS:
width и height на всех <img>INP:
Сервер:
Изображения:
loading="lazy" для ниже первого экранаСкорость — это не «приятный бонус», а технический фактор ранжирования. Медленный сайт теряет позиции, трафик и конверсии. Но ускорение — это не магия, а набор конкретных шагов: сжать изображения, отложить JS, настроить кэш, подключить CDN. Каждый шаг даёт 10–30% улучшения. В сумме — LCP с 6 до 2 секунд, рост трафика на 20% и конверсии на 50%.
Хотите проверить скорость своего сайта и понять, что тормозит? Пришлите URL — бесплатно прогоню через PageSpeed Insights и Lighthouse, покажу, что именно замедляет и как это исправить.
Пришлите URL — бесплатно проверю LCP, CLS, INP и покажу, что замедляет сайт. С конкретными рекомендациями по исправлению.
Получить аудит```
Нужна помощь в продвижении вашей организации?
Пишите мне в Телеграмм или MAX
и мы обсудим все детали.
Кейс 1. Дома под ключ (Санкт-Петербург)
Было: 200 визитов/мес, конверсия 1,8%, отказы 68%.
Стало: 5 100 визитов/мес (+59%), конверси - 2,9%, отказы - 54%.
Срок: 4 месяца.
Что сделали: убрали дубли, переписали тексты с LSI, настроили микроразметку, улучшили UX.
Кейс 2. Каркасные дома под ключ (Тверь и область)
Было: 1 800 визитов/мес, конверсия — 1,2%, дорогие лиды.
Стало: 2 400 визитов/мес, конверсия — 3,1%, CPL −38%.
Срок: 3 месяца.
Что сделали: сузили семантику, проработали посадочные, добавили калькуляторы и блок «прозрачная цена».
Кейс 3. Строительство деревянных домов (Москва)
Было: 900 визитов/мес, 12 заявок/мес, позиции в топ‑30–50.
Стало: 1 560 визитов/мес, 34 заявки/мес, топ‑10 по 35 запросам.
Срок: 5 месяцев.
Что сделали: кластеризовали семантику, выстроили структуру каталога.
Дмитрий вывел наш сайт в ТОП-10 по 30+ запросам за 3 месяца. Цена SEO-продвижения оказалась в 2 раза ниже, чем нам предлагали в студии. Результат — 15 заявок в месяц с органики, раньше было 2.
Заказали SEO у Дмитрия после двух неудачных опытов с агентствами. Разница колоссальная: отвечает сам, делает сам, отчитывается сам. Через 4 месяца — ТОП-10 по основным запросам».
Новый сайт, на котором не было ничего. Дмитрий собрал семантику, прописал структуру, написал ТЗ на тексты. Через 5 месяцев — 80 запросов в ТОП-10. Недорогое SEO-продвижение сайта — это реально».