SSR، CSR، SSG و ISR؛ یک انتخاب اشتباه چطور روی تجربه کاربر تأثیر می‌گذارد؟

وقتی یک کاربر وارد یک وب‌سایت می‌شود، معمولاً به این فکر نمی‌کند که صفحه‌ای که می‌بیند چگونه ساخته شده است. برای او مهم است که سایت سریع باز شود، محتوای موردنظرش را بدون انتظار پیدا کند و هنگام تعامل با صفحه، احساس کند همه چیز روان و طبیعی کار می‌کند.

اما پشت همین تجربه ساده، تصمیم‌های فنی مهمی وجود دارد.

یکی از این تصمیم‌ها، انتخاب روش مناسب برای رندر شدن صفحات است؛ اینکه محتوای صفحه در سرور ساخته شود، در مرورگر کاربر شکل بگیرد، از قبل تولید شده باشد یا در بازه‌های مشخص به‌روزرسانی شود.

در توسعه مدرن وب، چهار مفهوم SSR، CSR، SSG و ISR نقش مهمی در این تصمیم دارند.

انتخاب درست میان آن‌ها می‌تواند به بهبود:

• Performance

• SEO

• تجربه کاربری

• Scalability

• هزینه پردازش سرور

کمک کند.

در مقابل، انتخاب اشتباه ممکن است باعث ایجاد صفحات کند، اطلاعات قدیمی، Loadingهای طولانی یا مصرف غیرضروری منابع شود.

اما سؤال اصلی این است:

SSR، CSR، SSG و ISR چه تفاوتی دارند و چه زمانی باید از هرکدام استفاده کرد؟

Rendering چیست؟

مرورگر برای نمایش یک صفحه وب به HTML، CSS و JavaScript نیاز دارد.

اما اینکه HTML نهایی چه زمانی، کجا و چند بار تولید شود، به Rendering Strategy پروژه بستگی دارد.

به‌صورت ساده:

• CSR: بخش زیادی از صفحه در مرورگر ساخته می‌شود.

• SSR: صفحه هنگام درخواست روی سرور تولید می‌شود.

• SSG: صفحه هنگام Build از قبل تولید می‌شود.

• ISR: صفحه Static است، اما می‌تواند بعد از مدتی دوباره تولید و به‌روزرسانی شود.

همین تفاوت ظاهراً ساده، می‌تواند تأثیر قابل‌توجهی روی تجربه کاربر داشته باشد.

CSR؛ وقتی مرورگر مسئول ساخت صفحه است

در Client-Side Rendering، بخش زیادی از رابط کاربری در مرورگر کاربر ساخته می‌شود.

مسیر ساده یک صفحه CSR می‌تواند چنین باشد:

User
  ↓
Browser
  ↓
Download JavaScript
  ↓
Run Application
  ↓
Fetch Data
  ↓
Render UI

این روش برای Applicationهای تعاملی بسیار مناسب است.

برای مثال یک Dashboard را در نظر بگیرید که کاربر بعد از ورود، اطلاعات شخصی خودش را مشاهده می‌کند.

در چنین صفحه‌ای معمولاً:

• SEO اهمیت کمتری دارد.

• داده‌ها شخصی هستند.

• تعامل کاربر زیاد است.

• UI دائماً تغییر می‌کند.

بنابراین CSR می‌تواند انتخاب مناسبی باشد.

چالش CSR

اگر صفحه بیش از حد به JavaScript و درخواست‌های سمت کاربر وابسته باشد، ممکن است کاربر قبل از مشاهده محتوای اصلی با Loading یا صفحه ناقص مواجه شود.

در نتیجه حتی اگر عملکرد نهایی برنامه خوب باشد، Perceived Performance می‌تواند ضعیف باشد.

SSR؛ وقتی سرور صفحه را برای کاربر آماده می‌کند

در Server-Side Rendering، صفحه هنگام درخواست کاربر روی سرور تولید می‌شود.

User
  ↓
Server
  ↓
Fetch / Process Data
  ↓
Generate HTML
  ↓
Browser
  ↓
Display Content

این روش برای صفحاتی مناسب است که محتوای آن‌ها Dynamic است و باید هنگام درخواست کاربر به‌روز باشد.

برای مثال:

• صفحات شخصی‌سازی‌شده

• برخی صفحات محصول

• صفحات دارای داده Dynamic

