Does Google PageSpeed Insights really analyze Single Page Apps effectively?

Can PageSpeed Insights really evaluate a SPA effectively?

The tool PageSpeed Insights analyzes web pages according to standardized criteria, without specific logic for Single Page Applications. In practice, PSI measures Core Web Vitals and other performance metrics without adjusting to the particular architecture of SPAs built with Angular, React, or Vue.

The issue? These frameworks operate differently from traditional sites. Content loads progressively via JavaScript, the initial rendering may be minimal, and most interaction occurs on the client-side. Therefore, PSI may measure an intermediate or incomplete state, generating inappropriate recommendations for the real context of a SPA.

Should you ignore PageSpeed Insights suggestions for a SPA?

No, but they should be filtered intelligently. Mueller points out that some suggestions "may not apply exactly." This cautious wording indicates that Google acknowledges the limitations of its tool in the face of modern architectures.

Take a concrete example: PSI often recommends reducing unused JavaScript on a SPA. However, this "unused" JavaScript at initial loading can be crucial for subsequent interactions. Blindly applying this recommendation may break the user experience without real gain.

Are indexing and ranking affected by this limitation?

Mueller states that they are not. The performance measured by PSI does not directly affect Google’s ability to index and rank a SPA. This is consistent with what we observe: well-designed SPAs rank properly, even if PSI rates them with average scores.

The important nuance: Google can index and crawl a SPA if it is technically accessible. The real risk is not the PSI score, but an architecture that blocks Googlebot (lack of server-side rendering, blocking JavaScript, timeouts, etc.). Core Web Vitals remain a ranking signal, but their measurement by PSI is only a rough indicator.

• PageSpeed Insights analyzes without specific adaptation for SPAs, sometimes generating irrelevant recommendations
• PSI suggestions should be interpreted according to the context of the JavaScript architecture used
• The indexing and ranking of a SPA do not directly depend on the PSI score, but on the actual accessibility for the crawler
• Core Web Vitals remain important, but their measurement via PSI can be misleading for a SPA
• The priority is to ensure server rendering or pre-rendering for critical content, not to maximize the PSI score

Is this statement consistent with what we observe in the field?

Yes, and it is even an indirect admission of the limitations of Google’s tooling. For years, SEOs have seen that PSI gives erratic results on SPAs: variable scores from one test to another, metrics that do not reflect the real experience, recommendations that break functionality if applied harshly.

Mueller’s wording (“the suggestions may not apply”) is revealing. Google implicitly acknowledges that its flagship performance tool is not calibrated for modern architectures. Yet, how many teams have wasted time optimizing PSI metrics on SPAs, without real impact on traffic?

What nuances should be added to this claim?

Mueller states that this "does not affect their performance in search results." This is technically true for pure indexing, but partially false for ranking. Core Web Vitals have been a ranking signal since the Page Experience Update, and PSI remains one of the ways to measure them.

The real nuance: Google measures CWV via real-world data from the Chrome User Experience Report, not via PSI. If your SPA offers an excellent real experience to Chrome users, your CWV will be good in CrUX, even with a mediocre PSI score. Conversely, a good PSI score in the lab guarantees nothing if real users experience slowdowns. [To be verified]: Google has never clarified the exact weighting of CWV in the overall algorithm.

In what cases does this rule not apply?

Be careful with badly built SPAs that completely block initial rendering. If Googlebot has to wait 5 seconds for a JavaScript to execute to see any content, indexing will be compromised, no matter what Mueller says. The crawl budget will be wasted, and pages may remain orphaned.

Concrete case observed: Angular SPAs without Server-Side Rendering or pre-rendering, with content loaded after authentication or via slow APIs. PSI gives them a catastrophic score, and indeed, Google struggles to index them. This happens not "because of" the PSI score, but because the underlying causes (blocking JavaScript, lack of initial content) affect both PSI and Googlebot.

What should you do concretely on an existing SPA?

First step: check that Googlebot can actually access the content. Use the URL Inspection tool in Search Console to see what Google renders. If the main content appears, indexing is working. If you see a blank skeleton or an infinite loader, that’s where to take action.

Second priority: implement Server-Side Rendering or pre-rendering for strategic pages (product pages, articles, category pages). Solutions like Next.js for React, Nuxt for Vue, or Angular Universal exist precisely for this purpose. Server rendering ensures that Googlebot receives immediately usable HTML without relying on JavaScript execution.

What mistakes should you avoid regarding PSI recommendations?

Do not sacrifice real user experience to improve a lab score. A typical example: removing critical JavaScript to reduce the "Reduce unused JavaScript" metric, then finding that interactions no longer function properly. PSI measures a moment in time, not the complete journey.

Another common mistake: optimizing only the homepage for CWV, neglecting deeper pages. In a SPA, internal transitions (navigation between views) do not trigger a complete reload. If these transitions are slow or choppy, the overall experience degrades, even if PSI shows green on the homepage.

How can you verify that your SPA is indexable and performing well?

Use real CrUX data rather than synthetic PSI scores. In PageSpeed Insights, check the "Field Data" tab that shows metrics from real Chrome users. These are the data Google uses for ranking, not synthetic tests.

Regularly check Search Console: indexed vs. submitted pages, coverage errors, average loading speed. If the number of indexed pages stagnates while you publish content, it’s a warning signal. Compare with server logs to identify if Googlebot is properly crawling your URLs.

• Check Googlebot rendering via the URL Inspection tool (Search Console) on 10-15 representative pages
• Implement SSR or pre-rendering on priority page types (products, articles, categories)
• Monitor real CrUX data (LCP, FID, CLS) rather than synthetic PSI scores
• Test internal transitions of the SPA (navigation between views) to detect slowdowns that PSI may not capture
• Audit server logs to ensure that Googlebot is effectively crawling strategic URLs
• Do not blindly apply PSI recommendations without testing the impact on real user experience