Замовити консультацію

Аудит продуктивності Magento

Знайдемо, що уповільнює Magento, і визначимо, чи справді необхідні зміни.

Замовити аудит Що аналізуємо

Ми не просто показуємо, що працює повільно. Ми встановлюємо, чому це відбувається, де саме знаходиться проблема та які зміни дадуть найбільший ефект.

Повільний Magento-магазин не завжди має очевидну причину. Високий TTFB може бути пов’язаний із сервером, базою даних або важким PHP-кодом. Повільний рендеринг — із frontend, JavaScript, зображеннями чи темою. А проблеми, які проявляються тільки під навантаженням, можуть бути пов’язані з архітектурою, кешуванням, Redis, MySQL, чергами або неправильно налаштованими cron та indexers.

Тому performance audit Magento — не перевірка сайту одним сервісом чи спроба отримати 100 балів у PageSpeed.

Аудит продуктивності Planeta Web — це глибокий технічний аналіз Magento-магазину на рівні frontend, application, database та infrastructure, який визначає реальні bottlenecks, їхній вплив на бізнес і пріоритетність подальших робіт.

Ви можете почати з наших матеріалів і самостійно перевірити основні performance-ризики Magento. Або скористатися досвідом команди Planeta Web, яка працює з Magento на всіх рівнях — від frontend і custom code до database та infrastructure.

Коли Magento дійсно потребує performance audit

Проблеми з продуктивністю часто з’являються поступово. Магазин нормально працює після запуску, але зі зростанням каталогу, трафіку, кількості замовлень та інтеграцій сторінки починають завантажуватися довше, checkout реагує із затримкою, а сервер споживає дедалі більше ресурсів.

Загалом, послуга аудиту потрібна, коли

  • категорії або картки товарів завантажуються повільно
  • TTFB залишається високим навіть після базової оптимізації frontend
  • Magento повільно працює в адміністративній панелі
  • checkout або кошик реагують із затримками
  • швидкість магазину суттєво погіршується під час рекламних кампаній
  • сайт періодично перевантажує CPU або RAM
  • база даних займає надто багато ресурсів
  • cron або indexers не встигають обробляти дані
  • після встановлення або оновлення extension магазин став працювати повільніше
  • зміна теми не дала очікуваного приросту швидкості
  • магазин працює на потужному сервері, але продуктивність залишається низькою
  • Core Web Vitals погіршуються, хоча серверні показники виглядають прийнятно
  • планується масштабування магазину, міграція на іншу інфраструктуру або значне збільшення трафіку

Причина проблеми при цьому може знаходитися на будь-якому рівні Magento: у custom code або extension, database, cache, frontend, PHP-FPM чи infrastructure. Аудит допомагає визначити root cause, оцінити його вплив і зрозуміти, які технічні зміни мають найбільший пріоритет.

Що дає аудит продуктивності сайту вашому бізнесу

Швидкість Magento безпосередньо впливає на досвід користувача: чим швидше завантажується магазин і реагує на дії покупця, тим простіше йому знайти товар, оформити замовлення та завершити покупку. Для eCommerce це зрештою впливає на конверсію та дохід.

При цьому, PageSpeed і Lighthouse для нас — лише один із шарів діагностики. Повноцінний performance audit дає бізнесу розуміння реального стану магазину, причин знайдених проблем і пріоритетів подальших робіт.

