Автосалон: 20 000 фото машин в месяц и почему сайт на конструкторе это не тянет

MAATRIX

Каждая машина в наличии — это не одно фото, а серия: экстерьер с восьми ракурсов, салон, панель приборов, багажник, шины, возможно короткое видео обзора. Умножьте на десятки автомобилей, которые заезжают и уезжают за месяц, и цифра 20 000 фото перестаёт быть преувеличением — это рабочая реальность среднего автосалона с оборотом в пару сотен машин. Проблема в том, что сайт на конструкторе, который прекрасно справлялся с витриной на 200 карточек, начинает сыпаться именно на этом объёме — не потому что дизайн плох, а потому что у тарифа есть потолок по месту и трафику, в который вы упираетесь физически.

Почему у автосалона фото — это не десятки, а тысячи

Логика фотографа в автобизнесе сильно отличается от логики интернет-магазина одежды, где на карточку хватает трёх кадров. Машина — это дорогая покупка, и покупатель перед визитом хочет рассмотреть её со всех сторон: не одну "витринную" фотографию, а полный обход. Стандартный минимум для карточки — это уже 10-15 кадров: капот, багажник, четыре угла кузова, салон спереди и сзади, панель приборов, одометр, диски и резина отдельно, иногда царапины и сколы крупным планом для честности сделки. Если в наличии одновременно стоит 100-150 машин и оборот идёт активно — старые продаются, новые поступают, — счётчик новых файлов легко доходит до тех самых 20 000 в месяц, о которых говорит заголовок. Это ориентировочная цифра, у конкретного салона она будет своя в зависимости от размера стока и глубины съёмки, но порядок величины именно такой: не сотни, а тысячи файлов еженедельно.

К этому добавляется ещё одна деталь, которую редко считают заранее: фото не живут вечно на сайте в исходном виде. Машина продалась — карточку снимают с публикации, но архив снимков часто хочет остаться (для истории, для юридической подстраховки по состоянию авто на момент продажи, для повторного использования если машина вернулась по трейд-ину). То есть растёт не только "витрина", но и архив рядом с ней, а тариф конструктора считает место по общему объёму, а не только по опубликованному.

Где именно упирается конструктор

У площадок для самостоятельного создания сайтов почти всегда трёхуровневая система ограничений, и для автосалона узким местом становится не дизайн и не функциональность, а инфраструктурные лимиты тарифа:

• Хранилище. Тариф даёт фиксированный объём (условно — от нескольких гигабайт на входных планах до пары десятков на старших). Исходники с зеркалки или хорошего телефона весят по несколько мегабайт каждый; после автоматического сжатия конструктором на сайт может ложиться меньше, но исходники и превью для галереи всё равно накапливаются. При стабильном притоке в тысячи фото в месяц лимит вычерпывается быстрее, чем кажется на старте.
• Трафик отдачи. Каждый визит на страницу с 15 фото машины — это 15 загрузок картинок с сервера конструктора клиенту. При живой посещаемости (а карточки авто как раз хорошо индексируются и приводят трафик из поиска) месячный лимит трафика на тарифе исчерпывается, и либо сайт начинает тормозить, либо площадка настойчиво предлагает перейти на тариф выше.
• Обработка при загрузке. Массовая заливка сотен фото за один присест (после съёмочного дня) через веб-интерфейс конструктора — это не то, для чего он проектировался. Интерфейс рассчитан на владельца небольшого лендинга, который добавляет карточки по одной, а не на менеджера, заливающего партию из 150 файлов между делом.
• Скорость отдачи изображений. Даже если место и трафик формально укладываются в лимит, на верхней границе тарифа галереи начинают открываться заметно медленнее — конструктор не даёт вам управлять кэшированием или CDN тоньше, чем это заложено в тариф.

Итог предсказуем: вы упираетесь не в "мы плохо сделали сайт", а в потолок инфраструктуры, который был рассчитан на витрину другого масштаба. И следующий шаг конструктора — предложить тариф выше, часто с ценником, который неприятно удивляет, когда вы уже привязаны к платформе и переносить каталог с нуля не хочется.

Что меняется на своём сервере

Собственный сервер под сайт-каталог решает эту проблему не тем, что "там всё бесплатно", а тем, что вы платите за реальные ресурсы, а не за пакет с искусственным потолком. У вас есть диск нужного объёма (и его можно докупить/расширить, когда каталог вырос, без миграции на другой "тариф"), полоса на отдачу трафика без месячного лимита в привычном для конструкторов виде, и — что важнее всего для 20 000 фото в месяц — полный контроль над тем, как обрабатываются и отдаются изображения.

Конкретно это выглядит так:

• Место считается вами, а не тарифной сеткой. Условный расчёт: если после оптимизации для веба одно фото весит в среднем несколько сотен килобайт (это сильно зависит от разрешения и формата — ориентир, не измеренная величина), то 20 000 фото в месяц — это единицы-десятки гигабайт нового объёма ежемесячно. За год с учётом архива старых карточек набегает уже заметный том, но это вопрос размера диска, который вы выбираете сами, а не фиксированного лимита, который надо выпрашивать у площадки повышением тарифа.
• Обработка изображений — под вашим контролем. На своём сервере вы ставите пайплайн сжатия и генерации превью (например, через imagemagick или sharp в связке с вашей CMS/сайтом), который автоматически создаёт несколько размеров под разные точки использования: миниатюра в каталоге, среднее фото в галерее карточки, полноразмерный кадр по клику. Конструктор такую гибкость либо не даёт вообще, либо даёт в урезанном виде.
• Массовая заливка — по протоколу, а не через веб-форму. Фотограф или менеджер сбрасывает папку с 150 кадрами по rsync или через SFTP-клиент прямо в директорию сайта или в очередь на обработку — это минуты, а не ручная загрузка по одной картинке через интерфейс конструктора.
• CDN настраивается под вашу нагрузку, а не под усреднённый тариф. Раздачу статики (все те фото) можно вынести на CDN перед сервером — тогда сам сервер обслуживает только динамику (поиск по каталогу, формы заявок), а тяжёлые картинки летят с ближайшей к посетителю точки. Это разбирали отдельно в статье про настройку CDN для сайта — для галереи из тысяч фото такая связка обычно и есть правильная архитектура.

