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.

How are agencies doing?

Some are making the same mistakes as other agencies tend to do when building websites or webshops the more traditional, SSR way.

No focus on speed at all

Youwe Agency wrote about PWA, although speed not being mentioned. Speed turned out to be a collateral win. This could mean there was never any focus on performance, also suggested by their speed score. A big 'whoops' when you look at their pagespeed score, being 42% and having an FMP of 3.7 and a TTI of 12.5 seconds.

PWA making you blind

Gracious wrote an article about the Budgetplant PWA they've build. They managed to double the conversion by using a PWA on top of a headless e-commerce solution. Although important nuance was missing, another perspective is missing here. Not only was I curious to know what they count as conversion, they most likely also came from a (very) bad use-case, allowing them to improve no matter the alternative they would have choosen.

Instead of PWA being the reason that conversion increased, it might have been the prior solution which wasn't enabling budgetplant to reach full potential. Just like AMP, when you failed building a good shop in the first place, it is very likely that any new platform will do better.

Focussing on the wrong metrics

On top of the article, Gracious also published a whitepaper. As a performance consultant, I found their performance KPI most disturbing. Their whitepaper was stating their Time to First Byte metric improved:

  • Google's suggestion towards Time to First Byte is under 200 milliseconds;
  • The TTFB of Budgetplant appeared to be 638 milliseconds in 2018;
  • Their new TTFB is only 36 milliseconds, a reduction of almost 95%.

That's quite impressive. But only if you don't know anything about how server side rendering (SSR) and PWA (often CSR) works. Unfortunately, this was the only pagespeed metric to be found within the whitepaper.

The nuance missing in their whitepaper and most likely also missing in their field of focus, is that as PWA is client side rendered, only minimal work has to be done on the server in their new situation. Instead of doing algebra, the server only has to do basic math (or even less), spending less time doing so.

Above numbers are their own findings. Based on public data of November, 66% of users had a TTFB of less than 300 milliseconds while the 75th percentile is at exact 300 milliseconds as well. This in itself is a good TTFB, but not groundbreaking.

The heavy lifting is now done on the mobile device. As a result, also the individual metrics shifted. This TTFB metric isn't saying anything about perceived performance or real user experience and thus they should've measured and monitored more UX based metrics instead.

Accessibility as part of Human Rights

Although required by law for governmental organizations only, your website or webshop should be accessible. However, as a non-governmental organization, Beyonce as well as Domino's were sued respectively because of an inaccessible website and webshop. Obviously, PWA can be as accessible as any other solution, but once again, it will only be when we keep focus on accessibility. Often even the very basics of accessibility is missing: knowing where you are while using the tab-key (please don't omit outline property) as well as navigating and opening widgets by using keyboard only (use clickable elements for such actions).

To illustrate: All three PWA e-commerce solutions, including budgetplant and PostNL, are inaccessible.

Trust your framework?

The trend I am noticing, is that agencies are putting trust in build-processes and frameworks, neglecting the impact on user experience. For example, the JavaScript components of Bootstrap are accessible. You can implement it incorrectly however, making your end product inaccessible. The same applies for using Angular, React, Vue or any other framework. Accessibility and performance doesn't come out of the box.

Their purpose often is not delivering a fast user experience, but rather a fast developer experience. But, as a developer, it is still our responsibility to build fast and accessible end products.

Read more about PWA conclusion and take-aways on the next page.