Оптимизация скорости сайта – Гид по Core Web Vitals

Почему скорость сайта решает, останется посетитель или уйдёт

Скорость сайта - больше не техническая деталь для разработчиков. Это бизнес-метрика. Данные Google показывают: если страница дольше трёх секунд не становится интерактивной, более половины мобильных посетителей уходят. В конкурентных рынках Баку и Азербайджана, где пользователи выбирают поставщика услуг за секунды, медленный сайт - самый быстрый способ потерять лид, за который вы заплатили Google Ads. Поисковые системы превращают это нетерпение в ранжирование: Core Web Vitals - официальный сигнал ранжирования, значит медленная страница проигрывает более быстрому конкуренту даже при равном контенте.

В ONE Studio мы неоднократно замеряли эффект. У самого сайта one.az мобильный Largest Contentful Paint когда-то был между 8 и 13 секундами - потому что два провайдера шрифтов грузились параллельно и в первом paint играло тяжёлое hero-видео. После удаления дубликата провайдера шрифтов, замены видео на постер и переноса критического CSS в inline LCP упал ниже трёх секунд, а органические конверсии выросли более чем на треть за месяц. Эта статья поможет вам воспроизвести такой же результат.

Что такое Core Web Vitals?

Core Web Vitals - три полевые метрики, которыми Google измеряет реальный пользовательский опыт. Данные собираются от пользователей Chrome через Chrome User Experience Report (CrUX) и отображаются в Google Search Console в разделе Core Web Vitals. Три метрики отвечают на три вопроса: как быстро страница выглядит загруженной, как быстро она реагирует на действия, и насколько стабильна разметка при загрузке.

Метрика	Цель (Хорошо)	Типичные причины провала	Способ починки
LCP (Largest Contentful Paint)	< 2.5 с	Несжатое hero-изображение, блокирующий CSS, медленный TTFB, тяжёлые шрифты	Preload LCP-изображения, AVIF/WebP, CDN, критический CSS inline
INP (Interaction to Next Paint)	< 200 мс	Длинные JS-задачи, тяжёлые сторонние скрипты, стоимость hydration	Разбить длинные задачи, defer некритического JS, удалить неиспользуемые библиотеки
CLS (Cumulative Layout Shift)	< 0.1	Изображения без размеров, поздние баннеры, поздние шрифты	Резервировать место через width/height, font-display: optional, не вставлять поздние блоки над фолдом

Старая метрика First Input Delay (FID) была снята в марте 2024 года и заменена на INP - она измеряет задержку каждого взаимодействия за весь жизненный цикл страницы, а не только первого. Если команда всё ещё отслеживает FID, срочно обновите дашборды.

Как правильно измерять Core Web Vitals?

Измерений два вида, и путать их - самая частая ошибка. Lab data - результат теста в контролируемой среде на фиксированной скорости сети и CPU. Field data - реальный опыт реальных пользователей. Google ранжирует по полевым данным, поэтому идеальный lab-балл ничего не значит, если CrUX всё ещё показывает плохой опыт.

• PageSpeed Insights (pagespeed.web.dev) - показывает Lighthouse lab и 28-дневные CrUX field data рядом. Начинайте здесь.
• Chrome User Experience Report (CrUX) - исходный датасет, доступный через BigQuery или CrUX API для исторических трендов.
• Google Search Console Core Web Vitals - группирует URL по шаблонам и показывает, какие требуют доработки.
• WebPageTest.org - диагностический микроскоп. Waterfall, filmstrip, throttling, детализация по запросам.
• Chrome DevTools Performance - профилируйте реальное взаимодействие на своём устройстве. Расширение Web Vitals показывает LCP, INP и CLS в реальном времени.

Не гоняйтесь только за зелёным Lighthouse. Страница с 98 в Lighthouse, но с плохим реальным LCP на среднем Android - всё ещё проваленная страница в глазах Google.

Как улучшить LCP?

Largest Contentful Paint почти всегда - изображение, постер hero-видео или большой блок текста над фолдом. Чинить нужно в таком порядке:

