Why Magento is slow by default
Magento 2 is built for flexibility and extensibility, not for speed. A default Magento installation with a handful of popular extensions already delivers a JavaScript bundle that the browser needs seconds to parse before anything becomes visible.
- ▸Heavy theme JavaScript: frameworks like Infortis Ultimo or RWD load complete UI libraries, even on pages that don't use them.
- ▸RequireJS module loading: Magento's front-end bundling system is built for compatibility, not performance. Each module loads its own dependencies in a waterfall of requests.
- ▸Plumrocket and cookie consent plugins: these modules inject scripts that are render-blocking as long as there is no user consent.
- ▸Plugin sprawl: each extension adds CSS and JavaScript to every page, without checking whether it is needed there.
- ▸No hero LCP prioritization: the product hero or banner image is treated as a regular image by default, without eager load or fetchpriority.
- ▸Shared hosting TTFB: on Hypernode plans that are not well configured, or on shared environments without Full Page Cache, Time to First Byte already exceeds 800ms.
PSI lab simulates this under worst-case conditions: 4x CPU throttle, Slow 4G network. That explains why lab scores come out so low for Magento stores. It is not a sign that the store is unusable. It is a signal that there is room for improvement that real visitors will feel directly.
PSI lab versus CrUX: what real visitors experience
PageSpeed Insights shows two types of data side by side, and most store owners only read the lab score. That is the number that varies and disappoints. The field data below it, fed by the Chrome User Experience Report (CrUX), is what your customers actually experience.
Lab measures on a simulated device: 4x CPU throttle, Slow 4G, Lighthouse engine on a Google server. Field data measures on the hardware and connections of real visitors over the past 28 days. For Magento stores that primarily have desktop traffic, or visitors with 4G+ connections, the difference between lab and field is substantial.
For CarCare24, the mobile lab LCP was 14 to 16 seconds. The CrUX LCP over 28 days: 2.14 seconds. That is not because the store performs so well that lab cannot keep up. It is because lab simulates a worst-case scenario. I optimize for what your customers experience, not for what Lighthouse reports. CrUX is the source of truth for Core Web Vitals ranking in Google.
My audit approach for Magento 2
A Magento performance audit does not start with guessing. I measure first, then analyze, then prioritize. The difference from a generic web performance audit: I know the Magento internals that others overlook.
- ▸PSI API on homepage, category page, product page and checkout page: each page type has its own bottleneck profile.
- ▸Network waterfall in Chrome DevTools: which request is the LCP candidate, what loads before it, which script blocks the render.
- ▸CrUX dashboard and Google Search Console CWV report: what real visitors see over the past 28 days, per page type.
- ▸Magento mode check: is the store in developer mode on production? Then RequireJS runs unbundled and every JS file is a separate request.
- ▸Full Page Cache status: is Varnish or Magento FPC active and correctly configured? TTFB above 800ms is almost always a cache miss.
- ▸MagePack or requirejs bundling analysis: is JS already bundled and minified, and if so, how is the bundle strategy set up?
- ▸Third-party impact: how much main thread time do Plumrocket, GTM, chat widgets and consent banners claim together?
From this analysis comes a ranked list of bottlenecks. Not sorted by how easy they are to fix, but by how much impact the fix has on CrUX. That is the difference between score chasing and actually improving.
What I typically fix on Magento
After the audit I implement the fixes with the highest CrUX impact. On Magento stores it is almost always a combination of the following interventions:
- ▸Hero image: loading=eager and fetchpriority=high on the LCP candidate. This is the fastest win on almost every Magento store. The banner or product image above the fold is lazy-loaded by default. That is precisely wrong.
- ▸WebP conversion: Magento 2.4.x has built-in WebP support via the media gallery. Activating and testing per browser support is a matter of configuration.
- ▸Deferred third-party scripts: Plumrocket consent, GTM, livechat widgets and social embeds moved to after first contentful paint. They must not block the render.
- ▸Custom CSP module: a Content Security Policy that is too broad or too permissive blocks on some Magento installations scripts that are needed. I write a module that correctly enforces the CSP without breaking functionality.
- ▸MagePack bundling tuning: MagePack groups RequireJS modules per page type. Incorrect configuration actually gives larger bundles. I analyze the bundle profile and adjust the configuration.
- ▸Full Page Cache warming: a cold cache gives high TTFB on the first visitor. With a cache warmer script every page is pre-generated.
Which of these fixes apply depends on your installation, theme and extension set. On a Hypernode environment with Cloudflare Free, different levers are available than on a generic VPS. I adapt the approach to what your stack allows.
-- Client case
CarCare24: from 14 seconds lab LCP to 2.14 seconds CrUX
CarCare24 is a Magento 2 store with approximately 3,400 products in 4 languages (NL, EN, DE, FR), hosted on Hypernode with Cloudflare Free. The Infortis Ultimo theme, custom extensions and multiple third-party scripts created a complex front-end stack. Before the performance waves, the mobile LCP in PSI lab was 14 to 16 seconds.
The audit identified three primary bottlenecks: the hero banner loaded without eager/fetchpriority, so the browser only fetched it after all blocking scripts were done. Plumrocket cookie consent blocked render until user interaction. And the RequireJS bundle configuration led to more parallel requests than the browser could handle without main thread conflict.
After nine performance waves the results are as follows. PSI lab mobile: LCP 6.8 seconds. The lab score varies between 38 and 65 on the same day, depending on CPU throttle variance on the Google server. That is normal for lab conditions and no cause for concern. What the actual situation is: CrUX over 28 days shows LCP 2.14 seconds, INP 111ms, CLS 0.05, FCP 1.44 seconds. All Core Web Vitals are in the green. Accessibility went from 90 to 100, Best Practices from 88 to 96, SEO 100. PSI lab is a worst-case simulation. CrUX is what your customers experience. I steer on the second.
What I don't do
There are ways to push a Lighthouse score up without visitors noticing any improvement. I don't use them, and I always explain why a certain tactic is inadvisable.
- ✕Score chasing without CrUX context: a score of 90 in lab that is not reflected in CrUX field data is worth little. I optimize for field data, not for lab screenshots.
- ✕Unauthorized preload hints: fetchpriority=high on resources not on the critical path gives the browser wrong priority signals and can worsen performance.
- ✕Theme rewrites without cost analysis: a full Hyvä migration solves a lot, but also costs substantially. If the current stack already hits CrUX targets with targeted fixes, a theme rewrite is not a proportionate choice.
- ✕Hiding images to reduce CLS: getting the visual stability score up by hiding elements does not fix the root cause.
- ✕Serving lighter pages to bots: Google detects cloaking and penalizes it. The page Lighthouse sees must be identical to what visitors see.
I always give insight into the trade-off: what does a fix cost, what does it yield in CrUX, and what is the risk assessment for the rest of the store.
Pricing and scope
The price of a Magento performance engagement depends on three factors: the size of the store (number of unique page types and products), the number of extensions and the complexity of the theme stack, and whether you want only the audit or also the implementation.
I don't work with fixed price packages for Magento work. A small store with a standard theme and ten extensions has a different scope than a store with 3,400 products, custom CSP, MagePack and Cloudflare rules. Pricing is always on request, after an initial orientation call. In that call I determine the scope and give a fixed price for the audit phase.