Improving Page Speed in Magento 2

fast turnOkay, I should probably wait until the code is released and official numbers are in, but I just got an exciting update on some work in progress relating to improving page speed in Magento 2.

Disclaimer: The opinions in this post are mine and not necessarily those of my employer. The figures shown are also not final and are not guarantees of final improvement. They were just too good to keep to myself!

Performance vs Scalability

Permit me a quick divergence to help place this blog post in context of the grand plan.

Performance and scalability are related but different. If you improve the server performance of your site it will probably be able to take some more load. But it is not uncommon to change architecture in a way that reduces performance but increases scalability. For example, allowing multiple web servers with a shared Redis cache is more scalable than restricting your site to a single web server, even though a distributed Redis instance may be less efficient than everything running on a single host. Allowing multiple servers increases scalability at the cost of performance. So it is important to work out what problems you are trying to fix.

One area that is well known to be important to conversion on an ecommerce site is the speed in which a page renders in a web browser. People buy more when a site responds quickly. (Or said in a way I find easier to believe, people give up more on sites that are slow.) You can search the web for lots of posts sharing conversion metrics.

The front end developer experts out there can dissect page speed in great depth – I am going to keep things simple and say for many pages in Magento 2 today, roughly 1/3rd of the time is the Magento PHP server code forming a web page and 2/3rds of the time is rendering time, waiting for all the web page assets to download, and so on. Web page assets include JavaScript files, CSS files, and so forth. If we can reduce the 2/3rds delay, we can improve the customer’s experience on a site. This change however will not improve scalability as the server resource limit is the CPU, which is not important for downloading page assets.

“Performance and scalability for Magento 2” is not one thing to be done. There are a range of changes that have different impact on how a site will behave for different users. In this post I give a quick update on a few promising upcoming features in the are of page load speed – not server performance or scalability.

JavaScript Bundling

Magento 2 uses RequireJS to help manage JavaScript file downloads and dependency management. However this can result in a larger number of download requests. That is bad for page load performance.

One area of investigation currently being undertaken is in the area of bundling (and minifying) JavaScript files that are frequently downloaded together. The idea is to download one file instead of ten smaller files (bundling), and also compress (minify) the files by removing comments etc. Bundling and minification are well-known techniques to speed up a page. The challenge is to get bundling to work well in conjunction with RequireJS so developers get the RequireJS benefits of modularity during development and the benefits of bundling and minification in production, without much additional effort.

The good news is experiments in this area have shown a 45% improvement in page load time on some pages. This result is by no means final, but it means a 3 second page load would reduce to 1.65 seconds with a relatively little effort at a site. This improvement would not be gained on every page (the JavaScript files cache well after first download), but it would be on that all important first arrival at a site, such as the home page. This can be achieved with relatively little effort.

What I like in particular is that the team has made sure there is a switch so it is trivial to use the original raw files making JavaScript debugging easier without significant rework of your code. Using the individual native (pre-minified) files makes debugging tasks like single stepping and editing easier.

Further Page Caching Improvements

More pages have gone through the wringer to improve their cacheability in caches like Varnish. Areas include checkout, login, and customer pages.

Side note: So where do caches such as Varnish fit in the performance story? Every time you can fetch a page from cache instead of requiring the PHP server to generate the page helps in two ways. First it reduces latency for that particular page as the cache is much faster than the PHP server (the 1/3rd from the PHP server is reduced). Second it improves scalability as less CPU was needed to return the page, making more CPU available to other requests. So a product change that takes more CPU to generate a page may still be better, as long as the resultant page caches well. (And yes, yes, PHP server generation speed is still important for pages like checkout that are critical yet do not cache well as they are full of per-user data.)

Inline JavaScript

More inline JavaScript has been removed from web pages. There are various benefits in this work, but one has been the DomContentLoaded event has been observed being up to two times faster as a result. (I don’t have any numbers showing final end user impact, but I know the frontend-guru likes of Brendan Falkowski and Hrvoje Jurišić are keen on this one.)

