Magento PageSpeed optimization is one of the key tools for evaluating the technical performance of a website. Its metrics directly affect not only SEO but also user experience: page load speed, interface stability, and responsiveness during interaction.
For eCommerce projects, especially on Magento, these parameters are particularly important: high loading speed directly affects conversion and retention rates.

However, it is important to understand that Google PageSpeed is not a measurement of the actual loading speed of a website, but an analysis of its architecture and front-end optimization.
It shows how well the page rendering process, resource compression, and caching are organized.

In this article, I will show you how I optimized a website on Magento 2.4.8 step by step to achieve a score of 90+ in Google PageSpeed while maintaining functionality and design.
The goal of the project is not just to speed up the website, but to improve the technical health of the frontend by increasing Lighthouse scores and Core Web Vitals stability.

Testing methodology

To ensure that the optimization was objective, I used several tools and approaches to measure the results.

1. Lighthouse in Chrome DevTools (local testing)

This tool allowed us to perform detailed audits directly from the browser. Local measurements were used to analyze the impact of specific changes — for example, after implementing lazy loading or updating cache headers.
In addition to the Lighthouse tab, the Performance tab in DevTools was also very important.
It allowed us to track:

  • which resources block the first render (First Paint);
  • how long it takes to render key elements (LCP);
  • how the load is distributed between the main and auxiliary threads;
  • where delays occur when executing JavaScript.

This helped identify bottlenecks accurately and optimize the code without guesswork.

2. PageSpeed Insights (production testing)

After making local improvements, I ran final checks on the live server using the official Google PageSpeed service.
This allowed me to see the final score, taking into account actual network latency, CDN, and third-party scripts.
The difference between local and server results helped me assess how well the optimization maintains its effectiveness outside of ideal conditions.

Using DevTools for analysis and PageSpeed for verification improved the scores and explained why they changed. Each change was recorded in a “before/after” table with comments on its impact on key metrics (Performance, LCP, CLS, FID).

Initial data

For analysis and optimization, I took the main page of the site as a basis, as it is one of the most loaded in terms of structure and number of elements: slider, product collections, banners, and built-in brand blocks.
Optimization was primarily carried out on this example, but all the changes implemented were subsequently applied to all the main pages of the site — product cards, categories, and the Sale block.

A local test was performed using Lighthouse in Chrome DevTools before optimization began.
The results showed a typical picture for a Magento project: good technical level (SEO and Best Practices at 90+), but low performance due to a heavy frontend and render-blocking resources.

Local test (before optimization)

MetricValueComment
Performance53Low score due to long Largest Contentful Paint and unstable Layout Shift
Accessibility81Minor issues with contrast and aria attributes
Best Practices100All recommendations have been followed.
SEO93No comments overall

Metrics details:

  • First Contentful Paint: 0.6 s — good performance: the first visual elements appear quickly.
  • Speed Index: 2.7 s — relatively normal, but there is potential for improvement.
  • Largest Contentful Paint (LCP): 4.6 s — the main factor reducing performance.
  • Total Blocking Time (TBT): 0 ms — scripts do not block rendering.
  • Cumulative Layout Shift (CLS): 0.372 — exceeds the recommended value (< 0.1), noticeable “shaking” of the interface during loading.

Tests before optimization

Local Lighthouse tests

First desktop local test
Before optimization — Desktop, Local Test
First mobile local test
Before optimization — Mobile, Local Test

PageSpeed Insights tests

First desktop server test
Before optimization — Desktop, Live Server Test
First mobile server test
Before optimization — Mobile, Live Server Test

Conclusion

The analysis revealed that the performance drop was caused by front-end issues rather than server speed:

  • too late loading of large visual elements (banners, category images);
  • block shifts during loading (high CLS);
  • heavy CSS and JS resources that are not optimized for deferred loading.

Thus, further work was focused on improving rendering — optimizing images, reworking script loading, and reducing visual shifts.

Approach to Magento PageSpeed optimization

The optimization was divided into three steps to gradually improve PageSpeed scores and measure the impact of each step:

  1. Basic optimization of the Magento configuration (minification and resource consolidation);
  2. Custom code modifications and front-end optimization;
  3. Implementation of Varnish and Valkey (according to separate guides) for maximum effect on production.

Step 1: Minification and resource combining in Magento

The first step was switching to Production Mode and enabling compression and resource combining. This is a basic but critical optimization that dramatically reduces page rendering time and the number of HTTP requests.

Settings enabled in the Magento admin panel

Path: Stores > Configuration > Advanced > Developer

  1. CSS and JS merging and minification
    • Enable Merge CSS Files ➤ Yes
    • Enable Minify CSS Files ➤ Yes
    • Enable Merge JavaScript Files ➤ Yes
    • Enable Minify JavaScript Files ➤ Yes
    • Enable JavaScript Bundling ➤ Yes (merging into a single optimized bundle)
    • Enable Move JavaScript to the bottom of the page ➤ Yes (reduces render blocking)
  2. HTML minification
    • Enable HTML Minification ➤ Yes
      Reduces the overall weight of the page and improves Speed Index
  3. Switching to Production Mode
