These days, PWAs are everywhere. Almost every large site you visit is running a PWA to some extent, and we all interact with them on a daily basis because they offer some incredible advantages. If that’s a surprise to you, or if you’re not quite sure if you should implement a PWA within your existing website or tech-stack, then you’ve come to the right place. In this three-part series, we’ll explore:

  1. What PWAs are – how they benefit your bottom line, what the pros and cons are, and why it’s worth understanding them. 
  2. Service Worker Design – we’ll run through creating a Service Worker – the heart of a PWA, and one of the more difficult parts of implementing PWAs. We’ll explore some of the trade-offs you’ll run into, and walk through our choices and approach to AlphaFlow’s PWA implementation.
  3. Cross-Platform Implications – we’ll run through some of the varied support for PWAs across platforms (iOS, Android, different Browsers), including which features work across all of them and some of the more complex bits you need to manage – like analytics tracking. 

Imagine a website that functions like a desktop app, or a mobile app on your phone. Imagine if you could have the same indistinguishable, app-like experience wherever you interact with your product. Your app is blazing fast, with near-instant load times, it functions perfectly offline and has access to some of the tools and tricks that only native apps previously had access to. This is what PWAs offer. How they work is by creating something called a Service Worker, which can install everything your website needs to work offline and save it on your computer, for immediate loading the next time you visit the site. 

From a business standpoint, probably the most compelling reason to install a PWA is site speed.  All activities on your platform that require interaction with UI, whether on your admin or client-facing portals will run slightly faster, meaning more can be done on your website in less time. It doesn’t take a huge stroke of imagination to connect this benefit to clients using your platform faster, leading to more sales, to faster processing of sales and business activities and logic performed on your platform by employees. In the next paragraph, we’ll explain the chart above and the site-speed benefits we achieved at AlphaFlow by implementing our PWA. The topline is that we made page load on our site between 20% to 50% faster for every single page visited. If you multiply the average number of page visits by the average page load on your analytics platform, then you’ll begin to understand the total time saved per user, and efficiency gained per year from using this approach. 

From enabling and setting up PWA support in AlphaFlow’s React front-ends, we achieved a 20% speed increase in First Contentful Paint (the time it takes for a website to first load and show on your browser), and a near 100% increase in time to interactivity (the time it takes for you to be able to click and actually interact with the website). If interested, you can learn more about these terms developed by Google here

Apart from site speed and performance, there’s another huge benefit of PWAs I’d like to dive further into; running a PWA allows you to ship a website, as well as cross-platform mobile and desktop applications from one codebase which can be published on App Stores (except Apple’s). If suitable for your use, the cost of development time this can reduce is absolutely staggering. Running a PWA allows you to add your website to your Mac Dock, Windows Menu Bars, or iPhone/Android home screen making it as easily accessible as other apps, and in theory, meaning your users will access your app more often. Once you run it in this ‘app-like’ mode, known as ‘standalone’ mode, PWAs allow you to ‘sandbox’ your application – hiding the browser bar when in use, providing a little extra screen space for your users. It’s definitely worth noting, however, that this support varies by platform and browser, and there are absolutely still advantages that can only be gained by having a full native application (e.g. access to native Health APIs and data on iPhone). Apple for one, hides a lot of this functionality from the user as it has many reasons to dissuade you from doing this – namely wanting you to purchase apps through them on the App Store for obvious business reasons.

Last but not least, offline access can be gained with PWAs, meaning your users can use your website in its entirety offline, allowing you to display content to users and have them perform actions and tasks on your app wherever they may be. This comes with its own set of challenges, as you must ensure that new data created by an offline user is provided to the server and that existing data modified by the server while the user was offline is reconciled. This is especially true when deploying new versions of your application. When it comes to high-value business tasks, this terrain must be trodden very carefully. Race Conditions are not fun to deal with, and if not handled carefully can lead to data loss.  

To conclude, there are many reasons to set up Progressive Web Application support within your tech product. As long as you implement your PWA and service worker carefully, and manage the various difficulties and trade-offs you’ll encounter when building this in, your organization can gain some serious benefits. Next up in this series? We’ll look at Service Worker design and dive into some of those trade-offs in detail.

About the author:

JDJames Darby is a Software Engineer at AlphaFlow. He strives to build user interfaces that meet key requirements and delight users across devices. After successful careers in the food and media industries as a chef and business development manager, James decided to go all-in on software. In 2019 he went full-time on his own freelance software development business and taught himself to code along the way.

When not working, James loves to cook, travel, make music and read.

back to top