PWA, the untold story impacting your conversion

PWA, the untold story impacting your conversion

Progressive Web Apps have quite some advantages. The biggest one being a web-product with a native-like feeling. But it is also fast and mobile first, or rather should be. This is the untold story about PWA, impacting your conversion.

Progressive Web App is mobile first and fast

Mobile first and fast, just like Angular or AMP, right? Although both being a Google product, we all know how Angular 1.0 turned out to be. And even AMP pages may end up being slow. When embedding several AMP features, you will need several AMP libraries. As those are relying on JavaScript, those are render blocking, making your pages slower as you have less freedom optimizing.

Clean sheet

The thing is, when being the average online publisher or e-commerce webshop, you might have the feeling that it takes more time and budget optimizing your current situation. This might be the reason why quite some publishers jumped on the AMP train (including other priviliges Google might give AMP equivalent pages).

A new framework doesn't mean you can't mess things up; It might only provide your development team with a clean sheet to start from, while the quality of the end product depends on your implementation. The term PWA doesn't make a shop fast by default, despite PWA being marketed as fast and mobile first.

We forgot about variety of devices

Often, agencies forget that users are using different devices and those devices have different CPU limitations. While forgetting this, we are making the same mistake as when we started building mobile first using responsive frameworks.

A real-life use case where the PWA supplier and agency was celebrating the 100% pagespeed score, illustrates this. It turned out they changed the default configuration when testing it's performance. They might have:

  • changed this setting on purpose, attracting new clients;
  • didn't know what this configuration meant (although not being the default setting), not having the desired focus on performance.

So, when will PWA be fast

As a PWA webshop or website doesn't require new pageloads, only new contents will be fetched on user navigation. This means that the so-called skeleton is only loaded once. Most JavaScript resources are only downloaded (with HTTP/2 not the biggest culprit nowadays) and parsed (biggest performance impact nowadays) once, on first page-visit. After that moment, a PWA often will remain fast.

The conclusion here is, as PWA is often build with Client Side Rendering, quite some JavaScript is needed to fill your visitor's screen. As this JavaScript has to be downloaded, parsed, compiled and executed the very first time, this might lead to long render blocking and main thread blocking periods. During these moments, your user might see a white screen or experience janky behaviour, resulting in an early bounce.

As often Client Side Rendering is done by JavaScript import new JavaScript (maybe importing new JavaScript), it is possible that even your analytics tooling couldn't be parsed on time, causing your business to not only miss out on revenue, but also on reliable bounce-rates.

What about skeleton loading?

To address this bounce rate, some solutions might show the user a loading screen with placeholdered area's, telling the user where information might pop up. The user is seeing some kind of skeleton of the website, hence skeleton loading screen.

When it comes to perceived performance and user engagement, skeleton loading is better than spinner icons, while server side rendering where no skeleton loading is needed at all, will be your best bet, improving UX and reducing bounce-rate. But also hybrid rendered PWA will enable you to reduce first time bounce, but may come with new challenges.

Read more about how agencies are doing building PWA on the next page.