SPA Audit
Identify and understand the issues with 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 24hDon'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 if we focus on the first load, which occurs for new visitors. Several costly steps must indeed be executed successively:
- 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 are completed does the original blank page give way to your web application. However, multiple 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 master the optimization of SPA loading 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 back-end and front-end technical stack. The focus is on the framework, the rendering mode (SSR or CSR), the server environment, and any API connections. The goal is to provide 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 suite 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 is analyzed more thoroughly. The goal is multifaceted:
- reduction of CPU resource usage at idle
- improvement of rendering times by reducing unnecessary style and layout recalculations
- improvement of responsiveness during navigation (INP metric)
Recommendation Prioritization
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 webperf roadmap by prioritizing the rapid deployment of quick wins, for quickly measurable results.
Deliverable Presentation
05The deliverable prepared as part of the performance audit is presented to the development and business teams. The goal is to ensure that its content is perfectly understood by stakeholders, which is key to a quick and effective implementation. It is also a privileged time to answer questions and define the milestones for the final stage.
Deployment Acceptance Testing
06A dashboard allows our experts to monitor the deployments of your development teams. They can thus validate the relevance and effectiveness of 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 achieve the objective.
They entrusted us with the audit of their web application
You have a question?
We have the answer!
Consult the FAQ for more details on the service.
Our experts work on all types of technical stacks with consistently beneficial effects: whether the rendering is done client-side (CSR), server-side (SSR), or with static generation (SSG/ISR), we master all modern frameworks.
We adapt our optimizations to the existing architecture for measurable gains, regardless of your stack.
Our SPA audit service is fixed-price. It includes the six key steps presented above, as well as all support from our teams, both pre-sales and post-sales.
A 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 corresponding to your scope, contact us by message or phone: Marylise will send you a personalized proposal.
A Single Page Application with client-side rendering first delivers an almost empty HTML, then downloads and executes the JavaScript that builds the page. Nothing is displayed 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, its analysis and compilation 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 terminal's power, not the bandwidth.
This is why a SPA appears instantaneous on a development machine and slow on an entry-level mobile. Downloading can be fast, execution remains costly: it's the visitor's processor that becomes the limiting factor, and it varies by a factor of five or more depending on the actual device pool.
Subsequent navigations, however, are the model's strong point: the router changes view without a full reload. The first screen is the only real problem for a SPA, which explains why fixes focus on it rather than the entire application.
CSR, or client-side rendering, builds the page in the browser from an empty HTML. SSR, server-side rendering, generates the full HTML for each request. SSG, static site generation, produces the HTML once at build time and serves it as-is. All three differ in when the HTML is produced.
Their performance profiles are directly inferred from this. SSG offers the best TTFB and the best 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 first 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 every request. Modern frameworks allow mixing the three within the same application, page by page.
Added to this is hydration, a step common to SSR and SSG: JavaScript takes over the already displayed HTML to make it interactive. Heavy hydration negates some of the gain, which explains recent approaches to partial or deferred hydration in Next.js, Nuxt, and Astro.
Standard tools only measure the initial load, whereas most of the user journey takes place during internal navigations. These navigations are invisible to classic Core Web Vitals: the browser does not 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 real navigations. Without instrumentation, an SPA remains largely unmeasured.
INP deserves special attention on this type of application. It is 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 the deployment of a RUM tag. Field data is the only reliable source for an application whose user journeys vary depending on the user, their permissions, and their browsing history.
Not systematically. SSR significantly improves the first screen, thus LCP and FCP, but it doesn't fix an overly heavy bundle, costly hydration, or degraded INP. It shifts the work without eliminating it, and adds server infrastructure where static hosting was sufficient.
Before starting a migration, check what your RUM measures. If LCP is bad but INP is correct, SSR is relevant. If INP is the weak point, the work involves splitting the JavaScript and reducing the 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 handle organic traffic gain instant rendering, without recasting the entire application.