We've encountered this scenario: a Magento 2 page loading in 8 seconds, each request triggering 300 SQL queries and 60 file operations. Clients leave, conversion drops. The solution isn't just enabling cache—it's building the right stack: CDN → Varnish → Nginx → PHP-FPM 8.2 → MySQL 8.0, each layer tuned for the platform. In 6–10 business days we bring TTFB down to 200–500 ms. This article covers proven methods and configurations we use on commercial projects.
A recent case: a store with a 50,000 SKU catalog on shared hosting—pages loaded in 12 seconds, LCP 8 seconds. An audit revealed the “Featured Products” plugin made 150 SQL queries per page. After configuring Varnish and fixing N+1, TTFB dropped to 0.3s, LCP to 1.2s. Comparison: Varnish outperforms Magento's built-in cache 10x in TTFB, and Redis reduces block generation time from 50 ms to 1–2 ms.
Why Magento 2 is Slow
A default installation executes 200–400 SQL queries and 50–100 file operations per page. Typical causes:
-
N+1 problems —
afterLoadplugins, collections withoutaddAttributeToSelect, loading products one by one. - No Varnish — dynamic content regenerated on every request.
- MySQL untuned — default buffer 128 MB, redo log 48 MB.
- PHP without OPcache/JIT — code interpreted on every request.
- MySQL search —
LIKE '%query%'for a catalog of 10,000+ SKUs gives 2–5 second response.
How We Configure the Stack
Varnish
Varnish is a reverse proxy cache that stores full HTTP responses. For anonymous users, hit rate reaches 85–95%. VCL configuration accounts for Magento's architecture: we skip sessions, cart, checkout, and cache everything else.
Redis
Redis is used for cache (config, layout, block HTML, full page cache) and session storage. This eliminates disk I/O and reduces MySQL load. Setup includes separate instances for different data types.
PHP 8.2 + OPcache + JIT
Upgrading to PHP 8.2 yields a 15–25% boost on CPU-bound operations. OPcache with 512 MB memory and JIT in tracing mode accelerates script execution by up to 20%.
; /etc/php/8.2/fpm/conf.d/opcache.ini
opcache.enable=1
opcache.memory_consumption=512
opcache.interned_strings_buffer=64
opcache.max_accelerated_files=60000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.fast_shutdown=1
opcache.enable_cli=1
; JIT
opcache.jit=tracing
opcache.jit_buffer_size=256M[magento]
user = www-data
group = www-data
listen = /run/php/php8.2-fpm-magento.sock
listen.backlog = 65535
pm = dynamic
pm.max_children = 40
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 2000
php_admin_value[memory_limit] = 768M
php_admin_value[max_execution_time] = 600
php_admin_value[opcache.file_cache] = /tmp/opcacheMySQL
InnoDB buffer pool — 70% of server RAM. Redo log 1 GB, flush method O_DIRECT, query cache disabled (mutex kills concurrency). Below is a typical configuration for a 16 GB RAM server.
[mysqld]
innodb_buffer_pool_size = 8G
innodb_buffer_pool_instances = 8
innodb_log_file_size = 1G
innodb_log_buffer_size = 64M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_read_io_threads = 16
innodb_write_io_threads = 16
innodb_thread_concurrency = 0
query_cache_type = 0
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1Elasticsearch
We replace MySQL search with Elasticsearch — full-text search with relevance, autocomplete, faceted filtering. After reindexing, a search page with 50,000 products responds in 50–150 ms instead of 2–5 seconds.
What to Do About N+1 Queries
Diagnosing N+1
Diagnosis is performed using `n98-magerun2` — we enable query logging, open a page, and analyze the file. Typical sources:-
afterLoadplugins that issue queries for each collection record - EAV attributes without
addAttributeToSelectin the collection - blocks calling
$product->load($id)instead of working with the collection
The correct pattern is to load the collection in one query for all data, not 24+1.
How to Measure Optimization Results
| Metric | Before Optimization | After Optimization |
|---|---|---|
| TTFB | 3–8 s | 0.2–0.5 s |
| SQL queries | 200–400 | 20–50 |
| LCP | >4 s | <1.5 s |
| FCP | >3 s | <1 s |
| Search response | 2–5 s | 50–150 ms |
Measurements are done using Chrome DevTools, Lighthouse, Blackfire. For production, we recommend monitoring Core Web Vitals via Search Console and RUM.
How Long Does Optimization Take?
PHP and Varnish tuning — 2–3 days. MySQL and Elasticsearch — 1–2 days. N+1 audit, cron, CDN — 2–3 days. Full optimization — 6–10 business days. We estimate your project within 1–2 days after providing access.
Typical Problems and Their Solutions
| Problem | Solution | Typical Gain |
|---|---|---|
| High TTFB | Varnish + CDN | 10x speedup |
| Many SQL queries | Fix N+1, flat catalog | 90% reduction |
| Slow search | Elasticsearch | 20–50x faster |
| Low cache hit rate | VCL tuning, exclusions | 85–95% hit rate |
We guarantee stable results after optimization. With over 8 years of Magento experience and 50+ store acceleration projects completed, contact us for an audit — we will assess your current performance and propose a plan. Order a turnkey Magento 2 performance optimization — get a measurable boost in conversion and customer satisfaction.