bin/magento deploy:mode:set production
bin/magento cache:clean
bin/magento cache:flush

Results after step 1 (Production Mode)

Performance improved thanks to system optimization and the inclusion of minification.
Rendering time (LCP) was reduced by almost half, and CLS stabilized.

Desktop prod mod test
Production Mode — Desktop, Local Test
Mobile prod mod test
Production Mode — Mobile, Local Test

Step 2: Custom modifications and front-end optimization

Once the basic Magento configuration had been optimized, work moved on to custom changes aimed at improving actual front-end performance and eliminating server delays that were affecting PageSpeed scores.

Main improvements

  1. Image optimization
    • Conversion of all large images to WebP;
    • Addition of loading and fetchpriority tag for cards and banners images;
  2. JS and CSS optimization
    • Moving secondary JS scripts to deferred loading (defer, async);
    • Inline Critical CSS for Above the Fold elements;
    • Removing unused dependencies (Bootstrap, jQuery UI modules, etc.).
  3. Rendering stabilization
    • Added fixed container sizes to reduce CLS;
    • Used skeleton placeholders for slow blocks;
    • Preloaded key resources (<link rel="preload"> for banners and fonts).
  4. Optimizing PHP code using profiling
    • PHP Profiler was used to analyze server performance.
    • Slow sections of code were identified and optimized:
      • excessive collection calls in loops;
      • heavy join queries without the necessary indexes;
      • suboptimal model loading calls (load() in iterations);
      • unnecessary getData() calls inside templates.
    • After optimization, these bottlenecks were eliminated through:
      • preloading data (preload collections);
      • using addAttributeToSelect() instead of fully loading entities;
      • caching heavy blocks using Magento\Framework\App\CacheInterface;
      • simplifying plugins and observers with unnecessary logic.

Results after step 2 (custom optimization)

Scores rose to target values — 99 on desktop and 84 on mobile devices.
All key metrics were in the green zone: LCP decreased to 0.6 s, CLS was almost zero.

Desktop custom optimization test
After custom optimization — Desktop, Local Test
Mobile custom optimization test
After custom optimization — Mobile, Local Test

Step 3: Adding Varnish and Valkey

The final step was to implement server-side caching. Once the front end and PHP code had been optimized, it was the cache layer that enabled us to achieve stable loading speeds on the production server, even under high loads.

What was implemented

Key technologies:

  • Valkey — session and tag caching, database offloading;
  • Varnish Cache — Full Page Cache with instant HTML page delivery;

Verification of successful operation via the X-Magento-Cache-Debug header: HIT.

Thanks to these components, the server began to deliver pages with a TTFB of ≈ 150 ms, and the overall responsiveness of the interface increased more than twofold.

Detailed configuration instructions are available in separate guides:

Results after adding Varnish and Valkey

Desktop after added varnish test
After adding Varnish & Valkey — Desktop, Local Test
Mobile after added varnish test
After adding Varnish & Valkey — Mobile, Local Test

Results and conclusions

Optimizing the site for Google PageSpeed turned out to be not just a set of technical tricks, but a comprehensive process involving analysis, system configuration, and targeted code refinement.
The main result is not only an increase in Lighthouse scores to 100/88, but also a real improvement in user experience: the website has become more responsive, stable, and reliable under load.

Short comparison of results by steps

StepDesktopMobileKey changes
Minification and resource combining in Magento6945HTML/CSS/JS minification, resource combining, bundling
Custom modifications and front-end optimization9984WebP, lazy loading, preloading, inline CSS, PHP request optimization
Adding Varnish and Valkey10088Server caching, TTFB reduction, stable page delivery

What had the greatest effect

  • Moving JS to the end of the page and enabling bundling — the most noticeable improvement in Speed Index.
  • WebP and lazy loading — LCP reduced by almost 3 times.
  • Inline Critical CSS — faster rendering of the first screen.
  • PHP profiling — elimination of redundant operations and optimization of collections.
  • Varnish + Redis — acceleration of production to the level of instant response.

What is important to consider

  • Lighthouse is not a tool for measuring “loading speed” but rather for assessing the quality of front-end architecture.
  • A high score should not be an end in itself: it reflects the technical health of the project.
  • Optimization is not a single action but a chain of small improvements that together yield significant results.
  • Any change should be checked through DevTools → Performance to see the real bottlenecks.
  • PHP profiling helps to detect invisible delays that are not displayed in PageSpeed but directly affect TTFB.

Results

As a result of comprehensive optimization, the website achieved the following metrics:

  • Performance: 100 (Desktop), 88 (Mobile)
  • Largest Contentful Paint: 0.7s
  • Total Blocking Time: 40ms
  • Cumulative Layout Shift: 0.003

Pages open instantly, the interface is stable, and the infrastructure (Varnish + Redis) ensures high performance under any load.