Optymalizacja Wydajności Magento 2 – Varnish, Redis, PHP-OPcache, Core Web Vitals

Wydajność Magento to nie pojedyncza opcja do włączenia – to pięć warstw optymalizacji: serwer WWW (Nginx + Varnish), cache aplikacji (Redis), silnik PHP (OPcache), baza danych (MySQL query tuning) i frontend (Core Web Vitals). Każda warstwa ma swoje wąskie gardła i swoje narzędzia diagnostyczne. Domyślna konfiguracja Magento jest ustawiona na “bez błędów”, nie na “maksymalną prędkość”.

Varnish FPC – serwowanie z pamięci RAM

Varnish Cache działający jako reverse proxy przed Nginx serwuje pełnoekranowy cache (Full Page Cache) bezpośrednio z pamięci RAM. Użytkownik niezalogowany nie dotyka PHP ani bazy danych – dostaje odpowiedź w <50ms. To absolutna konieczność dla każdego sklepu z ruchem powyżej 100 odwiedzin dziennie.

Diagnostyka i zarządzanie Varnish przez CLI

Kluczowe komendy do monitorowania hit-rate cache, czyszczenia i analizy ruchu w czasie rzeczywistym.

# Sprawdzenie hit-rate Varnish (powinien być >90% na produkcji):

varnishstat -1 | grep -E "MAIN.cache_hit|MAIN.cache_miss|MAIN.sess_conn"

# Podróż ruchem przez Varnish w czasie rzeczywistym:

varnishlog -g request -q "ReqMethod ne 'PURGE'" | grep -E "ReqURL|RespStatus|Hit|Miss"

# Włączenie Varnish FPC w Magento (po instalacji Varnish):

php bin/magento config:set system/full_page_cache/caching_application 2

# Eksport konfiguracji VCL z Magento (wgraj do Varnish):

php bin/magento varnish:vcl:generate --export-version=6 > /etc/varnish/magento.vcl

# Czyszczenie pełnego cache Varnish (PURGE wszystkiego):

varnishadm "ban req.url ~ ."

Redis – cache aplikacji i sesje

Magento używa Redis do dwóch krytycznych celów: cache bloków aplikacji (konfiguracja, tłumaczenia, układ stron) i przechowywania sesji użytkowników. Kluczowa zasada: zawsze używaj oddzielnych instancji (lub przynajmniej osobnych baz danych) dla sesji i cache. Współdzielona instancja może doprowadzić do eviction sesji przez dane cache – użytkownicy będą tracili koszyk bez ostrzeżenia.

Pro Tip: Separacja Redis – poprawna konfiguracja env.php

Fragment pliku app/etc/env.php z oddzielonymi bazami danych Redis dla cache (db 0) i sesji (db 1). Nigdy nie użwaj tej samej bazy.

// env.php – konfiguracja Redis (fragment):

