The Road to PWA – Reacticon 2018
What’s the Big Deal?
Progressive Web Apps are the next big thing for the mobile web, just as responsive design has become the norm, PWAs will become the new standard. Originally talked about by Google back in 2015, it’s the benefits to both developer and customer that sets this technology apart.
The flow of a typical progressive web app goes like this:
- Starts out as accessible in tabs on the Web browser
- Shows the option of adding to the homescreen of the device
- Progressively starts exhibiting app-like properties such as offline usage, push notifications and background sync
How does the technology work?
A PWA is essentially a mobile app delivered through the web. It functions like a native app, due to the use of an app shell that allows for an app-style experience. The main difference is that there is no need to download it from an app store. It runs, self-contained, right in a web browser, able to load instantly, even in areas of low connectivity. With the help of pre-caching, the app stays up to date at all times, displaying the most recent version upon launching.
PWAs start out as tabs in an internet browser. They become increasingly app-like as more and more people use them. After a certain amount of use, they can be pinned on the home screen of a phone or in the app drawer and have access to app-like properties such as notifications and offline use.
Key benefits of a PWA over a native app
- Performance – they can load quickly (thanks to page load performance best practices) even in low quality or slow network conditions
- Functionality – PWAs have the functionality of both websites and mobile applications
- Re-engageable – through features like push notifications, users should be able to consistently engage and re-use the app
- Linkable – easy to share via a URL
- They work offline as well as on – and can be fully functional in both situations
- Efficiency – they work on demand and are always accessible, and they don’t take up your smartphone’s valuable memory or data
- User-experience – they offer an app-like user experience (splash screens and home screen icons)
- No App Store approval needed – developers don’t need to submit the progressive web app to app stores and wait for approval
PWAs are the future – nobody is questioning that. They are destined to bring essential features to the web platform, including better performance, network resilience and the ability to place themselves as a ‘first class citizen’ on mobile operating systems. In many cases, these points alone will help to obviate the need for most companies to even consider Native Android or iOS Apps.
It’s no surprise then that the development community has been falling over themselves with excitement ever since that original announcement.
PWA is the future, but what will happen to all the existing Magento 2 sites out there?
At JH, we’re extremely excited to begin working with the new PWA Studio platform being developed by Magento (we’ve even been involved in many conversations about the direction and goals of that project) – working on full PWA projects is going to become the norm soon enough.
But that time is not here, yet. Right now though, there are thousands of existing Magento 2 sites out there and many being signed as we speak. What happens to all of those?
This is of great interest to all at JH. Sure, we’ll be on the cutting edge of brand new PWA projects that you’ll be seeing soon, but this new-found enthusiasm for Magento and its focus on modern features (such as those falling under the PWA umbrella) have encouraged us to re-evaluate the core offering from Magento 2, all with the goal of dramatically improving it.
PWA is the future, but it shouldn’t stop us improving the present!
We made the decision to dedicate engineering time and resources into improving the performance of the current platform, for new and existing clients.
Moving existing sites to full a PWA solution, complete with an app-shell architecture would involve a complete re-write from scratch – a rather risky endeavour considering how new the technologies really are.
So, we’re helping clients bridge the gap by instead working on huge performance improvements to their existing sites. So much so, that it becomes viable to start thinking about incrementally adding PWA features right now.
PWA is not an ‘all or nothing’ approach – advanced features such as local caching of assets to enable an Offline fallback page could be implemented today.
There’s nothing technically stopping this, but it would be a tragedy to begin adding PWA features without first addressing the elephant in the room, Magento 2 Frontend Performance:
Improving Magento 2 Frontend Performance
When you put the default Luma theme through a Google Page Speed test, it can often score above 90 (out of 100) – an extremely encouraging result! But it’s not that simple. Far from it.
In this case, Google Page Speed is testing if a site loads assets in an efficient manner & how quickly something appears on the screen. These are important metrics on their own, however, they are not reporting anything about the underlying system under test – and can therefore lead to misleading results.
If the header of a website is rendered in only three seconds on a Mobile with a regular 3G connection – that initially sounds very good – but if the rest of the site is not interactive in a way that’s meaningful to the Magento system for another 16-18 seconds, then all of a sudden, we fall from ‘great’ performance, to poor at best.
This is where a standard test like Google Page Speed does not paint the full picture. It’s giving a score of over 90 out of 100, even though the user may not be able to ‘add to cart’ for 20 seconds!
A new standard measurement TTFMMRI
We’ve coined a new term to guide our continued work on performance improvements: “Time to First Meaningful Magento Related Interaction”. This mouthful of a phrase is meant to encapsulate the importance of how quickly the user can interact with the system.
To tackle this, we currently have 3 separate strategies:
Strategy 1: Implement intelligent bundling strategies for JS & CSS files
Unfortunately, due to the requirement of Magento being able to run in a PHP only environment, it doesn’t support (out of the box) the correct bundling mechanisms for RequireJS. This means that most Magento 2 websites are technically running in ‘development’ mode, when it comes to the frontend.
The ‘bundling’ options inside the Admin interface are also not the correct choice – since they don’t understand the dependency graph created by AMD modules.There are a number of other aspects that contribute to making this a complex problem to solve, far too many to list here, but an important one is the way in which modules can override and extend from other modules. This is controlled by the sequencing of Magento modules, and must be respected for the bundling process to be successful.
It seemed like an impossible task, but we’ve developed tools that can resolve each and every one of these issues, and can produce the configuration necessary for the RequireJS optimiser to generate page-specific bundles.
- Reduction in HTTP requests – from hundreds, down to a handful or less.
- Huge reduction in download size – less than half in most cases.
- Removal of staggered loading of modules – our methods can introduce some much-needed ordering & priority into the module-loading aspect of the page load.
- Dramatically quicker TTFMMRI – from 18-20 seconds on 3G, down to as low as 4s
- Has to be tailored to each site – although it can be automated to an extent, there’s a small amount of work involved in configuring the tools we use
- Can lead to slightly longer ‘white screen’ phase for users – at first this seems to fly in the face of recommendations from performance experts, but for us it’s clear that a slightly longer initial load is preferable to a 20 second delay in overall interactivity
Strategy 2: Begin to replace Magento Modules with smaller, newer versions
Magento is an extremely modular system – so much so that we’ve realised you can pick and choose certain widgets on a page and begin to rewrite those from scratch.This can be especially beneficial if an existing implementation (such as the checkout for example) has more features than are used by a particular client.
It also allows us to begin to gradually move away from the ancient libraries such as jQuery and jQuery UI in an incremental manner whilst adopting newer, smaller and more lightweight alternatives.
- Maintain full compatibility with existing Magento 2 extensions and modules
- Ability to cherry-pick individual areas to improve – such as a minicart or checkout
- Usage of modern tools and frameworks – we can author modules using the latest and greatest technologies, and then have tools translate them into a format that can be consumed and understood by RequireJS
- Maintains the possibility for ‘bad actors’ ruining the performance – since the existing module system remains in place, there’s nothing technically stopping a rogue 3rd party module from ruining the performance improvements
- Limited by the constraints of the AMD module loading system – advanced performance patterns, such as aggressive caching for example, are not possible.
Strategy 3: Bespoke Frontend Module system
This is the final option we’re developing for scenarios that require the ultimate in performance optimisations. It includes a modern toolchain, advanced caching mechanisms and performance that can compete with even the very best of the PWA examples out there – all without having to switch to a completely new platform.
We achieve such outstanding performance, such as initial render in less than 50kb, by building up only the features required by the client and by using the cutting-edge libraries and frameworks such as Preact and RxJS.
It’s an extreme approach, since it requires bespoke development of most modules, but the performance benefits that are possible still make it a viable choice in certain situations.
- Best possible performance – we only build exactly the features required, using the best tools out there
- Can compete and even out-perform some single page apps
- Removed complexity of client-side routing – everything about how the Magento platform already works in terms of URLs & backend code stays the same, we just give the frontend a face-lift!
- Aggressive caching strategies can be employed – because we handle the creation of all assets, we can utilise superior caching concepts
- Increased security – since we handle how modules are loaded, we can impose tighter restrictions on how and when client-side code is executed
- No direct interoperability with 3rd party modules – usually this just means writing a small wrapper to enable integration into our system – or otherwise custom development of the same features
Performance is the key to the future of PWA
At JH we’re passionate about addressing the existing performance problems in Magento, because we believe it’s the correct gateway to the amazing PWA future.
Too often in recent conversations around PWAs, we’ve heard people writing off the existing Magento 2 platform as unsuitable – something we’ve found to be untrue. Had we not invested such time and effort into researching how to solve the extremely complicated problems around Magento 2 and Frontend performance, we might have reached the same conclusion. But now, instead of not having an answer to this, we’re leading this revolution by developing a number of strategies that all produce amazing results.
Since great performance is a prerequisite of PWAs, we’re in a position to help clients begin the transition – either with a switch to a full PWA, or by improving their existing sites so much, that PWA features are a natural next step.
If you’re interested in finding out more about PWAs, and how they could impact your eCommerce business, get in touch with Jamie today.