• محتواهایی که به Request وابسته هستند

آیا SSR همیشه سریع‌تر است؟

خیر.

SSR به این معنی نیست که صفحه همیشه سریع‌تر خواهد بود.

اگر سرور برای تولید صفحه مجبور باشد:

1. چند API را صدا بزند،

2. Queryهای سنگین اجرا کند،

3. داده‌های زیادی پردازش کند،

4. HTML را تولید کند،

ممکن است زمان پاسخ افزایش پیدا کند.

بنابراین:

SSR ≠ Always Faster

SSG؛ وقتی صفحه قبل از ورود کاربر آماده شده است

در Static Site Generation، صفحه هنگام Build پروژه تولید می‌شود.

Build
 ↓
Generate HTML
 ↓
Deploy
 ↓
User Request
 ↓
Ready Page

در نتیجه برای هر Request معمولاً نیازی نیست صفحه از ابتدا روی سرور تولید شود.

SSG برای محتوای نسبتاً ثابت بسیار مناسب است.

برای مثال:

• Blog

• About

• Services

• Landing Pages

• Documentation

• صفحات معرفی

اما یک سؤال مهم وجود دارد:

اگر محتوای صفحه تغییر کند چه اتفاقی می‌افتد؟

اینجاست که ISR وارد می‌شود.

ISR؛ ترکیب قدرت Static و Dynamic

Incremental Static Regeneration یا ISR یکی از قابلیت‌های مهم معماری مدرن Next.js است.

ایده اصلی ISR ساده است:

صفحه را مثل یک صفحه Static با سرعت بالا ارائه کن، اما اجازه بده بعد از یک بازه مشخص، محتوای آن دوباره تولید شود.

به‌جای اینکه برای هر Request صفحه را از ابتدا بسازیم، می‌توانیم یک نسخه Static داشته باشیم و آن را در زمان مناسب به‌روزرسانی کنیم.

یک مدل ساده:

Build
  ↓
Generate Page
  ↓
Cache
  ↓
User Request
  ↓
Serve Cached Page
  ↓
Revalidate
  ↓
Generate Updated Page

به این ترتیب لازم نیست برای هر کاربر، تمام پردازش‌ها دوباره انجام شوند.

ISR چه مشکلی را حل می‌کند؟

فرض کنید یک فروشگاه اینترنتی دارید.

صفحه محصول شامل:

• نام محصول

• تصویر

• توضیحات

• قیمت

• موجودی

است.

این اطلاعات کاملاً Static نیستند؛ چون ممکن است تغییر کنند.

از طرف دیگر، شاید لازم نباشد با هر Request صفحه محصول از ابتدا روی سرور تولید شود.

در اینجا ISR می‌تواند انتخاب مناسبی باشد.

برای مثال می‌توان تصمیم گرفت صفحه در یک بازه مشخص دوباره اعتبارسنجی شود.

در نتیجه:

Static Performance
        +
Periodic Updates
        =
       ISR

ISR در دنیای واقعی

تصور کنید یک وب‌سایت خبری دارید.

یک مقاله ممکن است:

• در ساعت 10:00 منتشر شود.

• در ساعت 10:20 ویرایش شود.

• در ساعت 11:00 اطلاعات جدیدی دریافت کند.

اگر برای هر بازدید از مقاله SSR انجام شود، سرور باید دائماً صفحه را تولید کند.

اگر از SSG ساده استفاده شود، ممکن است محتوای صفحه بعد از Build دیگر به‌روز نشود.

ISR بین این دو قرار می‌گیرد.

صفحه می‌تواند سریع و Static ارائه شود و در عین حال در زمان مناسب مجدداً تولید شود.

ISR چه زمانی انتخاب خوبی است؟

ISR معمولاً برای صفحاتی مناسب است که:

• محتوای آن‌ها زیاد تغییر نمی‌کند.

• اما کاملاً Static هم نیستند.

• تعداد بازدید بالایی دارند.

• Performance اهمیت زیادی دارد.

• نمی‌خواهیم برای هر Request سرور صفحه را از ابتدا تولید کند.

مثلاً:

فروشگاه اینترنتی

Product Pages → ISR

وب‌سایت خبری

Articles → ISR

سایت شرکتی

Services → SSG / ISR

وبلاگ

Blog Posts → SSG / ISR

البته انتخاب نهایی همیشه به نیاز پروژه و نحوه تغییر داده‌ها بستگی دارد.

