Оптимизация Core Web Vitals: практическое руководство

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

Core Web Vitals — это три метрики, определённые Google, которые делают пользовательский опыт сайта измеримым. С 2021 года они официально влияют на ранжирование в Google, то есть это уже не приятное дополнение, а фактор, критичный для бизнеса.

Три метрики в обзоре:

Важно: Все три метрики должны попасть в зону «хорошо», чтобы Google счёл страницу быстрой. Недостаточно, чтобы зелёными были одна или две. Проверьте сайт прямо сейчас нашим Проверщиком производительности и посмотрите, где вы находитесь.

Как измеряются Core Web Vitals?

Google различает полевые данные (реальные пользователи) и лабораторные данные (моделирование):

• Полевые данные берутся из Chrome UX Report (CrUX) и основаны на анонимных данных реальных пользователей Chrome. Именно эти данные Google использует для ранжирования.
• Лабораторные данные измеряются инструментами вроде Lighthouse, PageSpeed Insights или WebPageTest в контролируемой среде. Они идеальны для диагностики и оптимизации.

Главное отличие: полевые данные показывают, как сайт работает в действительности, лабораторные — как он работает в идеальных условиях. Оптимизируйте по лабораторным данным, но успех измеряйте по полевым.

Как Google использует CWV для ранжирования

В мае 2021 года Google ввёл Page Experience как сигнал ранжирования, и Core Web Vitals составляют его основу. Вот что это значит на практике:

Что мы знаем:

• CWV влияют на ранжирование, но не сильнее всего. Релевантный контент, ссылки и авторитет домена весят больше.
• При прочих равных CWV могут стать решающим отличием, особенно на первой странице результатов.
• Google использует 75-й процентиль полевых данных: если 75 процентов пользователей видят хорошие значения, страница считается прошедшей проверку.
• CWV оцениваются по каждому URL, а не по домену. Отдельные медленные страницы не влияют на весь сайт.

Влияние на бизнес:

• По данным исследований Google, у сайтов с хорошими CWV на 24 процента ниже показатель отказов
• Магазины сообщают о росте конверсии до 15 процентов после оптимизации CWV
• Новостные сайты отмечают до 22 процентов больше просмотров страниц за сессию

В нашей работе как агентство веб-дизайна мы наблюдали у клиентов после оптимизации CWV улучшение позиций в среднем на 3-8 пунктов по конкурентным запросам, и не только за счёт самих CWV, но и за счёт связанного с ними лучшего пользовательского опыта и меньшего числа отказов.

Оптимизация LCP: улучшаем скорость загрузки

Метрика Largest Contentful Paint измеряет, когда полностью загрузился самый крупный видимый элемент в области просмотра, обычно это главное изображение, видео или крупный блок текста. Цель: меньше 2,5 секунды.

Самые частые проблемы с LCP и их решения

1. Неоптимизированные изображения (самая частая проблема)

Главное изображение в 70 процентах случаев и есть элемент LCP. Если он весит 2 МБ и загружается только после обработки CSS и JavaScript, хорошего значения LCP не добиться.

Решение:

2. Медленный ответ сервера (TTFB)

Если серверу нужно больше 800 мс, чтобы отдать HTML-файл, все последующие ресурсы стартуют с опозданием.

Решение:

• Перейти на лучший хостинг (управляемый VPS вместо общего хостинга)
• Настроить CDN (Cloudflare, Fastly, AWS CloudFront)
• Включить кеширование на сервере (Varnish, Redis, микрокеширование Nginx)
• Оптимизировать запросы к базе (индексы, кеш запросов)

3. CSS и JavaScript, блокирующие отрисовку

CSS и синхронный JavaScript в `<head>` блокируют отрисовку страницы.

Решение:

4. Отложить сторонние скрипты

Аналитика, чат-виджеты, встроенные блоки соцсетей и реклама могут заметно ухудшить LCP.

Решение: Загружайте сторонние скрипты только после события LCP:

Оптимизация CLS: убираем смещения вёрстки

Метрика Cumulative Layout Shift измеряет, насколько сильно элементы неожиданно смещаются во время загрузки. Это испытывал каждый: вы хотите нажать кнопку, и в последний момент она уезжает, потому что появился рекламный баннер. Цель: меньше 0,1.

Самые частые причины CLS

1. Изображения и видео без размеров

Если браузер не знает размер изображения, он не резервирует под него место. Как только изображение загрузится, весь контент под ним сдвинется.

Решение:

2. Веб-шрифты вызывают FOUT и FOIT

При загрузке веб-шрифта текст может внезапно изменить размер (Flash of Unstyled Text) или на миг исчезнуть (Flash of Invisible Text).

Решение:

Дополнительно: предзагрузка файлов шрифтов:

3. Контент, вставляемый динамически

Баннеры cookie, всплывающие окна подписки и отложенно загружаемые элементы вызывают смещения вёрстки, если под них не зарезервировано место.

Решение:

4. Динамическая реклама без заданного размера контейнера

Решение: Используйте фиксированные размеры контейнеров для рекламных блоков:

Оптимизация INP: ускоряем интерактивность

Interaction to Next Paint (INP) в марте 2024 года официально заменил FID (First Input Delay) в составе Core Web Vitals. INP измеряет время отклика на все действия пользователя (клики, касания, ввод с клавиатуры) за всё время визита, а не только на первое. Цель: меньше 200 мс.

Почему INP требовательнее, чем FID

FID измерял только задержку при первом взаимодействии. INP учитывает каждое взаимодействие и берёт худшее значение (точнее, 98-й процентиль). Это значит: даже если страница быстро отвечает на первый клик, но на десятый тратит 500 мс, INP будет плохим.

Стратегии оптимизации INP

1. Найти и разбить длинные задачи

Задачи JavaScript дольше 50 мс блокируют основной поток и задерживают взаимодействия.

Решение через `requestIdleCallback` и разбивку задач:

2. Оптимизировать обработчики событий

Дорогие вычисления в обработчиках событий (прокрутка, ввод, изменение размера) нужно ограничивать по частоте через debounce или throttle.

3. Разделение кода и динамические импорты

Загружайте только тот код, который действительно нужен:

4. Web Workers для тяжёлых вычислений

Инструменты для измерения Core Web Vitals

Правильные инструменты решают многое в успешной оптимизации. Вот наши рекомендации:

Рекомендуемый порядок работы:

1. Обзор: Google Search Console, проверить отчёт по CWV
2. Анализ: PageSpeed Insights для важнейших страниц
3. Отладка: Chrome DevTools, вкладка Performance, найти узкие места
4. Наблюдение: Web Vitals Extension для повседневной работы
5. Автоматизация: встроить Lighthouse CI в конвейер сборки

Чек-лист Core Web Vitals

Вот ваш полный чек-лист, упорядоченный по приоритету:

Чек-лист LCP

• [ ] Главное изображение сжато в WebP или AVIF (меньше 200 КБ)
• [ ] У главного изображения есть `fetchpriority="high"` и подсказка preload
• [ ] TTFB меньше 800 мс (хороший хостинг и CDN)
• [ ] Критичный CSS встроен в `<head>`
• [ ] Убран JavaScript, блокирующий отрисовку (`defer` или `async`)
• [ ] Сторонние скрипты загружаются после LCP
• [ ] Предзагрузка шрифтов для заголовков
• [ ] Никакой отложенной загрузки для изображений на первом экране

Чек-лист CLS

• [ ] У всех изображений заданы атрибуты `width` и `height`
• [ ] `font-display: swap` для всех веб-шрифтов
• [ ] Переопределение метрик шрифта (`size-adjust`, `ascent-override`)
• [ ] Фиксированные размеры контейнеров для рекламы и встроенных блоков
• [ ] Баннер cookie как наложение, а не как элемент, сдвигающий контент
• [ ] Нет динамически вставляемого контента без заранее отведённого места
• [ ] CSS `aspect-ratio` для адаптивных контейнеров
• [ ] Нет поздних манипуляций с DOM в видимой области

Чек-лист INP

• [ ] Нет длинных задач дольше 50 мс в основном потоке
• [ ] Обработчики событий ограничены по частоте (поиск, прокрутка, изменение размера)
• [ ] Разделение кода для некритичных модулей
• [ ] `requestAnimationFrame` для визуальных обновлений
• [ ] Web Workers для тяжёлых вычислений
• [ ] Минимальный размер сборки (tree shaking, удаление мёртвого кода)
• [ ] Сторонние скрипты асинхронные или отложенные
• [ ] Нет синхронных запросов XHR

Оптимизации, характерные для WordPress

У сайтов на WordPress свои трудности с производительностью. Вот самые действенные меры:

1. Провести ревизию плагинов

Главная проблема производительности в WordPress: слишком много плагинов. Каждый плагин добавляет CSS, JavaScript и запросы к базе.

Рекомендуемый порядок:

• Отключите все плагины и измерьте базовую производительность
• Включайте плагины по одному и измеряйте влияние каждого
• Удалите всё, что используется меньше чем на 1 процент
• Замените тяжёлые плагины лёгкими альтернативами

Рекомендации по плагинам для производительности:

2. Оптимизация темы

Многие темы WordPress загружают сотни килобайт неиспользуемого CSS и JavaScript. Конструкторы страниц вроде Elementor или Divi особенно тяжёлые.

Подходы к оптимизации:

• Перейти на лёгкие темы (GeneratePress, Kadence, Astra)
• Удалить неиспользуемый CSS (Perfmatters или PurgeCSS)
• Использовать конструктор страниц только там, где клиент должен сам собирать страницы
• Разработка собственной темы для максимальной производительности

3. Оптимизация на уровне сервера

# .htaccess — включаем кеширование в браузере <IfModule mod_expires.c> ExpiresActive On ExpiresByType image/webp "access plus 1 year" ExpiresByType image/jpeg "access plus 1 year" ExpiresByType text/css "access plus 1 month" ExpiresByType application/javascript "access plus 1 month" </IfModule> # Сжатие GZIP <IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/html text/plain text/css AddOutputFilterByType DEFLATE application/javascript application/json </IfModule>

