In this post, we’ll look at how Vue, React, and Angular compare in terms of performance and what can be done to optimize eCommerce SPAs running on these frontend frameworks for the best user experience.
Running a fast site leads to bottom-line growth through better SEO ranking, more visitors, longer sessions, and, as a result, more revenue. Many eCommerce leaders who understand the role of speed have already shifted to headless commerce architecture, enabling the adoption of modern frontends, such as progressive web apps and SPAs. Lightweight SPA frontends are gaining popularity because they are a surefire way to solve various performance issues inherent to modern eCommerce platforms so that operators can deliver lightning-fast storefronts.
Well, that’s the theory. To verify these lofty claims, we performed a small in-house performance analysis. To this end, we tested nearly 2,000 popular eCommerce websites running on the leading frontend frameworks and assessed their performance based on Lighthouse 6 scores. The findings were surprising—the average Lighthouse score for the tested SPA frontends was only 24, with a median of 19 (out of 100)! Low as it sounds, this was still 26% higher than the average score for the leading 500 US internet retailers by revenue.
Vue.js sites were the fastest, averaging a score of 27 with a median of 20. Angular websites saw an average of 23; however, their performance scores were more dispersed, with a median of just 18. React websites were the slowest tested, with an average Lighthouse score of 22 and a median of 18. This was surprising, especially since the framework is used by some of the biggest players, including sites like PayPal, Grammarly, and Vimeo, to name a few.
The conclusion of the test was rather clear—while SPAs are thought to be faster than traditional websites, there is still room for improvement. Moreover, Google CrUX and other measurement tools don’t track the page transitions of Single-Page Applications (SPAs), misrepresenting them as being far slower than they are and penalizing their scores. We write more about this issue in another post on the blog.
The performance of apps is defined by two metrics: start-up time and runtime performance. The size of the code bundle primarily influences the former—i.e., the app code and the framework code combined. Runtime performance is contingent on the specific optimization features of the framework and the way it handles DOM manipulation and updating.
All three frameworks have similarly-sized, minimal code bundles. Although the framework’s bundle size impacts start-up time, the metric shouldn’t be the main focus when comparing the performance of Angular, React, and Vue.
More precisely speaking, Angular bundle size is only slightly larger than Vue and React bundle sizes, with Vue bundles being a bit smaller than React bundles. Also, it is worth noting is that the Angular dev team is steadily optimizing the size of their (source) code bundles.
See the chart below for the approximated numbers.
Angular, React, and Vue all offer great runtime performance, and each is equally fit to be the backbone for complex, revenue-generating websites with heavy traffic.
Lighthouse is a great testing tool that returns valuable speed insights. It identifies possible performance issues and helps optimize a site's various aspects. A lighthouse score is calculated based on a weighted average of multiple metrics (go here for a full rundown). Still, the Largest Contentful Paint (LCP), Time To Interactive (TTI), and Cumulative Layout Shift (CLS) are very likely the most important ones from the user’s perspective. TTI and LCP are directly connected with perceived load speed.
TTI is a good representation of the impact of a framework’s bundle size on the speed of the SPA, as the bundle needs to be evaluated entirely before a user can interact with the app. Sites with a long TTI will show various pieces of the site while loading but won’t allow users to interact with it, which may ultimately lead to frustration.
The LCP metric, on the other hand, measures how long it takes until the largest element of the page's content is rendered on the screen.
Synthetic tests also tend to simulate older devices and connections (e.g., Lighthouse simulates 3G connections), while in reality, most mobile users are on fast LTE or even 5G networks.
A site running on a specific framework may “feel” faster but lose to other sites regarding its raw performance score and vice versa. This is mainly due to specific tricks (e.g., lazy loading) that each framework employs to improve how fast the site “feels” to users.
In the next sections, we will review the opportunities each of these frameworks offers for improving website performance.
Angular extends the HTML code with new tags and attributes and interprets the attributes to perform data binding.
Due to its rich features, the working application may be much bigger (approximately 500KB) compared to Vue or React, which may slightly impact performance.
Angular’s MVC abstraction (source)
Here is a quick summary of the main benefits of Angular.
Code splitting. Thanks to Component Router, Angular apps load quickly, delivering automatic code-splitting. This way, users load the code required to render the view they request.
Real DOM. Angular uses real DOM; therefore, it’s best suited for single-page applications where content is only updated from time to time, not those that frequently change, such as most eCommerce sites. Manipulating the virtual DOM is much faster because nothing is drawn on the screen.
Created and developed by Facebook, React is one of the most popular open-source mobile application frameworks. It doesn’t provide a wide range of libraries; thus, its size is significantly smaller than that of Angular.
With single-direction data, React allows better control over the project—when designing an app, React developers can nest child components within higher-order parent components.
React offers some interesting features, including:
Virtual DOM: Nodes are re-rendered only as needed. React compares the new data with the original DOM and updates the View automatically. This enhances the performance of all-sizes applications that need regular content updates.
One-way data binding: React uses one-way data binding with Flux controls application architecture. ReactJS helps update the View for the user, and Flux controls the application workflow. Virtual DOM adds advantages as it compares the new data with the original DOM and updates the View automatically.
Support for bundling and tree-shaking: minimizes the end user’s resource load.
Server-side rendering (SSR) support: offering speed gains in specific implementations.
To a bigger extent than Angular and Vue, React utilizes certain techniques that make the page “feel” faster to end users. For example, the framework prioritizes user input over rendering content on the page.
Vue is fast and very small at just about 30KB (gzipped), which results in faster first loads. This makes it the smallest of all the three frameworks and significantly speeds up the performance of websites running on Vue.
Server-side rendering (SSR)
Virtual DOM: changes within a project don’t affect the DOM properly. Modifying the real DOM is a resource-intensive task, so updates are first applied to the virtual DOM.
We know that benchmarks and performance scores don’t tell the whole story. Website speed may vary depending on application size and your optimization efforts. Here are a few ideas to help optimize Vue, React, and Angular SPAs for speed.
Overall, there are four key benefits of using SSR with SPA sites:
SSR allows you to quickly load a SPA template and display content to the user (although the user may not be able to interact with it immediately). Without SSR, users would stare at an empty screen, waiting for the content to load and render in the browser.
SSR reduces the load on the end user’s machine.
Social networks often can’t properly display content shared from client-rendered SPA sites. For example, Facebook scraper only relies on the meta tags set by the server—and doesn't work with client-side rendered meta tags. To better control how your SPA site looks when shared through Open Graph, SSR is a must.
Layer0 network and monitoring tools ensure that dynamic data is cached at least 95% of the time, shielding your database from the extra requests created by prefetching. This way, you can provide sub-second page loads, offering your visitors a seamless experience from landing through checkout.
Layer0 network and monitoring tools
Overall, regarding SSR capabilities and detailed documentation, Vue is superior to React, which needs third-party libraries (e.g.Next.js) to render pages server-side.
The downside is it’s different from how you write a PWA/SPA and means a complete rewrite of the app unless you use a dedicated framework with built-in AMP support, such as React Storefront.
AMP pages have 500ms median page loads for traffic coming from Google’s SERP. These speeds are possible because Google servers prefetch and prerender AMP content to a user’s browser before clicking on the AMP page link. The average eCommerce site gets a large chunk of its traffic from Google search (both organic and paid), so these gains can have a massive impact.
Sites that use AMP also see reduced bounce rates, as users who may typically bounce while waiting for a page to load will now be met with a lightning-fast experience.
Your single-page application will grow over time as you continue to add features. But we know that every application has some features that are hardly ever used and unnecessarily slow down. You should implement code splitting to keep your app as fast as possible.
Code splitting involves creating separate bundles for each top-level component in your app. In the case of an eCommerce SPA, there will be separate bundles for the home page, product listings, and product description pages. This way, when a user arrives at your app via a link to a specific product, the browser doesn’t need to download and run the code for all of the previous pages, thus cutting the TTI and FID times.
With code splitting, the app can “lazy-load” other page components in the background and use them if the user decides to navigate them. This saves bandwidth and decreases first input delay or FID (note FID is often approximated by time to interactive or TTI metric), improving your website speed and search engine ranking.
Vue, React and Angular all support lazy loading, which, in combination with SSR, can provide significant speed improvements.
Lazy loading presents a challenge when implementing SSR. The server should know which components were used to render the outgoing HTML and send the code for those components alongside the HTML. Otherwise, the app will need to mount in the browser and run two render cycles before it’s ready to be interactive, which will increase FID (and TTI), which may lead to content flash or jank.
Lazy loading and SSR are connected. The library you choose for lazy loading (e.g., React Loadable) will affect how you generate the final HTML sent back in the response. To capture the bundles that need to be loaded to hydrate the HTML that was rendered on the server, you’ll need to add <loadable.capture></loadable.capture> to your SSR code, then use React Loadable’s getBundles function to figure out which <script></script> tags need to be added to the document body.
Because lazy load client hints are not yet supported globally by all browsers, there are a couple of workarounds to implement lazy loading seamlessly.
Instead of rendering the images server-side, you can let them populate client-side when the app mounts.
Only use lazy loading for images “below the fold,” i.e., those you know will not be visible immediately after loading. This is challenging because the fold line may move up and down depending on the user’s device and display size. However, some heuristics help. For example, on an eCommerce category page, you might turn off lazy loading for the first set of product images (they are likely to be “above the fold)”. And for items you know will consistently be above the fold (e.g., headers, company logos, cart icons), you shouldn’t enable lazy load anyway and can always render them server-side.
Detecting the user agent can help to serve an appropriate version of the SSR-rendered page. User-agent detection is not generally recommended for implementing progressive enhancement, but it does the trick as a temporary workaround while browsers catch up and implement client hints.
This solution requires that you normalize your cache keys appropriately; otherwise, you could fragment your cache significantly.
Optimizing your SPA for speed and using a good CDN on top of that will boost your site, but it is not enough to achieve sub-second speeds. This is because most traditional CDNs are only good at caching static files, but overall they don’t cope so well with JSON/HTML/SSR data—whereas that’s exactly what eCommerce SPA sites are made of. Making these sites faster requires several web technologies working efficiently in unison. Unlike other CDNs, Layer0 application-aware CDN works well with eCommerce SPAs. It optimizes cache hit ratios to unheard-of levels and brings intelligence to the edge. This helps business owners decipher trends and opportunities for optimization by categorizing similar pages as such (for example, PDP, PLP, and Cart) instead of just displaying an endless list of URLs. This lets you take action and see a difference in website load times.
Angular is great for building mobile apps. You can use the framework to build a web application that runs on any device or develop iOS and Android native apps by combining Angular with NativeScrip. This allows you to reuse Angular concepts such as data binding, dependency injection, services, and routing.
Although Vue lags behind React, it still offers several valuable solutions for mobile development. For example, NativeScript allows you to write Vue applications and compile them to native iOS/Android apps.
Then comes Vue Native. The framework combines the advantages of Vue and RN ecosystems, declarative rendering, two-way binding, and a set of basic components for creating a cross-platform native app.
The original allure of a single-page application is that subsequent pages don’t reload during navigation, leading to a faster, frictionless browsing experience. But modern SPA frontends are only part of the site speed solution, and a couple of problems still need to be addressed:
Synthetic speed benchmarks and tests don’t necessarily tell the whole story. The speed of these frameworks may vary depending on application size and your optimization efforts.
While various cutting-edge frontend technologies, including progressive web apps, SPAs, and AMP, can dramatically enhance the customer experience, website speed is a full-stack problem. It spans the browser, edge, and server. This is why a full-stack solution is needed to speed up any website, SPA, and multi-page application.
All these technologies can improve speeds but work best when applied in unison. Making all these technologies work together is a complex task that in-house teams may be unable to handle (for example, it requires creating a Node.js layer).
Layer0 is a complete solution for making eCommerce websites fast and easier to develop. It combines advanced optimization techniques to speed up large-scale, database-driven websites, such as eCommerce SPAs, along with powerful tools that give devs back a day a week by putting the code in the center of their workflows. Layer0 essentially brings Jamstack to large eCommerce websites.
Simple: Layer0 (now Edgio) is your all-in-one platform to develop, deploy, preview, experiment on, monitor, and run the frontend that lets you:
Utilize Jamstack for eCommerce via both pre and just-in-time rendering
Enable zero latency networking via prefetching of data from your product catalog APIs
Run edge rules locally and in pre-prod
Create preview URLs from GitHub, GitLab, or Bitbucket with every new branch and push
Run splits at the edge for performant A/B tests, canary deploys, and personalization
Running a faster site is not just a fancy gimmick. At the end of the day, you are not only trying to wow your users but also attempting to please the largest search engine in the world. Since Google’s ranking will soon be determined, in part, by page speed, it cannot be taken lightly. A fast site means boosts your SEO rankings and conversions, which, in turn, generate more revenue.
While much can be said about the performance of each framework, there are three points to remember:
Real-world differences in framework performance may be minuscule. The performance of SPA sites depends on so many variables that it’s impossible to compare these frameworks side-by-side in a meaningful way.
Whether you’re on Angular, Vue, or React, there is still much space for improvement.
Making SPAs faster requires a combination of advanced web technologies working in unison, and your in-house teams may not be able to implement them efficiently. Thankfully a few forward-thinking vendors, including Layer0, have done the heavy lifting for you.