تفاوت SSG و ISR چیست؟

این دو روش بسیار شبیه‌اند، اما یک تفاوت مهم دارند.

SSG

صفحه در زمان Build ساخته می‌شود.

Build → Page

اگر محتوای صفحه تغییر کند، معمولاً باید فرآیند تولید مجدد صفحه انجام شود.

ISR

صفحه Static است، اما می‌تواند در زمان مشخصی دوباره تولید شود.

Build
 ↓
Static Page
 ↓
Revalidate
 ↓
Updated Page

بنابراین می‌توان گفت:

SSG = Static

ISR = Static + Revalidation

تفاوت چهار روش در یک نگاه

ویژگیCSRSSRSSGISRمحل اصلی RenderingBrowserServerBuildBuild + Revalidationتولید صفحهClientهر RequestBuild TimeStatic + Updateمناسب داده Dynamic⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐مناسب محتوای ثابت⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐SEOنیازمند توجه بیشتربسیار مناسببسیار مناسببسیار مناسبPerformance اولیهوابسته به JSوابسته به Serverمعمولاً بسیار خوبمعمولاً بسیار خوبفشار روی Serverبیشتر در Clientبیشترکمترکمتر از SSRمناسب Dashboard⭐⭐⭐⭐⭐⭐⭐مناسب Blog⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐مناسب Product⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐مناسب Landing⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

این جدول یک قانون قطعی نیست؛ بلکه یک راهنمای اولیه برای انتخاب معماری است.

یک مثال واقعی؛ فروشگاه اینترنتی

فرض کنید یک فروشگاه آنلاین داریم.

صفحات مختلف این فروشگاه می‌توانند Rendering متفاوتی داشته باشند:

                    E-Commerce
                        │
        ┌───────────────┼────────────────┐
        ↓               ↓                ↓
      Home           Product          Dashboard
        │               │                │
       SSG             ISR               CSR
                        │
                        ↓
                  Checkout
                        │
                       SSR

چرا؟

Home

محتوا نسبتاً ثابت است و Performance اهمیت زیادی دارد.

SSG / ISR

Product

اطلاعات محصول ممکن است تغییر کند، اما نمی‌خواهیم برای هر بازدید تمام صفحه دوباره ساخته شود.

ISR

Dashboard

داده کاملاً شخصی و Interactive است.

CSR

Checkout

اطلاعات به کاربر و وضعیت لحظه‌ای سفارش وابسته است.

SSR / CSR

این یعنی یک پروژه حرفه‌ای لزوماً یک Rendering Strategy واحد ندارد.

انتخاب اشتباه چه تأثیری روی کاربر دارد؟

تصور کنید صفحه‌ای داریم که برای کاربر عمومی است و محتوای آن نسبتاً ثابت است.

اما آن را به شکل CSR سنگین پیاده‌سازی کرده‌ایم.

کاربر وارد صفحه می‌شود:

Click
 ↓
Download JS
 ↓
Execute JS
 ↓
API Request
 ↓
Process Data
 ↓
Render

کاربر ممکن است چند لحظه منتظر بماند.

حالا همان صفحه را با یک معماری مناسب Static یا ISR تصور کنید:

Click
 ↓
Cached HTML
 ↓
Display Content

تفاوتی که در معماری اتفاق افتاده، مستقیماً در تجربه کاربر دیده می‌شود.

انتخاب اشتباه فقط سرعت را خراب نمی‌کند

انتخاب Rendering Strategy می‌تواند روی چند بخش مختلف تأثیر بگذارد:

Performance

زمان نمایش محتوای اصلی و میزان پردازش موردنیاز.

SEO

نحوه دسترسی موتورهای جستجو به محتوای اولیه صفحه.

Scalability

میزان فشاری که با افزایش کاربران روی Server ایجاد می‌شود.

هزینه زیرساخت

پردازش مداوم صفحات Dynamic می‌تواند هزینه بیشتری نسبت به ارائه صفحات Cache شده داشته باشد.

تجربه کاربر

Loading، تعاملات و سرعت درک‌شده.

بنابراین Rendering Strategy فقط یک تصمیم تکنیکی نیست.

آیا ISR جایگزین SSR است؟

خیر.

ISR و SSR برای مسئله‌های متفاوتی مناسب هستند.