Оптимизации, характерные для Next.js

Для проектов, которые мы делаем на Next.js и Payload CMS, действуют другие стратегии оптимизации:

1. Оптимизация изображений через next/image

2. Оптимизация шрифтов через next/font

3. Разделение кода по маршрутам

Next.js делает разделение кода по маршрутам автоматически. Дополнительно:

4. Серверные компоненты (App Router)

5. Метаданные и потоковая отдача

Примеры из нашей практики

Пример 1: корпоративный сайт (Next.js и Payload CMS)

Исходная ситуация:

• PageSpeed на мобильных: 52 из 100
• LCP: 4,1 с (неоптимизированное главное изображение PNG, 3,2 МБ)
• CLS: 0,22 (шрифты без swap, изображения без размеров)
• INP: 310 мс (тяжёлая библиотека анимаций)

Что сделали:

1. Главное изображение: PNG в WebP, 3,2 МБ в 120 КБ, `fetchpriority="high"`
2. Все изображения через `next/image` с фиксированными размерами
3. Оптимизация шрифтов через `next/font` (на своём сервере, `swap`)
4. Framer Motion заменили на переходы CSS (сборка минус 180 КБ)
5. Сторонние скрипты отложили до события LCP

Результат:

• PageSpeed на мобильных: 96 из 100 (плюс 44 пункта)
• LCP: 1,3 с (минус 68 процентов)
• CLS: 0,01 (минус 95 процентов)
• INP: 85 мс (минус 73 процента)
• Показатель отказов: минус 35 процентов, конверсия: плюс 22 процента

Пример 2: интернет-магазин (WordPress и WooCommerce)

Исходная ситуация:

• PageSpeed на мобильных: 38 из 100
• LCP: 5,8 с (слайдер из пяти несжатых JPEG)
• CLS: 0,31 (изображения товаров без размеров, отзывы подгружаются позже)
• INP: 420 мс (jQuery и 15 активных плагинов)

Что сделали:

1. Слайдер заменили статичным главным изображением
2. ShortPixel для автоматического сжатия изображений (WebP)
3. Ревизия плагинов: с 15 до 8 (убрали 7 ненужных)
4. Установили WP Rocket (кеширование, минификация CSS и JS, отложенная загрузка)
5. Сменили хостинг с общего на управляемый VPS
6. Всем изображениям товаров задали фиксированные размеры

Результат:

• PageSpeed на мобильных: 88 из 100 (плюс 50 пунктов)
• LCP: 1,9 с (минус 67 процентов)
• CLS: 0,04 (минус 87 процентов)
• INP: 145 мс (минус 65 процентов)
• Оборот: плюс 18 процентов в первый месяц после оптимизации

Пример 3: местная сервисная компания (WordPress)

Исходная ситуация:

• PageSpeed на мобильных: 44 из 100
• LCP: 4,5 с (неоптимизированное главное изображение JPEG, 2,1 МБ)
• CLS: 0,28 (изображения без размеров, баннер cookie подгружается позже)
• INP: 190 мс

Что сделали:

1. Главное изображение: JPEG в WebP, 2,1 МБ в 95 КБ, fetchpriority="high"
2. Всем изображениям задали width и height
3. Баннер cookie перевели на position: fixed
4. Установили WP Rocket и ShortPixel
5. Удалили неиспользуемый CSS (Perfmatters)

Результат:

• PageSpeed на мобильных: 92 из 100 (плюс 48 пунктов)
• LCP: 1,6 с (минус 64 процента)
• CLS: 0,03 (минус 89 процентов)
• INP: 95 мс (минус 50 процентов)
• Позиция в Google по главному запросу: со страницы 3 на страницу 1 (седьмое место)

Частые ошибки при оптимизации CWV

По опыту более 120 проектов мы снова и снова видим одни и те же ошибки:

1. Оптимизировать только лабораторные данные и игнорировать полевые

Лабораторные данные (Lighthouse) показывают потенциал, но Google ранжирует по полевым данным (CrUX). Сайт может иметь 100 из 100 в Lighthouse и всё равно плохие полевые данные, если реальные пользователи сидят на медленных устройствах или плохом интернете.

2. Отложенно загружать все изображения

Отложенная загрузка прекрасна, но не для изображений на первом экране. Поставить главному изображению `loading="lazy"` значит резко ухудшить LCP, потому что браузер начнёт загружать его только тогда, когда оно попадёт в область просмотра.

3. Загружать слишком много шрифтов

Каждый файл шрифта стоит времени загрузки и может вызвать CLS. Ограничьтесь двумя-тремя начертаниями (обычное, полужирное, при необходимости курсив) и загружайте только нужные наборы символов (latin вместо latin-extended).

4. Складывать плагины производительности друг на друга

Три плагина кеширования одновременно делают не лучше, а хуже. Конфликты между плагинами — самая частая причина необъяснимых проблем с производительностью. Одного хорошего плагина кеширования (например, WP Rocket) достаточно.

5. Игнорировать сторонние скрипты

