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