У результаті аудиту бізнес отримує

  • Чітке розуміння причин проблеми

    Ви бачите, де знаходиться bottleneck, чому він виникає та на який компонент системи впливає.

  • Пріоритетний план оптимізації

    Замість десятків технічних рекомендацій команда отримує послідовність робіт: що виправити зараз, що можна запланувати пізніше та які зміни дадуть найбільший ефект.

  • Прогнозований ефект від оптимізації

    Ми пов’язуємо технічні проблеми з очікуваним результатом і, де це можливо, визначаємо конкретні performance metrics, які можна покращити: response time, TTFB, навантаження на сервер, кількість запитів, час виконання PHP та інші показники.

  • Контроль над витратами на розробку

    Кожна рекомендація прив’язана до конкретної проблеми. Це допомагає оцінити обсяг робіт і не витрачати бюджет на оптимізацію компонентів, які не є критичними для магазину.

  • Вищу стабільність під навантаженням

    Аудит показує, як поточна архітектура поводиться при зростанні трафіку, каталогу, кількості замовлень та одночасних запитів.

  • Розуміння готовності до масштабування

    Можна заздалегідь визначити, які компоненти стануть bottleneck при зростанні магазину та які зміни варто внести до збільшення навантаження.

  • Контроль продуктивності після змін

    Зафіксований baseline і конкретні performance metrics дають можливість порівнювати результати після оптимізації, релізів, оновлень Magento або встановлення нових extensions.

Що ми аналізуємо під час аудиту Magento

Performance Magento формується на декількох рівнях та не обмежується аудитом frontend-показників.

01.

Frontend performance

Ми починаємо з того, що отримує користувач у браузері. Аналізуємо:

  • Core Web Vitals
  • LCP, INP та CLS
  • TTFB
  • waterfall завантаження сторінки
  • HTML, CSS та JavaScript
  • render-blocking resources
  • кількість та розмір frontend-запитів
  • JavaScript execution time
  • third-party scripts
  • зображення та їхні формати
  • lazy loading
  • шрифти
  • кешування статичних ресурсів
  • mobile performance
  • особливості Magento theme

Перевіряємо ключові типи сторінок магазину: homepage, category, product, search, cart та checkout — залежно від конфігурації конкретного проєкту.

Це важливо, тому що performance проблеми можуть бути локальними. Наприклад, категорія з великою кількістю товарів може поводитися зовсім інакше, ніж проста CMS-сторінка.

Для frontend-аналізу використовуємо Lighthouse, PageSpeed Insights та інші інструменти профілювання залежно від задачі. Adobe також рекомендує використовувати Lighthouse та PageSpeed Insights для перевірки frontend performance Magento.

02.

Magento application layer

Далі переходимо від того, що бачить браузер, до того, що відбувається всередині Magento. Ми аналізуємо:

  • PHP execution time
  • slow requests
  • Magento controllers
  • observers та plugins
  • custom modules
  • third-party extensions
  • dependency injection
  • важкі service calls
  • API та GraphQL-запити
  • кількість звернень до бази даних
  • повторне виконання однакових операцій
  • нестандартну бізнес-логіку
  • проблемні ділянки custom code

Особливу увагу приділяємо стороннім та кастомним модулям. Magento має велику екосистему extensions, і проблема далеко не завжди полягає в самому Magento core. Extension може додавати додаткові SQL-запити, змінювати процес формування сторінки, втручатися в checkout або створювати зайві операції під час кожного request.

Тому ми визначаємо, які компоненти створюють додаткове навантаження на application layer, чому це відбувається та як це впливає на продуктивність Magento.

03.

Database performance

MySQL — один із ключових компонентів Magento, тому проблеми з базою даних можуть проявлятися далеко за межами самої БД. Під час аудиту перевіряємо:

  • slow SQL queries
  • execution time запитів
  • індекси
  • таблиці, які активно використовуються
  • розмір бази даних
  • database configuration
  • temporary tables
  • locks
  • connection usage
  • навантаження на MySQL
  • Magento indexers
  • накопичення непотрібних даних
  • вплив extension на database layer

Також перевіряємо режим роботи indexers. Для Magento важливо, щоб індексація не створювала непотрібне навантаження під час роботи магазину. Adobe рекомендує для performance використовувати Update on Schedule для більшості indexers, оскільки оновлення виконується у фоні через cron, а не блокує операції магазину кожного разу при зміні даних.

На цьому рівні ми можемо використовувати профайлери та інструменти аналізу SQL, зокрема New Relic, Blackfire та інші засоби залежно від доступної інфраструктури.

04.

Cache та session management