Google Analytics, Facebook Pixel, Hotjar, Intercom, Drift: каждый дополнительный скрипт стоит производительности. Спрашивайте себя о каждом: он мне правда нужен? А если да, можно ли загрузить его с задержкой?

6. Оптимизировать только главную страницу

Google оценивает каждый URL отдельно. Страницы товаров, статьи блога и страница контактов должны быть оптимизированы так же, как главная. Проверьте в Search Console отчёт по CWV для всех групп страниц.

Настраиваем наблюдение за производительностью

Оптимизация CWV — не одноразовый проект. Новые функции, изменения контента и обновления сторонних сервисов могут испортить производительность в любой момент. Вот как настроить постоянное наблюдение:

1. Google Search Console (бесплатно)

• Откройте отчёт «Основные интернет-показатели» в разделе «Улучшения»
• Каждый месяц проверяйте количество URL со статусом «плохо» или «требует улучшения»
• Настройте оповещения об ухудшениях

2. Наблюдение за реальными пользователями (RUM)

3. Lighthouse CI в конвейере сборки

# .github/workflows/lighthouse.yml name: Lighthouse CI on: [push] jobs: lighthouse: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: treosh/lighthouse-ci-action@v11 with: urls: | https://example.com/ https://example.com/blog/ budgetPath: ./budget.json temporaryPublicStorage: true

4. Определяем бюджеты производительности

Сторонние скрипты и их влияние на Core Web Vitals

Сторонние скрипты — один из главных убийц производительности современных сайтов. По данным HTTP Archive, сайты в среднем загружают 21 сторонний ресурс: от аналитики через чат-ботов до рекламных пикселей. Эти внешние скрипты могут сильно испортить ваши Core Web Vitals.

Какие сторонние скрипты создают больше всего проблем

Сильное влияние на LCP и INP:

• Чат-виджеты (например, Intercom, Zendesk Chat): часто загружают 200-500 КБ JavaScript и блокируют основной поток
• Встроенные блоки соцсетей (Facebook, Instagram, Twitter): один встроенный блок Facebook может подтянуть 1-3 МБ дополнительных ресурсов
• Встроенные видео (YouTube, Vimeo): без оптимизации один iframe YouTube загружает 600 КБ - 1,5 МБ

Умеренное влияние:

• Инструменты аналитики (Google Analytics, Hotjar, Matomo): обычно 50-150 КБ, но пиксели отслеживания складываются
• Баннеры согласия на cookie (Cookiebot, Usercentrics): 30-100 КБ, но часто блокируют отрисовку
• Сервисы шрифтов (Google Fonts, Adobe Fonts): 50-200 КБ на семейство

Слабое влияние при правильном подключении:

• Диспетчеры тегов (Google Tag Manager): около 80 КБ, но размер контейнера растёт с каждым тегом
• Пиксели конверсий (Google Ads, Meta Pixel): по отдельности маленькие, но дают накопительный эффект

Стратегии оптимизации

1. Отложенная загрузка сторонних скриптов

Загружайте чат-виджеты, блоки соцсетей и прочие некритичные скрипты только тогда, когда они пользователю нужны:

• Чат-виджет грузить только после прокрутки или через 5 секунд.
• Встроенные блоки соцсетей делать фасадом (статичное изображение с загрузкой по клику)
• Видео с YouTube подключать по схеме lite-youtube-embed, это экономит до 500 КБ на каждое видео

2. Приоритеты для скриптов

Используйте правильные атрибуты загрузки:

• async: скрипт загружается параллельно и выполняется сразу (подходит для аналитики)
• defer: скрипт загружается параллельно, но выполняется после разбора HTML (подходит большинству скриптов)
• Без атрибута: скрипт блокирует отрисовку, этого нужно обязательно избегать

3. Свой хостинг вместо подключения с CDN

Размещайте часто используемые сторонние ресурсы у себя:

• Google Fonts: скачайте файлы WOFF2 и разместите их на своём сервере. Это избавляет от одного запроса DNS и одного дополнительного соединения.
• Скрипты аналитики: при собственном Matomo сторонний запрос исчезает совсем

4. Регулярная ревизия

Раз в квартал проводите ревизию сторонних скриптов. Удаляйте то, что больше не нужно. На практике мы находим в 70 процентах всех ревизий хотя бы один скрипт, который уже не приносит пользы.

Измерение влияния сторонних скриптов

Чтобы измерить влияние отдельных скриптов, используйте следующие инструменты:

• Chrome DevTools, вкладка Performance: показывает, какие скрипты блокируют основной поток
• WebPageTest, вкладка Block: проверьте время загрузки с определёнными сторонними домена и без них
• Lighthouse, Treemap: показывает размер JavaScript в разбивке по источнику

Оптимизация на стороне сервера: хостинг, CDN и кеширование

Самая лучшая оптимизация на стороне браузера мало поможет, если сервер отвечает медленно. Показатель Time to First Byte (TTFB) должен быть меньше 800 миллисекунд, а в идеале меньше 200 мс. В Австрии мы видим у многих сайтов малого и среднего бизнеса TTFB выше 1,5 секунды.

