Ситуация до проекта
Региональный каталог медицинской лаборатории объединял около 300 тысяч SKU и 3–4 тысячи услуг. Доступность, цены, адресация и другие параметры зависели от региона, поэтому количество уникальных вариантов страниц приближалось к миллиону.
Из-за SEO-требований отдельные страницы должны были содержать до 500–600 услуг без классического разбиения каталога на страницы.
Бизнес-задача
Классический подход с полной HTML-копией каждой страницы создавал бы огромный файловый кеш со сложной инвалидацией и обновлением. Одновременно тяжёлые листинги нагружали базу данных, backend, сеть и браузер: размер HTML отдельных страниц до оптимизации доходил примерно до 8 MB.
Что терял бизнес
Пациент дольше ждал каталог, а система повторно тратила ресурсы на получение цен, построение карточек и формирование большого документа. Простой рост full-page cache переносил проблему в файловую систему и усложнял актуализацию региональных данных.
Цели проекта
Ускорить загрузку большого регионального каталога без хранения миллиона полных HTML-копий, сохранить необходимый для SEO контент и сделать архитектуру производительности управляемой на уровне данных, запросов, кеша, разметки и браузера.
Решение
- Разделили данные по характеру изменения и стоимости получения вместо единого кеша полной страницы.
- Реализовали специализированную логику кеширования каталога и региональных параметров.
- Вынесли получение цен в отдельный кеширующий контур.
- Проанализировали и оптимизировали запросы, участвующие в построении каталога.
- Сократили первоначальную HTML-разметку карточек услуг и стоимость большого DOM.
- Перенесли подходящие пользовательские взаимодействия на frontend без заявления о конкретной SPA/SSR/CSR-архитектуре.
Производительность на каждом уровне
Кешируем данные, а не миллион копий HTML
Маленькая карточка × 600
Большой DOM · parsing · rendering
Конечный размер требует подтверждения
Подтверждены приблизительный масштаб и ускорение загрузки примерно в 5 раз. Схемы показывают принцип решения; конечный размер HTML, число SQL-запросов и конкретная технология кеша не заявляются без исходных измерений.
Быстрый сайт — это не кнопка «включить кеш»
При сотнях тысяч SKU, тысячах услуг, региональных ценах и примерно миллионе вариантов страниц производительность зависит от всей цепочки: данные → база данных → кеш → backend → HTML → браузер.
Оптимизация улучшила техническое качество страниц при сохранении SEO-требования к большому объёму доступного на странице каталога. Влияние на позиции и органический трафик не заявляется без данных поисковых систем.
Архитектура
Структура каталога и медленно меняющиеся данные используют долгоживущий слой кеша. Региональная доступность и параметры обрабатываются специализированным слоем. Цены кешируются отдельно. Backend собирает страницу из повторно используемых данных, а frontend выполняет подходящую интерактивную работу локально.
Конкретная внутренняя архитектура, серверная инфраструктура, конфигурация кеша и реальные SQL-запросы не раскрываются.
Этапы реализации
Работа охватила анализ формирования страницы, разделение кешируемых данных, оптимизацию запросов, отдельную стратегию для цен, сокращение разметки карточек и перенос подходящей логики на клиентскую сторону. Lazy loading не мог быть единственным решением, поскольку большой объём содержимого должен был оставаться доступным в HTML по требованиям SEO-проекта.
Результаты в цифрах
- ≈300 000 SKU
- ≈3 000–4 000 услуг
- ≈1 000 000 региональных страниц
- до 500–600 услуг на странице
- до ≈8 MB HTML до оптимизации
- ≈×5 ускорение загрузки
Технический уровень
Инструменты
- Highload-разработка
- Кастомное кеширование
- Кеширование цен
- Оптимизация SQL
- Frontend optimization
- HTML optimization
- Web Performance
Как измеряли результат
Подтверждено, что загрузка страниц была ускорена примерно в 5 раз. Какая именно метрика использовалась — серверная генерация, TTFB, DOMContentLoaded, Load, LCP или пользовательское время — требует уточнения. Конечный размер HTML, показатели SQL и Core Web Vitals пока не предоставлены.
Кому подходит аналогичное решение
Крупным проектам на 1С-Битрикс с сотнями тысяч позиций, региональными ценами, тяжёлыми листингами и SEO-ограничениями, где стандартного full-page cache уже недостаточно.
Вопросы по решению
Почему нельзя было просто включить композитный режим?
При примерно миллионе вариантов страниц кеш полной HTML-страницы сам создаёт нагрузку на диск, инвалидацию и обновление. Требовалось определить оптимальный уровень кеширования для разных типов данных.
Почему не загрузить остальные услуги при прокрутке?
В проекте действовало SEO-требование доступности большого объёма каталога на странице. Поэтому производительность улучшали без простого удаления необходимого содержимого из первоначального документа.
Использовались Redis или Memcached?
Конкретная технология кеша не раскрывается до подтверждения. Кейс описывает архитектурный принцип, а не неподтверждённый продукт.
Ускорение повысило позиции сайта?
Такое утверждение не делается без данных Search Console и согласованной методики сравнения.