As Product Managers, we care about a great User Experience on our Apps and Websites. A great User Experience consists of (in this order): A great concept/service that fulfills the user's needs, a reliable and usable product and a pleasurable experience when interacting with it. Let's say you have the base, a rock-solid and usable product. How can you make it stand out?
One thing that is absolutely essential to make your product pleasurable is speed. But when talking about speed, we need to keep in mind that speed is not just one parameter. I often hear things like "We have to improve our Page Speed to optimize conversions!". Okay, but before we start building, we need to ask ourselves, what kind of speed we actually want to optimize for. Do our users need the fastest page load time (e.g. because we have a lot of one-time and new visitors from paid ads on our page) or do we need to make sure that the interactions on the page feel more convenient (e.g. for a SaaS product with complicated user flows).
Since the rise of Angular, React and Co. we have experienced a massive shift in the way how web interfaces are built. I still remember this huge surprise when my former CTO showed me his first React SPA's that did not require a page reload while browsing the website. It felt so different and ja, so fast! Up to that point, I did not know that something like this is even possible. Fast forward many years, I and many other teams have also experienced the downsides of SPA's. There are many great articles out there highlighting why you don't need a SPA and I agree that in many occasions you really don't need one (while for some projects they are the best way to go). Ironically most of these articles argue with the same argument that their opponents are using: Speed. How is that possible?!
The truth is, that the amazing feeling that I had when using my first react apps was because of the highly reactive interactions that the app offered, not because of its initial loading time...
In my last job, I was working for a large E-Commerce company. We were operating 12 stores all over Europe based on a massive Magento system. We tried hard to get our Google Lighthouse Speed Score at least over 50 (we started from 20 and made it to 45), but we were running into many legacy issues that made the optimizations tedious and things were improving very slowly.
So we asked ourselves: How fast would the store be, if we would build up a new SPA based on React from the ground up (just for the exploring of our categories, not for the checkout). Since we used Algolia as a third-party provider for our search, we did not have to start from scratch, but could use their super fast search API and their react-search library to quickly assemble a Proof of concept.
The first speed measurements were great (>90/100 in the audits when served from an AWS CDN), so we invested some more time to bring the product into MVP state. The weeks went by and all the small features, designs, fonts, our personalization-designer library etc. etc. where added. Slowly we noticed that our speed measurements declined with the amount of time that we were putting into the project.. It was frustrating, the end result did barely beat its Magento counterpart (56 vs. 48 or so). And even though the click interactions in the App where fun, everything felt fast and the user's spend significantly more time on the page, the conversion rate did not improve significantly in our AB tests. Since it was still early days and many other areas like SEO were waiting for answers as well, we decided to stop the project after a few more iterations.
This is a good example of why both parties are right, when arguing that speed is a reason to use/not use a SPA. The truth is, when architectured well, React & co. are amazingly fast and even the issue of a big bundle size can be solved. The downside to all of this is, that it takes a lot of time and experienced developers to do it right. That is why until today you find a lot of shitty SPA experiences out there.
I am still a strong believer that for many projects, client-side focused apps are awesome. The limitations or issues that we experienced in this first big wave of applications will be overcome in new frameworks that are already being developed and that will make it easier for Developers to build great Apps, that still load fast even when they become more complex. All in all, it is amazing to see how fast the state of Web Development is changing in the last years. Looking forward to the next wave!