Коротко. Сайт почти всегда тормозит по одной из семи причин: тяжёлые изображения, сторонние скрипты, медленный ответ сервера, отсутствие кэша, шрифты, раздутая вёрстка или слабый хостинг. Начинать нужно не с переписывания сайта, а с замера: он показывает, какая из причин ваша. На действующем сайте клиента на 1С-Битрикс оптимизация без смены платформы сократила блокировку отрисовки главной с 1 900 до 690–890 мс.
Медленный сайт не выглядит сломанным. Он открывается, всё на месте — просто посетитель несколько секунд смотрит на белый экран или на прыгающую вёрстку. Часть людей в это время уходит, и в отчётах это видно только как «высокий процент отказов» без очевидной причины.
Сначала замер, потом ремонт
Скорость сайта измеряют тремя показателями Core Web Vitals. Их используют поисковые системы, и они же лучше всего описывают, что чувствует посетитель.
- LCP — когда появляется основное содержимое страницы. Хорошо — до 2,5 секунды.
- INP — как быстро страница реагирует на нажатие. Хорошо — до 200 мс.
- CLS — насколько сдвигается вёрстка при загрузке. Хорошо — до 0,1.
Проверить свой сайт можно бесплатно в PageSpeed Insights. Смотрите на мобильную версию и на блок данных реальных пользователей, если он есть: лабораторная оценка при повторных запусках колеблется, и одно число ничего не доказывает. Сделайте три-четыре замера и смотрите на повторяющиеся замечания.
Семь причин и что с ними делать
| Причина | Как проявляется | Что помогает |
|---|---|---|
| Тяжёлые изображения | долго появляется главный экран | современные форматы, правильные размеры, отложенная загрузка |
| Сторонние скрипты | страница «задумывается» при нажатии | ревизия виджетов, загрузка после основного контента |
| Медленный ответ сервера | белый экран в начале загрузки | кэш, оптимизация запросов к базе |
| Нет кэширования | повторные визиты такие же медленные | кэш страниц и статических файлов |
| Шрифты | текст появляется с задержкой или «прыгает» | меньше начертаний, подгрузка без блокировки |
| Раздутая вёрстка | тяжёлая страница даже без картинок | сжатие, удаление неиспользуемого CSS и JS |
| Слабый хостинг | медленно всё и всегда | смена тарифа или площадки — последним шагом |
1. Изображения. Самая частая причина и самая дешёвая в исправлении. Фото с камеры весом в несколько мегабайт, показанное в карточке шириной 400 пикселей, — обычное дело на сайтах, где контент загружают менеджеры. Решение — автоматическое сжатие и перевод в WebP при загрузке, а не просьба «загружайте поменьше».
2. Сторонние скрипты. Онлайн-чаты, виджеты обратного звонка, пиксели рекламы, несколько систем аналитики. Каждый по отдельности лёгкий, вместе они занимают процессор телефона на секунды. Начинать стоит с ревизии: половину таких скриптов обычно никто не использует.
3. Медленный ответ сервера. Если страница собирается из десятков запросов к базе при каждом открытии, никакое сжатие картинок не поможет. Здесь работают кэш и оптимизация кода.
4–7. Кэш, шрифты, лишний код и хостинг обычно дают меньший эффект по отдельности, но вместе заметны. Хостинг мы меняем в последнюю очередь: переезд на более дорогой тариф часто маскирует проблему, а не решает её.
Как это выглядело на реальном сайте
Действующий сайт клиента на 1С-Битрикс: много лет контента, тяжёлая главная, несколько подключённых сервисов. Менять платформу клиент не хотел. Мы провели оптимизацию на текущей CMS и сравнили замеры до и после (август 2026 года):
| Показатель | Было | Стало |
|---|---|---|
| Запросов к базе на страницу | 62 | 1 |
| Работа PHP на запрос | 0,37 с | 0,19 с |
| Блокировка отрисовки | 1 900 мс | 690–890 мс |
| Работа главного потока | 17 400 мс | 4 900–7 700 мс |
| Главная по сети | 191 КБ | 57 КБ |
| Изображения главной | 37,6 МБ | 14,6 МБ |
Что не сработало, тоже стоит сказать. Первой идеей было отложить загрузку всех сторонних скриптов. Один из виджетов после этого перестал работать как нужно, и для него изменение мы откатили — он снова грузится сразу. Вывод простой: отложенная загрузка — не переключатель «для всего», каждый сервис проверяется отдельно, после изменения — сценарий целиком.
И ещё одна честная оговорка: заявки и позиции в поиске этой работой не измерялись, поэтому их мы не приводим. Скорость — условие, а не гарантия продаж.
С чего начать
- Замерьте главную и две-три самые посещаемые страницы в мобильной версии, по несколько раз.
- Посмотрите на изображения — это можно сделать и без разработчика: какого размера файлы на главной?
- Составьте список сторонних сервисов на сайте и отметьте, какими из них реально пользуются.
- Если после этого неясно, что тормозит, нужен разбор с доступом к серверу и коду.
Оптимизация скорости у нас стоит от 120 000 ₽: Core Web Vitals, изображения, кэш, отложенные скрипты — на текущей платформе, без редизайна. Если нужно сначала понять масштаб, начните с технического аудита — от 45 000 ₽. Полный пример с этим сайтом — в статье «Сайт за 100 000 ₽ vs 350 000 ₽ vs 700 000 ₽».
Частые вопросы
Почему PageSpeed каждый раз показывает разную оценку?
Лабораторный тест запускается на удалённом сервере в разных условиях, и оценка колеблется на несколько пунктов. Поэтому решения принимают по нескольким замерам и по данным реальных пользователей, а не по одному числу.
Можно ли ускорить сайт на конструкторе?
Возможности ограничены тем, что разрешает платформа: изображения и набор блоков вы контролируете, сервер и код — нет. Если скорость упирается в платформу, это один из поводов подумать о переезде.
Поможет ли переезд на другой хостинг?
Если сервер действительно слабый — да. Но чаще сайт тормозит из-за картинок, скриптов и кода, и на дорогом хостинге он будет тормозить так же.
Нужен ли редизайн, чтобы ускорить сайт?
Нет. Почти все причины из списка исправляются без изменения дизайна и без смены CMS.
Оригинал опубликован на verstalabs.ru.