SSG چطور سرعت سایت محتوایی را چند برابر می‌کند؟

در معماری وب مدرن، SSG (Static Site Generation) لایه‌ای است که HTML را در زمان Build تولید می‌کند و از CDN توزیع می‌کند و پایه سریع‌ترین تجربه ممکن محسوب می‌شود. بدون درک محدودیت‌های SSG، بدون استراتژی بازسازی و بدون ترکیب با ISR، سایت محتوایی به یک سیستم راکد تبدیل می‌شود که محتوای جدیدش تا Build بعدی منتشر نمی‌شود. تفاوت SSG و SSR و ISR، انتخاب زمان Build و استراتژی بازسازی، تصمیم‌های معماری را به تصمیم‌های تجربه کاربری گره می‌زند. Build، توزیع، بازسازی و پایش، چهار لایه ضروری در SSG حرفه‌ای هستند. در این راهنما از ساختار پایه تا استقرار تولیدی SSG را با نگاه مهندسی و کد عملی پوشش می‌دهیم.

در پروژه‌های واقعی، سایت‌های محتوایی با SSG سریع‌ترین تجربه را دارند. اما چالش اصلی در سایت‌های بزرگ با هزاران صفحه، زمان Build است. این راهنما از همان نقطه‌ای شروع می‌کند که تجربه می‌گوید بیشترین ارزش را دارد.

SSG چیست و چه تفاوتی با SSR و ISR دارد؟

SSG یک مدل رندر است که در آن HTML در زمان Build تولید و به CDN منتقل می‌شود.

راهنمای Incremental Static Regeneration و به‌روزرسانی و SSR چرا کلید سئوی اپلیکیشن‌های مدرن است نقطه شروع مناسبی هستند.

چه زمانی SSG انتخاب درستی است

- سایت‌های محتوایی با محتوای پایدار
- وبلاگ و مستندات
- سایت‌های شرکتی با محتوای ثابت
- صفحات فرود و Landing
- سایت‌هایی که محتوا را به‌ندرت تغییر می‌دهند

مزایای SSG برای سایت محتوایی

SSG در سایت‌های محتوایی، بزرگ‌ترین مزایا را ارائه می‌دهد.

چهار مزیت اصلی

1. سرعت بی‌نظیر: TTFB زیر 100ms.
2. هزینه پایین: نیازی به سرور همیشه روشن.
3. امنیت بالا: نیازی به سرور داینامیک.
4. مقیاس‌پذیری: CDN محدودیتی ندارد.

مقایسه عملکرد

راهنمای Headless WordPress چیست و چرا آینده سایت‌های حرفه‌ای است و Core Web Vitals 2026 نقطه شروع مناسبی هستند.

محدودیت‌های SSG

SSG محدودیت‌های مهمی دارد که باید در استراتژی لحاظ شوند.

سه محدودیت اصلی

1. نبود داده زنده: محتوا فقط در Build تولید می‌شود.
2. زمان Build: در سایت‌های بزرگ، Build طولانی می‌شود.
3. محتوای شخصی‌سازی‌شده: امکان‌پذیر نیست.

Build Time در سایت‌های بزرگ

10 صفحه: < 10 ثانیه
100 صفحه: 30 ثانیه
1,000 صفحه: 5 دقیقه
10,000 صفحه: 50 دقیقه
100,000 صفحه: 8+ ساعت

راهکار محدودیت Build Time

1. Incremental Static Generation
2. Parallel Build
3. Pagination
4. Hybrid SSG + ISR + SSR
5. Deferred Build

راهکار نبود داده زنده

1. ISR برای به‌روزرسانی دوره‌ای
2. Client-Side Fetching برای داده پویا
3. Hybrid: SSG + SSR در بخش‌های پویا

چرخه اجرای SSG در Next.js

در Next.js، SSG در زمان Build اجرا می‌شود.

SSG در App Router

// app/blog/[slug]/page.tsx
async function getPost( slug: string ) {
  const res = await fetch(
    `${process.env.WP_API}/wp-json/wp/v2/posts?slug=${slug}`,
    { cache: "force-cache" }
  );
  return res.json();
}

export async function generateStaticParams() {
  const posts = await fetch( `${process.env.WP_API}/wp-json/wp/v2/posts?per_page=100` ).then( r => r.json() );
  return posts.map( ( post ) => ( { slug: post.slug } ) );
}

