Каталог вырос – и магазин начал заметно тормозить
Более мощный сервер может помочь, но сначала нужно понять, что именно перестало масштабироваться: база, фильтры, поиск, кеш, импорт, изображения или JavaScript.
БОЛЬШЕ ТОВАРОВ ≠ ОБЯЗАТЕЛЬНО МЕДЛЕННЕЕ
Рост каталога часто не создаёт проблему – он просто проявляет уже существующее слабое место
Пока в магазине 500 товаров, неэффективный запрос, плохо построенный фильтр или постоянный пересчёт характеристик могут оставаться незаметными. При 20 000–50 000 товаров та же архитектура начинает стоить уже секунды.
500 товаров · категория открывается быстро
20 000 товаров · те же операции занимают секунды
ЧТО ИЗМЕНИЛОСЬ
Важно понять не сколько стало товаров, а сколько работы выполняется для каждого посетителя
Посетителю по-прежнему нужно показать первые 24 товара, цену, наличие, фильтры и изображения. Но сервер может каждый раз перерабатывать значительно больше данных, чем реально требуется для вывода этой страницы.
Найти нужные 24 товара и необходимые данные
Пересчитать весь каталог, характеристики, остатки и фильтры перед каждым показом
ПЕРВОЕ РАЗДЕЛЕНИЕ
Сначала выясните – пользователь ждёт сервер или браузер
Долго ждём первый HTML
База данных, PHP/приложение, кеш, API, сервер.
HTML уже пришёл, но сайт ещё «думает»
JavaScript, изображения, DOM, виджеты, сторонние скрипты.
TTFB
Если долго не приходит первый ответ, сначала смотрите серверную цепочку
Браузер → сервер
Начало получения HTML
НЕ ГОВОРИТЕ ПРОСТО «САЙТ МЕДЛЕННЫЙ»
Симптом уже подсказывает, где искать причину
Сервер, база, приложение, общий кеш
Выборка товаров, фильтры, сортировка
Поисковый механизм и индекс
Фоновые задачи, CPU, база, блокировки
JavaScript, DOM, сторонние скрипты
КАТЕГОРИИ – ЧАСТО ПЕРВОЕ УЗКОЕ МЕСТО
Простая на вид страница каталога может выполнять десятки операций
ФИЛЬТРЫ – НЕ ТОЛЬКО SEO
Красивый фасетный интерфейс может заставлять сервер пересчитывать огромный объём данных
Чёрные – 412 · Белые – 203 · 128 GB – 376 · В наличии – 503
Чем больше характеристик, тем важнее способ их хранения и выборки
Бренд, цвет, размер, материал, мощность, объём, совместимость, серия и десятки других свойств сами по себе нормальны. Проблема появляется, если каждая комбинация требует большого количества тяжёлых операций.
Бренд
Цвет
Размер
Материал
Мощность
Объём
Совместимость
МНОГО МЕЛКИХ ЗАПРОСОВ
Страница может быть медленной не из-за одного тяжёлого запроса, а из-за сотен повторяющихся
24 ТОВАРА
ПОИСК – ОТДЕЛЬНАЯ СИСТЕМА
Если медленный только поиск, не нужно оптимизировать весь магазин
При десятках тысяч товаров поиск может учитывать название, артикул, бренд, характеристики, синонимы и опечатки. Это уже существенно сложнее обычного фильтра по одной колонке.
ПОЛЬЗОВАТЕЛЬ ВВОДИТ
«самсунг с24»
ГЛУБОКАЯ ПАГИНАЦИЯ
Первая страница категории и страница №800 могут стоить серверу совершенно разных денег
0,5 с
6 с
Такой результат указывает уже не на общую «медленную CMS», а на конкретный способ получения глубокой страницы каталога.
КЕШ – КЛЮЧЕВОЙ СЛОЙ
Не обязательно генерировать одну и ту же страницу заново для каждого посетителя
КЕШ МОЖЕТ БЫТЬ – И НЕ РАБОТАТЬ
Если каждое изменение остатка уничтожает кеш всей категории, он почти бесполезен
Кеш страницы и кеш данных – разные инструменты
Статические ресурсы
Доставка и кеш статических данных
Готовый HTML
Результаты дорогих вычислений и запросов
ФОНОВЫЕ ПРОЦЕССЫ
Импорт остатков и цен может тормозить покупателей, хотя они вообще не связаны с импортом
ПРОВЕРЬТЕ РАСПИСАНИЕ
Несколько нормальных фоновых задач могут вместе создать серьёзную нагрузку
Резервная копия
Экспорт товаров
Обновление остатков
Генерация товарного фида
ВНЕШНИЕ ЗАВИСИМОСТИ
Карточка магазина не должна становиться такой же медленной, как чужой API
ВНЕШНИЕ СЕРВИСЫ
CRM
Поставщик
Отзывы
Платёжный сервис
Для части данных безопаснее использовать локальное хранение, кеш или фоновое обновление, а не ждать удалённую систему при каждом открытии страницы.
ИЗОБРАЖЕНИЯ
Быстрый backend не спасёт страницу, которая загружает десятки мегабайт фотографий
Изображение 4000×3000 px
Используется в карточке шириной 250 px.
Размер изображения соответствует реальному отображению
Lazy loading полезен ниже первого экрана, но не должен задерживать главный контент
Главное изображение нужно загрузить своевременно
Десятки товарных изображений можно загружать по мере необходимости
JAVASCRIPT
Сервер может ответить за 300 мс, а пользователь всё равно будет ждать
HTML получен за 300 мс
Выполняет JavaScript ещё несколько секунд
Меню, фильтры, корзина, чат, аналитика, рекомендации, варианты товара и сторонние виджеты конкурируют за основной поток браузера.
СТОРОННИЕ СКРИПТЫ
Они накапливаются по одному – а тормозят страницу уже все вместе
Вопрос для каждого скрипта
Должен ли он действительно загружаться до того, как пользователь сможет работать с магазином?
АДМИНКА – ОТДЕЛЬНЫЙ СЦЕНАРИЙ
Покупатели могут ничего не замечать, а сотрудникам приходится ждать список товаров по 15 секунд
Административная таблица может одновременно выводить изображения, остатки, варианты, категории, бренды, поставщиков и множество дополнительных полей. При большом каталоге это отдельная задача оптимизации.
ЖЕЛЕЗО ТОЖЕ ВАЖНО
Но покупать ресурсы нужно после понимания, во что именно упирается система
CPU
RAM
Диск
PHP workers
Соединения БД
CPU 20%, RAM 50%, а SQL выполняется 8 секунд?
Дополнительный процессор может не решить основную проблему.
«Купим VPS помощнее» – не полноценная стратегия масштабирования
Если стоимость одного запроса растёт вместе с каталогом, более дорогое оборудование лишь финансирует неэффективную архитектуру.
ТЕСТИРУЙТЕ ДВА СОСТОЯНИЯ
Быстрый запрос из кеша и медленный первый запрос могут быть одной и той же страницей
4,0 с
0,2 с
РЕАЛЬНЫЕ ПОЛЬЗОВАТЕЛИ
Быстро на мощном ПК владельца – ещё не значит быстро для покупателей
Мощный ПК · быстрый интернет
Недорогой Android · мобильная сеть
CORE WEB VITALS
Скорость нужно оценивать не одной абстрактной цифрой
До 2,5 с
Скорость появления основного содержимого.
До 200 мс
Отзывчивость интерфейса.
До 0,1
Визуальная стабильность.
СКОРОСТЬ И SEO
Не превращайте оптимизацию скорости в охоту за магическими 100 баллами
Скорость важна для SEO и пользовательского опыта, но идеальный технический показатель не заменяет полезность страницы, ассортимент, релевантность и другие факторы.
Главная бизнес-задача
Пользователь должен быстро открыть каталог, применить фильтр, выбрать товар, добавить его в корзину и оформить заказ.
НЕ ПРОВЕРЯЙТЕ ТОЛЬКО ГЛАВНУЮ
Главная может быть самой простой и самой быстрой страницей магазина
Главная
Категория
Фильтр
Карточка
Поиск
Корзина
Checkout
НАБОР ТЕСТОВ
Проверяйте реальные сценарии, а не «среднюю скорость сайта»
ИЗМЕРЯЙТЕ ДО И ПОСЛЕ
«Оптимизировали базу» – это не результат, если неизвестно, что изменилось
TTFB 2,8 с
TTFB 0,6 с
СНАЧАЛА ИСПРАВЛЯЕМ САМОЕ ДОРОГОЕ
Не имеет смысла экономить 50 KB CSS, если сервер генерирует страницу пять секунд
Сначала backend / база / кеш
Сначала JavaScript и клиентская часть
ПРАКТИЧЕСКАЯ МАТРИЦА
Симптом → направление проверки
Backend, база, кеш, API.
Каталог, фильтры, сортировка.
Поисковый индекс и алгоритм.
Способ выборки данных.
Сброс кеша.
Фоновые процессы и база.
JavaScript.
Административные запросы.
ЧЕК-ЛИСТ ВЛАДЕЛЬЦА
Что проверять, если магазин начал тормозить
ГЛАВНЫЙ ВЫВОД
Не начинайте с покупки сервера – начинайте с поиска самой дорогой операции
Найти медленный сценарий
Отделить сервер от браузера
Измерить
Найти самое дорогое узкое место
Исправить
Повторно измерить
Частые вопросы о скорости большого интернет-магазина
Почему магазин стал медленным после добавления большого количества товаров?
Само количество товаров не обязательно является причиной. С ростом каталога становятся заметнее тяжёлые запросы, фильтры, сортировка, поиск, пересчёты характеристик, синхронизация и проблемы кеширования.
Стоит ли сразу менять хостинг?
Не обязательно. Сначала нужно определить, действительно ли система упирается в CPU, память, диск или количество процессов. Тяжёлый запрос к базе более мощный сервер может лишь временно скрыть.
Что показывает TTFB?
Он показывает время до начала получения ответа от сервера и помогает отделить серверную задержку от последующей обработки страницы браузером.
Что проверять, если медленные только фильтры?
Запросы к базе, пересчёт доступных характеристик и количества товаров, хранение атрибутов, кеш результатов и сложность комбинаций.
Может ли кеш решить проблему большого каталога?
Да, но только при правильной стратегии. Нужно понимать, что кешируется, как долго живёт результат и какие изменения вызывают его очистку.
Почему сайт медленный только во время обновления остатков?
Массовые обновления активно используют базу данных, процессор и диск, а также могут инициировать пересчёты и сброс кеша.
Нужно ли проверять скорость только на главной?
Нет. Для магазина критичнее отдельно тестировать категории, карточки, фильтры, поиск, корзину, checkout и другие реальные сценарии.
Какие Core Web Vitals нужно контролировать?
LCP оценивает загрузку основного содержимого, INP – отзывчивость интерфейса, CLS – визуальную стабильность. Для хорошей пользовательской оценки ориентируются примерно на LCP до 2,5 с, INP до 200 мс и CLS до 0,1.
Что важнее – ускорить сервер или JavaScript?
Зависит от источника задержки. Если HTML приходит пять секунд, сначала нужен backend. Если сервер отвечает быстро, а интерфейс не реагирует, нужно анализировать JavaScript и основной поток браузера.
МАГАЗИН ЗАМЕДЛИЛСЯ ПОСЛЕ РОСТА?
Найдём реальное узкое место до покупки нового сервера
Проверим категории, фильтры, поиск, серверный ответ, запросы к базе, кеш, импорт, изображения и браузерную часть – и определим, где именно система перестаёт масштабироваться.