Оптимизация хостинга

Общий хостинг, самая частая проблема

Более 60 процентов сайтов австрийского малого и среднего бизнеса работают на общем хостинге. Это значит, что сотни сайтов делят один сервер. В часы пик TTFB растёт очень сильно.

Рекомендации по типу сайта:

• Статические сайты и JAMstack: хостинг на границе сети (Vercel, Netlify, Cloudflare Pages), TTFB меньше 50 мс по всему миру
• Сайты на WordPress: управляемый хостинг WordPress (Raidboxes, Cloudways), TTFB 100-300 мс
• Приложения на PHP: VPS с OPcache, PHP 8.2 и новее и FastCGI, TTFB 150-400 мс
• Приложения на Node.js: хостинг контейнеров (Railway, Fly.io) или VPS с PM2

Как правильно настроить CDN

Сеть доставки контента Content Delivery Network распределяет статические файлы по серверам во всём мире. Для австрийских сайтов с аудиторией в немецкоязычных странах оптимален CDN с узлами во Франкфурте, Вене и Цюрихе.

Лучшие практики настройки CDN:

• Статические файлы (CSS, JS, изображения, шрифты) отдавать через CDN
• HTML-страницы кешировать только если они редко меняются (например, целевые страницы)
• Заголовки Cache-Control задавать правильно: 'public, max-age=31536000, immutable' для файлов с версией в имени
• Сжатие Brotli включить, оно даёт на 15-25 процентов меньший размер, чем Gzip

Кеширование на стороне сервера

Кеширование страниц:

Создавайте HTML-страницу один раз и отдавайте закешированную версию. Для WordPress подходят плагины вроде WP Super Cache или W3 Total Cache. Для Next.js используйте Incremental Static Regeneration (ISR).

Кеширование объектов через Redis:

Redis держит часто запрашиваемые результаты из базы в оперативной памяти. Улучшение TTFB может достигать 50-80 процентов. Для WordPress плагин Redis Object Cache меняет всё, особенно в магазинах на WooCommerce.

OPcache для PHP:

Включите OPcache с достаточным объёмом памяти (минимум 128 МБ). OPcache компилирует файлы PHP один раз и хранит байт-код. Прирост производительности составляет 200-400 процентов для сайтов на PHP.

HTTP/2 и HTTP/3

Убедитесь, что ваш сервер поддерживает HTTP/2, а в идеале HTTP/3 (QUIC):

• HTTP/2: мультиплексирование позволяет загружать несколько ресурсов параллельно по одному соединению
• HTTP/3: построен на UDP вместо TCP и снижает задержку при плохой сети на 30-50 процентов
• Большинство современных хостинг-провайдеров и CDN поддерживают HTTP/3 с 2024 года

Core Web Vitals для интернет-магазинов

У интернет-магазинов особые трудности с Core Web Vitals. Изображения товаров, системы фильтров, динамические цены и процесс оформления заказа делают оптимизацию сложной, но тем более выгодной.

Оптимизация LCP на страницах товара

Самый крупный видимый элемент на странице товара — обычно главное изображение товара. Оптимизируйте его целенаправленно:

• Предзагружайте изображение через '<link rel="preload" as="image">' в head документа
• Используйте заполнитель: изображение низкого качества (LQIP) или размытую подложку
• Ограничьте размер: главное изображение должно весить не больше 150 КБ (WebP, качество 80)
• Никакой отложенной загрузки для главного изображения товара, оно должно загружаться сразу

Проблемы с CLS в магазинах

Самые частые причины CLS в электронной коммерции:

• Цены, которые подгружаются: персональные цены или метки распродажи, вставляемые через JavaScript
• Звёзды рейтинга товара: когда виджет оценок загружается асинхронно и сдвигает контент
• Баннеры и уведомления об акциях: баннер «бесплатная доставка от 50 евро», который появляется после отрисовки страницы
• Рекомендации товаров: карусели «с этим товаром также покупали», которые занимают место

Решения:

• Резервируйте фиксированное место (min-height или aspect-ratio) под все динамические элементы
• Загружайте информацию о цене на стороне сервера, а не через JavaScript в браузере
• Задавайте атрибуты width и height всем изображениям товаров

Оптимизация INP для фильтров и поиска

Фильтры товаров и поиск интерактивны, и именно здесь проявляется значение INP:

• Задержка ввода для поиска: подождите 300 мс после последнего нажатия клавиши и только потом запускайте поиск
• Виртуальные списки с прокруткой для категорий с сотнями товаров
• Web Worker для трудоёмких расчётов фильтров, чтобы разгрузить основной поток
• Оптимистичный интерфейс: показывайте результаты фильтрации сразу и обновляйте их в фоне

Производительность оформления заказа

Оформление заказа — самый критичный момент для магазина: каждая секунда задержки может поднять долю отказов на 7 процентов:

• Скрипты оплаты (Stripe, PayPal, Klarna) загружать только на странице оформления, а не на всех страницах
• Формы с минимумом JavaScript: использовать встроенную проверку HTML вместо тяжёлых библиотек
• Автоподстановка адреса экономит время пользователя и сокращает ожидание следующего действия