export default async function Page( { params } ) {
  const post = await getPost( params.slug );
  return <article>{post.title}</article>;
}

SSG در Pages Router

export async function getStaticProps( { params } ) {
  const post = await getPost( params.slug );
  return {
    props: { post },
    revalidate: false,  // SSG بدون بازسازی
  };
}

export async function getStaticPaths() {
  const posts = await getPosts();
  return {
    paths: posts.map( ( p ) => ( { params: { slug: p.slug } } ) ),
    fallback: "blocking",
  };
}

Build Output

Route (app)                              Size
○ /                                     1.2 kB
○ /blog                                 2.1 kB
● /blog/[slug]                         1.8 kB
○ /about                                0.9 kB

○ (Static)  prerendered as static content
● (SSG)     prerendered as static HTML

استراتژی Build برای سایت‌های بزرگ

در سایت‌های بزرگ، Build به گلوگاه تبدیل می‌شود.

Parallel Build

// next.config.js
module.exports = {
  experimental: {
    workerThreads: true,
    cpus: 4,
  },
};

Incremental Static Generation

// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  // فقط 100 پست اول را در Build بساز
  const posts = await fetch( `${process.env.WP_API}/posts?per_page=100` ).then( r => r.json() );
  return posts.map( ( post ) => ( { slug: post.slug } ) );
}

export const dynamicParams = true;  // بقیه در Runtime

Hybrid Build Strategy

- 100 صفحه پرترافیک: SSG
- 10,000 صفحه کم‌ترافیک: ISR
- 100 صفحه پویا: SSR
- صفحات کاربری: CSR

Build Cache

# در Vercel
- Build Cache خودکار
- ذخیره Output در Cache
- Build تدریجی

# در CI/CD
- ذخیره node_modules
- ذخیره .next/cache
- استفاده از Turbo

توزیع با CDN و Edge

SSG از CDN برای توزیع جهانی استفاده می‌کند.

پلتفرم‌های میزبانی SSG

Cache-Control برای SSG

Cache-Control: public, max-age=0, must-revalidate
X-Vercel-Cache: HIT

// یا برای فایل‌های Hash دار
Cache-Control: public, max-age=31536000, immutable

Edge Functions با SSG

// middleware.ts
import { NextResponse } from "next/server";

export function middleware( request ) {
  const country = request.geo?.country || "US";
  const response = NextResponse.next();
  response.headers.set( "x-country", country );
  return response;
}

export const config = { matcher: "/((?!api).*)" };

بازسازی تدریجی و On-Demand

بازسازی، محدودیت اصلی SSG را حل می‌کند.

Time-Based Revalidation

// app/blog/[slug]/page.tsx
export const revalidate = 3600;  // 1 ساعت

On-Demand Revalidation

// app/api/revalidate/route.ts
import { revalidatePath, revalidateTag } from "next/cache";

export async function POST( request ) {
  const secret = request.nextUrl.searchParams.get( "secret" );
  if ( secret !== process.env.REVALIDATE_SECRET ) {
    return Response.json( { error: "Invalid secret" }, { status: 401 } );
  }
  const body = await request.json();
  if ( body.tag ) {
    revalidateTag( body.tag );
  }
  if ( body.path ) {
    revalidatePath( body.path );
  }
  return Response.json( { revalidated: true } );
}

Webhook از WordPress

<?php
add_action( "save_post_post", function( $post_id ) {
    if ( wp_is_post_revision( $post_id ) ) return;
    $post = get_post( $post_id );
    wp_remote_post( get_option( "wpk_revalidate_endpoint" ) . "?secret=" . get_option( "wpk_revalidate_secret" ), array(
        "headers" => array( "Content-Type" => "application/json" ),
        "body"    => wp_json_encode( array(
            "tag"  => "post-{$post->post_name}",
            "path" => "/blog/{$post->post_name}/",
        ) ),
        "timeout" => 10,
    ) );
}, 10, 1 );

SSG با WordPress Headless

WordPress به‌عنوان Headless CMS، با SSG ترکیب قدرتمندی می‌سازد.

الگوی Fetch با Cache

async function getPost( slug: string ) {
  const res = await fetch(
    `${process.env.WP_API}/wp-json/wp/v2/posts?slug=${slug}`,
    {
      next: {
        revalidate: 3600,
        tags: [ `post-${slug}` ],
      },
    }
  );
  return res.json();
}

