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.
“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.)
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.
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!
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 😉
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.
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!
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?
performance custom section larger than 2 seconds
how to fix it?
I was also facing same issue with my Magento store, I just moved my hosting with cloudways, Their Magento full page cache extension worked very well and store performance is now optimized and loading in 2 second, https://www.cloudways.com/blog/free-magento-full-page-cache-cloudways/