Медленный сайт похож на магазин с одной работающей кассой: товар хороший, цены нормальные, но часть людей смотрит на очередь и уходит. Они не пишут жалоб и не оставляют отзывов — их просто нет в отчётах. Поэтому потери от медленной загрузки трудно заметить и легко недооценить.
Скорость — не вопрос красивой оценки в Lighthouse. Это вопрос того, сколько оплаченных посетителей доходит до заявки.
Где скорость превращается в деньги
- Реклама. Вы платите за переход в момент клика. Если человек закрыл вкладку, не дождавшись страницы, деньги уже потрачены — и потрачены ни на что.
- Конверсия. Путь к покупке — это несколько загрузок подряд: каталог, карточка, корзина, оформление. Задержка на каждом шаге складывается, и до конца доходят не все.
- Поиск. Поисковые системы учитывают скорость и удобство страницы при ранжировании. Это не единственный и не главный фактор, но при прочих равных он работает на быстрый сайт.
- Инфраструктура. Неэффективный сайт требует более мощного сервера для той же посещаемости. Оптимизация запросов нередко обходится дешевле, чем переход на следующую конфигурацию.
Сколько это в рублях, зависит от ваших цифр, и чужая статистика тут не поможет. Зато посчитать можно самому: в системе аналитики сравните конверсию посетителей, у которых страница загрузилась быстро, и тех, у кого медленно. Арифметика простая: если магазин получает тысячу заказов в месяц, каждый потерянный на загрузке процент — это десять заказов. Умножьте на средний чек и на двенадцать месяцев — получится бюджет, в который должно уложиться ускорение.
Что измерять
«Сайт грузится нормально» — не измерение. Нужны цифры, и лучше те, которые описывают ощущения человека, а не работу сервера. Общепринятый набор — три показателя Core Web Vitals.
- LCP — когда появился главный элемент страницы: заголовок, крупное изображение, карточка товара. Отвечает на вопрос «загрузилось ли». Хорошим считается значение до 2,5 секунды.
- INP — как быстро страница откликается на нажатие. Отвечает на вопрос «работает ли». Хорошо — до 200 миллисекунд.
- CLS — насколько содержимое прыгает во время загрузки. Знакомая ситуация: целились в кнопку, а попали в баннер, который появился секундой позже. Хорошо — до 0,1.
К ним стоит добавить время ответа сервера: если первая порция данных приходит через секунду, уложить остальные показатели в норму будет трудно.
Важное различие — между лабораторными и полевыми данными. Lighthouse — инструмент проверки страниц, встроенный в браузер Chrome, — на ноутбуке разработчика с быстрым интернетом показывает, как сайт может работать. Данные реальных посетителей показывают, как он работает — на недорогом телефоне и в мобильной сети. Ориентироваться нужно на вторые, а проверять не одну главную страницу, а всю цепочку до заявки.
Где обычно теряется время
Сервер
Запросы к базе без индексов, отсутствие кэширования, страница, которая при каждом открытии собирается заново из сотни запросов. Симптом — долгий ответ ещё до начала загрузки картинок и скриптов. Сюда же относится перегруженный или слишком слабый хостинг.
Изображения
Причина, которую проще и дешевле всего исправить. Фотография с камеры, показанная в блоке шириной триста пикселей; старые форматы вместо WebP или AVIF; отсутствие размеров в разметке, из-за чего страница прыгает; загрузка сразу всех картинок, включая те, до которых посетитель не долистает.
Скрипты
Чаты, виджеты обратного звонка, счётчики, пиксели рекламных систем, карты. Каждый добавляли «на время», и по отдельности каждый невелик, а вместе они занимают процессор телефона на секунды. Сторонние скрипты опасны ещё и тем, что их скорость от вас не зависит.
Шрифты, кэш и сжатие
Шрифты с чужого сервера, пять начертаний там, где хватило бы двух. Статические файлы без заголовков кэширования, из-за чего браузер скачивает их при каждом визите. Отключённое сжатие. Для статики с хэшем в имени файла настройка в nginx занимает несколько строк:
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;
location /assets/ {
add_header Cache-Control "public, max-age=31536000, immutable";
}Скорость закладывается в начале
Ускорять готовый сайт можно, но это всегда дороже, чем сразу делать его быстрым. Решения, которые определяют скорость, принимаются на этапе проектирования: сколько весит страница, что отдаётся с сервера готовым, а что достраивается в браузере, какие сторонние сервисы действительно нужны, как устроено кэширование.
Скорость нельзя прикрутить в конце. В конце можно только убрать то, что мешает.
Поэтому при разработке сайтов и магазинов мы закладываем производительность с самого начала: скорость — такое же требование к странице, как внешний вид. Влияет на неё и выбор платформы — о нём в статье «На чём делать интернет-магазин».
Есть и вторая сторона: сайт не остаётся быстрым сам. Новый баннер, ещё один счётчик, выросшая база — и через год показатели уже другие. Скорость нужно не только сделать, но и держать. Полезно задать странице допустимый вес и проверять показатели после каждого заметного обновления.
С чего начать
- Измерьте ключевые страницы на мобильном устройстве: главную, каталог, карточку товара, оформление заказа. Запишите цифры.
- Посмотрите на ответ сервера. Если он медленный, начинать нужно с него: остальное не поможет.
- Разберитесь с изображениями: размеры, современные форматы, отложенная загрузка для всего, что ниже первого экрана.
- Пересмотрите сторонние скрипты. По каждому задайте вопрос, кто им пользуется и что будет, если его убрать.
- Включите сжатие и кэширование статических файлов.
- Сравните цифры с исходными и с конверсией за тот же период.
- Настройте регулярный контроль — разовый замер устаревает с первым же обновлением сайта. Для этого существуют сервисы мониторинга; у нас есть собственный — Website Director.
Первые пункты списка не требуют переписывать сайт и часто дают заметный результат. Если после них страницы всё ещё медленные, дело в архитектуре или в сервере — и это уже задача для планомерной работы над сайтом, а не для разовой правки.