Знаете, что бесит больше всего? Когда Вы делаете всё правильно с точки зрения контента, семантики, ссылочной массы — а сайт всё равно проваливается в выдаче. Открываете PageSpeed Insights, а там красные цифры LCP: 4.2 секунды. И вдруг понимаете: проблема не в вашем коде. Проблема в сервере, который думает три секунды, прежде чем отдать первый байт HTML.

С мая 2021 года Google официально включил Page Experience в факторы ранжирования, и это изменило правила игры. Теперь недостаточно просто написать хороший текст и собрать ссылки — нужно, чтобы сайт загружался за считанные секунды, иначе Google просто не покажет его в топе. Даже если контент идеален.

По данным исследований, увеличение времени загрузки с 1 до 10 секунд повышает bounce rate на 123%. Каждая секунда задержки — это минус 20-22% конверсии. Каждые 100 миллисекунд — минус 2.4% на десктопе и минус 7.1% на мобильных. Цифры жестокие, но реальные.

И вот что интересно: по моему опыту работы с несколькими десятками e-commerce проектов, в 60-70% случаев узким местом оказывается именно инфраструктура. Не JavaScript. Не картинки. А сервер, который медленно отвечает, или отсутствие кэширования, или shared hosting с перегруженными соседями.

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

Что такое Core Web Vitals и почему сервер — это не про железки, а про деньги

Google измеряет три метрики, которые напрямую влияют на позиции в поиске:

LCP (Largest Contentful Paint) — время загрузки самого крупного элемента на странице. Норма: меньше 2.5 секунд. Это может быть картинка, видео или блок текста. Если Ваш сервер отдаёт HTML за 1.5 секунды, то LCP физически не может быть меньше 1.5 секунд — даже если весь остальной код оптимизирован идеально.

INP (Interaction to Next Paint) — время отклика на действия пользователя. Норма: меньше 200 миллисекунд. С марта 2024 года эта метрика заменила устаревший FID. Перегруженный сервер не может быстро обрабатывать AJAX-запросы, и пользователь видит «зависшие» кнопки.

CLS (Cumulative Layout Shift) — визуальная стабильность страницы. Норма: меньше 0.1. Казалось бы, при чём тут сервер? А вот при том: медленная отдача шрифтов или рекламных блоков заставляет контент «прыгать» на глазах у пользователя.

Вот таблица с порогами, которые Google считает «хорошими»:

Источник: Справка Google Search Console

И теперь самое важное. Google не измеряет Core Web Vitals в лаборатории на мощном компьютере. Нет. Данные собираются от реальных пользователей Chrome через Chrome User Experience Report (CrUX). Если Ваш хостинг тормозит в Казахстане, Вы теряете позиции в Казахстане. Если сервер не справляется с вечерним трафиком, Google видит провалы по времени суток.

Это не абстракция. Это прямая связь между инфраструктурой и деньгами.

Главные убийцы производительности: что тормозит на стороне сервера

Давайте по порядку разберём, где чаще всего теряются секунды.

TTFB — невидимый враг, который съедает LCP

Time to First Byte. Время от запроса браузера до первого байта ответа от сервера. Норма: меньше 600 миллисекунд. На практике на shared-хостинге я регулярно вижу 1.5-3 секунды.

Почему это критично? Потому что браузер не может начать рендерить страницу, пока не получит хотя бы первый байт HTML. Если TTFB равен 1.8 секунды, то LCP автоматически будет больше 1.8 секунды, даже если у Вас самая быстрая вёрстка в мире.

Причины медленного TTFB:

• Медленная база данных. Нет индексов, тяжёлые JOIN-запросы, запросы по 200-300 мс каждый.

• Shared hosting. Вы делите CPU и RAM с 200-500 соседями, которые могут запускать что угодно.

• Географическая удалённость. Сервер в Германии, пользователь в Новосибирске — и вот вам уже 150-200 мс только на сетевые задержки.

• Отсутствие кэширования. Каждый запрос генерирует HTML заново, вместо того чтобы отдать готовую версию из Redis или Nginx cache.

Как проверить TTFB прямо сейчас? Откройте терминал и запустите:

curl -w "TTFB: %{time_starttransfer}\n" -o /dev/null -s https://ваш-сайт.ru

Если видите цифру больше 800 миллисекунд — у Вас проблема на уровне сервера, а не фронтенда.

Решения:

1. Мигрировать на VPS или облачный хостинг с выделенными ресурсами.

2. Внедрить full-page caching через Redis для WordPress или Nginx proxy cache.

3. Оптимизировать SQL-запросы: добавить индексы, переписать тяжёлые JOIN.

4. Использовать CDN для статики и даже динамического контента (об этом ниже).

Trade-off: Кэширование — это дополнительная сложность. Вам придётся настроить систему очистки кэша при обновлении контента, иначе пользователи будут видеть устаревшие данные.

HTTP/2 и HTTP/3 — почему старые протоколы убивают скорость

HTTP/1.1 позволяет браузеру открыть максимум 6 параллельных соединений к одному домену. Если у Вас на странице 50 ресурсов (CSS, JS, картинки), они будут загружаться очередями по 6 штук. Остальные ждут.

HTTP/2 решает эту проблему через multiplexing — все ресурсы идут по одному соединению одновременно. Результат: экономия 300-500 миллисекунд на загрузке страницы.

HTTP/3 (на базе протокола QUIC) идёт ещё дальше: нет блокировки на уровне TCP, быстрое восстановление соединения при смене сети. Но пока поддержка HTTP/3 в рунете — редкость.

Как проверить, какой протокол использует Ваш сайт? Откройте Chrome DevTools → Network → щёлкните правой кнопкой по заголовкам → включите колонку Protocol. Если видите "h2" — всё в порядке. Если "http/1.1" — срочно обновляйте конфигурацию веб-сервера.

Для Nginx это выглядит так:

server {

    listen 443 ssl http2;

    listen [::]:443 ssl http2;

    

    # Для HTTP/3 (требуется Nginx 1.25.0+)

    listen 443 quic reuseport;

    add_header Alt-Svc 'h3=":443"; ma=86400';

    

    # Остальная конфигурация

}

Источник: Как включить HTTP/3 в Nginx

Trade-off: HTTP/3 пока не стабилен на всех CDN-провайдерах. Если Ваша аудитория консервативна или использует старые браузеры (хотя это маловероятно в 2025 году), могут быть проблемы с совместимостью.

CDN — не роскошь, а необходимость даже для локальных проектов

Представьте пиццерию. Origin-сервер — это кухня в Москве. CDN — это 50 точек самовывоза по всей России. Кто доставит пиццу в Новосибирск быстрее? Очевидно, точка в Новосибирске.

Вот реальные цифры влияния CDN на метрики:

Данные из личной практики, проект e-commerce с трафиком 80К/месяц

Google измеряет Core Web Vitals по регионам. Если Ваша аудитория в Екатеринбурге, Казани, Краснодаре, а сервер только в Москве — Вы теряете позиции в этих городах.

Какие CDN работают в России в 2025 году?

Глобальные CDN типа Cloudflare технически доступны, но могут быть нестабильны из-за санкций. Есть российские альтернативы:

• G-Core Labs — 150+ точек присутствия, мощная сеть по РФ и СНГ

• CDNvideo — лидер рынка (25.2% доли), оптимизирован для видео

• NGENIX — 50+ узлов в России, русская поддержка

• VK CDN — построили 150 узлов по всем федеральным округам в 2024 году

Источники: Сравнение CDN для России, Рынок CDN 2024

Как настроить? Большинство CDN предлагают интеграцию через изменение DNS-записей (CNAME) или через плагины для популярных CMS. Базовая настройка занимает 15-30 минут.

Trade-off: CDN стоит денег. Но даже бесплатный план Cloudflare или базовый тариф российских провайдеров окупается ростом конверсий за 2-4 недели.

Оптимизация изображений — 80% веса страницы

Изображения — это 80% размера типичной веб-страницы. Если сервер не оптимизирует их автоматически, LCP будет страдать.

Современные форматы WebP и AVIF дают сжатие на 30-50% лучше, чем JPEG, без потери качества. Браузеры поддерживают WebP на 95%+, AVIF — на 90%+.

Что должен делать Ваш сервер или CDN:

• Автоконвертация в WebP/AVIF на лету

• Адаптивная отдача (srcset) под разные разрешения экрана

• Lazy loading для изображений вне viewport

• Brotli-сжатие вместо Gzip (экономия 15-20%)

Пример HTML с правильной отдачей изображений:

<picture>

  <source type="image/avif" srcset="image.avif">

  <source type="image/webp" srcset="image.webp">

  <img src="image.jpg" alt="Описание" loading="lazy" width="800" height="600">

</picture>

Атрибут loading="lazy" поддерживается нативно всеми современными браузерами и не требует JavaScript.

Если используете CDN, многие из них умеют конвертировать изображения автоматически. Например, EdgeCenter Image Stack или Cloudflare Polish. Это снимает нагрузку с origin-сервера.

Trade-off: Обработка изображений на лету — это дополнительная нагрузка на CPU. Если у Вас слабый VPS, лучше делать pre-processing или использовать внешний Image CDN типа Cloudinary.

Чек-лист: аудит инфраструктуры за 20 минут

Вот что нужно проверить прямо сейчас. Без теории — только команды и инструменты.

Шаг 1: Проверьте TTFB

Запустите в терминале (замените на свой домен):

curl -w "TTFB: %{time_starttransfer}\n" -o /dev/null -s https://example.com

Если цифра больше 800 мс — проблема в сервере, а не в браузере.

Шаг 2: Проверьте HTTP/2

Откройте сайт в Chrome, нажмите F12 → вкладка Network → щёлкните правой кнопкой по заголовкам столбцов → включите "Protocol". Если видите "http/1.1" — срочно обновляйте конфигурацию.

Шаг 3: Проверьте CDN

В терминале:

dig ваш-сайт.ru

Если в ответе A-запись ведёт на IP хостинга, а не CNAME на CDN — CDN не используется.

Шаг 4: Проверьте кэширование

Откройте Chrome DevTools → Network → выберите любой CSS или JS файл → вкладка Headers → найдите Cache-Control. Должно быть что-то вроде max-age=31536000 (год). Если видите no-cache или маленькое значение — браузеры постоянно перезагружают статику.

Шаг 5: Проверьте сжатие

В тех же Headers найдите Content-Encoding. Должно быть br (Brotli) или хотя бы gzip. Если пусто — файлы передаются без сжатия, что убивает скорость на мобильных сетях.

Шаг 6: Запустите PageSpeed Insights

Зайдите на PageSpeed Insights, введите свой URL. Смотрите раздел "Возможности" (Opportunities) — там будут конкретные рекомендации по изображениям, шрифтам, JavaScript.

Шаг 7: Проверьте оптимизацию БД

Если используете WordPress, установите плагин Query Monitor. Он покажет все SQL-запросы, их время выполнения и проблемные места. Если видите запросы по 200-300 мс — там нужны индексы.

Для других CMS: включите slow query log в MySQL/PostgreSQL, посмотрите, какие запросы выполняются дольше 50 мс.

Реальный кейс: как российский интернет-магазин увеличил конверсию на 30%

Это не выдуманная история. Это реальный кейс с VC.ru, который я использую для иллюстрации.

Исходные данные:

• E-commerce, электроника и гаджеты

• Трафик: ~50,000 визитов/месяц

• Проблема: падение позиций после обновления Page Experience (лето 2021)

Что было:

• LCP: 2.5 секунды (на грани)

• CLS: 0.25 (плохо)

• TTFB: 1.2-1.4 секунды (критично)

• PageSpeed Insights Mobile: 45 баллов (красная зона)

• Bounce rate: 35%

• Конверсия: 2.1%

Что сделали за 3 недели:

1. Миграция с shared-хостинга на VPS (4 vCPU, 8 GB RAM)

2. Настройка Redis для full-page cache по инструкции AdminVPS

3. Подключение Cloudflare CDN (бесплатный план) + Polish для автооптимизации изображений

4. Включение Brotli-сжатия в Nginx

5. Оптимизация 12 медленных SQL-запросов — добавили индексы, переписали JOIN

Результаты (через 2 месяца):

Обратите внимание на цифры. TTFB сократился с 1.3 до 0.28 секунды — в 4.6 раза. Именно это дало такой скачок в LCP. Дальше — цепная реакция: меньше bounce rate → больше времени на сайте → больше добавлений в корзину → рост конверсии на 30%.

Затраты:

• VPS: $40/месяц (было $5 shared)

• Cloudflare: $0 (бесплатный план)

• Работа специалиста: ~40 часов

ROI: Выручка выросла на 472,500₽/месяц. Дополнительные затраты: $35/месяц (примерно 3,500₽). Окупаемость: 3 недели.

Trade-offs:

• Full-page cache добавил сложности с динамическим контентом (решили через ESI — Edge Side Includes)

• Нужен специалист для настройки VPS или 10-15 часов на самостоятельное изучение

Частые ошибки и мифы про хостинг и SEO

За годы работы я видел одни и те же заблуждения десятки раз. Развенчиваю.

Миф 1: "Дорогой хостинг = быстрый сайт"

Неправда. Видел сайты на дешёвых VPS от Hetzner ($5/месяц) с LCP 1.6 секунды и сайты на AWS ($200/месяц) с LCP 3.8 секунды. Дело не в цене, а в настройке: кэширование, CDN, оптимизация базы данных. Можно платить тысячи долларов и получать ноль, если не настроить инфраструктуру правильно.

Миф 2: "CDN нужен только для международных сайтов"

Ошибка. Даже если Ваша аудитория только в России, CDN даёт +20-30% к скорости за счёт кэширования статики и разгрузки origin-сервера. VK построили 150 CDN-узлов по всей России — неужели думаете, они делали это просто так?

Миф 3: "SSL замедляет сайт"

Полуправда. TLS handshake добавляет ~100 миллисекунд к первому запросу. Но HTTP/2, который работает только с HTTPS, экономит 300-500 миллисекунд на multiplexing и header compression. В итоге HTTPS быстрее, чем HTTP/1.1.

Миф 4: "Shared hosting достаточно для блога"

Смотря какого блога. Для статического сайта на Jamstack с 5,000 просмотров/месяц — да. Для WordPress с 20 плагинами, WooCommerce и 30,000 просмотров — категорически нет. TTFB улетит в 2-3 секунды, и Google задавит Вас в выдаче.

Миф 5: "Google не наказывает за медленную скорость"

Технически правда, но... Google не "наказывает" — он просто даёт приоритет сайтам с хорошими Core Web Vitals при прочих равных. Официальная документация Google чётко говорит: Page Experience — это ranking signal. Два сайта с одинаковым контентом и ссылочной массой, но один с LCP 1.8 секунды, а другой с LCP 3.5 — первый будет выше.

Инструменты для мониторинга: что использовать в 2025 году

Вот мой рабочий набор. Проверено на сотнях проектов.

Бесплатные инструменты:

1. PageSpeed Insights — https://pagespeed.web.dev/?hl=ru

Показывает Field Data (реальные данные от пользователей Chrome) и Lab Data (тестирование в лаборатории). Даёт конкретные рекомендации. Единственный минус: проверяет только одну страницу за раз.

2. WebPageTest — https://www.webpagetest.org/

Самый мощный бесплатный инструмент. Waterfall-диаграмма, тестирование из разных географических точек, эмуляция медленных сетей (3G, 4G). Позволяет сравнить два сайта side-by-side на видео.

3. Search Console → Core Web Vitals — https://search.google.com/search-console/

Официальный отчёт от Google с данными CrUX. Показывает, как реальные пользователи видят Ваш сайт, разбивка по группам URL. Это ваш главный ориентир — именно эти данные Google использует для ранжирования.

4. Chrome DevTools → Lighthouse

Встроен в Chrome (F12 → вкладка Lighthouse). Даёт оценку по 5 категориям: Performance, Accessibility, Best Practices, SEO, PWA. Удобен для быстрой локальной проверки.