Magento активно використовує кешування, тому неправильно побудована cache strategy може стати одним із головних bottlenecks. Ми перевіряємо:

  • Magento cache configuration
  • Full Page Cache
  • Varnish
  • Redis
  • session storage
  • block cache
  • cache invalidation
  • cache hit/miss behavior
  • конфігурацію кешів у multi-server environment
  • взаємодію Magento з reverse proxy
  • поведінку кешу для dynamic та personalized content

Adobe рекомендує Varnish як reverse proxy для full-page caching Magento, оскільки кешування дозволяє віддавати сторінки без повторного виконання повного application request.

Для масштабованих інсталяцій окремо перевіряємо Redis та розподіл cache/session storage. Adobe рекомендує для multi-server Magento окремі Redis instances для sessions та application cache, а обсяг пам’яті має відповідати реальному cache workload.

Для актуальних версій Adobe Commerce також враховуємо можливості L2 caching, яке зменшує кількість звернень web nodes до remote cache storage.

05.

Infrastructure performance

Magento не існує окремо від сервера. Іноді розробники намагаються оптимізувати PHP-код, хоча реальна проблема знаходиться на рівні infrastructure. В інших випадках сервер має достатньо CPU та RAM, але його ресурси використовуються неефективно через неправильну конфігурацію Magento.

Тому ми аналізуємо:

  • CPU та RAM usage
  • PHP version та PHP-FPM
  • Nginx
  • PHP-FPM workers
  • MySQL resources
  • Redis
  • Varnish
  • Elasticsearch / OpenSearch
  • disk I/O
  • network latency
  • server response time
  • кількість concurrent connections
  • cron workers
  • queue consumers
  • server architecture
  • load balancing
  • окремі web, database та cache nodes
  • можливості горизонтального масштабування

Для production Magento Adobe виділяє PHP, Nginx + PHP-FPM, MySQL та Elasticsearch/OpenSearch як базові компоненти software stack, а для multi-server та масштабованих deployment рекомендує Varnish і Redis у відповідній архітектурі.

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

06.

Cron, queues та background processes

Не всі performance-проблеми виникають під час відкриття сторінки. Частина Magento-операцій виконується у фоні: індексація, імпорт даних, оновлення каталогу, генерація окремих процесів, queue consumers та інші scheduled tasks.

Команда перевіряє:

  • cron configuration
  • частоту запуску задач
  • execution time
  • cron backlog
  • indexers
  • queue consumers
  • паралельне виконання процесів
  • конфлікти між background jobs
  • вплив імпортів та синхронізацій на storefront
  • пікове навантаження на сервер

Це особливо важливо для магазинів із PIM, ERP, CRM, marketplace та іншими системами, які регулярно передають великі обсяги даних.

07.

Magento theme та frontend architecture

Окремий рівень аудиту — тема та спосіб побудови storefront. Тут варто звернути увагу на:

  • Luma або Hyvä
  • custom theme
  • child theme
  • layout XML
  • templates
  • .phtml
  • JavaScript components
  • Alpine.js
  • Tailwind CSS
  • сторонні frontend extensions
  • кількість завантажуваного JS
  • дублювання frontend dependencies
  • blocking resources
  • custom integrations
  • rendering logic

Якщо магазин працює на Hyvä, ми аналізуємо, чи дійсно storefront використовує переваги цієї архітектури, а не переносить у неї старі frontend-підходи.

Якщо використовується Luma або значно кастомізована тема, визначаємо, які компоненти створюють найбільше навантаження та чи є сенс оптимізувати існуючу реалізацію, модернізувати окремі компоненти або розглядати глибшу зміну frontend architecture.

08.

Third-party integrations та extensions

Чим більше систем інтегровано з Magento, тим більше потенційних точок впливу на performance. Ми досліджуємо інтеграції з:

  • ERP
  • CRM
  • PIM
  • payment providers
  • delivery services
  • search platforms
  • marketing platforms
  • analytics
  • marketplaces
  • external APIs
  • custom middleware

Метою є зрозуміти, коли і як саме ці інтеграції взаємодіють із Magento.

Наприклад, зовнішній API не повинен без необхідності блокувати критичний storefront request. Великий імпорт не повинен створювати неконтрольоване навантаження на database layer. А marketing script не повинен блокувати основний rendering path сторінки.

