Зображення в OpenCart: розміри, назви файлів і структура папок
Типова історія: магазин на OpenCart живе другий рік, товарів під три тисячі, і одного дня власник запускає перевірку швидкості. Головна вантажиться шість секунд, PageSpeed світить червоним, перша рекомендація: «Оптимізуйте зображення». Відкриваєте image/catalog по FTP, а там IMG_20250412_153207.jpg на шість мегабайтів, «Фото товару №3 (нове).jpg» кирилицею з пробілами й дужками, і все це навалом в одній теці разом із банерами, логотипами та фотографіями з акції дворічної давнини.
Розгребти такий завал постфактум у рази дорожче, ніж одразу завантажувати фото правильно. Бо ім'я файлу вшивається в шляхи в базі даних (таблиці oc_product_image, oc_product, oc_category), і масове перейменування без правки бази просто відірве картинки від товарів. Тому правила нижче краще впровадити до того, як каталог розростеться.
Як OpenCart насправді працює із зображеннями
Щоб рекомендації не виглядали догмами, спершу про механіку. Ви завантажуєте оригінал через менеджер зображень в адмінці, і він лягає в папку image/catalog. На вітрині ж показується не оригінал: OpenCart через бібліотеку system/library/image.php (під капотом GD) генерує зменшені копії під кожне місце в шаблоні й складає їх у image/cache. Тому поруч із вашим wine-merlot.jpg у кеші з'являються wine-merlot-500x500.jpg, wine-merlot-228x228.jpg і так далі, під кожен розмір, прописаний у налаштуваннях теми.
З цього випливають дві речі. Перша: оригінал відкривається лише раз, у момент генерації кешу, далі віддаються готові копії. Друга: шлях до оригіналу зберігається в базі як текст, і будь-яка «косметика» з іменами файлів на диску без синхронного оновлення бази закінчується порожніми квадратами замість фото.
Який розмір оригіналу обирати
Для основного зображення товару беріть 800x800 або 1000x1000 пікселів. Цього вистачає і для картки товару, і для збільшення при кліку (лайтбокс), і для адаптивної верстки на ретина-екранах. Формат краще квадратний: OpenCart вписує картинку в задані пропорції й доганяє білими полями, тож коли частина фото вертикальна, частина горизонтальна, категорія виглядає як паркан із різних дощок.
Чому не завантажувати оригінали на 4000–5000 пікселів «про запас»? Тому що ресайз через GD їсть пам'ять пропорційно площі зображення, а не вазі файлу. На бюджетному хостингу з memory_limit 128M генерація кешу з такого оригіналу падає, у error.log сиплеться «Allowed memory size of 134217728 bytes exhausted», і відвідувач бачить биту картинку. Симптом упізнаваний: половина фото в категорії є, половини нема, і саме на найважчих файлах.
Розміри кешованих копій задаються в адмінці. В OpenCart 3.x це Дизайн → Теми → редагування теми, там поля на кшталт «Розмір зображення товару», «Розмір зображення в списку товарів», «Додаткові зображення». В OpenCart 2.x ті самі поля живуть у Система → Налаштування → редагування магазину, вкладка «Зображення». Після зміни розмірів кеш треба скинути: у 3.x це шестірня на дашборді й кнопка оновлення кешу зображень, або вручну видалити вміст image/cache (крім index.html). Старі копії самі не перегенеруються, і це класична причина «поміняв розмір, а нічого не змінилось».
Вага файлу і формат
Розмір у пікселях і вага в мегабайтах — різні речі, і друга б'є по швидкості не менше. Фото прямо з телефона важить 4–8 МБ, тоді як пристойний JPEG 1000x1000 після стискання вкладається в 100–200 КБ без видимої втрати якості. Прогін через Squoosh або TinyPNG перед завантаженням займає секунди, а економія на трафіку працює роками.
По форматах усе просто: JPEG для фотографій товарів, PNG там, де потрібна прозорість (логотипи, іконки). З WebP нюанс: стандартний OpenCart 2.x і 3.x сам його не генерує, кеш створюється в тому ж форматі, що й оригінал. А от у шаблонах OCTemplates генерація WebP уже вбудована: ви завантажуєте звичайний JPEG чи PNG, а вітрина віддає браузеру легші WebP-копії без окремих модулів і правок сервера. На дефолтній темі для того самого результату доведеться ставити розширення або налаштовувати конвертацію на рівні сервера.
Назви файлів і папок: тільки латиниця
Тут правило залізне. У назвах тек та імен файлів використовуйте тільки латиницю з малої букви, цифри, дефіс і нижнє підкреслення. Все. Ні кирилиці, ні пробілів, ні дужок, ні знаків на кшталт №, %, +.
Це не педантизм, а зекономлені години дебагу. Ось що ламає кожен із заборонених варіантів:
Кирилиця. У URL вона кодується, і охайне «червоне-вино.jpg» перетворюється на
%D1%87%D0%B5%D1%80... Такі посилання обрізаються в листах і месенджерах, а при переносі магазину між серверами з різними локалями файлової системи імена файлів можуть покалічитися ще на етапі розпакування архіву. Бачив бекапи, де після tar на іншому сервері половина кириличних імен перетворилася на знаки питання, і картинки довелося відновлювати вручну.
Пробіли. У URL стають %20, і на цьому спотикаються деякі парсери, старі системи вивантаження фідів і чужі інтеграції, яким ви віддаєте посилання на фото.
Великі літери. Linux регістрозалежний: Photo.jpg і photo.jpg для нього два різні файли. Типовий сценарій: магазин розробляли локально на Windows, де регістр байдужий, все працювало. Переїхали на бойовий Linux-хостинг, і третина картинок віддає 404, бо в базі шлях із великої літери, а файл на диску з малої. Домовтеся один раз: усе з малої, і цей клас проблем зникає.
Дефіс чи підкреслення
Обидва символи дозволені, але роль у них різна. Для розділення слів у назві беріть дефіс: пошукові системи трактують його як роздільник, тобто chervone-vyno-2024.jpg читається як три окремі слова. Підкреслення слова склеює, тож chervone_vyno_2024.jpg для пошуковика ближче до одного незрозумілого слова. Підкреслення лишіть для технічних суфіксів, де це доречно: banner_main.jpg, logo_footer.png.
Назва має бути короткою, але інформативною. Добра схема: назва товару транслітом плюс унікальний ідентифікатор (артикул або ID з бази), щоб файли не перезаписували один одного при збігу назв.
Неправильно:
Фото товару №3 (нове).jpg IMG_20250412_153207.jpg Красное вино 2024 КОПИЯ.jpg
Правильно:
chervone-vyno-merlot-2024.jpg vyno-merlot-0-75l-art-4521.jpg banner-sale-summer.jpg
Перший варіант із «неправильних» ще й нічого не каже пошуковику про вміст, другий — типовий слід завантаження прямо з телефона. Ім'я файлу — це один із сигналів для пошуку по картинках, і викидати його на «IMG_2025...» просто марнотратно.
Структура папок: не звалюйте все в одну теку
Друга половина порядку — папки. Менеджер зображень в OpenCart при відкритті теки вантажить мініатюри всіх файлів у ній. Поки файлів триста, це непомітно. Коли їх п'ять тисяч в одній image/catalog, вікно вибору картинки відкривається по пів хвилини, і кожне редагування товару перетворюється на чаювання.
Розкладайте за логікою каталогу. Робочий приклад структури:
image/catalog/ ├── products/ │ ├── wine/ │ ├── cognac/ │ └── accessories/ ├── categories/ ├── manufacturers/ ├── banners/ └── blog/
Ділити можна за категоріями, за брендами чи за роками надходження, головне, щоб логіка була одна на весь каталог і в теці не збиралися тисячі файлів. Назви папок підкоряються тим самим правилам, що й файли: латиниця, мала буква, без пробілів. Пам'ятайте, що ім'я папки теж стає частиною URL зображення.
І окремо: не перейменовуйте і не переносьте вже підключені до товарів файли по FTP. Шлях у базі від цього сам не оновиться. Якщо реструктуризація назріла, робіть її разом з оновленням шляхів у таблицях oc_product_image та oc_product (поле image), попередньо знявши бекап бази.
Що це дає для SEO
Пошук по картинках приводить живий трафік, особливо у візуальних нішах: одяг, меблі, декор. OpenCart тут дає базу, але не все. Alt-текст у дефолтній темі підставляється з назви товару, окремого поля для alt додаткових зображень у стандартній адмінці немає, це обмеження движка. Sitemap для зображень «з коробки» теж не генерується. Тому ім'я файлу лишається одним із небагатьох сигналів, які ви контролюєте без модулів, і нехтувати ним не варто.
Плюс охайні імена працюють на вас і поза пошуком: у фідах для маркетплейсів і прайс-агрегаторів, у вивантаженнях для реклами, при синхронізації з обліковими системами. Скрізь, де посилання на фото їде в чужу систему, «IMG з дужками й кирилицею» рано чи пізно вилазить боком.
Що робити, якщо каталог уже захаращений
Якщо магазин працює не перший рік і в image/catalog уже хаос, не кидайтеся перейменовувати все підряд. Спершу аудит. Знайти найважчі файли можна однією командою по SSH:
find image/catalog -type f -size +1M -exec ls -lh {} \; | sort -k5 -rh | head -50
Вона покаже топ-50 файлів понад мегабайт. Зазвичай уже тут видно винуватців: десяток «сирих» фото з камери, які тягнуть на собі половину ваги каталогу. Їх можна перестиснути без перейменування, шлях у базі не зміниться, а вага впаде в рази. Кеш після заміни оригіналів скиньте, інакше вітрина показуватиме старі копії.
Друга частина аудиту: файли-сироти, які лежать на диску, але не підключені до жодного товару. Вони не сповільнюють вітрину, зате роздувають бекапи й засмічують менеджер зображень. Перевіряється порівнянням вмісту image/catalog зі шляхами в полях image таблиць oc_product, oc_product_image, oc_category, oc_manufacturer. Руками це робити тоскно, тому або скрипт, або одне з готових розширень для чищення невикористаних зображень з маркетплейсу OpenCart.
А от масове перейменування кириличних файлів лишіть на крайній випадок, коли без нього ніяк: наприклад, перед переїздом на інший сервер. Робиться це скриптом, який транслітерує ім'я файлу й тут же оновлює відповідний рядок у базі, обидві операції в одній зв'язці. І тільки після повного бекапу файлів і бази. Половинчасте перейменування, коли диск уже новий, а база ще стара, кладе всі картинки магазину разом.
Чек-лист
- Основне фото товару: квадрат 800x800 або 1000x1000 пікселів.
- Вага JPEG після стискання: орієнтовно до 200 КБ, стискайте до завантаження.
- У назвах файлів і папок тільки: латиниця з малої букви, цифри, дефіс, підкреслення.
- Дефіс для розділення слів, підкреслення для технічних суфіксів.
- Схема імені: назва-товару-транслітом плюс артикул або ID.
- Папки за структурою каталогу, без тисяч файлів в одній теці.
- Після зміни розмірів у налаштуваннях теми: скинути кеш зображень.
- Ніяких перейменувань підключених файлів по FTP без оновлення шляхів у базі.
- Перед масовими операціями із зображеннями: бекап image/catalog і бази.
