I recently travelled to London to attend Magento Live 2015. Whilst there I was able to (in-between sufficient amounts of networking) expand my knowledge in numerous areas of Magento, none more so than the "imminent" release of Magento 2 thanks to Magento 2 'Deep Dive' session.
This deep dive session was a mammoth 3-hour talk focussing on several different areas of Magento 2. This blog post is specifically related to how Magento 2 has optimised the checkout process. This was a small but significant section of a talk on 'Performance, Scale & Magento 2' from Ted Pietrzak, the Head of Magento Technology.
As a Front-End developer, I play a significant role in Magento projects ensuring the performance of the theme, both in terms of bundling and minifying css/js files and requesting and handling data from the Magento database in the templates. In that aspect, I have always found Magento to be very unhelpful due to numerous dated approaches to theming.
I'm not referring to the CSS approach or the lack of task runners, for example, in an out of the box Magento theme; there are reasonable solutions that can be added with very little effort to implement these and provide great results. What I mean is the technical approach to handling requests and data in the more complex sections of the site, such as the checkout.
What I refer to specifically in this case is a dated approach when it comes to handling requests and data. Thankfully, this is where Magento 2 looks like it will begin to really come in to its own from a front-end performance perspective.
Take the Magento checkout for example, on every single page load Magento queries the database for user & order data, meaning that each time the user clicks to continue to the next step of the checkout journey, there is a delay retrieving this information. Waiting for the data seems pointless when very little or no data has changed since the last request 2 minutes ago.
In the following scenario, a user is already logged in to their account and has clicked the ‘add to basket’ button for a product. When loading the cart/checkout pages their user information is requested on each page load despite them already being logged in.
The getCart() function in Magento returns an object structured like below:
(This is a stripped down version of the object to illustrate the returned data from Magento data requests)
protected '_data' =>
protected '_customer' =>
protected '_addresses' => null
protected '_items' => null
protected '_payments' => null
As all of the order data is grouped within the one cart object, it needs to be re-requested each time some data is added/amended - e.g. at each step of the checkout to keep it up to date with the new data input by the user.
Whenever repetitive data such as user or order information is requested, it is stored in the browser cache in a segmented format; the benefit being that one set of data can be updated independently of another.
Given the exact same scenario in Magento 2 the process has been improved. Once the logged in user has clicked the ‘add to basket’ button on the product page, their user data will already be stored in its own section within the browser cache. This will have been stored when they logged in to their account. This means that no request is required to gather this data; the only new data that is requested from the server is related to the order and will be stored in its own, new segment in the browser cache, which will not be requested again - unless the data has been amended in some way.
To further explain, below is an example of how Magento 2 will store the order information in the browser cache.
(The structure might not be 100% accurate to Magento 2 standards as it is still a work in progress but the approach and theory is correct)
name: 'MageTitan T-Shirt',
Because the data is segmented in the browser cache in this way, the checkout can utilise much smaller requests to update only the relevant information. For example, rather than calling the getCart() method which returns all of the data, a simple request of cart->getItems could be triggered or cart->getAddress. This data will then be stored in its own segment in the browser cache so that it can be stored/amended independently of other cached data.
Utilising smaller AJAX calls to request only the updated data means the server is having to deliver much smaller amounts of data, leading to a quicker page load. There will also be an perceived performance improvement from the user, due to the asynchronous nature of AJAX requests.
This new feature is not yet completed in Magento 2 and is still in development, so it'll be a little while yet before we can have a look at how this works in detail. We're excited by the approach Magento have taken and look forward to seeing how they improve this further and implement the same approach throughout the rest of Magento 2.