Accelerating Single-Page Applications (SPAs) With Speed Kit

‍

Key Takeaways

• Solves Core SPA Challenges: Speed Kit is specifically designed to solve the unique performance challenges of Single-Page Applications by optimizing both initial loads and subsequent "soft navigations" which are often invisible to standard tools.
• Intelligent Acceleration: Acceleration is achieved through multiple techniques, including API call caching and transforming slow soft navigations by predictively pre-rendering them in the background.
• Advanced LCP Measurement: Speed Kit has developed techniques to accurately measure the Largest Contentful Paint (LCP) for soft navigations, providing a true picture of a user's perceived loading performance where standard tools fail.

Introduction

Single-Page Applications (SPAs), often built with popular frameworks like React, Vue, and Angular, have become a cornerstone of the modern web, offering fluid, app-like user experiences. However, this architecture presents unique challenges for performance optimization that traditional methods cannot solve. Unlike multi-page sites, SPAs rely on "soft navigations"—dynamically rewriting content with JavaScript instead of full-page loads.

This fundamental difference means that standard caching techniques and performance metrics often fail. A user might experience significant slowness when navigating between views, but this lag can be completely invisible to traditional tools. Speed Kit addresses this blind spot with a suite of specialized techniques designed for the SPA lifecycle.

SSR vs. CSR: A Quick Comparison

The performance of an SPA is heavily influenced by its rendering strategy.

• Server-Side Rendering (SSR): The server sends a fully rendered HTML page to the browser, allowing for a fast initial display of content. While all common SPA frameworks support this capability, it requires additional server infrastructure that must be managed and paid for, making its adoption a customer-specific decision. It is generally the recommended approach for optimal performance, as it mitigates the initial JavaScript initialization overhead.
• Client-Side Rendering (CSR): The browser receives a minimal HTML shell and uses JavaScript to render the content. This can lead to a slower initial load and a poor Largest Contentful Paint (LCP), as the user must wait for scripts to download and execute. Since the LCP for an SPA is only measured on this first page view, a slow initial load can negatively affect your Core Web Vitals score in the Chrome User Experience Report (CrUX)—a public dataset from Google that collects real user performance data—which may impact search ranking and ad prices.

For a detailed analysis of these architectures and how Speed Kit optimizes them, please refer to our full documentation on Rendering Architectures.

Solving SPA Performance Bottlenecks

Speed Kit offers two powerful ways of optimizing soft navigations. The best strategy depends on the client's specific setup, and we use our Real User Monitoring (RUM) data to make a smart, data-driven decision for each application. It is possible to use one or both methods depending on the project's goals. Both methods are compatible with all modern browsers. Both methods only apply to page types that are whitelisted for acceleration by Speed Kit.

Method 1: Transforming Soft Navigations into Hard Navigations

A major bottleneck in SPAs is the JavaScript rendering process itself. After the API data is received, the framework must execute code to build the new view and update the DOM (the structural representation of the page). This process can occupy the browser's main thread, leading to significant delays, especially on average mobile devices with limited CPU and memory resources.

The "Soft-to-Hard" navigation technology is a powerful tool that typically has a greater performance impact than API caching. As this method fundamentally alters the application's default navigation behavior, it is only enabled with explicit customer approval.

The underlying logic only transforms the navigation if the destination page has already been pre-cached or pre-rendered, which guarantees that the resulting hard navigation is faster than the original soft navigation. This ensures the user always experiences the fastest possible page transition. An important additional benefit is the positive impact on Core Web Vitals, as this method generates new hard navigations that are correctly measured by Google's Chrome User Experience Report (CrUX).

1. Predictive Preloading & Pre-rendering: Using machine learning on RUM data, Speed Kit predicts the user's next action and either pre-caches or pre-renders (in Chromium browsers) the complete HTML for the destination page in the background. For more details on this process, please refer to our documentation on Predictive Preloading.
2. Navigation Check & Conditional Switch: When the user clicks a link, Speed Kit first checks if the target page has been successfully pre-cached or pre-rendered.
   
   • If the page is pre-cached or pre-rendered: Speed Kit intercepts the JavaScript event and performs an instant hard navigation. This leverages the browser's highly optimized native renderer, completely bypassing the framework's client-side rendering process.
   • If the page is not pre-cached or pre-rendered: Speed Kit allows the SPA's default soft navigation to proceed. In this scenario, the navigation can still be accelerated using Method 2.
3. Implementation: Speed Kit can automatically intercept navigation events to apply this logic. For a more direct integration, the same logic can also be added to your application's router (the part of the SPA that manages URL changes).

