Yuvraj Raulji | Magento performance
A slow Magento store is rarely slow because of the theme. Time to first byte climbing while the lab score looks respectable points below the front end every time: cache invalidation, a query plan, an index doing a full scan. Fixing the images first is the most common wasted month in Magento performance work.
Direct answer
Magento 2 is slow for infrastructure and data reasons far more often than for front-end ones. The usual causes are full-page cache being invalidated too widely, Redis or Varnish misconfigured or absent, indexers running on save rather than on schedule, and database queries that scan rather than seek on a large catalogue. Fixing those changes time to first byte, which is the number every other metric sits on top of. Image and JavaScript work matters too, but it improves what the visitor sees after the server has already answered, so on Magento it comes second.
Best suited for
- Time to first byte climbing under real traffic
- Core Web Vitals failing in field data while lab scores pass
- Large catalogues where indexing is a planning constraint
- Stores that got slower after a sale or a catalogue import
The problem
The symptom as the person carrying it would describe it, and the part that shows up in the numbers rather than in the ticket queue.
The lab score is fine and real users are not
What it costs
Lighthouse passes on a fast connection and Core Web Vitals fail in the field, so the team optimises what the tool measures rather than what the customer experiences. Google ranks on the field data, and the customer leaves on it too.
Time to first byte climbs with traffic
What it costs
The store is fastest when nobody is using it, which points at caching and query cost rather than at page weight. It fails hardest during exactly the campaigns the business spent money on.
A single catalogue import slows the whole site
What it costs
Indexers reindex on save, cache is invalidated broadly, and an ordinary merchandising task becomes an outage. Operations learn to import at night, which hides the problem rather than fixing it.
Checkout is where the speed loss actually costs money
What it costs
A slow category page loses patience; a slow checkout loses the order that was already won. It is the highest-value place to measure and the one most often left until last.
Approach
In this order, and the order is the opinion. Most of what goes wrong on this kind of engagement is a step taken before the one it depends on.
Measure the field, not the lab
Real user data first, segmented by device and template, so the work targets the pages and the conditions that actually carry revenue. A lab score is a useful check afterwards and a poor place to start.
Work down the stack, not across the surface
Cache configuration, then query and index behaviour, then the front end. Almost every Magento engagement that starts with images ends up repeating the work once the server response is fixed.
Fix cache invalidation, not just cache hits
Full-page cache, Varnish and Redis tuned together, with attention to what invalidates what. Broad invalidation is why a store with caching enabled still behaves as though it has none.
Tune the database and the indexers
Query plans, indexer mode, and the specific scans that only appear at catalogue scale. This is where large-catalogue Magento differs most from the generic advice written for small stores.
Then the front end, and hold it
CDN, image pipeline, critical path and layout stability, followed by a monitor so the gain does not quietly erode over the next two releases. Performance work without a monitor is a one-off, not an improvement.
Scope
Caching
VarnishRedisFull-page cacheInvalidation strategyCDN configuration
Data layer
Query plan analysisIndexer mode and schedulingMySQL tuningElasticsearch and OpenSearch
Infrastructure
AWS provisioningPHP-FPM tuningNginx configurationCron and queue behaviour
Front end
Core Web VitalsImage pipelineCritical pathLayout stabilityCheckout speed
Proof
Both carry catalogue volume large enough that indexing and query cost, not page weight, set the speed.
Magento 2 · Marketplace
Multi-category marketplace
A scalable Magento 2 platform powering a wide multi-category retail catalogue.
Magento 2Multi-categoryScale
Custom platform · B2B
Procurement and approvals platform
Scalable B2B procurement platform streamlining purchase requests and approvals.
B2B workflowsApprovalsIntegrations
Outcome
60%
Improvement in site speed
Delivered through caching, CDN and database optimization on a high-traffic platform. None of it touched the theme, which is the point of the caching-first order of work on this page.
Where this came from
From the verified delivery record: site speed improved by 60% through caching, CDN and database optimization.
Core Web Vitals measured where they count
Field data on real devices rather than a lab score, segmented by template, so the improvement shows up in what Google uses to rank and in what a customer on a mid-range phone actually waits for.
The figure above comes from one platform and its own starting position. A store that already has Varnish and Redis configured correctly has less headroom than one that does not, and quoting the same percentage to both would be dishonest.
Questions
- Why is my Magento 2 store slow when the server looks idle?
- Usually cache invalidation. When full-page cache is invalidated too broadly, a large share of requests miss the cache and are built from scratch, so the platform behaves as though caching were switched off while the infrastructure graph looks calm. The fix is in what invalidates what, not in a bigger server.
- Will a bigger server fix Magento performance?
- It buys headroom and hides the cause. If the store is slow because of cache misses, scans on a large catalogue or indexers running on save, more hardware moves the ceiling without changing the shape of the problem, and the cost recurs monthly.
- How do Core Web Vitals apply to Magento?
- They are measured on real visits, so the number that matters is field data rather than a Lighthouse run. On Magento the server response usually dominates, which means caching and query work move the vitals more than image compression does, and category and product templates need measuring separately because they fail differently.
- Does Magento performance work help SEO or conversion more?
- Both, at different points. Speed is a ranking input and a genuine one at the slow end of the scale, but the larger commercial effect is usually conversion, and it concentrates in checkout, where the order has already been won and is waiting on the server.
- How long before the improvement shows up?
- Server-side gains are visible immediately in field data collection, and Core Web Vitals reporting moves over the following weeks because it is measured on a rolling window. Conversion effects are visible sooner than ranking effects, which is worth knowing before setting expectations with a board.
Next step
Describe what is actually in front of you and we will work out whether this is the right piece of work before anyone scopes it. That conversation is usually shorter than people expect, and it occasionally ends with me saying you do not need the project.