اگر محتوا باید برای هر Request کاملاً تازه و وابسته به همان درخواست باشد، SSR می‌تواند گزینه مناسب‌تری باشد.

اما اگر محتوا می‌تواند برای یک بازه مشخص Cache شود و سپس به‌روزرسانی شود، ISR می‌تواند Performance و Scalability بهتری ارائه دهد.

به زبان ساده:

Need Fresh Data Every Request?
          ↓
         SSR

Can Data Be Cached Temporarily?
          ↓
         ISR

Rendering Strategy را قبل از شناخت مسئله انتخاب نکنید

یکی از اشتباهات رایج در پروژه‌های Frontend این است که ابتدا تکنولوژی انتخاب شود و بعد مسئله بررسی شود.

مثلاً:

«همه صفحات باید SSR باشند.»

یا:

«چون Next.js داریم، همه چیز باید Static باشد.»

هیچ‌کدام رویکرد مناسبی نیستند.

فرآیند حرفه‌ای‌تر این است:

Business Requirements
        ↓
User Experience
        ↓
Data Characteristics
        ↓
SEO Requirements
        ↓
Performance Requirements
        ↓
Rendering Strategy
        ↓
Technology

یعنی ابتدا باید بدانیم صفحه چه مسئله‌ای را حل می‌کند.

Performance فقط به Rendering وابسته نیست

حتی اگر بهترین Rendering Strategy را انتخاب کنیم، هنوز عوامل زیادی روی سرعت سایت تأثیر دارند.

مواردی مانند:

• حجم JavaScript

• بهینه‌سازی تصاویر

• Font Loading

• API Performance

• Database Queries

• Caching

• CDN

• Code Splitting

• Lazy Loading

• Component Architecture

• Network Conditions

همگی در Performance نهایی نقش دارند.

بنابراین یک سایت ISR یا SSG لزوماً به‌صورت خودکار سریع نیست.

Rendering Strategy فقط یکی از قطعات پازل Performance است.

در نهایت کدام را انتخاب کنیم؟

هیچ پاسخ واحدی برای تمام پروژه‌ها وجود ندارد.

اما می‌توان یک راهنمای ساده داشت:

CSR

برای بخش‌های:

• Interactive

• User-specific

• Dashboard

• Admin Panel

SSR

برای بخش‌هایی که:

• Dynamic هستند.

• اطلاعات باید هنگام Request تازه باشند.

• به Context درخواست وابسته‌اند.

SSG

برای بخش‌هایی که:

• تقریباً ثابت هستند.

• تغییرات کمی دارند.

• Performance و SEO اهمیت زیادی دارند.

ISR

برای بخش‌هایی که:

• Static هستند اما گاهی تغییر می‌کنند.

• بازدید بالایی دارند.

• نیاز به Cache دارند.

• نمی‌خواهیم برای هر Request دوباره Render شوند.

جمع‌بندی

SSR، CSR، SSG و ISR چهار ابزار برای حل یک مسئله مشترک هستند:

چطور محتوا را در زمان مناسب و به شکل مناسب به کاربر برسانیم؟

CSR قدرت زیادی برای ساخت Applicationهای تعاملی دارد.

SSR برای داده‌های Dynamic و وابسته به Request مناسب است.

SSG برای محتوای ثابت می‌تواند Performance بسیار خوبی ایجاد کند.

و ISR زمانی ارزشمند می‌شود که بخواهیم مزایای Static Rendering را با امکان به‌روزرسانی محتوا ترکیب کنیم.

اما مهم‌تر از انتخاب هرکدام، شناخت درست مسئله است.

یک وب‌سایت حرفه‌ای الزاماً سایتی نیست که از پیچیده‌ترین تکنولوژی‌ها استفاده کند.

یک وب‌سایت حرفه‌ای سایتی است که برای هر صفحه و هر نوع داده، Rendering Strategy متناسب با نیاز واقعی آن انتخاب شده باشد.

در نهایت، کاربر اهمیتی نمی‌دهد که صفحه با SSR ساخته شده، CSR یا ISR.

او فقط می‌خواهد سایت:

سریع باز شود، محتوای درست را نشان دهد، روان کار کند و در لحظه‌ای که به آن نیاز دارد آماده باشد.

و این دقیقاً جایی است که تصمیم‌های معماری Frontend از یک موضوع صرفاً فنی، به بخشی از تجربه واقعی محصول تبدیل می‌شوند.