It should be noted that the JavaScript for a page still needs to be loaded and run. Removing inline JavaScript can make a page visually appear before the user faster, but JavaScript is often needed to fully render or interact with a page.


This post is a bit of a sneak peak of page load time improvements that are coming soon to a GitHub repository near you. This is not the only performance and scalability work going on, just a few highlights in the page speed area. My personal excitement is not so much that these are radical new approaches (they are not!), but rather that the team is continuing to get known areas of improvement into the Magento 2 core so all customers can benefit from them with less effort.

I will sneak in a side reference as well. The HTTP 2 protocol can also provide page asset speed improvements by improving the underlying HTTP protocol. There are several features in the protocol such as better concurrent downloading of page assets and the ability for the server to push files the browser is likely to need before the browser even knows it. It will be interesting over the coming years to see how much benefit HTTP 2 provides reducing need for techniques such as RequireJS asset bundling described above.

(Oh, and although I put actual numbers in the above, the code and testing is not finished. The trends are positive, very positive – that is the message you should go away with.)


  1. The tips and tricks about static content delivery have been unveiled years ago when tools like YSlow and Google Page Speed told you all the things that could be improved on your site. Combining JavaScript files has been introduced in Magento 1.3 (correct me if it was even earlier) and tools like Minify have been used in the community for years, now used with Less/Sass. Also standards like image sprites have made their way in the Magento core with the introduction of the RWD theme (thanks to Classy Llama).
    So the 2/3rds you are mentioning shouldn’t give much room for improvement compared to what we already have today in Magento 1. And the page resources (which normally get gzipped) are only downloaded once and modern browsers can even cache parsed JS/CSS code to reuse it on new pages.

    Also full page caching with Varnish and dynamic blocks is nothing new to the community. There are various implementations on Magento Connect and Github. So adopting this in the core in Magento 2 is just logical.

    However, when talking about performance, Magento shops today are not suffering from static content delivery or missing FPC implementations. The 1/3rd in your blog post, which we try to mitigate with FPC/Varnish, is the slow thing that really needs some improvement in Magneto 2 – the page generation time. Cache invalidation and page variations can hardly be mitigated so the pure Magento execution time always matters and can’t be improved enough in Magento 2.
    From the numbers we know today there is still some work to do to be significant faster than what we already have today.

    1. Thanks for the feedback. I do believe Magento 2 is going to do a better job than Magento 1 in terms of modularity (and isolation of code) while still enabling good bundling etc. But absolutely agree have to further improve php server response time. That was just not focus of *this* post. Thx!

      1. I know I’m bothering you with this, I just want to make sure you won’t forget about this important little thing during all the refactoring efforts making Magento 2 more modular but not necessarily faster😉

      2. I can assure you we have not forgotten! The community won’t let us forget that one!😉

        But other goals are important too, like lowering the cost or risk of projects for Merchants.

  2. About inlining Javascripts, I was reading an article about inlining Javascripts ( ) and it said you should only inline small scripts. What do you think? Inline all Javascript big or small or inline just the smaller ones? Thanks

    1. We are trying to eliminate most if not all inline JavaScript. I am not the expert here, but JavaScript in the page slows down the page being visible and makes it harder to replace by another module. We have instead support for bundling JavaScript files together. So we can achieve both page render and download speed at same time.

  3. Alan, one of our teams largest concerns is performance during development mode without caching, and compilation.

    Do you have any suggestions for the developer working on the platform, as we’ve found load times in excess of 20 seconds with the same hardware running Magento 1 around 3-5 seconds locally with no cache. FPC, Varnish etc, allow for a very usable platform in Production modes, but developing is almost painful.

    Any suggestions / ideas would be greatly appreciated! Thx!

    1. Is there a reason you turn off all the caches? I normally use the defaults in developer mode. We are considering ideas like cache auto flushes, gulp like file watching, and of course speeding up code. I was curious to learn if there was a special reason to disable all caches?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: