< SPA Audit />
Identify and understand the issues of your Single Page App
Is your web application based on a JavaScript framework like React, Angular, Vue.js, or Svelte not meeting your users' expectations?
Get a quote in 24 hoursDon't let failing Core Web Vitals permanently penalize your online business!
< Our web performance experts audit your web app to identify performance issues />
We audit all JavaScript frameworks
Improve the performance of your critical visits
SPAs offer undeniable performance advantages when it comes to viewing many pages. However, the situation is very different when focusing on the initial load, which occurs for new visitors. Several costly steps must be executed sequentially:
- downloading generally heavy JavaScript bundles
- executing these scripts, which generate Blocking Time (TBT) and negatively impact interactivity (INP)
- rendering the page and its components, which again consumes a significant amount of CPU resources
- hydration (adding user interactions), which can occur during or after the third phase depending on the technical stack
Only once these steps have been completed does the original blank page give way to your web application. However, numerous studies have demonstrated the value of focusing specifically on the First Visit Experience: in web performance as in other fields, it is indeed "the first impression that counts".
Our experts are masters in optimizing the loading of SPAs regardless of the framework used: React, Next.js, Angular, Vue.js, Nuxt…
A service in 6 key steps
Our SPA audits are broken down into several key stages.
Technical Alignment
01Our experts meet with your teams to learn more about your web application and its technical stack, both back-end and front-end. A focus is placed on the framework, the rendering mode (SSR or CSR), the server environment, and any potential API connections. The objective is to propose operational recommendations adapted to your constraints.
RUM Tag Implementation
02We place a tag on your site that collects performance data from your real users. This "RUM" data is used to precisely identify bottlenecks. Thanks to this data-driven approach, we operate with maximum visibility on your issues.
Site Audit
03Our experts examine your site using a well-established methodology and a battery of tools. They identify the issues that impact web performance and, for each one, propose one or more concrete and actionable solutions. In the specific case of SPAs, the JavaScript component undergoes further in-depth analysis. The objective is multifaceted:
- reduction of CPU resource usage when idle
- improvement of rendering times by reducing unnecessary style and layout recalculations
- improvement of responsiveness during navigation (INP metric)
Prioritization of Recommendations
04We rank our recommendations using the RICE prioritization method: Reach (number of users reached), Impact on performance, Confidence, and Effort of deployment. We thus design your web performance roadmap by prioritizing the rapid deployment of quick wins for measurable results.
Deliverable Presentation
05The deliverable, drafted as part of the performance audit, is presented to the development and business teams. The objective is to ensure that its content is perfectly understood by stakeholders, which is key to a quick and effective implementation. It is also a prime opportunity to answer questions and define the milestones for the final stage.
Testing of deployments
06A dashboard allows our experts to monitor the deployments of your development teams. They can thus validate the relevance and effectiveness of the implementations with great responsiveness. This can be done directly in production, or on a staging or pre-production environment (ideal). In case of divergence from what is expected, detailed explanations are shared to help achieve the objective.
They entrusted us with the audit of their web application
Have a question?
We have the answer!
Consult the FAQ for details about the service.
What server-side rendering technologies do you work with?
Our experts work with all types of technical stacks with consistently beneficial results: whether rendering is done client-side (CSR), server-side (SSR), or via static generation (SSG/ISR), we master all modern frameworks.
We adapt our optimizations to the existing architecture for measurable gains, regardless of your stack.
How much does an SPA audit cost?
Our SPA audit service is **fixed price**. It includes the six key stages presented above, as well as all the support from our pre-sales and post-sales teams.
An SPA audit costs between €2,500 and €3,500 excluding tax, depending on the framework in place, the number of user journeys to instrument, and the rendering complexity. For a quote matching your scope, contact us by message or phone: Marylise will send you a personalized proposal.
Why is an SPA slow to load initially?
A client-side rendered Single Page Application first delivers an almost empty HTML, then downloads and executes the JavaScript that builds the page. Nothing displays until this code has run: the browser waits, whereas a server-rendered site would have already painted its main content.
The cost is spread over three successive stages: downloading the bundle, parsing and compiling it by the JavaScript engine, then execution which often triggers API calls before the first meaningful paint. Each step adds to the LCP, and the last two depend on the device's power, not the bandwidth.
This is why an SPA seems instantaneous on a development machine and slow on an entry-level mobile. Downloading can be fast, execution remains costly: the visitor's processor becomes the limiting factor, and it varies by a factor of five or more depending on the actual device pool.
Subsequent navigations, on the other hand, are the model's strong suit: the router changes views without a full reload. The initial screen is the only real problem for an SPA, which explains why fixes focus on it rather than the entire application.
What is the difference between SSR, SSG, and CSR?
CSR, or client-side rendering, builds the page in the browser from an empty HTML. SSR, server-side rendering, generates the complete HTML for each request. SSG, static site generation, produces the HTML once at build time and serves it as is. The three differ in when the HTML is produced.
Their performance profiles are directly deduced from this. SSG offers the best TTFB and LCP, as a static file is served from a CDN. SSR adds server generation time but delivers up-to-date content. CSR shifts all the work to the browser, and therefore pays the most for the initial screen.
The choice depends on the freshness required by the content. A product page whose stock changes continuously is not well suited to SSG; documentation or a blog have no reason to be rendered on each request. Modern frameworks allow mixing the three within the same application, page by page.
Add to this hydration, a common step for both SSR and SSG: JavaScript takes back control from the already displayed HTML to make it interactive. Heavy hydration negates some of the gains, which explains recent partial or deferred hydration approaches in Next.js, Nuxt, and Astro.
How to measure the Core Web Vitals of an SPA?
Standard tools only measure initial loading, whereas most of the user journey happens during subsequent internal navigations. These navigations are invisible to classic Core Web Vitals: the browser doesn't consider them new pages, and no new LCP is recorded.
Two mechanisms fill this blind spot. The web-vitals library allows instrumenting the application to record LCP, CLS, and INP per view, and the Soft Navigations API, still experimental in Chrome, aims to treat route changes as actual navigations. Without instrumentation, an SPA remains largely unmeasured.
INP deserves special attention on this type of application. It's the metric that truly captures the cost of JavaScript-managed interactions: filters, instant search, add to cart, panel opening. An SPA fails more often on INP than on LCP, precisely where it claims to excel.
This is why our audit begins with deploying a Real User Monitoring (RUM) tag. Field data is the only reliable source for an application whose user journeys vary based on the user, their permissions, and their browsing history.
Should you switch to SSR to improve performance?
Not systematically. SSR significantly improves the first screen, thus LCP and FCP, but it doesn't fix an overly large bundle, costly hydration, or degraded INP. It shifts the work without eliminating it, and adds server infrastructure where static hosting was sufficient.
Before undertaking a migration, check what your RUM measures. If LCP is poor but INP is acceptable, SSR is relevant. If INP is the weak point, the work involves JavaScript chunking and reducing work during execution, whether the rendering is server-side or client-side.
A less costly alternative often deserves to be studied first: pre-rendering public pages using SSG, while keeping CSR for authenticated journeys. Pages that receive organic traffic gain instant rendering, without needing to refactor the entire application.
