How do performance, SSR, and SEO interact in a modern web app?
All three reinforce each other. SSR ships real HTML so first paint is fast (LCP win) AND crawlers see content (SEO win). SSG goes further: pre-rendered + CDN-cached HTML, sub-100ms TTFB globally, perfect SEO. The Page Experience signal (Core Web Vitals) makes performance a direct SEO factor. Add metadata (title, description, OG, JSON-LD), canonical URLs, sitemap, mobile-first design. Treat SSR/SSG as the foundation — CSR-only for content kills both perf and SEO.
Performance, SSR, and SEO converge in the modern web. Each amplifies the others, and CSR-only architecture sacrifices all three for content pages.
How they interact
Performance → SEO. Google uses Core Web Vitals (LCP, INP, CLS) as a Page Experience ranking signal. Fast pages rank better. Slow pages rank worse (and have higher bounce, which is also a signal indirectly).
SSR/SSG → SEO. Server-rendered HTML is what crawlers index. Non-Google crawlers (Bing, Baidu, social previewers — LinkedIn, Slack, iMessage) don't run JavaScript. SSR makes content visible to all of them.
SSR/SSG → Performance. HTML arrives with content already rendered — LCP is bounded by network + paint, not JS bundle parse. CSR pushes LCP behind bundle download + execute, often adding 2–4 seconds.
So:
- CSR-only: bad LCP + bad SEO + broken social previews.
- SSR: good LCP + good SEO + per-request server cost.
- SSG: best LCP + best SEO + CDN-cacheable.
- ISR: SSG with bounded staleness for dynamic data.
What "good" looks like per page
| Page type | Rendering | Why |
|---|---|---|
| Marketing homepage | SSG | Pre-rendered, CDN-cached, sub-100ms TTFB, perfect SEO |
| Blog post / article | SSG | Same — content rarely changes per request |
| Product detail (e-commerce) | ISR | Pre-rendered + revalidate on price/inventory change |
| Category / search results | ISR or SSR | Filterable, frequently updated |
| Personalized homepage (logged in) | SSR | Per-user; SEO irrelevant; LCP still matters |
| App / dashboard (logged in) | CSR fine | SEO irrelevant; snappiness from cached API + UI |
SEO checklist that depends on SSR
These must be in the initial HTML response to work:
<title>and<meta name="description">per page.<meta property="og:*">for social previews.<link rel="canonical">.<script type="application/ld+json">structured data.- Semantic HTML headings hierarchy.
- Real anchor tags with
href(not JS-only navigation).
If any of these are JS-injected, crawlers without JS execution miss them.
Performance checklist that affects SEO
Core Web Vitals at p75:
- LCP < 2.5s — first big content render.
- INP < 200ms — interaction responsiveness.
- CLS < 0.1 — visual stability.
Google's Page Experience ranking factor uses real-user CrUX data for these.
Speed compounds with content: a well-SEO'd page that's slow gets dinged; a fast page with no metadata never gets found.
Concrete: Next.js example
// app/blog/[slug]/page.tsx
export const revalidate = 3600;
export async function generateMetadata({ params }) {
const post = await getPost(params.slug);
return {
title: `${post.title} — My Blog`,
description: post.excerpt,
openGraph: { title: post.title, images: [post.cover] },
alternates: { canonical: `https://example.com/blog/${post.slug}` },
};
}
export default async function Post({ params }) {
const post = await getPost(params.slug);
return (
<article>
<h1>{post.title}</h1>
<script type="application/ld+json" dangerouslySetInnerHTML={{ __html: JSON.stringify({
'@context': 'https://schema.org',
'@type': 'Article',
headline: post.title,
author: { '@type': 'Person', name: post.author },
datePublished: post.publishedAt,
})}} />
<div dangerouslySetInnerHTML={{ __html: post.content }} />
</article>
);
}This is SSG with ISR (1h revalidate), full metadata in the initial response, JSON-LD for rich results. Cached at the edge → ~100ms TTFB globally → fast LCP → good Page Experience → SEO wins.
Mobile-first
Google indexes mobile-first. If your mobile page is slow or has different content than desktop, mobile loses. Don't:
- Hide content on mobile with
display: none(Google may consider it hidden). - Serve a stripped-down mobile site at a different URL — use responsive design.
- Forget the mobile viewport meta tag.
Things that ruin all three
- CSR for content pages.
- Hashbang URLs (
#/foo) for routes — uncrawled. - Lazy-loading the LCP image.
- Blocking JS in
<head>that delays first paint. - Massive bundles that delay TTI.
- Layout shifts from late-loading images or fonts.
- Missing OG/canonical/JSON-LD.
Measurement
- Search Console — what Google actually indexes, crawl errors, Page Experience scores, mobile usability.
- CrUX (PageSpeed Insights field data) — real-user perf per URL.
- Lighthouse SEO + Performance audits per PR.
- Bing Webmaster Tools + LinkedIn Post Inspector + Twitter Card Validator for social previews.
Mental model
SSR/SSG/ISR + correct metadata + speed = content gets found, ranks well, loads fast, looks good when shared. CSR for content sacrifices all of that. Picking the right rendering mode per page is the single highest-leverage architecture decision for content-heavy products.
Follow-up questions
- •How does Page Experience ranking actually work?
- •When does ISR's stale-while-revalidate hurt SEO?
- •What's the role of JSON-LD structured data?
- •How do you handle metadata for SPA route transitions?
Common mistakes
- •CSR for marketing/content — bad SEO, broken previews, slow LCP.
- •JS-injected meta tags — crawlers without JS miss them.
- •Duplicate content (www vs non-www, trailing slash) without canonical.
- •Hidden mobile content — Google may not index it.
- •Lazy-loaded LCP image — tanks Page Experience.
- •Hashbang URLs — uncrawled.
Performance considerations
- •SSG + edge cache → 100ms TTFB globally → 1-2s LCP. Same page with CSR → 4-6s LCP. The delta is huge for both users and rankings. Page Experience is a real ranking signal — slow pages lose visibility.
Edge cases
- •International sites: hreflang for locale variants.
- •Pagination: rel=next/prev for paginated content.
- •AMP — largely deprecated; doesn't help anymore.
- •JS-rendering crawlers (Googlebot) have a budget; heavy JS pages may get partial indexing.
- •ISR stale content during regeneration — usually fine for SEO, but news/breaking stories may need shorter revalidate.
Real-world examples
- •Next.js + Vercel: marketing sites that hit 100/100 Lighthouse + sub-1s LCP.
- •Shopify Hydrogen: SSG + ISR for storefronts.
- •News sites (NYT, BBC): server-rendered + JSON-LD for rich results.
- •Internal tools (Linear, Figma): CSR is fine — SEO irrelevant.