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

Аналізуємо:

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.

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

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.

Під час аудиту перевіряємо:

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 та інші засоби залежно від доступної інфраструктури.

Ми перевіряємо:

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.

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

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 у відповідній архітектурі. 

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

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

cron configuration;

частоту запуску задач;

execution time;

cron backlog;

indexers;

queue consumers;

паралельне виконання процесів;

конфлікти між background jobs;

вплив імпортів та синхронізацій на storefront;

пікове навантаження на сервер.

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

Тут варто звернути увагу на:

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.

Ми досліджуємо інтеграції з:

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 сторінки.