CSR vs SSR: ko uzņēmumiem ir svarīgi zināt

Renderēšanas stratēģija nav tikai tehnisks lēmums — tā tieši ietekmē SEO, veiktspēju, lietotāju pieredzi un pat jūsu servera rēķinus. Next.js 15+ piedāvā visus renderēšanas režīmus vienā ietvarā, ļaujot izvēlēties optimālo pieeju katrai lapai atsevišķi.

Renderēšanas režīmi padziļināti

CSR (Client-Side Rendering)

Saturs tiek renderēts pārlūkā pēc JavaScript ielādes:

• Kā tas strādā — serveris nosūta tukšu HTML ar `
  ` un JavaScript bundle. Pārlūks ielādē JS, izpilda to, un TIKAI TAD saturs parādās ekrānā
• TTFB ir zems — serveris atbild ātri, jo nesūta renderētu HTML. Bet FCP un LCP ir augsti — lietotājs redz tukšu lapu līdz JS ielādējas
• Bundle size problēma — visa aplikācijas loģika ir client-side JavaScript. Mazām aplikācijām tas ir OK, bet lielām — bundle var sasniegt 500KB–2MB
• Piemērots — dashboards, admin paneļi, iekšējie rīki, SPA ar autentifikāciju, kur SEO nav prioritāte
• Nav piemērots — publiskas lapas, mārketinga saturs, blogs, e-komercija

SSR (Server-Side Rendering)

Lapa tiek renderēta serverī katrā pieprasījumā:

• Kā tas strādā — katrs pieprasījums izpilda React komponentu kodu serverī, ģenerē HTML un nosūta pārlūkam. Pēc tam notiek hydration — JS pārņem interaktivitāti
• SEO draudzīgs — pilnībā renderēts HTML ar metadata, ko meklētājprogrammas nekavējoties indeksē
• Dinamisks saturs — katrs pieprasījums var ģenerēt jaunu HTML ar aktuāliem datiem (lietotāja sesija, personalizēts saturs, reāllaika cenas)
• Servera slodze — katrs pieprasījums patērē CPU un RAM. Augsta trafika = augsti servera rēķini
• TTFB augstāks — serverim jāizpilda kods pirms atbildes. Tipiski 100–500ms atkarībā no datu sarežģītības
• Piemērots — e-komercija ar personalizāciju, ziņu portāli, lapas ar reāllaika datiem, lietotāja profila lapas
• Next.js 15 — Server Components ir noklusējuma SSR ar streaming. `async function Page()` automātiski ir SSR

SSG (Static Site Generation)

Lapas veidotas būvēšanas (build) laikā, servētas kā statiski faili:

• Kā tas strādā — `next build` laikā Next.js izpilda katras lapas kodu un ģenerē HTML failus. Tie tiek servēti no CDN bez jebkādas servera izpildes
• Ātrākais variants — TTFB < 50ms no CDN edge. FCP un LCP tikpat ātri. Ideāls Core Web Vitals
• CDN caching — faili tiek kešoti globāli, servēti no tuvākā edge servera. Nav servera slodzes
• Ierobežojums — saturs ir statisks. Ja mainās dati, jāveic pilna pārbūvēšana (vai jāizmanto ISR)
• Build laiki — ar tūkstošiem lapu build var aizņemt 10–30 minūtes. Katrs pageviews nemainīgais saturs tiek ģenerēts vienreiz
• Piemērots — mārketinga lapas, dokumentācija, blogs, landing pages, portfolio
• Next.js 15 — `generateStaticParams()` definē kādas dinamiskās lapas ģenerēt build laikā

ISR (Incremental Static Regeneration)

Next.js specifiska funkcija — labākais no abām pasaulēm:

• Kā tas strādā — lapa sākotnēji ģenerēta kā statiski (SSG). Pēc definēta laika perioda (revalidate) nākamais pieprasījums izsauc lapas pārģenerēšanu fonā, kamēr lietotājs saņem kešoto versiju
• On-demand revalidation — `revalidatePath('/blog/my-post')` vai `revalidateTag('blog')` API maršrutā. CMS webhook izsauc revalidāciju, kad saturs tiek atjaunināts
• Labākais no abām pasaulēm — statiskā ielādes ātrums + dinamiskas satura atjaunināšanas iespējas
• Nav pilnas pārbūvēšanas — tikai konkrētā lapa tiek pārģenerēta, ne visa aplikācija
• Piemērots — lieli satura portāli, e-komercija ar periodiski mainīgām cenām, blogs ar biežiem atjauninājumiem

PPR (Partial Prerendering) — Next.js 15 jaunums

• Kā tas strādā — lapas statiskā daļa (shell) tiek pre-renderēta, bet dinamiskās daļas (personalizēts saturs) tiek straumētas (streamed) pēc pieprasījuma
• Suspense boundaries — React Suspense nosaka, kas ir statisks un kas dinamisks
• Rezultāts — tūlītējs TTFB no CDN (statiskais shell) + dinamisks saturs straumēts sekundes laikā

SEO un veiktspēja padziļināti

Core Web Vitals pa renderēšanas režīmiem

Meklētājprogrammu indeksēšana

• SSR/SSG/ISR — pilnībā renderēts HTML, ko Googlebot un citi roboti nekavējoties indeksē. Meta tagi, structured data, Open Graph — viss ir pieejams pirmajā pieprasījumā
• CSR — Googlebot spēj izpildīt JavaScript un indeksēt CSR saturu, BET: 1) tas notiek ar kavēšanos (dienas vai nedēļas), 2) citi meklētāji (Bing, DuckDuckGo) var neindeksēt, 3) social media crawlers (Facebook, Twitter, LinkedIn) NEIZPILDA JS — deleizēšanas priekšskatījumi nedarbosies
• Structured data — JSON-LD shēmas (Article, FAQ, Product) darbojas tikai ar SSR/SSG, jo tām jābūt HTML pirmajā pieprasījumā

Mērogojamības apsvērumi

SSG build laiku optimizācija

• Parallel page generation — Next.js 15 paralēli ģenerē lapas, izmantojot vairākus CPU kodolus
• Selective builds — ģenerējiet tikai kritiskās lapas build laikā, pārējās ar ISR pēc pieprasījuma
• Turbopack — Next.js jauns bundler, kas ir 10x ātrāks par Webpack build laikā

SSR mērogošana

• Streaming SSR — Next.js App Router automātiski straumē SSR atbildes ar React Suspense. Lietotājs redz saturu pakāpeniski, ne gaida pilnu lapu
• Edge Runtime — SSR funkcijas var izpildīt edge serverī (Vercel Edge, Cloudflare Workers) ar <50ms latency globāli
• Caching stratēģijas — pat SSR lapas var kešot ar CDN headers (Cache-Control, s-maxage). SSR + smart caching = SSG ātrums vairumā gadījumu

Pareizā pieeja katrai situācijai — detalizēts ceļvedis

Renderēšanas izvēle nav "viens izmērs visiem" — mūsdienīgas Next.js aplikācijas bieži izmanto dažādus režīmus dažādām lapām vienas aplikācijas ietvaros.