My personal thoughts on front-end performance
When picking a technology, experienced stakeholders are usually concerned with performance. There’s a well-known chant that “for every second of application loading time, we lose customers.” Given that eCommerce is all about conversion, performance is really a thing to worry about. In this blog post, I’ll help you answer the question of whether SAP Spartacus is the right choice for you in terms of its speed.
If you want to learn more about how speed affects conversion rates, then
I recommend reading the following articles:
- Cloudflare.com “How Website Performance Affects Conversion Rates”
- HubSpot Blog: “12 Statistics That Show How Page Load Time Impacts Conversion Rate”
What does “fast” mean?
Web performance is no longer a simple metric. It was a decade ago when all we had to worry about was server response time. It’s no longer a single time measurement. There are a multitude of things to be measured, and in the end, the thing we care most about is the perceived performance, which is actually not measurable.
“Perceived performance is a subjective measure of website performance, responsiveness, and reliability. In other words, how fast a website seems to the user. It is harder to quantify and measure than the actual speed of operation, but perhaps even more important.”
MDN Web Docs
Of course, we use tools like Google Lighthouse to measure web vitals, which are some numeric approximation of how fast the page might seem to a real user. However, that doesn’t cover all aspects of the user actually using the application. This all makes it very difficult to define what’s fast and what’s not.
Comparing apples and oranges
Spartacus is based on Angular, and Angular is often said to be slow. I hope that, after reading the previous paragraph, you’re already suspicious of the word “slow.” This bad label might have come from the benchmarks. Yes, it’s true that Angular has the biggest bundle size compared to React and Vue. However, you have to bear in mind that Angular is a full-featured framework, while Vue And React projects usually require adding third-party libraries.
JavaScript frameworks are also commonly compared based on Stefan’s Krause benchmark. The tool is great for comparing the raw speed of the frameworks and is very useful for the framework creators to improve their work. However, when you’re picking technology for your project, you have to have a closer look at the testing method used in this comparison before drawing any conclusions. The benchmark measures the time of creating and modifying tables with 1,000 and 10,000 rows. Now, think how many rows of data you might have in your storefront? From my experience, it’s rather unusual to have a product listing page with more than 100 products served at once. The point is that for a smaller amount of data, differences in speed between frameworks is negligible.
There’s another interesting benchmark that’s supposed to give more real-world results. It’s actually called “A RealWorld Comparison of Front-End Frameworks.” It compares the performance of a similar application written in different frameworks. It’s worth pointing out that the tested application is something more than a simple to-do list. It’s a blogging application. What I like the most about the comparison is the disclaimer at the beginning:
“Let me start with this — this is by all means not a comparison of what should be your next choice for Front-End. It’s a small, relatively unsophisticated, comparison of three things: Performance, Size, and Lines of Code of a pretty similar application.”
Jacek Schae, A RealWorld Comparison of Front-End Frameworks 2020
There’s one more aspect that I’d like to add, and that’s the human factor. There’s a project called “The Computer Language Benchmarks Game,” which compares the speed of programming languages based on a set of programs with various implementations. What’s interesting is, it turns out, that implementation affects the speed of a program greatly. I mean that a badly written program in C++ might be slower than the same program badly written in Java, even though C++ is faster in most cases. What this means to me is that we shouldn’t be asking the question, “How fast is a language/framework?” but instead, “How easy is it to write a reasonably fast program using the given technology?” Remember that finding top-notch specialists these days is not only costly but also difficult.
Finding the right measure
I’ve complained a little about the conventional methods of performance measurement or, to be more specific, about how these measurements are misinterpreted. I don’t want to be only a rabble-rouser, so I’ll give you some hints on this. Measuring the web vitals is actually a good thing, and it’s fairly easy to set up continuous monitoring of them. There’s just one thing that you have to bear in mind while analyzing this data. That is that web vitals tell you only about the very first impression that a user may have when opening your page. Even though this is utterly important, it doesn’t tell you, for example, how long it’ll take for a user to search for a product or add this product to a cart.
It’s easy to get fixated on improving the loading time of the homepage while forgetting about the rest of the system. So, what I propose as a complementary measure is a time required to finish a given user journey like, for example, the time required to search for a product, add it to the cart, and successfully checkout. The problem with this is that it requires custom-measurement implementation, and there are no standard timings to compare with. You have to define what’s acceptable on your own. Nevertheless, this approach would help you find the bottlenecks that your users experience.
What about Spartacus?
I’ll be honest with you. Simply adding Spartacus to your project adds around 2 MB to your bundle size. That’s a lot, but it’s compared to an application that does literally nothing 😎 . I’m aware that creating your storefront from scratch might result in a slightly better performance than Spartacus-based because Spartacus has to be generic. This adds some overhead. However, you have to think how long it would take to develop a custom storefront, how much it would cost, and what could go wrong along the way.
In return for adding some overhead, Spartacus comes in with some cool performance optimization features.
- Lazy loading lets you load modules and components on demand, resulting in better initial page load time.
- Image lazy loading makes the images load when they are actually needed.
- Server-side rendering not only improves SEO, but it also speeds up the initial page load.
- Above-the-fold loading and deferred loading are techniques to only load components which are visible to the user at the moment.
- Loading scopes limit data payload to be transferred through the network.
- Progressive web apps (PWA) caches static assets and, optionally, data on a device.
This all makes Spartacus quite fast and efficient. However, this won’t save you if your custom Angular/JavaScript code is slow. So, before you fiddle with these features, inspect your own code first, and make sure it’s free of bottlenecks.
See what you can get from Spartacus Audit Offer >
Conclusion
It’s hard to say whether Spartacus is fast or not in the case of performance. It depends on the implementation and the measures applied. What I can say, for sure, is that it’s very fast to market, and the performance is better than in the accelerator-based storefronts. There’s no silver bullet for performance measurement. I think that the combination of different measures tailored to your specific project is the right way to go.
Published April 27, 2021