Отраслевые ориентиры для Австрии

Для интернет-магазинов в немецкоязычных странах отличными считаются такие значения CWV:

• LCP: меньше 2,0 секунды (в среднем по отрасли 3,8 секунды)
• INP: меньше 150 мс (в среднем по отрасли 280 мс)
• CLS: меньше 0,05 (в среднем по отрасли 0,15)

Магазины, у которых все три значения в зелёной зоне, сообщают о конверсии выше на 12-25 процентов по сравнению со средней по отрасли.

Оптимизация скорости на практике: анализ до и после

Теория важна, но ничто не убеждает сильнее, чем реальные результаты. Ниже три обезличенных примера из нашей агентской практики с конкретными мерами и измеримыми улучшениями.

Пример 1: ремесленная компания из Вены

Исходное положение:

• Сайт на WordPress, 35 страниц, общий хостинг
• LCP: 6,2 секунды | CLS: 0,28 | INP: 420 мс
• Оценка PageSpeed: 28 из 100 (мобильные)

Выполненные меры:

• Перенос на управляемый хостинг WordPress (Raidboxes)
• Конвертация изображений в WebP, внедрена отложенная загрузка
• Отключены и удалены 8 неиспользуемых плагинов
• Сформирован критичный CSS, выполнение JavaScript отложено
• Google Fonts размещены локально, число начертаний сокращено до двух

Результат через 4 недели:

• LCP: 1,8 секунды (улучшение на 71 процент) | CLS: 0,02 | INP: 95 мс
• Оценка PageSpeed: 92 из 100 (мобильные)
• Органический трафик: плюс 34 процента через 3 месяца

Пример 2: интернет-магазин спортивной одежды (Австрия)

Исходное положение:

• WooCommerce с 1200 товарами, хостинг на VPS
• LCP: 4,8 секунды | CLS: 0,22 | INP: 380 мс
• Оценка PageSpeed: 35 из 100 (мобильные)

Выполненные меры:

• Установлен и настроен Redis Object Cache
• Изображения товаров автоматически переведены в WebP (Shortpixel)
• Слайдер на главной заменён статичным главным изображением
• Отключены фрагменты корзины WooCommerce на страницах вне магазина
• Включён CDN Cloudflare со сжатием Brotli
• Оформление заказа вынесено на отдельный поддомен с минимальной нагрузкой CSS и JS

Результат через 6 недель:

• LCP: 2,1 секунды (улучшение на 56 процентов) | CLS: 0,04 | INP: 140 мс
• Оценка PageSpeed: 78 из 100 (мобильные)
• Конверсия: плюс 18 процентов, доля брошенных корзин: минус 12 процентов

Пример 3: целевая страница SaaS (Next.js)

Исходное положение:

• Next.js 14 на Vercel, 8 целевых страниц
• LCP: 3,1 секунды | CLS: 0,08 | INP: 250 мс
• Оценка PageSpeed: 62 из 100 (мобильные)

Выполненные меры:

• Главное изображение оптимизировано через next/image с атрибутом priority
• Чат-виджет Intercom загружается отложенно через Intersection Observer
• Библиотека анимаций (Framer Motion) заменена переходами CSS (экономия 120 КБ)
• Анализ сборки через @next/bundle-analyzer, неиспользуемый код удалён
• Font-display: swap и подмножество символов для используемого шрифта

Результат через 2 недели:

• LCP: 1,4 секунды (улучшение на 55 процентов) | CLS: 0,01 | INP: 85 мс
• Оценка PageSpeed: 97 из 100 (мобильные)
• Запросы на демонстрацию: плюс 22 процента в следующем месяце

Выводы из всех трёх проектов

• Самый большой выигрыш почти всегда дают изображения и сторонние скрипты
• Переход на лучший хостинг часто оказывается самой выгодной отдельной мерой
• Чем меньше, тем лучше: последовательно сокращайте число плагинов, начертаний шрифта и анимаций
• Измеряйте до и после каждой меры: так вы поймёте, какие изменения дают наибольший эффект

Core Web Vitals и позиции в поиске: измеримые последствия

С тех пор как Google ввёл Core Web Vitals в число официальных факторов ранжирования, у многих владельцев сайтов в немецкоязычных странах возникает вопрос: насколько сильно LCP, CLS и INP действительно влияют на позиции? Ответ тоньше, чем многие ожидают. Опираясь на свежие исследования и данные, мы разбираем измеримые последствия и показываем, как использовать Core Web Vitals как стратегическое преимущество.

Связь между Core Web Vitals и позициями

Несколько крупных исследований изучали связь между Core Web Vitals и органическими позициями. Результаты согласуются между собой, но они не настолько драматичны, как утверждают некоторые специалисты по SEO:

