Покупатели уходят
Если каталог или корзина грузятся по несколько секунд, часть посетителей не дожидается загрузки страницы и закрывает вкладку. С телефона уходят ещё чаще.
Определяем, где и почему сервис тормозит: тяжёлые изображения и видео, неоптимизированный код, устаревшее ядро или модули, тяжёлые запросы к базе, иногда — вирусы или майнеры. Убираем эти узкие места: правим код и настройки, настраиваем кэширование, при необходимости — Elasticsearch и очереди. Эффект сверяем замерами до и после.
Цена медленной загрузки
Это не только неудобство для каждого потенциального клиента. Это сорванные заказы, просадки по SEO и конверсии — и в итоге меньше выручки с того же трафика.
Если каталог или корзина грузятся по несколько секунд, часть посетителей не дожидается загрузки страницы и закрывает вкладку. С телефона уходят ещё чаще.
Человек уже на ресурсе, но из‑за долгой загрузки не оформляет заказ и не оставляет заявку. Трафик есть, а заявок и заказов меньше, чем могло бы быть.
В Яндексе и Google тяжёлые страницы хуже держат позиции: поисковики учитывают скорость загрузки.
Что именно ускоряем
Идём от частого к редкому: сначала медиа и код, затем кэш, и только если нужно — очереди, поисковый движок и проверка на вредоносный код.
Сжимаем изображения, обрезаем до нужного размера, подбираем формат. С видео поступаем аналогично. Подключаем lazy load, чтобы тяжёлые файлы ниже по странице не мешали быстрому открытию первого экрана.

Разбираем, что именно тормозит при открытии страниц и ответах сервера: плохо написанный код, тяжёлые скрипты, запутанные доработки, устаревшее ядро или модули, тяжёлые запросы к базе. Упрощаем и правим так, чтобы ресурс отвечал быстрее — без переписывания всего проекта, если в этом нет нужды.

Настраиваем кэширование страниц и данных, чтобы повторные запросы не выполняли одну и ту же тяжёлую работу заново. Это один из самых быстрых способов ускорить отдачу на уже работающем ресурсе.

Если ситуация того требует — выносим тяжёлые фоновые задачи в очереди вроде RabbitMQ, а поиск по большому каталогу — в Elasticsearch или OpenSearch. Не ставим это «на всякий случай»: только когда без этого задержки не снять.

Иногда ресурс тормозит не из‑за архитектуры, а из‑за вредоносного кода или скрытого майнинга на сервере. Проверяем и это: если заражение есть, сначала чистим, потом уже говорим об оптимизации.

Типичные причины
Обычно виноваты не «сайт в целом», а конкретные вещи: тяжёлые медиа, плохо написанный код и запросы к базе, отсутствие кэша, иногда — вирусы. Ниже — три самых частых случая.
Страница долго открывается, потому что медиа слишком большие. Сжимаем, обрезаем, ставим lazy load, настраиваем загрузку скриптов.
Сервер долго отвечает даже на простых страницах. Разбираем код и запросы к базе: какие запросы слишком тяжёлые и неоптимизированные, какие модули и скрипты отрабатывают дольше, чем могли бы.
Настраиваем кэширование, чтобы не обрабатывать одно и то же на каждый запрос. Очереди и Elasticsearch подключаем только если без них не обойтись. Отдельно проверяем вирусы и майнеры.
По ссылке можно сделать только предварительную оценку. Чтобы найти реальную причину и ускорить ресурс, нужны доступ к коду и к серверу. Опишите коротко проблему — скажем, что потребуется для начала работ.
Оставить заявку на ускорение
Как работаем
Замеряем скорость загрузки, смотрим логи сервера и код: тяжёлые картинки и видео, запросы к базе, скрипты, кэш, при подозрении — вирусы и майнеры.
Сначала то, что быстрее даст результат: медиа, код и запросы, кэш. Очереди и Elasticsearch — только если без них не обойтись. План работ фиксируем до старта.
Правим поэтапно. Ресурс продолжает принимать заявки и заказы. После каждого этапа снова замеряем скорость.
Оставляем рекомендации по поддержке, чтобы скорость не откатилась после новых доработок или тяжёлых интеграций.
Нет. Картинки часто дают быстрый эффект, но причина тормозов может быть глубже: в коде, в запросах к базе, в настройках сервера или в заражении. Сначала находим источник, потом уже правим.
Часто да. У многих ресурсов за годы накопился технический долг: срочные доработки, устаревшие модули, костыли под разовые задачи. Такое обычно правят точечно. Но бывают ситуации, когда оптимальнее переработать ресурс целиком: чинить старое выходит дороже и почти без смысла. Об этом скажем сразу. Но решение всегда остается за вами.
Да. Берём и коробочные CMS, и кастомные сервисы. Стек важен, но план работ строим не от названия технологии, а от того, что тормозит работу именно вашего ресурса.
Краткое описание проблемы и доступы к проекту. Без этого можно дать лишь предварительную оценку.
Оставьте контакты и коротко опишите проблему: каталог, поиск, кабинет, обмен с 1С. Ведущий инженер свяжется и предложит план работ.