1. Найдите элемент. DevTools Performance подсвечивает его, расширение Web Vitals называет напрямую. Не гадайте.
2. Отдайте в современном формате. AVIF на 40-50% меньше JPEG, WebP - на 25-30%. Используйте next/image, Laravel Media Library, или билд-шаг для генерации обоих.
3. Preload. Добавьте <link rel="preload" as="image" fetchpriority="high" href="/hero.avif">, чтобы браузер начал скачивание ещё до парсинга CSS.
4. Раздайте через CDN с Brotli. Cloudflare, Bunny или Fastly сокращают round-trip для пользователей вне региона. Brotli на 15-20% меньше Gzip для текстовых ассетов.
5. Почините TTFB. Если TTFB выше 800 мс, никакие трюки с изображениями не спасут. Включите full-page cache, увеличьте PHP-FPM воркеры или переезжайте на современный VPS.

Как снизить INP?

INP - метрика, которая ловит тяжёлые JavaScript-стеки. React или Vue приложение, гидрирующее всю страницу при загрузке, часто показывает INP выше 300 мс на среднем Android, даже если Lighthouse даёт 95. Практические средства:

• Разбивайте длинные JS-задачи через scheduler.yield() или setTimeout(fn, 0). Любая задача дольше 50 мс - Long Task.
• Удаляйте неиспользуемые библиотеки. Аудит бандла через next build --analyze или webpack-bundle-analyzer. Замените Moment.js на date-fns или нативный Intl. Lodash - на индивидуальные импорты.
• Defer некритических сторонних скриптов. GTM, чаты и рекламные пиксели редко нужны на первом paint. Грузите после события load или при первом скролле.
• Используйте острова или частичный hydration. Astro, Qwik и Next.js App Router с Server Components отправляют часть JS от того, что нужно legacy SPA.

Оптимизация изображений: WebP, AVIF и next/image

Изображения - самый большой класс ассетов почти на любом сайте. Девяносто процентов сайтов, которые мы аудируем, до сих пор отдают JPEG или PNG шириной 1920 пикселей на экран телефона 360 пикселей. В 2026 году современная работа с изображениями не опция, а обязательство.

• Используйте AVIF как основной формат, WebP как fallback, JPEG как крайнюю меру. Все три покрывают 99% браузерного рынка.
• Отдавайте отзывчивые источники через srcset и sizes, чтобы телефон качал файл 480 пикселей, а не оригинал desktop.
• Фиксируйте размеры через явные width и height, чтобы избежать CLS.
• Ниже фолда - loading="lazy". LCP-изображение никогда не lazy, используйте fetchpriority="high".
• В Next.js - встроенный next/image. В Laravel - Intervention Image или spatie/laravel-medialibrary.

Стратегия шрифтов: быстрый текст без невидимых вспышек

Шрифты создают две проблемы: блокируют LCP, если рендерят текст над фолдом, и вызывают CLS, если приходят после fallback. Решение - не отказаться от кастомных шрифтов, а грузить их предсказуемо.

• Хостите шрифты сами. Сторонние провайдеры добавляют DNS lookup и TCP handshake. Скачайте WOFF2, положите на CDN и используйте @font-face напрямую.
• Subset шрифтов под реальные языки. Латиница + азербайджанский + кириллица весит долю от полного multi-script файла.
• Для body-текста - font-display: swap, для стабильного текста над фолдом - font-display: optional.
• Preload основного веса: <link rel="preload" as="font" type="font/woff2" crossorigin href="/fonts/inter-variable.woff2">.
• Никогда не грузите один и тот же шрифт из двух провайдеров. Именно эта ошибка держала LCP one.az выше восьми секунд.

CDN, HTTP/3 и Brotli

CDN приближает байты к пользователю. Для origin в Баку, обслуживающего клиентов по Азербайджану, правильно прогретый Cloudflare cache обычно сокращает TTFB вдвое. Комбинируйте CDN с:

• HTTP/3 (QUIC) - меньше round-trip на нестабильных мобильных сетях. Включается в Cloudflare или на современных nginx.
• Brotli - на 15-20% меньше Gzip для HTML, CSS, JS и SVG. brotli on; в nginx или в Cloudflare Speed.
• Длинные cache-заголовки для хешированных ассетов: Cache-Control: public, max-age=31536000, immutable.
• Stale-while-revalidate, чтобы CDN отдавал слегка устаревший HTML, пока подтягивает свежий.

