Okay, 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/3^rd of the time is the Magento PHP server code forming a web page and 2/3^rds 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/3^rds 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/3^rd 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.

Conclusions

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.)