Содержание10
- Сколько вы теряете: цифры влияния скорости на бизнес
- Как измерить скорость: инструменты и что они показывают
- Причина №1: хостинг и сервер — почему TTFB «плывёт»
- Причина №2: тяжёлые картинки, шрифты и «лишний» код
- Особенности CMS: где искать типовые тормоза
- Как понять, что ускорение сработало: метрики до и после
- Частые ошибки: что ломает скорость при «оптимизации»
- Когда брать помощь: что делает техподдержка сайта
- Частые вопросы
- Источники
Медленный сайт теряет деньги: каждая лишняя секунда загрузки снижает конверсию на 4,42% по данным Portent 2024. Проблема чаще не в «плохом коде», а в накопившихся мелочах — неоптимизированных изображениях, устаревшем хостинге, лишних плагинах. Статья даёт пошаговую диагностику: найдёте узкое место за 20 минут, получите приоритетный план исправления.
Сколько вы теряете: цифры влияния скорости на бизнес
Знаете ли вы, сколько заявок ушло к конкурентам, пока грузилась ваша страница? Google фиксирует порог внимания пользователя: при загрузке до 2,5 секунд LCP (Largest Contentful Paint) — показатель входит в состав Core Web Vitals — страница получает зелёную зону. При 4 секундах посетитель начинает уходить, при 6 — уходит половина.
Разница между мобильными и десктопными пользователями критична. Сайт, загружающийся 3 секунды, теряет в 3 раза больше мобильных пользователей, чем за 1 секунду. Десктопная аудитория терпит дольше, но не значительно: порог отказа сдвигается лишь на 0,8 секунды.
С 2024 года Google использует скорость как фактор ранжирования напрямую через Core Web Vitals. Сайт в жёлтой или красной зоне по LCP, INP или CLS не получает штрафа в классическом смысле, но проигрывает в выдаче равноправному конкуренту с зелёными метриками.
Сайт, загружающийся 3 секунды, теряет в 3 раза больше мобильных пользователей, чем за 1 секунду.
Как измерить скорость: инструменты и что они показывают
Для 80% диагностики хватит бесплатного PageSpeed Insights от Google. Он измеряет Core Web Vitals и выдаёт приоритетный список правок. GTmetrix удобен для отслеживания динамики: сохраняет историю тестов и строит графики. WebPageTest — уровень разработчика: показывает водопад запросов, но требует интерпретации.
Четыре метрики, которые стоит знать:
| Метрика | Что измеряет | Хорошо | Плохо |
|---|---|---|---|
| TTFB | Время до первого байта | < 800 мс | > 1,8 с |
| LCP | Загрузка крупного контента | < 2,5 с | > 4 с |
| INP | Отклик на взаимодействие | < 200 мс | > 500 мс |
| CLS | Сдвиги вёрстки | < 0,1 | > 0,25 |
TTFB влияет на LCP: пока сервер не отдал первый байт, браузер не начинает рендерить страницу. INP заменил FID в метриках в марте 2024 года — он ловит не только первое взаимодействие, а все задержки в течение сессии.
Лабораторные данные PageSpeed эмулируют идеальное соединение. Полевые данные CrUX (Chrome User Experience Report) собирают с реальных устройств пользователей. Расхождение между ними — норма: ваш смартфон в метро и сервер Google в дата-центре — разные условия.
Причина №1: хостинг и сервер — почему TTFB «плывёт»
Хостинг определяет базовое значение TTFB. Для shared-хостинга в РФ норма — 400–800 мс. Если TTFB стабильно выше 1,2 секунды при пустой странице, причина в сервере, а не в коде.
Пять признаков, что хостинг — бутылочное горлышко:
- TTFB прыгает в разное время суток — «соседи» на shared забирают ресурсы
- PHP-версия ниже 8.0 — каждый мажорный релиз даёт 10–20% прироста скорости
- Отсутствует серверное кэширование — база данных гоняет одни запросы снова и снова
- Таблицы базы раздуты — логи, ревизии, спам-комментарии не чистились годами
- HTTP/2 отсутствует, HTTP/3 недоступен — мобильные пользователи страдают больше всего
База данных замедляет TTFB через медленные запросы и отсутствие индексов. Проверка простая: любой плагин профилирования покажет запросы дольше 100 мс. Их оптимизация — работа для специалиста, не для владельца сайта.
HTTP/3 ускоряет загрузку при мобильных сетях за счёт встроенного мультиплексирования и устойчивости к потерям пакетов. Переход с HTTP/1.1 на HTTP/2 даёт 20–30% выигрыша, HTTP/3 добавляет ещё 5–15% в нестабильных сетях.
Причина №2: тяжёлые картинки, шрифты и «лишний» код
LCP чаще всего страдает от изображений. Переход JPEG -> WebP сокращает размер файла на 25–35% при сопоставимом качестве. AVIF даёт ещё 20–30% поверх WebP, но пока не везде поддерживается. Стратегия: WebP как основной формат с fallback на JPEG для старых браузеров.
| Формат | Тип картинки | Сжатие vs JPEG | Поддержка |
|---|---|---|---|
| JPEG | Фото, градиенты | Базовый | Универсальная |
| WebP | Фото, прозрачность | 25–35% | 96%+ браузеров |
| AVIF | Фото, анимация | 50–60% | 85%+ браузеров |
| PNG | Скриншоты, UI | 5–10% (редко выгоден) | Универсальная |
Google Fonts тормозят страницу двумя способами: дополнительный DNS-запрос и блокировку рендеринга до загрузки шрифта. Решение — предзагрузка критичных начертаний (<link rel="preload">) и отказ от лишних весов. Локальные шрифты быстрее на 150–400 мс LCP.
CSS и JavaScript требуют минификации — удаления пробелов и комментариев — и объединения файлов. Но объединение устарело при HTTP/2: параллельная загрузка выигрывает у одного тяжёлого файла. Удаление неиспользуемого кода даёт больше эффекта, чем сжатие.
Кэширование на уровне браузера снижает повторный TTFB до нуля для статики. Настройка через .htaccess или панель хостинга — 5 минут работы, эффект на всех возвратных посетителях.
Ленивая загрузка (lazy loading) откладывает изображения за пределами viewport. Нативный атрибут loading="lazy" поддерживается всеми современными браузерами, не требует плагинов.
Особенности CMS: где искать типовые тормоза
WordPress доминирует по числу тормозов: конструкторы страниц вроде Elementor генерируют избыточный HTML, 15+ плагинов загружают свои скрипты на каждой странице, а «многофункциональные» темы тащат CSS под все возможные виджеты. Типовое решение — плагин кэширования. WP Rocket, W3 Total Cache, LiteSpeed Cache дают прирост LCP на 0,5–1,5 секунды при стандартных настройках.
1С-Битрикс предлагает композитный кэш, который работает как «статика для анонимов, динамика для авторизованных». Проблема: при неправильной настройке авторизованные пользователи получают устаревшие данные, а анонимы — сломанную персонализацию. Проверка — зайти в корзину в режиме инкогнито.
Joomla и Drupal страдают от избыточных модулей и неоптимизированных запросов к базе. ModX — от нестандартных сниппетов, написанных без индексов.
| CMS | Типовое узкое место | Плагин кэширования | Ожидаемый прирост LCP |
|---|---|---|---|
| WordPress | Конструктор страниц + лишние плагины | WP Rocket, LiteSpeed Cache | 0,5–1,5 с |
| 1С-Битрикс | Композитный кэш врёт | Стандартный композит + CDN | 0,3–0,8 с |
| Joomla | Модули без lazy loading | JCH Optimize | 0,4–1,0 с |
WordPress требует кэширования больше остальных: динамическая генерация каждой страницы при каждом запросе без кэша — архитектурная особенность, а не баг.
Пошаговая диагностика: чек-лист за 20 минут
Чек-лист разбит по усилиям и эффекту. Зелёные шаги — делайте сами. Жёлтые — с разработчиком. Красные — техподдержка берёт на себя.
Сжать изображения и включить lazy loading
Эффект высокий, 10 минут. Инструменты: Squoosh, TinyPNG, или плагин под вашу CMS.
Включить браузерное и серверное кэширование
Эффект высокий, 15 минут. Проверьте панель хостинга или установите плагин.
Обновить PHP до 8.1+ и проверить TTFB
Эффект средний, 30 минут. TTFB > 800 мс на пустой странице — сигнал к разговору с хостером.
Подключить CDN для статики
Эффект средний, 1 час. Критично, если аудитория географически разбросана.
Оптимизировать базу данных: индексы, очистка, медленные запросы
Эффект высокий, 2–4 часа. Требует специалиста.
Переход на VPS, рефакторинг кода, смена архитектуры
Эффект высокий, 1–2 недели. Полная перестройка.
Граница самостоятельной работы проходит между шагами 4 и 5. Оптимизация базы данных, настройка серверного кэширования и исправление «тяжёлого» кода требуют понимания архитектуры — ошибка стоит падения сайта.
Как понять, что ускорение сработало: метрики до и после
Оптимизация без замеров — это не оптимизация, а ритуал. Фиксируйте четыре метрики до начала работ: TTFB, LCP, INP, CLS. Записывайте из PageSpeed Insights и из CrUX — оба источника.
Сроки стабилизации отличаются. Кэш CDN обновляется за 24–48 часов. Данные CrUX обновляются за 28 дней — это накопительная статистика, не мгновенный снимок. Улучшение в PageSpeed Insights может не дать улучшения в CrUX, если реальные пользователи заходят с устаревших устройств или медленных сетей.
Оптимизация без замеров — это не оптимизация, а ритуал.
Когда улучшение в лабораторных данных не отражается в полевых, проверяйте географию аудитории и устройства. CrUX покажет, какой процент пользователей в зелёной зоне — цель не идеальная метрика, а рост этого процента.
Частые ошибки: что ломает скорость при «оптимизации»
Агрессивное кэширование ломает динамику: корзина показывает устаревшие товары, цены не обновляются после акции, персонализация «вылетает» для авторизованных. Правило: кэшируйте статику полностью, динамику — с осторожностью, никогда не кэшируйте страницы с персональными данными.
Плагины «всё в одном» для WordPress — типичная ловушка. Один плагин заменяет пять, но конфликтует с темой, дублирует функции уже установленных решений и в итоге замедляет сайт сильнее, чем ускоряет. Проверка: деактивируйте плагин, замерьте INP до и после.
Оптимизация без бэкапа — откат невозможен. Любое изменение на уровне сервера: обновление PHP, правка .htaccess, установка плагина кэширования — требует рабочей копии сайта.
Игнорирование мобильной версии — ошибка масштаба. 70% трафика в большинстве ниш — мобильный, но усилий на его оптимизацию уходит 30%. PageSpeed Insights по умолчанию показывает мобильные метрики — это не случайность, а приоритет Google.
Когда брать помощь: что делает техподдержка сайта
Техподдержка сайта берёт аудит скорости на себя: проверяет TTFB, LCP, INP, анализирует водопад запросов, выдаёт отчёт с приоритетами. Клиент получает не список задач, а понимание, что даст каждое действие и сколько стоит.
Разница между «починить картинки» и «комплексная оптимизация» — в глубине. Первое решает 20% проблемы за 2 часа. Второе включает аудит базы данных, настройку серверного кэширования, оптимизацию критичного пути рендеринга и валидацию через CrUX.
По скорости можно обещать конкретные метрики: снижение TTFB на X%, вывод LCP в зелёную зону. Нельзя обещать рост позиций в выдаче — Google использует сотен сигналов, скорость лишь один из них. SLA техподдержки фиксирует измеримые показатели, а не абстрактный «результат».
Если после самостоятельных шагов 1–4 TTFB остаётся выше 800 мс или LCP не входит в зелёную зону — проще делегировать. Диагностика занимает 1 день, базовая оптимизация — 1–2 дня, комплексная с валидацией — 1–2 недели.
Источники
- Portent — Site Speed and Conversion Rates — исследование влияния скорости на конверсию
- Google Developers — Core Web Vitals — официальная документация по метрикам
- Google Developers — WebP Study — исследование сжатия WebP vs JPEG