الگوی generateStaticParams

export async function generateStaticParams() {
  const res = await fetch( `${process.env.WP_API}/wp-json/wp/v2/posts?per_page=100` );
  const posts = await res.json();
  return posts.map( ( post ) => ( { slug: post.slug } ) );
}

معماری Hybrid

صفحه اصلی: SSG + ISR
صفحه بلاگ: SSG + ISR
صفحه پست: SSG + ISR + On-Demand
صفحه محصول: ISR
صفحه سبد: SSR
صفحه حساب کاربری: SSR

راهنمای Headless WordPress با Next.js App Router و REST API یا GraphQL در وردپرس نقطه شروع مناسبی هستند.

عملکرد و Core Web Vitals

SSG بهترین عملکرد را در Core Web Vitals ارائه می‌دهد.

مزایای عملکردی

LCP: < 1.5s (بهترین در دسته)
INP: بستگی به JS کلاینت
CLS: بستگی به CSS
TTFB: 20-50ms در CDN

چالش‌های عملکردی SSG

- Hydration باعث تأخیر INP می‌شود
- JS Bundle بزرگ بر LCP اثر دارد
- فونت‌های بارگذاری‌نشده باعث CLS می‌شوند

بهینه‌سازی SSG

- Critical CSS inline
- Font Preload
- Image Preload
- Partial Hydration
- Islands Architecture
- Server Components

تست و پایش

تست SSG در سه سطح انجام می‌شود: سطح Build، سطح Cache و سطح عملکرد.

تست Build

npm run build
# بررسی حجم و زمان Build

# بررسی Output
ls -la .next/server/app/

# بررسی prerender manifest
cat .next/prerender-manifest.json

تست Cache

curl -I https://example.com/blog/test-post/
# x-vercel-cache: HIT
# cache-control: public, max-age=0, must-revalidate

تست Revalidation

curl -X POST "https://example.com/api/revalidate?secret=XXX" 
  -H "Content-Type: application/json" 
  -d '{"tag":"post-test-post"}'

# پس از revalidate، درخواست دوم باید محتوای جدید را نشان دهد

اشتباهات رایج در تست

اشتباه اول، نبود تست Build Time. اشتباه دوم، نبود تست Cache. اشتباه سوم، نبود تست Revalidation. اشتباه چهارم، نبود تست با محتوای جدید. اشتباه پنجم، نبود پایش پس از Deploy.

پرسش‌های پرتکرار درباره SSG

آیا SSG برای فروشگاه مناسب است؟

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

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

SSG فقط در Build تولید می‌شود، ISR در بازه‌های مشخص بازسازی می‌شود.

چگونه زمان Build را کاهش دهم؟

با Parallel Build، Incremental Generation و تقسیم Build.

آیا SSG بر سئو اثر دارد؟

بله، به‌طور غیرمستقیم از طریق Core Web Vitals. راهنمای Core Web Vitals و سئو را ببینید.

آیا SSG با WordPress Headless کار می‌کند؟

بله، ترکیب بسیار مؤثر است. راهنمای Headless WordPress با Next.js را ببینید.

چگونه محتوای زنده را در SSG نشان دهم؟

با ISR، On-Demand Revalidation یا Client-Side Fetching.

آیا SSG برای سایت‌های بزرگ مقرون‌به‌صرفه است؟

بله، هزینه CDN بسیار کمتر از سرور داینامیک است.

نتیجه و مسیر ادامه

SSG سریع‌ترین تجربه را برای سایت‌های محتوایی فراهم می‌کند. کلید موفقیت، استراتژی Build، توزیع CDN، بازسازی تدریجی و ترکیب هوشمند با ISR و SSR است. اگر این لایه‌ها با دقت طراحی شوند، سرعت سایت چند برابر می‌شود.

پیشنهاد می‌کنم مسیر یادگیری را با SSR چرا کلید سئوی اپلیکیشن‌های مدرن است ادامه دهید و سپس Incremental Static Regeneration و به‌روزرسانی را به‌عنوان مکمل مطالعه کنید. همچنین مفهوم Static site generator را در ویکی‌پدیا مرور کنید.

اگر روی پروژه واقعی خود SSG پیاده کرده‌اید، برایم جالب است بدانید کدام بخش — Build یا Revalidation — بیشترین چالش را ایجاد کرده است. تجربه خودتان را در دیدگاه‌ها بنویسید.