Praxium Labs ships this for Nepali clients — here is what works. The "SSR vs SSG" debate is largely settled in 2026 — the winning answer is usually "both, depending on the page". The interesting choice is matching the rendering strategy to the content lifecycle.
The four rendering strategies
- SSG (Static Site Generation): HTML pre-built at build time. Fastest serving, best caching. Right for content that does not change per-user
- ISR (Incremental Static Regeneration): hybrid — pre-built but re-generated on a schedule or on-demand. Right for content that changes occasionally but you want SSG speed
- SSR (Server-Side Rendering): HTML generated per request. Right for personalised content (authenticated dashboards), real-time data, user-specific pages
- CSR (Client-Side Rendering): HTML built in the browser via JavaScript. Right for highly interactive apps. Bad for SEO-relevant pages
Page-by-page decision framework
For a typical Nepali e-commerce or marketing site:
- Homepage: SSG (rebuilds on content change) or ISR (revalidate hourly)
- Blog posts: SSG (immutable until you edit)
- Product pages: ISR (revalidate every 5-60 min as stock / price changes)
- Category / search pages: SSR (per-query) or ISR with on-demand revalidation
- Cart / checkout: SSR + CSR hybrid (page shell SSR, interactive parts CSR)
- Account dashboard: SSR (per-user data, never cache)
- Order tracking: SSR (real-time)
SEO implications
For SEO-relevant pages (anything you want to rank in Google for non-personalised queries): SSG and ISR are both safe — search engines see fully-rendered HTML on first crawl. SSR is also fine but adds latency cost. Pure CSR is risky — Google's JavaScript rendering is improved but not instant; some content gets indexed slowly or imperfectly.
Performance and cost
- SSG: cheapest to host (static files behind a CDN); fastest TTFB
- ISR: still mostly static; small overhead for revalidation
- SSR: requires server resources per request. Hosting cost scales with traffic. TTFB depends on data-fetching latency
- CSR: server cost is low but client-side JS can be heavy. Larger JS bundle means slower mobile experience
Nepali-specific considerations
- Slow user networks: SSG / ISR win — smaller payload, fewer round-trips
- Limited DC presence near Nepal: CDN edges (Cloudflare in Singapore) cache static pages aggressively; SSR pages must hit origin every time
- Devanagari content does not change rendering model: same trade-offs apply to Nepali pages
Praxium Labs default
For client sites in 2026 we default to: Astro for content-heavy marketing (SSG-first), Next.js App Router for product apps (mix of RSC + ISR + SSR + Client Components per route). The mental model: "what is the data lifecycle?" → pick the matching rendering strategy. For related context, see our Next.js vs Astro vs SvelteKit for Nepali Startups in 2026 post.
Frequently asked questions
Is SSR worse for SEO than SSG?
No, both serve fully-rendered HTML to crawlers. The practical difference is TTFB and consistency — SSG is faster on average; SSR can be slower under load if origin has issues. Google does not directly penalise either approach.
How long does ISR take to update?
On-demand revalidation: a few hundred milliseconds. Scheduled revalidation: at the next interval (60s minimum on Vercel; configurable on self-hosted). Plan revalidation cadence around how stale you can tolerate the page being.
Can I mix strategies in one site?
Yes — modern frameworks (Next.js App Router, Astro, SvelteKit) support per-route rendering choices. Mixing is the norm in 2026; pure all-SSG or all-SSR sites are rare.
What if my site is highly dynamic but I want SSG benefits?
ISR is exactly that. Pre-build the page, revalidate when stale. Most "dynamic" Nepali sites (e-commerce, news) actually serve the same content to most users — perfect for ISR.
How do I tell if Google is rendering my JavaScript?
Search Console URL Inspection tool: it shows you the rendered HTML Googlebot saw. Fetch as Google to verify. If your content is missing from the rendered version, you have an SEO problem regardless of which framework you use.
Who can build this in Nepal?
Praxium Labs — Nepal's AI and automation consultancy, based in Lalitpur — designs and builds the systems described in this guide for Nepali businesses and for international teams hiring from Nepal. Start a project or see all services.