Getting a Magento store above 90 in Google Core Web Vitals takes three things working together: image optimization (switching to WebP or AVIF), JavaScript and CSS minification, and a lower server response time (TTFB). Together, these three areas cover most of the technical issues that cost you points. In our experience, most business leaders expect a single quick fix, such as switching on the cache, to work miracles. In reality, a score above 90 is only sustainable when all three areas are optimized at the same time, in a coordinated way. In many cases, Magento stores get stuck around 50–70 points because one area is improved while the other two stay untouched, and that caps the overall potential. This article gives you concrete, practical steps to get a Magento store to a genuine 90+ Core Web Vitals score on both mobile and desktop.
Image optimization: switching to WebP and AVIF
Image optimization delivers measurable Core Web Vitals gains faster and with less risk than any other area, because product photos and banners typically make up most of the total page weight on a Magento catalog page. In our experience, switching from traditional JPEG or PNG to WebP or AVIF alone cuts file sizes by 30–50 percent at the same visual quality, which directly improves Largest Contentful Paint (LCP). In the cases we have analyzed, online stores that introduced automated format conversion for every uploaded image achieved significantly faster category page loads, especially on listing views that show many products at once.
Which specific settings does image optimization require?
Effective image optimization requires automatic conversion to a modern format (WebP or AVIF), lazy loading for images below the fold, and responsive image sizing that serves a differently sized image to each device. When is a format switch alone not enough? When images are still too large for their display area even after conversion. Without responsive sizing, the browser keeps receiving unnecessarily large files, especially on mobile devices.
JavaScript and CSS minification: reducing render-blocking load
JavaScript and CSS minification directly affects Interaction to Next Paint (INP) and First Contentful Paint (FCP), because uncompressed, bloated code files slow down the browser’s processing and rendering. In many cases, we have found that enabling the minification and bundling options available in the native Magento admin settings brings a noticeable improvement on its own. The real breakthrough, however, comes from removing unused CSS rules and JavaScript code, which often builds up from accumulated modules and extensions and weighs the system down for no reason.
Why isn’t enabling built-in minification enough on its own?
Built-in minification is not enough on its own because it only shrinks existing files. It does not remove the unused code left in the system by third-party modules or outdated custom development. Who shouldn’t rely on switching minification on once and forgetting about it? Stores that regularly install new modules, because every new extension adds more potentially unoptimized code that needs to be reviewed on a regular basis.
| Optimization area | Core Web Vitals metric affected | Typical improvement |
| Image optimization (WebP/AVIF) | Largest Contentful Paint (LCP) | 30–50% smaller file sizes |
| JS/CSS minification | Interaction to Next Paint (INP), FCP | Noticeably faster rendering |
| TTFB reduction | Time to First Byte, indirectly LCP | Improvement on the order of seconds |
| Varnish cache implementation | Total page load time | From seconds to milliseconds |
Reducing server response time (TTFB): optimizing the foundation
Reducing server response time, or Time to First Byte (TTFB), is fundamental, because every other optimization, whether for images or JavaScript, only takes effect after the browser has received the server’s first response. In our experience, most clients see the biggest TTFB gains when Varnish cache is configured properly, because cached pages are served straight from memory, without PHP execution or database queries. According to data from an independent performance benchmark, a vanilla Magento 2.4.9 installation without proper optimization produces a mobile LCP of 4.2–5.8 seconds, while the threshold for a “good” rating is under 2.5 seconds. That shows how much the server-side foundation matters for the final score.
Which factors affect TTFB the most in a Magento system?
TTFB is mainly influenced by the quality of the hosting infrastructure, how current the PHP version is, how well database queries are optimized, and the type of Full Page Cache backend (the built-in file system or Varnish). Together, these determine how long it takes the server to build and send its first response. Should you reduce TTFB before optimizing images and code? Yes, because a slow server-side foundation limits the effectiveness of every other optimization, so it always makes sense to start your Core Web Vitals work with the server layer.
How to sustain a score above 90
A one-off optimization round is not enough to keep your Core Web Vitals score above 90, because the score can drop over time as new modules, images, or features are added without optimization. In our experience, most successful stores that maintain consistently high scores introduce regular, recurring performance audits that recheck Core Web Vitals after every significant change.
In what order should you carry out the full optimization process?
Start the full optimization process with the server layer (Varnish cache, TTFB), continue with image optimization, and finish with JavaScript and CSS minification and the removal of unnecessary code. This order ensures that each layer builds on the best possible foundation. When is it a bad idea to focus on a single area? When your goal is a lasting score above 90, because Core Web Vitals metrics are interconnected, and a single neglected area can hold back the entire score.
To reach a Core Web Vitals score above 90, work through these steps in order:
- Configure Varnish cache properly and optimize server-side TTFB.
- Automatically convert every product image to WebP or AVIF and enable lazy loading.
- Minify and bundle JavaScript and CSS files, and remove unnecessary code.
- Review installed modules and phase out extensions that add unnecessary load.
- Measure Core Web Vitals regularly, after every significant change.
Before you start the optimization process, also consider the following:
- Whether your current Magento hosting and operations setup and server environment have the capacity for the required changes.
- The option of adding a CDN to serve static content (images, JS, CSS) faster.
- The impact of existing modules and custom development on current performance.
- The gap between mobile and desktop results, and its causes.
- Setting up regular monitoring to protect your score over the long term.
Lazy loading and handling above-the-fold content
Implementing lazy loading correctly is critical. Deferring images below the fold improves initial page load speed, but applying lazy loading to above-the-fold elements that are visible immediately has exactly the opposite effect and can hurt Largest Contentful Paint. In our experience, the most common mistake is a global lazy loading rule applied to every image, instead of distinguishing between content in the initial viewport and content further down. In the cases we have analyzed, the stores with the best LCP results were those where the hero banner and the images in the first few product rows were explicitly prioritized, while the rest of the content was lazy loaded.
How do you correctly identify which elements can be lazy loaded?
To identify them correctly, determine which elements appear in the initial, unscrolled viewport on the most common device sizes. Those elements need to be prioritized during loading, not lazy loaded. When should you avoid an automatic, blanket lazy loading solution? When the hero banner or featured products appear in the initial viewport on your category pages, because lazy loading them hurts LCP, the most important metric of all.
How third-party scripts affect your Core Web Vitals score
Third-party scripts, such as analytics tools, marketing pixels, and chat widgets, have an often underestimated but significant impact on Core Web Vitals, because they load independently of your own optimization work and can substantially increase JavaScript execution time. In many cases, we have seen the score of an otherwise well-optimized Magento store drop drastically as soon as 5–10 different marketing and analytics scripts are added without any control.
How can you manage third-party scripts without hurting your score?
To manage third-party scripts, use a tag management solution (such as Google Tag Manager) that lets you load scripts in a deferred, conditional way, instead of loading every tool directly and immediately on every page. Should every marketing and analytics tool load immediately on every page? No. Most of these scripts are not critical to the initial user experience, and deferred loading can significantly reduce their negative impact on Core Web Vitals.
Optimizing font loading and reducing Cumulative Layout Shift
Font loading optimization directly affects Cumulative Layout Shift (CLS), because when web fonts are handled poorly, the size and position of text can change suddenly while they load, causing visual shifts and a worse user experience. In our experience, the default font loading strategy of most Magento stores ignores this problem, which is exactly why CLS stays above the target threshold even when image and code optimization are otherwise in good shape.
Which technical solutions reduce layout shift caused by font loading?
To reduce layout shift caused by font loading, use the font-display: swap or font-display: optional CSS property, and preload critical fonts in the HTML head so the browser starts downloading them as early as possible. Who shouldn’t embed web fonts directly without thinking it through? Stores that use custom, non-system typefaces for brand identity reasons, because for them a poor font loading strategy can cause especially severe CLS problems for visitors on slower network connections.
Which optimization order is the right choice for reaching 90
The right choice is never to concentrate on a single eye-catching fix, such as converting images. Instead, develop the server layer, image optimization, and JavaScript/CSS minification in a deliberate, coordinated order where each step builds on the previous one, because Core Web Vitals metrics are closely interconnected. In our experience, most Magento stores that consistently score above 90 started with server-side TTFB and Varnish cache configuration, since a slow foundation also limits the effectiveness of image and code optimization. The switch to WebP or AVIF and the removal of unnecessary code then built on that foundation. In many cases, the biggest yet most frequently overlooked risk comes from third-party marketing and analytics scripts, because they can drastically pull the score down regardless of your own optimization work if they are not managed with a tag management solution and deferred loading.
In our experience, handling lazy loading and font loading correctly are fine-tuning steps without which Largest Contentful Paint and Cumulative Layout Shift will not reach the target level, even after the bigger optimization steps are done. Who isn’t a one-off optimization round right for? Stores that regularly add new modules, images, or features, because their score will drop over time unless regular, recurring performance audits are carried out after every significant change. The right choice, then, is a deliberately layered and continuously maintained optimization practice that covers every layer, from the server-side foundation through images and code all the way to managing third-party scripts. This approach ensures that a Magento store reaches a Core Web Vitals score above 90 not just once, but for the long term.