Сокращение JavaScript-бандла

Бандл больше 300 КБ gzipped - предупреждение, больше 500 КБ - кризис. Конкретные шаги:

• Анализируйте бандл. В каждом стеке есть анализатор: next build, rollup-plugin-visualizer для Vite или Webpack Bundle Analyzer.
• Code-split по маршрутам, чтобы пользователь скачивал JS только для открытой страницы.
• Tree-shake неиспользуемые экспорты. Используйте ES-модули и именованные импорты, никаких import _ from 'lodash'.
• Заменяйте тяжёлые зависимости. Нативные API: fetch вместо axios в простых случаях, URLSearchParams вместо query-string.
• Отправляйте современный JS современным браузерам через паттерн module/nomodule.

Управление сторонними скриптами

Аналитика, рекламные пиксели, чаты, cookie-баннеры, A/B-тесты, error-трекеры - каждый стоит миллисекунд INP и килобайт бандла. Аудитируйте безжалостно.

• Перечислите каждого стороннего в Chrome DevTools > Network > Domain и оспорьте. Никто не смотрит данные - удаляйте.
• Грузите аналитику после события load или через server-side tagging.
• Чаты - при скролле или наведении. Intercom, Tawk и Crisp поддерживают отложенную инициализацию.
• Для всего, что трогает DOM, предпочитайте defer, а не async, и не смешивайте несколько библиотек аналитики, отправляющих одинаковые события.

Кейс: one.az с 8-13 с LCP до менее 3 с

Главная one.az была нашим собственным худшим примером. Аудит показал четыре наложенные проблемы: два провайдера шрифтов параллельно, 4.2 МБ hero-видео с автоплеем на мобильных, блокирующий CSS-бандл 340 КБ и отсутствие CDN cache для HTML. Работа заняла четыре рабочих дня и дала такие цифры до/после на среднем Android с 4G в Баку:

Метрика	До	После
LCP	8.4 - 13.1 с	2.6 - 2.9 с
INP	410 мс	160 мс
CLS	0.28	0.04
Bounce rate (мобильные)	62 процента	44 процента

Самая большая единичная победа - удаление дубликата провайдера шрифтов. Одно это изменение срезало LCP более чем на четыре секунды.

Чек-лист перед деплоем

Перед каждым релизом крупных изменений прогоняйте короткий список - на нём мы ловим 80% регрессий скорости у клиентов ONE Studio:

• PageSpeed Insights на мобильной версии главной, категорийной и продуктовой (или сервисной) страницы. Сравнить с предыдущим релизом.
• Проверить, что LCP-элемент помечен fetchpriority="high" и не задерживается CSS.
• Убедиться, что в head нет двух провайдеров шрифтов - один preconnect, один WOFF2 через @font-face.
• Проверить размер JS-бандла на маршруте. Порог для главной - 200 КБ gzipped, для внутренних - 300 КБ.
• Пройти реальный сценарий с включённым throttling Fast 3G - INP должен оставаться ниже 200 мс.
• Открыть Search Console спустя 72 часа и проверить, что кривые Core Web Vitals не деградировали.

Куда копать глубже

Каноническая документация - от самого Google: web.dev/vitals, PageSpeed Insights и Chrome DevTools Performance. Если нужны сырые полевые данные - датасет CrUX в BigQuery публичный.

Оптимизация скорости с ONE Studio

ONE Studio проводит аудиты Core Web Vitals и полные программы оптимизации для клиентов в Азербайджане и за рубежом. Аудит выдаёт приоритизированный план работ, ревью CDN и хостинга, пайплайн для изображений и шрифтов, а также JavaScript-бюджет, которого сможет придерживаться ваша инженерная команда. Наши клиентские сайты обычно стабилизируются на 90+ mobile Core Web Vitals и держат этот балл под реальным трафиком.

Готовы ускорить сайт в 3-5 раз? Изучите разработку веб-сайтов, чтобы строить на быстром фундаменте, или начните с поддержки и сопровождения, чтобы починить существующий сайт. Свяжитесь с ONE Studio в Баку сегодня и превратите Core Web Vitals из красного предупреждения в конкурентное преимущество.