Wait, what!? Obviously, I could name some great PWA solutions out there, but it wasn't always so. Today's case, migrated in November, is proving that you can build perfectly performant solutions, for real users, the traditional way.
PWA might have been a hype to become a serious solution, but it often is implemented dead wrong, especially in the beginning. PWA is here to stay but it may still come with caveats, such as in todays case. I already wrote about PWA caveats and the untold story of PWA implementation more than a year ago.
But maybe to few changed, yet. What did change is that I turned out to be correct and even agencies started realizing PWA was the solution for improved developer experience (not always), but real users out there didn't turn out to always be using the same devices and internet connectivity.
React and Deity Falcon for PWA
In July 8th 2019, a Dutch agency had built a webshop using Magento 2, where React and Deity Falcon was making up its frontend stack. They described their case as following:
we will detail why and how we built this cutting-edge and lighting-fast webshop
But it turned out this wasn't really the case. The PWA that was used didn't seem to come with expected pagespeed results. The reason? Real users out there didn't turn out to be on the same device and connectivity as tested by its manufacturer. Important to know is that this very webshop did not use any third parties, expect for non-marketing third parties such as:
- fonts via Google Fonts;
- Google Analytics via Google Tag Manager.
PWA PageSpeed Insights data explained
What we are seeing in the above screenshot of a mobile pagespeed result of a product detailpage is as following:
- The overall score is only 11%. There almost is no 3G left in The Netherlands while this shop has a Dutch-only audience. So, this score alone doesn't have to be a problem;
- However, looking at the field data and thus real UX data, we see that only 11% are epxeriencing a good First Contentful Paint, less than 1 second. Another 33% is having a very bad FCP, meaning more than 3 seconds. The 75th percentile is at 3.3 seconds.
- The 75th percentile of the Largest Contentful Paint metric is 3.7 seconds. This is close to the 3.3 seconds FCP, which could indicate that the bootup time is very high. It still isn't 50% of users who are having a good LCP experience of less than 2.5 seconds (48%). Nineteen percent are having an LCP of more than 4 seconds.
- FID might be misleading. As long as users don't see anything happening yet, they won't try to interact. As a result, the FID is very good, but only because overall user experience is very bad. Moreover, about 88% of all tracked websites are having a good FID result.
The 75th percentile is important as this is where Google draws the line when it comes to Core Web Vitals and SEO ranking: at least 75% of your users must have a good experience.
If you think this data looks bad, than consider the amount of users who are impatient, in a hurry and maybe not even waiting for the page to finish. These users might not be part of this data at all or are not tracked properly.
PWA performance concerns
As months went by, I saw more writing of agencies on Twitter and LinkedIn, expressing their concerns about pagespeed and performance results. PWA didn't turn out to be the silver bullet in addressing pagespeed and performance related issues. Fixing UI issues when going from for example M2 to any PWA solution might already come with conversion improvements.
However, you would rather also cater to all other users, who might be using an older device generation or are experiencing other constraints.
Moving away from PWA to improve real user experiences
Last december, I saw this very same shop passing by in my Twitter timeline. They changed their stack using Hyvä theme, using Alpine.js. And by they, I mean elgentos ecommerce solutions, located in The Netherlands. After replatforming uitgeverijpluim.nl, I tested the new outcomes myself as well. The mobile results, tested under the same circumstances, are as following:
Hÿva PageSpeed Insights data explained
The above PageSpeed Insights screenshots means:
- FCP improved from 3.3 to 1.2 seconds, an improvement of 64%;
- Moreover, 66% of users are having a great FCP experience of less than 1 seconds, instead of only 11% when it still was a PWA.
- LCP improved from 3.7 to 1.6 seconds, an improvement of 57%;
- Moreover, 92% of users are having a great LCP experience of less than 2.5 seconds, instead of the 48% when it still was a PWA.
I guess we needed such proof that traditional way of building is not dead, certainly not when it comes to real user experiences. We proved it before with two server side rendered cases I was involved in. But next to bigger brands such as bol.com, we had to wait for Hÿva to get this confirmed. Although Alpine.js could impact Core Web Vitals due to high CLS, elgentos' solution as well as the latest Hÿva version even took good care of Cumulative Layout Shift.
Reasons for moving away from PWA
Interesting numbers, so I set up a call with Wouter, frontend developer and co-owner of elgentos. Elgentos clearly is an a e-commerce agency not to afraid to try new stacks, but also share findings if the outcomes weren't as expected.
In short, some reasons to move away from its previous PWA implementation:
- They also noticed that rendering work in the client came with caveats;
- It obviously takes another development mindset, learning new frameworks and libraries;
- When it comes to API's, Magento wasn't really ready yet to make it work in an optimal way;
- And this very PWA solution still required quite some bugfixing, which also drew a bill on the team.
What they loved about Hÿva? Limited learning curve and keeping closer to Magento's default setup. During this replatforming, they did benefit from previous work, done in preparation for hooking up the PWA.
Not a PWA rant
This should not be considered as a PWA rant, as PWA isn't to blame here. PWA wasn't meant or designed to become bloated. It mostly is the way PWA's are built and implemented that should have changed and caused current drawbacks.
PWA is here to stay, but if we are about to start overengineering and lose focus on UX, we might be better of optimizing our traditional stack or keep things simple for developers but mostly our users.