Outdated Magento 2 Speed Tips to Drop in 2026
The Magento 2 speed tips that no longer work in 2026 are merging JavaScript and CSS over HTTP/2, tuning query_cache_size (removed in MySQL 8.0), cleaning Magento 1 log tables, relying on Elasticsearch or Redis, and enabling the flat catalog. Use minification over HTTP/2, OpenSearch 3, Valkey and indexers on Update by Schedule instead.
The Magento 2 speed tips that no longer work in 2026 are merging JavaScript and CSS, tuning query_cache_size, cleaning Magento 1 log tables, and relying on Elasticsearch, Redis and the flat catalog. Each made sense at some point, but the platform and its infrastructure moved on, and Adobe's documentation spells out what to do instead.
Plenty of Magento speed guides were written for 2.3 or early 2.4 and have had their dates refreshed without their content. Some quote numbers with no source, or misquote the studies they do cite. This article lists the advice that still circulates, with what's true today and the replacement for each.
Which Magento speed tips are outdated?
| Outdated tip | What's true in 2026 | Do this instead |
|---|---|---|
| Enable Merge JS and Merge CSS | Adobe considers merging deprecated and of no benefit over HTTP/2 | HTTP/2 with minification |
Tune query_cache_size |
The query cache was removed in MySQL 8.0 | innodb_buffer_pool_size |
Clean log_url and log_visitor tables |
Those are Magento 1 tables and don't exist in Magento 2 | Let the visitor_clean cron job run |
| Elasticsearch is required | Deprecated from 2.4.8 and not listed for 2.4.9 | OpenSearch 3 |
| Use Redis for cache and sessions | The latest patches mark Redis as not supported | Valkey 8.1 or 9, depending on your version |
| Enable the flat catalog | No longer a best practice from 2.3.x | Index tables and OpenSearch |
| PHP 8.1 or 8.2 is fine | 2.4.9 requires PHP 8.5 | The version in Adobe's requirements table |
| Varnish caches static files | The default VCL passes /static and /media uncached |
A CDN for static assets |
| Luma has no lazy loading | Core adds loading="lazy" to listing images |
Don't lazy-load the LCP image |
| Just enable built-in JS bundling | Adobe calls it a fallback; it loads every bundle on the first visit | HTTP/2 or advanced bundling |
| TTFB and TTI are key metrics | TTFB isn't a Core Web Vital, and Lighthouse 10 removed TTI | LCP, INP and CLS |
| Magento's cache is stored in the shopper's browser | The cache is server-side: var/cache, Valkey or Varnish |
Cache Management and cache:clean |
Why is merging JavaScript and CSS a mistake now?
Merging cut request counts back when HTTP/1.1 needed a connection per file. HTTP/2 downloads many files over one connection, so merging just produces one large file for no benefit. Adobe says so directly: don't merge or bundle files if your deployment uses HTTP/2.
Built-in JS bundling is worse: it loads every bundle on the first visit, whether the page needs it or not. Adobe measured a clean-install homepage on a Slow 3G connection taking about 44 seconds to load its bundles. Use minification, HTTP/2, page-type advanced bundling, or a lighter theme such as Hyvä. How RequireJS loads files in the first place is covered in the frontend lesson (Arabic, with English code).
Why don't query_cache_size and log tables matter?
- Query cache: MySQL 8.0 removed it entirely, and MariaDB disables it by default because it doesn't scale under load. Any guide recommending
query_cache_sizewas written for an old version. - Log tables: names like
log_url,log_visitoranddataflow_batch_exportcome from Magento 1. In Magento 2 thevisitor_cleancron job cleans thecustomer_visitortable daily on its own. - The setting sometimes called "log cleaning": MySQL Message Queue Cleanup removes messages from database-backed queues, and its defaults are sensible. It has nothing to do with page speed.
What does matter in the database is keeping tables and indexes in memory and writing collections well, covered in the database and performance lesson (Arabic).
Why are Elasticsearch, Redis and the flat catalog behind us?
- Elasticsearch: its modules have been deprecated since Magento 2.4.8, it isn't listed in the 2.4.9 requirements, and Elasticsearch 7.17 reached end of support on January 15, 2026. Use OpenSearch 3.
- Redis: Adobe's requirements for the latest 2.4.6, 2.4.7 and 2.4.8 patches mark it as not supported and list Valkey 8.1; 2.4.9 requires Valkey 9. The steps are in moving Magento from Redis to Valkey.
- Flat catalog: Adobe says it's no longer a best practice from 2.3.x, and both settings are off by default. Magento relies on index tables instead, explained in the indexers lesson (Arabic).
What goes wrong with lazy loading?
There are two opposite mistakes. One is believing Magento has no lazy loading; in fact core's listing image template outputs loading="lazy" and image dimensions. The other is lazy-loading everything, which delays the main image that determines LCP: web.dev found pages that did so had a median LCP of 3,546 ms versus 2,922 ms without.
The rule: load the main above-the-fold image immediately and lazy-load the rest.
How should you read speed statistics in articles?
- Ask for the source: figures like "every 100 ms costs 1% of sales" circulate widely without a link to an original study.
- Read the study itself: web.dev's Rakuten 24 case study reports a 53.37% increase in revenue per visitor and a 33.13% increase in conversion rate, and some articles swap the two. Tokopedia's study reports a 23% increase in average session duration, not in conversions.
- Separate lab from field: a PageSpeed score is a lab measurement, while the Core Web Vitals assessment uses real-user data at the 75th percentile.
- Know the current metrics: the Core Web Vitals are LCP, INP and CLS. TTFB is a diagnostic, and TTI was removed in Lighthouse 10 in 2023.
The full order of changes that do make a difference is in the Magento 2 speed checklist for 2026.
Checklist: audit your store's settings
-
dev/js/merge_filesanddev/css/merge_css_filesare off if you serve HTTP/2 - The database configuration has no
query_cache_size - The search engine is OpenSearch 3, not Elasticsearch
- Cache and sessions run on Valkey at the required version
- Use Flat Catalog Category and Use Flat Catalog Product are set to No
- PHP matches the requirements table for your version
- No scripts clean Magento 1 tables
- The LCP image isn't lazy-loaded
- You measure LCP, INP and CLS from real users
Sources
Technical claims in this article were checked against:
- Adobe — Optimize CSS and JavaScript files
- Adobe — Advanced JavaScript bundling
- MySQL 8.0 — What is new (query cache removed)
- Adobe — System requirements
- Adobe Commerce 2.4.8 release notes
- Adobe — Flat catalog
- Magento source — varnish7.vcl (2.4-develop)
- Magento source — Customer crontab.xml (2.4-develop)
- Magento source — image_with_borders.phtml (2.4-develop)
- Adobe — Cache management
- web.dev — Lazy loading and LCP
- web.dev — Time to First Byte
- Chrome for Developers — Lighthouse 10
- web.dev — Rakuten 24 case study
- web.dev — Business impact of Core Web Vitals
Frequently asked questions
Should I enable the flat catalog in Magento 2.4?
No. Adobe says the flat catalog is no longer a best practice for 2.3.x and later, and both Use Flat Catalog Category and Use Flat Catalog Product are off by default in core.
Does query_cache_size speed up Magento 2?
No. The query cache was removed in MySQL 8.0, and MariaDB disables it by default because it scales poorly. The setting that matters is innodb_buffer_pool_size, so tables and indexes stay in memory.
Does Magento 2.4.9 support Elasticsearch?
Elasticsearch isn't listed in the 2.4.9 requirements, its modules have been deprecated since 2.4.8, and Elasticsearch 7.17 itself reached end of support on January 15, 2026. Use OpenSearch 3.
Should every image in a Magento store be lazy-loaded?
No. Magento already lazy-loads category listing images, but the main above-the-fold image should load immediately. web.dev found pages that lazy-load images had a median LCP of 3,546 ms versus 2,922 ms without.
Is TTFB a Core Web Vital?
No. The Core Web Vitals are LCP, INP and CLS. TTFB is a diagnostic that affects LCP, and web.dev treats 0.8 seconds or less as a rough guide for good.
Related lessons (Arabic)
These free lessons are written in Arabic; code and technical terms are in English.