Як проводять етапи аудиту продуктивності Magento

Ви можете продавати спортивне взуття, виробляти професійне обладнання, розвивати ювелірний eCommerce, керувати мережею супермаркетів або працювати з B2B-каталогом на десятки тисяч позицій. У кожного такого Magento-проєкту будуть свої бізнес-процеси, інтеграції, обсяги даних, навантаження та вимоги до продуктивності.

Тому аудит завжди адаптується під конкретний магазин: ми враховуємо його архітектуру, технологічний стек, сценарії користувачів і характер навантаження. Водночас є базовий каркас, який проходить крізь більшість performance audit: від збору даних і фіксації поточного стану до пошуку root cause, визначення пріоритетів і формування roadmap для подальшої оптимізації.

Радимо звернутися до нашої команди, щоб сформувати персональний план вже зараз.

Сформувати план

  1. Збираємо дані про магазин

    На старті визначаємо контекст проєкту. Це дозволяє не оцінювати Magento у вакуумі.

    • Magento Open Source або Adobe Commerce
    • версію Magento
    • обсяг каталогу
    • кількість store views
    • приблизний traffic
    • поточну infrastructure
    • тему
    • ключові extensions
    • інтеграції
    • характер навантаження
    • основні проблеми, які бачить бізнес або команда

  2. Фіксуємо baseline

    Перед оптимізацією важливо знати, з якої точки ми починаємо.

    Фіксуємо тут ключові performance metrics для основних сценаріїв та сторінок. Це дозволяє після внесення змін порівняти результати не суб’єктивно, а за конкретними показниками.

  3. Проводимо технічне профілювання

    На цьому етапі аналізуємо frontend, application, database, caching та infrastructure. Не кожен інструмент потрібен кожному проєкту: ми підбираємо набір відповідно до того, де потрібно знайти bottleneck.

    Залежно від проєкту використовуємо:

    • Google Lighthouse
    • PageSpeed Insights
    • Chrome DevTools
    • WebPageTest
    • GTmetrix
    • New Relic
    • Blackfire
    • MySQL profiling
    • Magento CLI
    • server monitoring
    • PHP profiling
    • network та infrastructure metrics

  4. Знаходимо root causes

    Наше завдання — визначити, що саме стоїть за проблемою з продуктивністю та на якому рівні Magento виникає bottleneck.

    • Наприклад, симптом — високий TTFB. Причиною може бути повільний PHP request, SQL query, сторонній extension, cache miss або проблема на рівні infrastructure.
    • Ще один приклад — повільний checkout. Тут причиною можуть бути JavaScript і custom checkout logic, зовнішні API, database queries або extensions, які виконуються під час оформлення замовлення.
    • Або сервер перевантажується під час акцій чи різкого зростання трафіку. У такому випадку проблема може бути в низькому cache hit rate, неправильній Varnish configuration, недостатній кількості PHP-FPM workers, database bottleneck або архітектурі, яка не розрахована на таке навантаження.

    Чому це важливоОдна performance metric не дає готової відповіді — вона лише показує, де проявляється проблема. Під час аудиту ми рухаємося від симптому до root cause: перевіряємо пов’язані компоненти системи, визначаємо джерело bottleneck і вже на основі цього формуємо рекомендації щодо оптимізації.

Який технологічний стек ми аналізуємо

Magento performance залежить від усієї технологічної системи, тому в межах аудиту можемо працювати з:

  • Magento / Adobe Commerce

    Magento Open Source, Adobe Commerce, custom modules, extensions, Magento configuration, indexers, cron, queues, GraphQL, REST API.

  • Backend

    PHP, PHP-FPM, Nginx, custom PHP code, dependency injection, observers, plugins, controllers.

  • Database

    MySQL, SQL queries, indexes, locks, database configuration, query profiling.

  • Caching

    Varnish, Redis, Magento Full Page Cache, block cache, sessions, browser cache, L2 cache.

  • Search

    Elasticsearch, OpenSearch та пов’язані з ними процеси індексації.

  • Frontend

    Luma, Hyvä, custom themes, Alpine.js, Tailwind CSS, JavaScript, CSS, HTML, images, fonts, third-party scripts.

  • Infrastructure

    VPS/VDS, dedicated servers, cloud infrastructure, multi-server architecture, load balancing, CDN та edge infrastructure.

  • Monitoring & profiling

    Lighthouse, PageSpeed Insights, Chrome DevTools, WebPageTest, GTmetrix, New Relic, Blackfire та інші інструменти відповідно до задачі.