• Одно исследование Searchmetrics (2025, 500 000 URL в немецкоязычных странах) показывает: сайты, у которых все три Core Web Vitals в зелёной зоне, в среднем занимают позицию на 3,2 пункта выше, чем сравнимые сайты с плохими значениями
• Ahrefs в 2025 году разобрал более 33 миллионов страниц и выяснил: только 33 процента страниц на первом месте проходят все проверки Core Web Vitals, а значит, одни Core Web Vitals позицию не определяют
• Анализ HTTP Archive по немецкому рынку дал такую картину: доля сайтов с хорошими значениями CWV выросла с 24 процентов (2022) до 48 процентов (2025), то есть конкуренция усиливается

Главный вывод: Core Web Vitals — это фактор для разрешения ничьей. При прочих равных релевантности и авторитете именно они определяют позицию. Слабый контент они на первое место не вытащат, но разницу между третьим и седьмым местом создать могут.

Отраслевые ориентиры для немецкоязычных стран

Требования к Core Web Vitals заметно различаются по отраслям. Для австрийского рынка конкурентоспособными считаются такие значения:

Электронная коммерция и интернет-магазины:

• LCP: меньше 2,0 секунды (в среднем по региону 3,1 секунды)
• CLS: меньше 0,05 (в среднем 0,14)
• INP: меньше 150 мс (в среднем 280 мс)
• Трудность здесь в оптимизации изображений товаров и во множестве сторонних скриптов (отслеживание, платёжные сервисы, чат-боты)

Услуги B2B:

• LCP: меньше 1,8 секунды (в среднем по региону 2,4 секунды)
• CLS: меньше 0,03 (в среднем 0,08)
• INP: меньше 100 мс (в среднем 180 мс)
• У сайтов B2B обычно меньше сторонних скриптов, поэтому хороших значений добиться проще

Новостные порталы и контентные сайты:

• LCP: меньше 2,5 секунды (в среднем по региону 3,8 секунды)
• CLS: меньше 0,08 (в среднем 0,22)
• INP: меньше 200 мс (в среднем 320 мс)
• Главная трудность здесь — высокий CLS из-за подгружаемых рекламных баннеров и динамического контента

Расчёт отдачи: что даёт оптимизация CWV?

Компании в немецкоязычных странах задаются вопросом, окупаются ли вложения в оптимизацию Core Web Vitals. Ответ зависит от модели бизнеса, но в большинстве случаев он однозначно положительный:

Прямое влияние на конверсию:

• Vodafone сообщил о конверсии выше на 31 процент после улучшения LCP на 31 процент
• Netzsieger.de после оптимизации CWV зафиксировал рост органического трафика на 18 процентов за три месяца
• Zalando выяснил, что каждые 100 мс улучшения времени загрузки повышают выручку с сессии на 0,7 процента.

Расчёт для типичной австрийской компании малого и среднего размера:

Допустим, у вашего сайта 10 000 органических посетителей в месяц при конверсии 2 процента и средней прибыли с заказа 500 евро. Оптимизация CWV, которая поднимает конверсию на 15 процентов (с 2 до 2,3 процента), даёт:

• Дополнительные конверсии в месяц: 30
• Дополнительная выручка в месяц: 15 000 евро
• Дополнительная выручка в год: 180 000 евро

Против этого стоит разовое вложение в оптимизацию CWV, которое в зависимости от сложности сайта составляет от 2000 до 15 000 евро. Возврат вложений обычно достигается в течение одного-трёх месяцев.

Наблюдение и постоянное улучшение

Core Web Vitals — не разовая задача, они требуют постоянного наблюдения. Изменения контента, новые плагины, обновлённые сторонние скрипты или рост трафика могут испортить значения в любой момент.

Опирайтесь на такую схему наблюдения:

• Раз в неделю: автоматические тесты Lighthouse CI в конвейере CI/CD
• Раз в месяц: проверка данных CrUX (Chrome User Experience Report) в Google Search Console
• Раз в квартал: полный аудит производительности со сравнением с конкурентами
• При каждом выпуске: автоматические бюджеты производительности, останавливающие сборку при превышении пороговых значений

Будущее Core Web Vitals: что придёт после INP?

Google постоянно развивает Core Web Vitals. После замены FID (First Input Delay) на INP (Interaction to Next Paint) в марте 2024 года многие ответственные за SEO спрашивают: какие метрики появятся следующими и как к ним подготовиться уже сегодня?

Как развивались Core Web Vitals

Взгляд на прошлое помогает оценить, куда всё движется:

• 2020: появление Core Web Vitals с LCP, FID и CLS
• 2021: Core Web Vitals становятся официальным фактором ранжирования
• 2024: FID заменяется на INP, заметно более требовательную метрику интерактивности
• 2025: Google вводит улучшенное измерение CLS (смещения учитываются только в определённых случаях)
• 2026 и далее: несколько новых метрик находятся на стадии проверки

Тенденция ясна: Google уходит от упрощённых метрик к более полному измерению реального пользовательского опыта.

Экспериментальные метрики, о которых стоит знать

Google и сообщество веб-производительности работают над несколькими новыми метриками, которые потенциально могут войти в Core Web Vitals:

Плавность (Smoothness)

Эта метрика измеряет, насколько плавно работают анимации и прокрутка на сайте. Цель — выявлять пропуски кадров и рывки, то есть подёргивания, портящие впечатление. Особенно важно для:

• Сайтов с эффектом параллакса при прокрутке
• Магазинов с каруселями товаров
• Сайтов со сложными анимациями CSS
• Одностраничных приложений с динамическими переходами

Отзывчивость за пределами INP

INP измеряет задержку до визуального обновления после взаимодействия, но есть стремление охватить всю цепочку взаимодействия. Сюда входит:

• Время до завершения всех сетевых запросов, вызванных взаимодействием
• Стабильность вёрстки после взаимодействия
• Постоянство времени отклика на протяжении всего визита

Long Animation Frames (LoAF)

Этот интерфейс позволяет точнее понять, почему страница отвечает медленно. В отличие от прежних длинных задач, которые измеряли только длительность, LoAF даёт подробную информацию о причине задержки, включая виновные скрипты и функции.

Мягкие переходы и одностраничные приложения

Один из главных пробелов в нынешних Core Web Vitals — измерение мягких переходов, то есть смены страниц внутри одностраничных приложений (SPA) без полной перезагрузки. Google активно работает над решением, которое сделает CWV справедливыми и осмысленными и для SPA.

Это особенно важно для сайтов на фреймворках вроде Next.js, Nuxt.js или Angular. В немецкоязычных странах, по данным W3Techs, уже 18 процентов сайтов из первых десяти тысяч построены на архитектуре SPA, и доля растёт.

Что это значит для вас?

• Если у вас SPA, следите за Soft Navigation API.
• Внедряйте наблюдение за производительностью клиентских переходов уже сейчас
• Проверяйте своё SPA не только на первую загрузку, но и на последующие переходы

Подготовка к будущим метрикам

Даже если точные будущие метрики пока неизвестны, подготовиться можно уже сегодня:

• Введите бюджет производительности — задайте максимальный размер сборки JavaScript, максимальное время загрузки и максимальные смещения вёрстки. Эти бюджеты защищают от ухудшений независимо от того, какие метрики введёт Google
• Внедрите наблюдение за реальными пользователями (RUM) — собирайте данные о производительности у настоящих пользователей, а не только из синтетических тестов. Инструменты вроде SpeedCurve, Web Vitals Library или Vercel Analytics дают ценные данные в реальном времени
• Разберите сборку JavaScript — уберите неиспользуемый код, внедрите разделение кода и отложенную загрузку. Меньшая сборка означает лучшую производительность независимо от конкретной метрики
• Оптимизируйте производительность сервера — вложитесь в быстрые серверы, настройку CDN и вычисления на границе сети. Прочная серверная инфраструктура — основа для всех метрик производительности
• Доступность как фактор производительности — доступные сайты часто и работают быстрее, потому что опираются на лёгкий семантический HTML. Google всё больше рассматривает доступность как сигнал качества

Главный совет для немецкоязычного рынка: придерживайтесь подхода, ориентированного на пользователя, вместо оптимизации отдельных метрик. Если сайт быстро загружается, надёжно отвечает на действия и визуально стабилен, вы выиграете от любых будущих обновлений Core Web Vitals, какие бы конкретные метрики Google ни ввёл.

Вывод и следующие шаги

Core Web Vitals — не разовый проект, а непрерывный процесс. Новые функции, изменения контента и обновления сторонних сервисов могут испортить производительность в любой момент. Вот ваш план действий:

Немедленные меры (на этой неделе)

1. Измерить: откройте PageSpeed Insights и проверьте пять важнейших страниц
2. Расставить приоритеты: определите метрику с наибольшим потенциалом улучшения
3. Быстрые победы: сжать изображения, задать размеры, оптимизировать шрифты

Краткосрочно (в этом месяце)

1. Оптимизировать сервер: оценить хостинг, настроить CDN, настроить кеширование
2. Ревизия JavaScript: найти и убрать ненужные плагины и скрипты
3. Оценить тему или фреймворк: не является ли ваша тема или фреймворк узким местом?

Долгосрочно (в этом квартале)

1. Настроить наблюдение: автоматическое наблюдение за производительностью (например, SpeedCurve, Calibre)
2. Определить бюджет производительности: максимальный размер сборки, максимальное значение LCP
3. Осведомлённость команды: объяснить всем разработчикам важность производительности
4. Регулярные аудиты: ежемесячный разбор производительности

Нужна помощь?

Оптимизация Core Web Vitals сложна и требует технических знаний. В GoldenWing мы оптимизируем Core Web Vitals как обязательную часть каждого проекта по веб-дизайну и SEO. От анализа производительности до внедрения: мы приводим ваш сайт в зелёную зону.

Воспользуйтесь нашим бесплатным проверщиком производительности, чтобы узнать текущее состояние сайта, и свяжитесь с нами для разговора без обязательств. Вместе мы сделаем ваш сайт быстрым, стабильным и удобным.

Если хотите узнать больше о техническом SEO, заходите в наши записи словаря или читайте другие статьи блога по темам веб-дизайн и оптимизация производительности. Core Web Vitals входят в наш веб дизайн в Вене как обязательная часть.