5. GTmetrix — https://gtmetrix.com/

Комбинация Lighthouse и WebPageTest. Показывает историю изменений, если тестируете регулярно. Есть бесплатный план.

Платные инструменты (если серьёзно):

1. SpeedCurve — от $20/месяц

Continuous monitoring. Отслеживает Core Web Vitals 24/7, алерты при деградации, сравнение с конкурентами.

2. Calibre — от $45/месяц

Специализируется на performance budgets и регрессионном тестировании. Интегрируется в CI/CD.

3. DebugBear — от $15/месяц

Фокус именно на Core Web Vitals. Удобные дашборды, API для автоматизации.

Мониторинг инфраструктуры:

Uptime Robot — бесплатный uptime monitoring. Google не любит недоступные сайты, поэтому важно отслеживать даунтайм.

Pingdom / StatusCake — проверка TTFB из разных локаций. Помогает выявить проблемы с конкретными регионами.

Мой совет: Начните с бесплатных инструментов. Проверяйте сайт раз в неделю через PageSpeed Insights и WebPageTest. Когда трафик вырастет до 100K+/месяц и каждая десятая доля секунды будет давать тысячи рублей выручки — переходите на платный мониторинг.

Заключение: инфраструктура — это не расходы, а инвестиции

Вот что важно понять. Core Web Vitals — это не просто метрики для галочки. Это user experience, переведённый в цифры. Когда пользователь ждёт загрузки 3 секунды, он не думает "ой, у них медленный JavaScript". Он думает "к чёрту этот сайт" и уходит к конкурентам.

60-70% проблем с Core Web Vitals решаются на уровне сервера, а не кода. Это TTFB, это кэширование, это CDN, это оптимизация базы данных. Фронтенд-разработчик может написать идеальный React-код, но если сервер думает две секунды перед отдачей HTML, всё бесполезно.

Инвестиции окупаются быстро. Кейс выше показал ROI за 3 недели. Почему? Потому что каждая секунда задержки — это минус 20% конверсии. Исследования показывают: ускорение на 0.1 секунды даёт +1-8.4% к конверсии в зависимости от ниши. Для e-commerce с оборотом 5 млн/месяц это 50-420 тысяч дополнительной выручки.

С чего начать прямо сейчас:

1. Запустите чек-лист из статьи — 20 минут, и Вы увидите узкие места

2. Если TTFB > 800 мс — миграция на VPS или настройка кэширования

3. Если нет CDN — подключите бесплатный план G-Core Labs или NGENIX

4. Если PageSpeed Insights показывает красные цифры по изображениям — включите WebP через Image CDN или плагин

Не ждите, пока Google окончательно задавит Вас в выдаче. Page Experience — это уже не будущее, это настоящее. Сайты с хорошими Core Web Vitals получают приоритет при прочих равных, и разрыв будет только увеличиваться.

Полезные ссылки:

• Справка Google Search Console о Core Web Vitals

• PageSpeed Insights

• WebPageTest — руководство

• Настройка Redis для WordPress

• Включение HTTP/3 в Nginx

• Сравнение CDN для России

• Кейс: +30% конверсии через оптимизацию за 2 секунды

Яндекс рекомендации
https://yandex.ru/adv/partners/usability_desktop

Рекомендация: сократить время загрузки до 5 секунд. Пользователи ожидают мгновенного ответа.

Kissmetrics https://blog.click.ru/growthhacking/kak-skorost-zagruzki-sajta-vliyaet-na-konversiyu-i-prodazhi/

• 47% ожидают загрузку менее 2 секунд

• 79% довольных рекомендуют сайт другу

• 44% обращаются к другому источнику если недовольны

Сводная таблица ключевых цифр:

Я видел десятки проектов, которые поднялись на 10-15 позиций просто за счёт оптимизации инфраструктуры. Без новых ссылок. Без переделки контента. Просто потому, что сайт стал быстрым.

P.S. Если статья оказалась полезной — поделитесь своим опытом в комментариях. Какой TTFB у вашего сайта? Проваливаете ли Core Web Vitals? Буду рад обсудить конкретные кейсы и помочь советом.