'cache' => [

'frontend' => [

'default' => ['backend' => 'Magento\Framework\Cache\Backend\Redis',

'backend_options' => ['server' => '127.0.0.1', 'database' => '0']],

'page_cache' => ['backend' => 'Magento\Framework\Cache\Backend\Redis',

'backend_options' => ['server' => '127.0.0.1', 'database' => '1']],

]

'session' => ['save' => 'redis',

'redis' => ['host' => '127.0.0.1', 'database' => '2']], // osobna baza!

Diagnostyka Redis przez CLI

Monitorowanie pamięci, hit-rate i ewentualnych evictions – kluczowe przy skalowaniu sklepu.

# Zużycie pamięci Redis:

redis-cli info memory | grep -E "used_memory_human|maxmemory_human|mem_fragmentation_ratio"

# Statystyki hit-rate cache Redis:

redis-cli info stats | grep -E "keyspace_hits|keyspace_misses"

# Liczba kluczy w każdej bazie (0=cache, 1=FPC, 2=sesje):

redis-cli info keyspace

# Czyszczenie tylko cache Magento (bez sesji):

php bin/magento cache:flush && redis-cli -n 0 flushdb && redis-cli -n 1 flushdb

PHP OPcache – kompilacja kodu raz, używanie wielokrotnie

PHP OPcache przechowuje skompilowany bytecode PHP w pamięci RAM. Bez OPcache każde żądanie HTTP wymaga ponownej interpretacji dziesiątek tysięcy plików PHP Magento. Z OPcache – kod jest już skompilowany. Niepoprawna konfiguracja OPcache (za mały memory_consumption lub zbyt mała liczba opcache.max_accelerated_files) to jeden z najczęstszych i najtrudniejszych do wykrycia problemów wydajnościowych.

Zalecana konfiguracja PHP OPcache dla Magento 2

Minimalne wartości dla instalacji produkcyjnej Magento 2.4.x. Zbyt niskie wartości powodują ciche resetowanie cache pod obciążeniem.

; /etc/php/8.3/fpm/conf.d/10-opcache.ini

opcache.enable=1

opcache.memory_consumption=512 ; min. 512MB dla Magento 2

opcache.interned_strings_buffer=64

opcache.max_accelerated_files=130000 ; Magento ma ~100k plików PHP

opcache.revalidate_freq=60 ; 0 na dev, 60 na prod

opcache.fast_shutdown=1

opcache.enable_cli=1

# Sprawdzenie stanu OPcache (wymagany php-cli z opcache):

php -r "print_r(opcache_get_status(false));" | grep -E "num_cached_scripts|memory_usage"

Optymalizacja obrazów i Core Web Vitals

Obrazy to 70–80% wagi strony – i najszybszy obszar do optymalizacji. Konwersja do WebP (obsługiwany przez 97% przeglądarek) redukuje rozmiar o ~50% bez straty jakości. Na poziomie serwera Nginx może serwować .webp automatycznie, gdy przeglądarka go obsługuje.

Core Web Vitals wpływają bezpośrednio na ranking Google. Kluczowe metryki dla Magento to LCP (Largest Contentful Paint – główne zdjęcie produktu), CLS (Cumulative Layout Shift – skoki layoutów przy ładowaniu bloków) i INP (Interaction to Next Paint – reakcja na dodanie do koszyka).

WebP na poziomie Nginx

Nginx sprawdza nagłówek Accept i serwuje .webp jeśli istnieje. Brak zmian w kodzie Magento – czysta optymalizacja serwerowa.

Critical CSS (ponad the fold)

Wyłącz CSS blokujący renderowanie. Włącz: Stores → Config → Advanced → Developer → CSS Settings → Use CSS Critical Path.

Minifikacja i łączenie JS/CSS

Stores → Config → Advanced → Developer. Włącz Merge JS Files, Minify JS, Minify CSS. Wymagane przy wyłączonym Hyvä (pełny Luma).

Lazy loading obrazów

Magento 2.4.4+ obsługuje natywny loading="lazy" dla obrazów produktu. Zmniejsza początkowy rozmiar transferu o 40–60%.

Profilowanie SQL – wykrywanie wąskich gardeł

Magento 2 może wykonywać kilkaset zapytań SQL na jedno żądanie HTTP. Problem N+1 (pętla generująca osobne zapytanie dla każdego produktu) jest niezwykle częsty w źle napisanych wtyczkach. Query Profiler wbudowany w Magento oraz MySQL Slow Query Log to podstawowe narzędzia diagnostyki.

Pro Tip: Włączenie Query Profilera i Slow Query Log

Dwa poziomy diagnostyki SQL: Magento Query Profiler (widoczny w stopce admin) i MySQL Slow Query Log (wszystkie zapytania >1s).

# Włączenie Query Profilera Magento (tylko na dev/staging!):

php bin/magento dev:query-log:enable

# Podgląd zalogowanych zapytań SQL:

tail -f var/debug/db.log | grep -v "catalogsearch\|session"

# MySQL: włączenie Slow Query Log (zapytania >1s):

SET GLOBAL slow_query_log = 'ON';

SET GLOBAL long_query_time = 1;

SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

# Analiza najwolniejszych zapytań:

mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

Najczęstsze problemy wydajnościowe i ich źródła

TTFB > 2s mimo Varnish

Varnish cache miss – strony nie są cachowane. Sprawdź nagłówek X-Cache: MISS i logi VCL. Może być błąd w konfiguracji cookie-based exclusion.

Koszyk znika przy dużym ruchu

Eviction sesji przez Redis – współdzielona baza dla cache i sesji, brak ustawienia maxmemory-policy noeviction dla sesji.

Wysokie CPU PHP przy każdym żądaniu

OPcache wypłukuje się pod obciążeniem – za małe opcache.max_accelerated_files lub za małe memory_consumption.

Wolne ładowanie strony kategorii

Problem N+1 w pluginie lub zestawach atrybutów. Włącz Query Profiler i szukaj powtarzających się zapytań SELECT * FROM catalog_product_entity_varchar.

CLS (layout shift) na stronie produktu

Blok ceny lub promocji ładuje się asynchronicznie i przesuwa treść. Zdefiniuj wymiary kontenera przez CSS, aby zarezerwować miejsce przed załadowaniem bloku.

Wolna reindeksacja blokuje frontend

Indeksatory w trybie Update on Save blokują zapis produktu. Przełącz na Update by Schedule i sprawdź, czy Cron działa co 1 minutę.

Optymalizacja wydajności to proces ciągły – każda nowa wtyczka, aktualizacja lub zmiana asortymentu może wprowadzić regresję. W Mage24.pl każde środowisko produkcyjne dostarczamy z prekonfigurowanym Varnish, Redis (z separacją baz), OPcache i monitoringiem APM – gotowe na ruch od pierwszego dnia.

Optymalizacja: Piekielnie Szybkie Magento 2