Is client-side JavaScript really holding back your SEO performance?

Why does Google distinguish between server-side rendering and client-side rendering?

The nuance is crucial. Google perfectly indexes JavaScript, whether it’s rendered client-side or server-side. The Googlebot executes JS, waits for the DOM to stabilize, and then indexes the content. No crawl or understanding issues.

But indexing does not mean performing. Client-side JS forces the browser to download, parse, and execute code before displaying anything. On the server side, HTML arrives ready. The difference? Several hundred milliseconds on average connections. And those milliseconds weigh heavily in Core Web Vitals.

What makes client-side JavaScript “less predictable”?

Google does not elaborate, and this is intentional. Less predictable means more friction points: JS errors that break rendering, external dependencies that are slow to load, race conditions between scripts, React/Vue hydration blocking interactivity.

On the server side, these risks don’t exist. HTML arrives complete, stable, and immediately usable. The Googlebot doesn’t have to wait for three JS bundles to load in the correct order to understand your page. It’s this stability that Splitt values here.

Is this recommendation contradicted by Google’s previous statements?

No, it refines them. For years, Google has repeated: “we handle JS.” That’s true for indexing, but false for performance. Splitt doesn’t say “never use JS” — he says “use it only when necessary.”

The real target of this statement? Websites that throw React or Vue to display static text. Full SPA blogs. Landing pages that load 400 KB of JS for a form. It’s wasteful, and Google knows it.

• Google crawls and indexes client-side JavaScript without major technical difficulties
• The issue is not indexing, but the negative performance impact (LCP, CLS, INP)
• Server-side rendering (SSR, SSG, static HTML) remains faster, more stable, and more predictable for Google and users
• Client-side JS should be reserved for truly dynamic interactions (filters, interactive maps, dashboards)
• This position is consistent with Google’s policy on Core Web Vitals and UX

Does this recommendation truly reflect real-world observations?

Yes, without ambiguity. Performance audits consistently show that full client-side JS websites have disastrous PageSpeed scores compared to their SSR or static counterparts. LCP above 3 seconds, TBT skyrocketing, degraded INP. Core Web Vitals don't relent.

And contrary to what some developers believe, SSR is not just a trend. Next.js, Nuxt, Astro — all of these frameworks exist precisely because full client-side has become untenable. Sites migrating to SSR immediately gain 30-50% in loading times. It’s not marginal.

What nuances should be added to this statement?

Splitt does not provide any figures or thresholds. How many KB of JS is acceptable? What performance delta becomes problematic? [Check] on each project. An e-commerce site with dynamic filters will necessarily have more JS than a blog, and that’s justified.

Then he says “less predictable,” but less predictable than what exactly? Less than static HTML, obviously. But what about SSR with partial hydration? Streaming SSR? Islands Architecture? Google doesn’t make this distinction, yet it matters greatly in practice.

In which cases does this rule not apply?

Complex web applications have no choice. A real-time dashboard, a SaaS tool, a collaborative platform — all of these require heavy client-side JS. Google knows this, and these sites are not penalized as long as performance remains acceptable.

The real issue lies with content sites using JS without a valid reason. A WordPress showcase site that loads React just to animate a menu? A Gatsby blog with 300 KB of bundles to display markdown articles? That is unacceptable.

What should you concretely do on an existing site?

First, audit your actual usage of JavaScript. Open DevTools, Network panel, filter by JS. How many KB? How many requests? What is the blocking time before First Contentful Paint? If you exceed 150-200 KB of JS for a content site, you have a problem.

Next, identify what is critical and what is not. An image carousel can be lazy-loaded. A dropdown menu can be CSS-only. Animations can use CSS transitions instead of GSAP. Every KB saved improves your metrics.

What mistakes to avoid when migrating to less JS?

Don’t break user experience under the pretext of optimization. Removing JS without a functional alternative is worse than keeping it. If your users depend on dynamic filters, keep them — but optimize their implementation (code splitting, lazy loading, debouncing).

Another classic pitfall: switching to SSR without understanding hydration. Poor SSR can be as slow as full client-side if hydration blocks everything. Test under real conditions, not just locally on fiber optic.

How can I check if my site complies with Google's recommendations?

The Core Web Vitals are your only reliable indicator. PageSpeed Insights, Search Console (Web Signals report), and Chrome User Experience Report provide you with real-world metrics. If your LCP is under 2.5 seconds and your INP is under 200 ms, you are in good standing, regardless of your JS stack.

Use Lighthouse in throttling mode to simulate average connections. A score of 90+ on desktop means nothing if you drop to 40 on mobile 3G. Test on real devices, not just in the Chrome emulator.

• Audit your current JavaScript: identify unnecessary bundles, outdated dependencies, redundant polyfills
• Prefer SSR or static generation for all non-dynamic content (product pages, articles, landing pages)
• Implement code splitting and lazy loading to defer the loading of non-critical JS
• Monitor your Core Web Vitals in Search Console and fix pages that exceed thresholds
• Test under real conditions (mobile, network throttling) before deploying major changes
• Document technical choices: each JS library must have a clear justification