Що залишається у вас після аудиту

Після завершення аудиту у вас залишається структурований performance roadmap для Magento-магазину — технічна карта подальших робіт із продуктивністю. Вона допомагає команді перейти від діагностики до конкретних змін і розуміти, які задачі мають найбільший вплив на систему.

Для кожної виявленої проблеми ми фіксуємо:

  1. 01

    Виявлену проблему

    Що саме створює bottleneck і на якому рівні системи він знаходиться: frontend, application, database, cache чи infrastructure.

  2. 02

    Root cause

    Чому виникла проблема та який компонент, процес або технічне рішення її створює.

  3. 03

    Impact

    Як bottleneck впливає на продуктивність Magento, конкретні користувацькі сценарії та поведінку магазину під навантаженням.

  4. 04

    Priority

    Наскільки критично вирішити проблему зараз. Рекомендації розподіляємо за трьома рівнями:

    • Critical / High — проблеми, які вже суттєво впливають на роботу магазину, створюють ризик при поточному навантаженні або можуть призвести до серйозних performance degradation.
    • Medium — проблеми, які не створюють критичних збоїв зараз, але знижують ефективність системи або можуть стати bottleneck при зростанні трафіку, каталогу чи кількості замовлень.
    • Low — покращення, які мають сенс після усунення основних bottlenecks і не потребують першочергового ресурсу команди.
  5. 05

    Рекомендоване рішення

    Конкретний напрямок технічних змін: code optimization, database optimization, cache configuration, infrastructure changes, frontend optimization, extension refactoring тощо.

  6. 06

    Complexity

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

У результаті roadmap показує всі проблеми, які можна покращити в Magento + послідовність дій відповідно до їхнього реального впливу.

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

Коли після аудиту потрібна оптимізація та яких витрат вона потребує

Не кожен performance audit закінчується великим переліком робіт. Іноді проблема локальна та вирішується одним-двома точковими змінами. В інших випадках аудит показує системні bottlenecks, які потребують комплексної оптимізації коду, бази даних, frontend або infrastructure.

Результати аудиту визначають, який обсяг оптимізації потрібен магазину і де команда отримає найбільший performance impact.

Якщо технічні зміни потрібні, Planeta Web може не лише сформувати roadmap, а й реалізувати його в Magento.

Залежно від виявлених bottlenecks це може включати

  • оптимізацію custom code — скорочення зайвих операцій і PHP execution time
  • refactoring проблемних extensions — усунення надмірних запитів та конфліктів
  • database optimization — оптимізацію структури та роботи БД
  • SQL optimization — прискорення slow queries та database operations
  • cache та Varnish configuration — покращення cache hit rate і роботи FPC
  • Redis optimization — оптимізацію cache та customer sessions
  • PHP-FPM tuning — налаштування workers під реальне навантаження
  • infrastructure optimization — розподіл ресурсів і компонентів системи
  • frontend optimization — скорочення ресурсів і часу рендерингу
  • Hyvä optimization — оптимізацію теми та frontend architecture
  • image optimization — зменшення ваги зображень без втрати якості
  • оптимізацію JavaScript — скорочення execution time та blocking
  • роботу з Core Web Vitals — покращення ключових UX-метрик
  • оптимізацію cron та indexers — стабільну обробку фонових процесів
  • оптимізацію API та інтеграцій — скорочення затримок зовнішніх запитів
  • підготовку Magento до масштабування — адаптацію архітектури до майбутнього навантаження