This method has shown excellent results across several customer implementations and is the ultimate optimization for SPAs, as it combines the predictive power of Speed Kit with the raw rendering speed of the browser.

Method 2: API Call Caching

This foundational method accelerates soft navigations by caching the API calls that fetch data for the next view. The time spent waiting for these network requests is a major source of delay. By caching the API responses in the browser, the required data can be served instantly when a user navigates. Furthermore, this method can be wired together with our predictive preloading engine. By analyzing user behavior, Speed Kit can predict which API calls will be needed for the next soft navigation and proactively fetch them before the user even clicks.

Important Prerequisite: This method is only effective if your backend architecture separates general, cacheable content (like product data) from personalized, uncacheable content (like user information) into distinct API calls. An API endpoint that returns mixed content cannot be cached.

To ensure data from these cached APIs is always up-to-date, the same powerful cache coherence mechanisms used for HTML content are applied. This includes real-time change detection and the ability to trigger refreshes, either manually through the dashboard or automatically on a schedule. You can learn more about how this works in our documentation on Dynamic Caching.

Fallback: Accelerating Hard Navigations

In cases where neither of the above methods for accelerating soft navigations can be implemented, it is important to remember that Speed Kit’s core technology always accelerates hard navigations. This includes the crucial first page a user lands on, which has a significant impact on the overall user experience, especially for returning users and traffic from marketing campaigns like retargeting.

Measuring Real SPA Performance

Tracking Core Web Vitals (CWV) in Single-Page Applications is notoriously difficult. Many of our customers were not aware that their data in the Chrome User Experience Report (CrUX)—a public dataset from Google that collects real user performance data—only represents the initial page load correctly. Since the first load is typically the slowest because the entire JavaScript framework must be downloaded first, this creates a skewed picture of the overall user experience. While some clients measure their API response times, the subsequent JavaScript rendering time remains a huge blind spot in their data. This lack of visibility makes it very difficult to make smart, data-driven decisions about performance.

The technical problem begins with the fundamental challenge of reliably identifying when a "soft navigation" has even occurred. Different frameworks handle this process in unique ways. Some change the URL, while others do not; the timing of this change can also vary. This inconsistency makes it incredibly hard for monitoring tools to pinpoint the precise start and end of a navigation event, including the subsequent rendering process. Many soft navigations render the new view in several iterations—often involving animations or interim loading spinners—making it challenging to measure the correct final paint of the new content.

The Measurement Challenge

• Largest Contentful Paint (LCP): Standard LCP only measures the initial load. It does not capture the LCP of a new view that appears after a soft navigation, which is often the most important perceived loading metric for the user.
• Interaction to Next Paint (INP): The INP for the entire session is defined by the single slowest interaction that occurs. This makes it difficult to trace a poor score back to the specific soft navigation or component that caused the delay.
• Cumulative Layout Shift (CLS): The measurement method, which finds the worst 5-second window of layout shifts, is the same for all page loads. However, for hard navigations, only the windows on that specific page are considered. In an SPA, windows from the entire session are evaluated, and the worst one becomes the final CLS score. This makes it very difficult to trace a poor score back to the specific soft navigation that caused it.

Ultimately, the way INP and CLS are measured across an entire session means the Core Web Vitals scores for an SPA in CrUX are likely to be worse than for a traditional site. The longer a user's session, the higher the likelihood that a single poor interaction or a significant layout shift will occur, which then defines the score for the entire journey.

The Google Solution

The Google team is aware of these challenges and is working to standardize the definition of a soft navigation. Their proposed approach requires a navigation to meet three criteria to be considered valid: it must be initiated by a user action, it must change the URL visible to the user, and it must result in a meaningful manipulation of the DOM. A full solution to enable the tracking of soft navigations in a way that is similar to hard navigations is currently in the making. For more info, read the following article: “Experimenting with measuring soft navigations”.

The Speed Kit Solution

To provide our customers with actionable data immediately, Speed Kit has developed its own solution to track the LCP of soft navigations today, rather than waiting for Google's official standard to be finalized. Our integrated RUM includes advanced instrumentation designed to accurately track the LCP for soft navigations. This provides an authentic picture of how users genuinely experience your site, allowing you to segment performance data, correlate it with business metrics, and proactively identify real-world regressions with the help of our Web Performance Intelligence Team. You can find detailed information about our approach in the blog post “Measuring Largest Contentful Paint in Single-Page Applications”.