PWA, the untold story impacting your conversion

The switch to mobile first

When responsive webdesign came along, we changed the way of building our websites and webshops. Instead of a separa­te subdomain for mobile users, we obtained one single web-version: for desktop, laptop, tablet and smartphone users. Easier for content managers, developers, marketeers and SEO specialists to maintain.

But instead of really building mobile first, agencies often started adding more code to make websites more responsive rather than shipping less resources at the same time. We are already transferring more resources to make a website or webshop work in the browser, than Margaret Hamilton wrote as on-board flight software to land Apollo 11 on the Moon. And although main bottleneck nowadays might not be the amount of requests or data, the browser's main thread and CPU is.

Technical implications of PWA

Let's start with some technical implications we have to be aware of when building client side rendered (CSR) solutions, such as Progressive Web Apps (PWA).

HTML versus javaScript

HTML by default is accessible and fast:

• Accessible because link-clicks works across all devices;
• Fast, because HTML is streamed into the browser right away, while being rendered.

As server side rendering (SSR) will return main content within the initial HTML payload, this will give your users an advantage over making your website content JavaScript dependant. Because:

• Someone could have turned of JavaScript (due to privacy or security reasons, by choice, or as part of a company policy such as within some government departments);
• Used device might not be compatible with your JavaScript codebase;
• Users might use cheap or older devices for several reasons, thus less CPU;
• Users might have a bad connectivity, causing a time-out on other (critical, as you are now building CSR) resources.

You can read more on these topics at "User experience implications of PWA".

It is beneficial to have server side rendered pages (and moreover, make them server side cached), so contents will become visible as soon as HTML is being received, instead of forcing the browser and thus visitor to wait on new requests (having all the risks mentioned above).

Technical SEO

Building CSR means that external resources has to be downloaded, parsed, compiled and executed before most DOM manipulations can take place. Yes, I am talking about JavaScript. This will take time for real visitors as well as (clever or less clever) search bots. JavaScript indexing delays are still an issue for Google.

Also consider the amount of testing needed to be sure your pages aren't indexed correctly, but all content is in the right places as well. Browsers as well as search bots are less forgiving when it comes to JavaScript and thus CSR syntax errors, as when HTML and thus SSR syntax errors would occur.

Jan-Willem Bobbink created an SEO infographic based on Google's rendering infographic:

First Meaningful Paint and Time to Interactive

When choosing to build a client side rendered solution, which PWA often is, metrics will be different than when doing server side rendering. The reason is simple: your contents isn't present in the initial payload. New resources have to be fetched (and parsed, compiled and executed) first. On their turn, these resources will re-use JSON content present in the initial payload or maybe even trigger API calls to fetch the actual contents, eventually painting it into your screen.

As illustrated before, the increase of JavaScript while building PWA is impacting the user experience, as the browser's main thread has more work to do, impact CPU and thus user experience.

Educating developers

When having in-house developers, be aware of the need to train or even re-educate your developers within this new building stack, toolsets, frameworks and mindset of building web solutions the CSR way. Although PWA being around for a while, there still is room to discover and improve security, accessibility, technical SEO and performance.

When deciding on an approach to rendering, measure and understand what your bottlenecks are.

developers.google.com