Після впровадження змін ми повторно вимірюємо performance та порівнюємо показники з baseline, зафіксованим під час аудиту. Так ми бачимо фактичний результат оптимізації, а не просто факт виконання технічних задач.

Якщо ж аудит показує, що поточна продуктивність відповідає вимогам магазину, масштабування найближчим часом не планується, а знайдені Low-priority покращення не мають достатнього впливу, масштабна оптимізація може бути недоцільною. У такому випадку roadmap залишається орієнтиром для майбутніх змін і допомагає команді розуміти, на які компоненти варто звернути увагу при наступному релізі, зростанні навантаження чи зміні архітектури.

Чому обирають Planeta Web

Бо в eCommerce ми працюємо не заради красивих performance metrics.

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

Magento performance для нас — частина ширшої експертизи в eCommerce development. Ми працюємо з Magento на різних рівнях: від custom code, modules та extensions до Hyvä, frontend, database, infrastructure, Cloudflare та інтеграцій із зовнішніми системами.

Маємо багаторічний практичний досвід у eCommerce та працюємо з проєктами різного масштабу й складності. Тому дивимося на технічні рішення через призму бізнесу: як швидкість, стабільність і масштабованість магазину впливають на користувацький досвід, конверсію та дохід.

До кожного проєкту залучаємо персонального менеджера, який координує роботу команди та залишається основною точкою комунікації для клієнта. Залежно від задачі до аудиту можуть підключатися Magento-розробники, performance-спеціалісти, DevOps та інші експерти.

За потреби ми можемо пройти з проєктом повний цикл — від аудиту та формування roadmap до впровадження оптимізацій, повторного тестування й подальшої підтримки.

Замовити аудит продуктивності Magento

Якщо Magento-магазин працює повільніше, ніж повинен, не обов’язково починати з масштабування сервера, заміни теми або встановлення чергового optimization extension. Спочатку потрібно зрозуміти, де саме система втрачає продуктивність. Передайте нам інформацію про ваш Magento-магазин — команда Planeta Web проаналізує поточну архітектуру, визначить основні performance bottlenecks та сформує roadmap із пріоритетами для подальшої оптимізації.

Дякуємо! Ми зв’яжемося з вами найближчим часом.

FAQ

Що входить в аудит продуктивності Magento?

Ми аналізуємо frontend, Magento application layer, custom code, extensions, database, cache, Redis, Varnish, infrastructure, cron, indexers, queues та інтеграції. Конкретний набір перевірок залежить від архітектури та проблем конкретного магазину.

Чи достатньо перевірити Magento через Google PageSpeed?

Ні. PageSpeed добре підходить для аналізу frontend performance, але не показує повної картини backend та infrastructure. Для Magento важливо аналізувати весь request lifecycle: браузер, web server, PHP, Magento, database та cache.

Чи потрібно оптимізувати сервер, якщо Magento повільний?

Не обов’язково. Іноді infrastructure є bottleneck, але іноді додаткові ресурси сервера не вирішать проблему повільного SQL-запиту, extension або custom code. Саме тому спочатку визначаємо root cause.

Чи перевіряєте ви сторонні Magento extensions?

Так. Extensions входять до application-level аналізу. Ми визначаємо, чи створюють вони додаткове навантаження на PHP, database, frontend або API та чи можуть бути причиною performance degradation.

Чи можна провести аудит магазину на Hyvä?

Так. Hyvä-магазини також потребують performance audit. Ми окремо аналізуємо frontend architecture, Alpine.js, Tailwind CSS, JavaScript, custom components та інтеграції.

Чи можна провести аудит перед міграцією або масштабуванням?

Так. Performance audit може бути окремим етапом перед міграцією на іншу infrastructure, переходом на Hyvä, масштабуванням Magento або збільшенням очікуваного traffic.

Чи ви не тільки знаходите проблеми, а й виправляєте їх?

Так. Після аудиту можемо сформувати окремий план optimization work та перейти до технічної реалізації. Це дозволяє спочатку визначити пріоритети, а вже потім витрачати ресурс команди на оптимізацію.