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 відбувається сплесками — і майже завжди в адмінці або у фонових завданнях. Перекомпіляція мініатюр після зміни теми, переіндексація каталогу для пошуку, масовий імпорт товарів, генерація фіду для маркетплейсу — ось моменти, коли магазин на хвилину-другу «з’їдає» весь доступний процесор. На загальному хостингу це призводить до вичерпання ліміту процесора: провайдер уповільнить ваші процеси, і операція або затягнеться, або обірветься через тайм-аут посередині.
Окремо підступною є кнопка перегенерації зображень в адмінці. Натискаєш її після зміни теми — і движок одразу перегенерує мініатюри для всього каталогу: це одночасно й сплеск завантаження процесора, й лавина нових файлів. На великому магазині така операція на загальному хостингу застрягне на півдорозі й залишить частину товарів без зображень — а ви будете гадати, що зламалося.
Додайте сюди ще й базу даних. 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 навантажує хостинг одразу у трьох напрямках — пам’ять в адмінці, кількість файлів, піки завантаження процесора, – і всі три досягають меж, яких на дешевих тарифах або немає в описі, або вони встановлені жорстко й без права підвищення.
Магазин-заготовку або вітрину на пару десятків товарів можна спокійно тримати на пристойному загальному хостингу – за однієї умови: memory_limit обсяг пам’яті реально збільшується до 512 МБ, а ліміт на файли не смішний. Як тільки каталог перевищує кілька сотень позицій із фотографіями, ситуація змінюється. Тут або потрібен вищий тариф загального хостингу з чесними, а не «вітринними» лімітами, або перехід на VPS, де ресурси належать вам, і межі ви встановлюєте самі.
Є й проміжний варіант, який часто випадає з поля зору, — загальний хостинг, спеціально налаштований під важкі CMS. На такому тарифі «з коробки» надаються LiteSpeed або nginx із кешем, OPcache та доступ до Redis, а ліміти пам’яті й файлів розраховані на магазини, а не на візитні картки. За ціною він ближчий до звичайного загального хостингу, за запасом міцності — до найпростішого VPS. Для середнього інтернет-магазину це нерідко розумніше, ніж одразу брати сервер і адмініструвати його самотужки.
Як відрізнити чесний тариф від «вітринного» — тема нашої методики оцінки: рекламні цифри та те, що реально надається, розходяться частіше, ніж хотілося б. А якщо ви порівнюєте конкретні тарифи «за свої гроші», інструмент підбору за індексом TVI якраз і розраховує цінність тарифу з урахуванням таких лімітів.
І наостанок, для порівняння. Якщо ви поки що лише обираєте, на чому будувати магазин, корисно розуміти: PrestaShop — важкий і спеціалізований движок, налаштований саме під торгівлю. Інтернет-магазин на WordPress із WooCommerce запускається легше і на слабкому хостингу працює довше, зате по-своєму примхливий; OpenCart — компроміс між ними. У кожного своя логіка навантаження, і хостинг під них обирається різний.
Джерела
- Документація для розробників PrestaShop – Системні вимоги (PrestaShop 9)
- Документація для розробників PrestaShop – Системні вимоги (PrestaShop 8)
- Документація для розробників PrestaShop – Оптимізація PrestaShop
- PHP Manual – Опис основних директив php.ini (memory_limit, max_input_vars)
Часті запитання щодо 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.
Чому після зміни теми у частини товарів зникли зображення?
Швидше за все, спрацювала перекомпіляція мініатюр: движок одночасно перегенерує зображення для всього каталогу. Це одночасно сплеск навантаження на процесор і лавина нових файлів, і на великому магазині така операція на загальному хостингу «заглухає» на півдорозі. У результаті частина товарів залишається без зображень, хоча самі вихідні файли на місці.
Чи потрібен SSH для PrestaShop?
Для вітрини він не обов’язковий, але оновлення PrestaShop і частина операцій із залежностями відбуваються через Composer, а це вже термінал. SSH потрібен і під час переїзду: сто тисяч дрібних файлів простіше зібрати в архів на сервері, ніж переносити по FTP по одному. Якщо плануєте довго працювати з магазином, тариф без робочого SSH зажене вас у кут.
Коли переходити зі спільного хостингу на VPS для PrestaShop?
Орієнтир простий: поки каталог не перевищує кількох десятків товарів, вистачає пристойного загального хостингу. Як тільки кількість товарів досягає кількох сотень позицій із фотографіями, навантаження на пам’ять, файли та процесор стає постійним. Між загальним хостингом і власним сервером є проміжний варіант — загальний хостинг, налаштований під важкі CMS, з LiteSpeed, OPcache та Redis «з коробки».
Як зменшити споживання inode в PrestaShop?
Допомагають дві речі: перенесення кешу в пам’ять через Redis або Memcached замість файлів і регулярне очищення старих мініатюр. Просто попросити провайдера підвищити ліміт на файли зазвичай не вийде — на загальному хостингу це не налаштування облікового запису, а спосіб розподілу сервера між усіма. Тому найчастіше у відповідь пропонують очистити каталог або перейти на вищий тариф.
Чому не зберігається товар із великою кількістю комбінацій?
Тут є два налаштування, що заважають. Перше — memory_limit: картка зі сотнею комбінацій споживає багато пам’яті. Друга — max_input_vars: якщо варіантів багато, форма просто не зберігається повністю, доки цей параметр не буде підвищено до кількох тисяч, і частина характеристик після збереження непомітно зникає.