Технический костяк каталога на своём сервере

Если разложить связку на компоненты, для автосалона на 100-150+ машин в наличии типичная схема выглядит так:

Загрузка фото → директория /storage/cars/{vin}/  
  → скрипт обработки (imagemagick/sharp): 
      original → resize 1600px, resize 800px, resize 320px (thumb) → webp/avif
  → CMS/сайт отдаёт нужный размер под контекст (карточка/галерея/полноэкран)
  → nginx как reverse proxy + кэш статики
  → CDN перед сервером для отдачи изображений

Практические моменты, которые стоит продумать заранее:

• Структура хранения по VIN или ID машины, а не по дате съёмки — так проще архивировать и находить фото конкретного авто, когда карточка снята с публикации, но снимки нужно поднять (гарантийный спор, повторная продажа после трейд-ина).
• Формат webp/avif вместо голого jpeg для отдаваемых на сайт версий — при сопоставимом визуальном качестве вес файла заметно меньше, что напрямую снижает нагрузку на диск и трафик. Это одна из тех настроек, которую конструктор либо не даёт менять, либо включает выборочно.
• Много мелких файлов — отдельная головная боль для диска, если её не учесть на старте: тысячи мелких изображений создают повышенную нагрузку на файловую систему при бэкапах и обходах каталога. Мы разбирали этот эффект в статье почему миллион мелких файлов убивает диск — для фотокаталога это значит: продумать ротацию старых архивов и не держать вечно на быстром диске то, что не показывается на сайте прямо сейчас.
• Бэкап каталога — отдельно от бэкапа базы данных. Фото — это основной объём, и снимать их полной копией каждую ночь избыточно; разумнее инкрементальный бэкап (rsync с --link-dest или аналогичный механизм) плюс отдельное холодное хранилище для архива снятых с продажи машин.
• Мониторинг места на диске с запасом, потому что рост каталога у автосалона неравномерный: весной и в сезон обновления модельного ряда фотосъёмок больше, чем зимой. Лучше держать буфер по свободному месту и алерт на его исчерпание, чем узнавать о переполненном диске от менеджера, у которого не загружаются новые фото.

Сколько ресурсов на самом деле нужно

Не нужно сразу брать сервер "с запасом на вырост в десять раз" — это переплата за ресурсы, которые год простоят незадействованными. Для сайта-каталога автосалона с несколькими тысячами активных карточек и десятками тысяч фото в архиве обычно достаточно средней конфигурации VPS: несколько ядер CPU (обработка/ресайз фото — не самая тяжёлая по CPU задача, но при пакетной загрузке в 150+ кадров сразу нагрузка кратковременно подскакивает), оперативной памяти с запасом под кэш nginx и работу CMS, и главное — диска, объём которого вы прицельно рассчитываете под свой темп съёмки, а не подгоняете под чужую тарифную сетку.

Если сайт вырастает дальше — например, автосалон открывает вторую площадку и объединяет каталоги, или трафик из поиска резко растёт после сезонной рекламной кампании — переезд на более мощный тариф или выделенный сервер не требует переноса всей платформы, потому что вы уже управляете инфраструктурой напрямую. Что входит в конфигурацию под по-настоящему высоконагруженный сайт и как считать её стоимость, подробно разобрано в статье про выделенный сервер для высоконагруженного сайта — полезно держать в голове как ориентир следующего шага, даже если сейчас хватает обычного VPS.

Миграция с конструктора: что учесть заранее

Перенос каталога — это не разовое действие "скачал архив, залил на новый сервер", особенно если сайт уже проиндексирован поисковиками и приводит живой трафик на карточки машин. Несколько вещей, которые стоит спланировать до переезда, а не после:

• Экспорт данных с конструктора. У большинства площадок есть выгрузка каталога товаров/карточек в CSV или похожем формате, но фото часто нужно будет скачивать отдельно — прямыми ссылками или через встроенный экспорт медиатеки, если он есть. Стоит сделать это заранее и проверить, что все файлы действительно скачались, а не только часть.
• Сохранение URL-структуры или грамотные редиректы. Если карточки машин на конструкторе уже проиндексированы Google и Яндексом, переезд на новые адреса без редиректов 301 обнулит накопленную видимость в поиске. Это стандартная, но легко забываемая часть переезда сайта — общие принципы разобраны в материале про перенос сайта на новый VPS без простоя.
• Переключение DNS с минимальным окном простоя. Автосалон не может позволить себе сутки "сайт недоступен" — заявки с сайта конвертируются в звонки прямо сейчас. Разумный порядок: развернуть новый сайт на сервере, полностью его протестировать по отдельному домену/IP, и только потом переключать DNS с коротким TTL.
• Параллельная работа старой и новой версии на переходный период, чтобы менеджеры салона успели привыкнуть к новому интерфейсу загрузки фото до того, как старый инструмент отключат окончательно.

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

Частые вопросы