Аудит производительности 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 страницы.