Covering in this article:
- The switch to mobile first
- Technical implications of PWA
- User experience implications of PWA
- PWA, fast and mobile first
- How are agencies doing?
The switch to mobile first
When responsive webdesign came along, we changed the way of building our websites and webshops. Instead of a separate 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 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.
- 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).
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.
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