Slow Magento 2 store: how to improve your Google PageSpeed score and Core Web Vitals (from Lighthouse to SQL)

First, measure the right way

PageSpeed Insights shows two different things: field data (what real visitors experienced over the last 28 days) and the Lighthouse lab test. Google uses field data to assess experience; Lighthouse helps you find the cause.

I measure the pages that sell: home, category, product, cart and checkout. Each page type has different bottlenecks, and optimising only the home page rarely solves anything.

• LCP (largest visible element): good up to 2.5 s
• CLS (layout stability): good up to 0.1
• INP (interaction response): good up to 200 ms
• TTFB (time to first byte): the backend thermometer

Frontend: the Lighthouse report, item by item

On Magento 2 with Luma or a derived theme, the same culprits show up. I open the report and treat each opportunity as a task, in order of impact:

• LCP image without priority: a banner or product photo loading late, without dimensions or a modern format (AVIF/WebP).
• Render blocking: a huge CSS file in the head, fonts without preload and synchronous third-party JavaScript.
• The RequireJS dependency tree: dozens of modules loaded before the page is usable. Badly configured bundling makes it worse, not better.
• Knockout.js working too hard: minicart, customer-data and widget components re-rendering every time a section reloads, which hurts INP.
• CLS: promo blocks, cookie banners and reviews pushing content after the page appears.

Backend: where high TTFB comes from

If the server is slow to deliver HTML, no frontend tweak will save LCP. In Magento, high TTFB almost always comes from a cache that isn't working or from heavy queries.

• Full Page Cache invalidated by non-cacheable blocks (a single cacheable="false" in the layout disables caching for the whole page).
• Slow SQL queries on catalogue collections, EAV attributes and stale indexes. The slow query log and EXPLAIN show where an index is missing.
• Redis badly sized for cache and sessions, or sessions still stored in files.
• Extension plugins and observers running on every request, even where they aren't needed.

Why the score fluctuates (and what a realistic goal is)

Mobile Lighthouse simulates a mid-range device on a slow network, so the score varies a few points between runs. That is why I compare several runs and, above all, follow field data.

A Magento store full of integrations can have green Core Web Vitals. The goal that matters is not a pretty number in a screenshot: it is real visitors loading and buying without waiting.

How I run an optimisation

• Baseline measurement of key pages (lab + field).
• A list prioritised by impact: frontend and backend together.
• Fixes in small batches, with a deploy and a new measurement after each one.
• A before-and-after report, with what was done and what is still worth doing.