Кейс оптимізації 

Те, що для власника виглядало як «ну воно якось працює, але все повільно», технічно виглядало так:

• 65 плагінів, із них 47 активних.
  Частина дублює функціональність, частина давно не оновлюється, про деякі вже ніхто не пам’ятає, навіщо їх ставили, але чипати 

• Купа товарів в статусі draft, порожні розділи в меню без жодного товару 
• База даних розрослася до ~3 ГБ.
  Понад 70 таблиць, включно з артефактами типу copy_wp_posts — швидко «скопіювали на всяк випадок», а потім забули прибрати.

• Документація фактично відсутня.
  Є лише опис обміну з 1С. Усе інше — «чорна скринька» з набором плагінів і кастомних налаштувань

На практиці це призвело до таких наслідків:

• Головна сторінка вантажилася близько 12 (!) секунд.
  Адмінка – так само повільно, і це критично, бо в ній щодня виконувалося багато ручної роботи. 

• Оцінити правки було майже неможливо.
  У ~70% випадків «проста правка» перетворювалася на кілька годин робіт через приховані зв’язки між плагінами.

• Урахування конверсій у Google Analytics 4 працювало некоректно.
  Події губилися «в надрах» кастомних скриптів, GA4 віддавав «дробні» конверсії, на які не можна спиратися у маркетингу.

• Оновлювати сайт було небезпечно.
  Будь-яке оновлення ядра, WooCommerce або плагіна могло щось зламати — і було незрозуміло, що саме.

• Звичайні бекапи стали проблемою.
  Працювати з сайтом і БД без спеціальних інструментів важко: велика вага, багато таблиць, ризики падіння під час копіювання.

• Хостинг доводилося постійно «прокачувати».
  За останній рік двічі переходили на дорожчі тарифи, щоб усе це хоч якось працювало.

• Це все ускладнювалось досить складною логікою бізнес-процесів

• Є експорт фідів для маркетплейсів і Google Merchant, зав’язаний на поточну структуру даних та плагіни.

• Варіативні товари – для одного товару могли бути різні розміри, для чоловіків\жінок і відповідно різні залишки на складах

• Складна логіка акцій.
  Тимчасові знижки на окремі товари / категорії на період акцій, у відсотках від ціни, з урахуванням валют.

• Мультимовність та мультивалюта:
  3 валюти для різних геозон, 3 мовні версії.

1. Новий фундамент: чистий WordPress + WooCommerce

• Розгорнули чисту установку WordPress + WooCommerce 

• Імпортували всі товари зі старого сайту (з урахуванням варіацій, валют і мов).

• Почали переносити дизайн і ключову функціональність, поступово відмовляючись від зайвих плагінів.

Важливий момент: старий сайт продовжував працювати і оновлюватися, ми синхронізували дані, щоб не втрачати актуальність по товарах у процесі міграції.

2. SEO й структура сайту

Завдання — зробити технічний «ремонт» без різкого падіння трафіку.

• Движок і URL-структуру не змінювали, що істотно знизило SEO-ризики.

• Повністю просканували сайт і виявили «забуті» розділи:

  • наприклад, старий блог, який давно прибрали з меню, але його сторінки досі індексувалися.

• Склали повний список URL, провели ревізію разом із замовником і:

  • погоджено видалили частину сторінок, які більше не мають сенсу;

  • налаштували редиректи на актуальні цільові сторінки.

Паралельно підчистили технічну базу: логічні шаблони, акуратні мета-дані, коректні налаштування для індексації.

3. Оптимізація плагінів і бізнес-логіки

• Переглянули всі 65 плагінів і скоротили їх до 14 робочих, що реально потрібні проєкту.

• Частину логіки винесли в functions.php та власні снипети, щоб:

  • зменшити залежність від сторонніх рішень,

  • зробити оновлення безпечнішими,

  • мати контроль над критично важливим кодом.

• Для кожного залишеного плагіна зафіксували:

  • навіщо він потрібен,

  • за що відповідає,

  • які ризики пов’язані з його оновленням.

Це стало основою внутрішньої документації, якої раніше просто не існувало.

4. Дані, база й бекапи

• Оптимізували структуру бази даних:

  • видалили зайві «тимчасові» та дубльовані таблиці;

  • розділили активні дані та архів.

• Налаштували схему, де:

  • в основній БД знаходяться актуальні дані за останні 3 місяці,

  • старіші дані архівуються в окрему архівну БД.

• Історичні дані про покупки з 2016 року (про яких замовники взагалі не знали):

  • зібрали й очистили, на їх основі сформували базу з 12 000 email-адресів,

  • передали маркетинговій команді для реанімаційних та повторних кампаній.

Деякі з цих кампанії потім виявились досить результативними. Кліенти, писали: “дякуємо, що нагадали, ми в вас давно замовляли, але потім загубили\забули адресу”

Продуктивність і стабільність

• Швидкість завантаження головної сторінки зменшилася приблизно з 12 до 3 секунд, при цьому ще залишився резерв за рахунок додаткової оптимізації зображень.

• Адмінка перестала гальмувати — стало реально працювати з товарами та замовленнями щодня без постійних зависань.
  Продуктивність роботи менеджера з роботи з сайтом приблизно на 35%

• Скорочення кількості плагінів і винесення критичної логіки в код дозволили безпечно оновлювати ядро, WooCommerce та самі плагіни.

• Завдяки зниженню навантаження на сервер вдалося повернутися на простіший тариф хостингу й зменшити щомісячні витрати.

Керованість і супровід

• З’явилася зрозуміла документація:

  • призначення кожного з 14 плагінів;

  • схема обміну даними з 1С;

  • логіка формування фідів для маркетплейсів і Google Merchant;

  • реалізація акцій, мультивалюти й мультимовності.

• Оцінка робіт стала прогнозованою.
  Невеликі зміни більше не перетворюються на багатогодинне «полювання за багами».

• Склали інструкцію для контент менеджера, що і де можна змінювати з адмінки, щоб робити це самостійно.