PrestaShop – это не плагин к сайту, а отдельный движок магазина целиком. И ведёт он себя на хостинге не как визитка, а как программа, которой постоянно нужно место для разворота. Если у вас магазин с реальным каталогом – сотни товаров, у каждого по несколько фотографий, – то самый дешёвый тариф общего хостинга почти наверняка окажется ловушкой. Причём упрётесь вы не туда, куда ожидаете.
Обычно человек, выбирая тариф под магазин, смотрит на объём диска и лимит трафика. С PrestaShop эти две цифры – последнее, о чём стоит беспокоиться. Раньше всего заканчивается другое: оперативная память в тот момент, когда вы редактируете товар, и число файлов на аккаунте. Про них в тарифах либо пишут мелким шрифтом, либо не пишут вовсе.
Короткий ответ такой. Для витрины-заготовки или магазина на десяток позиций хватит приличного общего хостинга, где memory_limit реально поднимается хотя бы до 512 МБ. Для магазина с настоящим каталогом – от нескольких сотен товаров и выше – закладывайте либо старший тариф с честными лимитами, либо сразу VPS. Дальше разберём, почему именно так, и на чём спотыкаются чаще всего.
Магазин работает у покупателей и падает у вас
Первое, что удивляет новичка: витрина может прекрасно открываться у клиентов и валиться в тот момент, когда вы сами заходите её редактировать.
Собранная и закешированная витрина PrestaShop не так уж прожорлива – отдать посетителю готовую страницу товара движок умеет экономно. А вот админка живёт по другим правилам. Стоит зайти в редактирование товара с десятком комбинаций – размеры, цвета, варианты, – и PHP-скрипт разом тянет в память пол-магазина. Официальный минимум memory_limit у PrestaShop – 256 МБ, рекомендованное значение – 512 МБ, но на практике карточка товара с большим числом комбинаций способна упереться и в гигабайт. В баг-трекере движка таких историй хватает: человек поднимает лимит до 512 МБ, потом до 1024 МБ, и всё равно ловит Allowed memory size exhausted при сохранении товара.
Ошибка при этом выглядит пугающе: белый экран или строчка про исчерпанную память в логах, а снаружи посетитель видит 500-ю или похожий код. Каталог у покупателей при этом продолжает работать – тяжёлая операция была именно в админке, её никто, кроме вас, не запускал.
Есть и родственная мелочь, о которую спотыкаются на товарах с большим числом вариантов, – max_input_vars. Если комбинаций у товара много, форма редактирования просто не сохранится целиком, пока этот параметр не поднят до нескольких тысяч. В описании тарифа его обычно вообще не показывают, а обнаруживаете вы его в тот момент, когда часть характеристик после сохранения таинственно исчезла.
Про сам memory_limit и то, чем «выделенная память» на хостинге (PMEM) отличается от цифры, которую вы вписываете в настройки, у нас есть отдельный разбор. Здесь важно другое: под PrestaShop смотреть надо не на строчку memory_limit в тарифе, а на то, разрешит ли провайдер реально её поднять. На дешёвых тарифах её нередко режут сверху, и никакие ваши настройки выше потолка не прыгнут.
Со стороны провайдера это, кстати, выглядит логично. Один магазин, редактирующий товар с сотней комбинаций, способен на пару секунд занять столько памяти, сколько десяток обычных сайтов вместе. Ради этого лимит и ставят – откуда вообще берутся ограничения на общем хостинге, мы разбирали отдельно.
Главная ловушка – не место, а число файлов
А теперь про то, из-за чего PrestaShop заслужил у хостеров отдельную репутацию.
Представьте: магазин на пару тысяч товаров, диск занят на треть, трафик небольшой. И вдруг сайт перестаёт сохранять изменения, вылезает No space left on device – хотя места на диске вагон. Место действительно есть. Закончилось другое – inode, счётчик числа файлов на аккаунте. Про inode у нас есть большая статья, та самая, про что молчат провайдеры, поэтому здесь только о том, почему именно PrestaShop выжигает их быстрее всех.
Причина – в том, как движок работает с картинками. Вы загружаете одну фотографию товара, а PrestaShop делает из неё не одну копию, а целую пачку разного размера: миниатюру для списка, среднюю для карточки, крупную для галереи, ещё несколько под темы и модули. На практике из одного исходника получается десять и больше файлов. Умножьте на число товаров и на число фотографий у каждого – картина складывается быстро.
Цифры тут не абстрактные. Каталог на 10 000 товаров легко порождает больше 100 000 файлов только под изображения. На форумах PrestaShop годами висят однотипные истории: магазин на две-три тысячи товаров с пятью-восемью тысячами фотографий упирается в лимит в 250 000 файлов и встаёт. И это ещё без второго источника – кеша.
Кеш добавляет свою долю. Smarty-шаблоны, скомпилированные страницы, служебные файлы в var/cache – всё это тоже отдельные мелкие файлы, и на файловом кешировании их накапливаются десятки тысяч. Провайдеры, которые смотрят на аккаунты со своей стороны, находят в этих папках сотни тысяч крохотных файлов по одному-два килобайта – а по счётчику inode каждый весит как полноценный.
И ещё один момент, который упускают: даже пустой PrestaShop уже тяжёлый. Ещё до первого товара движок разворачивает тысячи служебных файлов – ядро, компоненты Symfony, папка vendor, десятки стандартных модулей. Вы стартуете не с нуля, а с заметного веса по числу файлов, и каталог только надстраивается сверху.
Вот здесь и кроется самое неприятное. Лимит по числу файлов на общем хостинге обычно жёсткий – типичные значения от 100 000 до 250 000, и он не резиновый. Магазин может годами не приближаться к потолку по диску и внезапно упереться в потолок по файлам, просто дорастив каталог. А дальше встаёт всё сразу: новые заказы не сохраняются, миниатюры не генерируются, бэкап не создаётся.
Кстати, из-за этого же счётчика стоит осторожнее относиться к резервным копиям, которые лежат рядом с сайтом: распакованный архив магазина – это ещё тысячи файлов поверх имеющихся. Что на самом деле стоит за словом «бэкап» – разговор отдельный, но на PrestaShop про inode при бэкапах забывать нельзя.
И поднять этот потолок по просьбе, как память, обычно нельзя. Число inode на общем хостинге – не настройка вашего аккаунта, а способ, которым провайдер делит файловую систему между всеми клиентами сразу. Поэтому в ответ на «увеличьте, пожалуйста, лимит файлов» вы чаще услышите не «сделали», а «почистите каталог или берите тариф выше». Со стороны хостера логика та же, что и с памятью: один магазин с миллионом мелких файлов замедляет резервное копирование и обслуживание всего сервера, а не только своё.
Частично проблема лечится переносом кеша в память – Redis или Memcached вместо файлов – и регулярной чисткой старых миниатюр. Но это уже не тот разговор, который ведут на дешёвом тарифе: там обычно нет ни того, ни другого.
Статья длинная. Предлагаем сделать паузу и ознакомиться с лучшими украинскими хостинг-провайдерами из нашего рейтинга. По каждому есть подробный разбор: как тестировали, что с аптаймом, скоростью и поддержкой, где сильные и слабые стороны. Загляните в обзоры тех, кто вам интересен, почитайте отзывы клиентов.
Процессор: тихая витрина и шумная админка
С процессором история короче, но знать её тоже стоит.
Витрина, повторюсь, из кеша отдаётся легко. Нагрузка на CPU в PrestaShop идёт всплесками – и почти всегда в админке или в фоновых задачах. Пересборка миниатюр после смены темы, переиндексация каталога для поиска, массовый импорт товаров, генерация фида для маркетплейса – вот моменты, когда магазин на минуту-другую съедает весь доступный процессор. На общем хостинге это упирается в лимит CPU: провайдер притормозит ваши процессы, и операция либо растянется, либо оборвётся по таймауту на середине.
Отдельно коварна кнопка пересборки изображений в админке. Нажимаешь её после смены темы – и движок разом перегенерирует миниатюры для всего каталога: это одновременно и всплеск CPU, и лавина новых файлов. На большом магазине такая операция на общем хостинге глохнет на полпути и оставляет часть товаров без картинок – а вы гадаете, что сломалось.
Сюда же прибавьте базу. PrestaShop любит писать в неё много и часто – логи, статистика, брошенные корзины, гостевые сессии. Таблицы разрастаются незаметно, и на общем MySQL это со временем становится ещё одним источником тормозов, отдельным от файлов и памяти.
Для покупателя всё это оборачивается медленным ответом сервера – тем самым TTFB, по которому потом ругается PageSpeed. Хотя на витрине чаще виноват не столько процессор, сколько отсутствие нормального кеша и оптимизации запросов.
Версии, PHP и обновления
Отдельная головная боль с PrestaShop – версии и обновления, и хостинг завязан на них плотнее, чем кажется.
Сейчас в ходу сразу три поколения движка. Самое свежее – PrestaShop 9, вышедший в 2025 году на архитектуре Symfony 6.4; ему нужен PHP не ниже 8.1, а комфортнее – 8.2–8.3. Массово при этом работает восьмая ветка, PrestaShop 8, тоже с PHP 8.1 как минимумом. И до сих пор живёт старьё на PrestaShop 1.7 и ниже, которое держится за PHP 7.x и сыпется при переходе на восьмую линейку – старые модули и правки под новым PHP выдают фатальные ошибки.
Что это значит при выборе хостинга. Провайдер должен давать не просто «PHP», а возможность переключать его версию под ваш движок и держать актуальной. Магазин, застрявший на PHP 7.4, – это не только медленнее и небезопаснее; это ещё и запертая дверь: половина свежих модулей и обновлений на него просто не встанет.
Добавьте сюда тему и модули. Каждый платный шаблон и каждый модуль оплаты, доставки или SEO несёт свои требования к версии PHP и свою долю в расходе памяти и числе файлов. Магазин на голом движке и тот же магазин с десятком модулей – это две разные нагрузки на хостинг, и вторая всегда заметно тяжелее. Оценивать тариф по чистой установке – распространённая ошибка: реальный магазин к моменту запуска весит совсем иначе.
И то, о чём забывают почти все. Обновление PrestaShop и часть операций с зависимостями иногда идут через Composer, а значит – через доступ по SSH и право запускать команды в терминале. На совсем бюджетных тарифах SSH либо нет, либо он декоративный. В итоге обновить магазин «в один клик» из админки не выходит, а руками – нечем. Сегодня это не остановит работу, но через год-полтора, когда версия устареет и модули начнут отваливаться, загонит вас в угол.
Переезд, о котором не предупреждают
Ещё одно следствие того же числа файлов всплывает в самый неподходящий момент – при переезде на другой хостинг. Сто тысяч мелких файлов по FTP не перельёшь: передача каждого – отдельная операция с задержкой, и то, что на обычном сайте занимает минуты, на большом магазине растягивается на часы, а нередко и обрывается на середине.
Нормальный способ – не копировать файлы по одному, а собрать их в архив прямо на сервере, перенести одним куском и распаковать на новом месте. Для этого снова нужен SSH – причём и на старом хостинге, и на новом. Магазин, который жил на тарифе без терминала, оказывается в ловушке: данных много, а вытащить их аккуратно нечем. Это стоит проверять не в день переезда, а при первом выборе хостинга.
Так какой хостинг брать под PrestaShop
Сложим всё вместе. PrestaShop давит на хостинг сразу по трём направлениям – память в админке, число файлов, всплески CPU, – и все три упираются в потолки, которых на дешёвых тарифах либо нет в описании, либо они выставлены жёстко и без права поднять.
Магазин-заготовку или витрину на пару десятков товаров можно спокойно держать на приличном общем хостинге – при одном условии: memory_limit реально поднимается до 512 МБ, а лимит по файлам не смешной. Как только каталог переваливает за несколько сотен позиций с фотографиями, разговор меняется. Тут либо старший тариф общего хостинга с честными, а не витринными лимитами, либо переход на VPS, где ресурсы ваши и потолки вы ставите сами.
Есть и промежуточный вариант, который часто выпадает из поля зрения, – общий хостинг, специально заточенный под тяжёлые CMS. На таком тарифе из коробки идут LiteSpeed или nginx с кешем, OPcache и доступ к Redis, а лимиты по памяти и файлам выставлены под магазины, а не под визитки. По цене он ближе к обычному общему хостингу, по запасу прочности – к младшему VPS. Для среднего магазина это нередко разумнее, чем сразу брать сервер и администрировать его в одиночку.
Как отличить честный тариф от витринного – тема нашей методики оценки: рекламные цифры и то, что реально отдаётся, расходятся чаще, чем хотелось бы. А если сравниваете конкретные тарифы «за свои деньги», подборщик по индексу TVI как раз и считает ценность тарифа с поправкой на такие лимиты.
И напоследок, для сравнения. Если вы пока только выбираете, на чём строить магазин, полезно понимать: PrestaShop – движок тяжёлый и специализированный, заточенный именно под торговлю. Магазин на WordPress с WooCommerce стартует легче и на слабом хостинге живёт дольше, зато по-своему капризен; OpenCart – компромисс между ними. У каждого своя нагрузочная логика, и хостинг под них берётся разный.
Источники
- PrestaShop Developer Documentation – System requirements (PrestaShop 9)
- PrestaShop Developer Documentation – System requirements (PrestaShop 8)
- PrestaShop Developer Documentation – Optimize your PrestaShop
- PHP Manual – Description of core php.ini directives (memory_limit, max_input_vars)
F.A.Q. по PrestaShop
Сколько памяти (memory_limit) нужно для PrestaShop?
Официальный минимум – 256 МБ, рекомендованное значение – 512 МБ. Но реальный расход задаёт не витрина, а админка: карточка товара с большим числом комбинаций способна упереться и в гигабайт. Поэтому под PrestaShop смотрите не на саму цифру memory_limit в тарифе, а на то, разрешит ли провайдер её реально поднять.
Почему PrestaShop пишет «No space left on device», хотя место на диске есть?
Место действительно есть – закончилось другое. Это inode, счётчик числа файлов на аккаунте, и у PrestaShop он выгорает раньше диска. Магазин с большим каталогом упирается в лимит по числу файлов, и тогда перестают сохраняться заказы, не генерируются миниатюры и не создаётся бэкап.
Почему PrestaShop создаёт так много файлов?
Из одной загруженной фотографии движок делает целую пачку копий разного размера – миниатюру для списка, среднюю для карточки, крупную для галереи и ещё несколько под темы и модули. На практике из одного исходника выходит десять и больше файлов. Каталог на 10 000 товаров легко даёт больше 100 000 файлов только под изображения, а сверху добавляется кеш.
Подойдёт ли самый дешёвый общий хостинг для PrestaShop?
Для витрины-заготовки или магазина на десяток позиций – да, но при условии, что memory_limit реально поднимается хотя бы до 512 МБ, а лимит по числу файлов не смешной. Как только каталог переваливает за несколько сотен товаров с фотографиями, дешёвого тарифа перестаёт хватать. Тогда разумнее старший тариф с честными лимитами или переход на VPS.
Почему магазин работает у покупателей, но падает, когда я редактирую товар?
Собранная и закешированная витрина отдаётся экономно, а вот админка тянет в память пол-магазина за одну операцию. Тяжёлое редактирование товара запускаете только вы, поэтому каталог у покупателей продолжает работать, пока у вас выскакивает ошибка памяти. Снаружи это чаще всего выглядит как 500-я или похожий код.
Какая версия PHP нужна для PrestaShop 8 и 9?
PrestaShop 9 требует PHP не ниже 8.1, комфортнее – 8.2–8.3. Восьмая ветка тоже работает от PHP 8.1. Старые магазины на PrestaShop 1.7 держатся за PHP 7.x и ломаются при переходе на восьмую линейку, поэтому важно, чтобы хостинг давал переключать версию PHP.
Почему после смены темы у части товаров пропали картинки?
Скорее всего, сработала пересборка миниатюр: движок разом перегенерирует изображения для всего каталога. Это одновременно всплеск CPU и лавина новых файлов, и на большом магазине такая операция на общем хостинге глохнет на полпути. В результате часть товаров остаётся без картинок, хотя сами исходники на месте.
Нужен ли SSH для PrestaShop?
Для витрины он не обязателен, но обновление PrestaShop и часть операций с зависимостями идут через Composer, а это уже терминал. SSH нужен и при переезде: сто тысяч мелких файлов проще собрать в архив на сервере, чем перегонять по FTP по одному. Если планируете жить с магазином долго, тариф без рабочего SSH загонит в угол.
Когда переходить с общего хостинга на VPS для PrestaShop?
Ориентир простой: пока каталог держится в пределах пары десятков товаров, хватает приличного общего хостинга. Как только доходит до нескольких сотен позиций с фотографиями, упор в память, файлы и CPU становится регулярным. Между общим хостингом и своим сервером есть промежуточный вариант – общий хостинг, заточенный под тяжёлые CMS, с LiteSpeed, OPcache и Redis из коробки.
Как уменьшить расход inode в PrestaShop?
Помогают две вещи: перенос кеша в память через Redis или Memcached вместо файлов и регулярная чистка старых миниатюр. Просто попросить провайдера поднять лимит по файлам обычно не выйдет – на общем хостинге это не настройка аккаунта, а способ деления сервера между всеми. Поэтому чаще в ответ предлагают почистить каталог или взять тариф выше.
Почему не сохраняется товар с большим числом комбинаций?
Тут две упирающиеся настройки. Первая – memory_limit: карточка с сотней комбинаций съедает много памяти. Вторая – max_input_vars: если вариантов много, форма просто не сохраняется целиком, пока этот параметр не поднят до нескольких тысяч, и часть характеристик после сохранения тихо пропадает.