JavaScript

Next.js: SSR مقابل SSG مقابل ISR

اختيار استراتيجية العرض المناسبة للأداء، وتحسين محركات البحث، وتجربة المطور في Next.js.

١٠ يوليو ٢٠٢٥
4 دقيقة قراءة
بواسطة useLines Team
Next.jsSSRSSGISRSEO
Illustration for Next.js: SSR مقابل SSG مقابل ISR

عرض Next.js، مبسط

اختر بناءً على الحداثة والسرعة والتخصيص:

SSG (ثابت)

  • البناء عند النشر؛ تقديم HTML من CDN
  • الأسرع والأرخص والأكثر قابلية للتوسع
  • استخدم لـ: المدونات، المستندات، التسويق

ISR (ثابت + تحديث)

  • مثل SSG، ولكن يتم إعادة إنشائه تلقائيًا على مؤقت
  • يبقى سريعًا، ويحصل على التحديثات في الخلفية
  • استخدم لـ: صفحات المنتجات، الأخبار، الكتالوجات

SSR (خادم)

  • يتم عرض HTML لكل طلب على الخادم
  • حديث ومخصص، ولكنه أبطأ وأكثر تكلفة
  • استخدم لـ: لوحات التحكم، الصفحات التي تتطلب مصادقة كثيفة

دليل سريع

  • نادرًا ما يتغير ← SSG
  • يتغير أحيانًا ← ISR (اضبط revalidate)
  • في الوقت الفعلي أو لكل مستخدم ← SSR

ابدأ بـ SSG، وأضف ISR عند الحاجة، واحتفظ بـ SSR للصفحات الديناميكية حقًا.

ضع في اعتبارك ثلاثة محاور:

  • نافذة الحداثة (من ثوانٍ إلى أيام)
  • التخصيص (لكل مستخدم مقابل عالمي)
  • تكرار البناء (لكل نشر مقابل عند الطلب)

طابق وضع العرض مع هذه الاحتياجات بدلاً من اختيار واحد حسب العادة.

أمثلة على حالات الاستخدام

  • تفاصيل المنتج: ISR مع revalidate: 60 وإعادة التحقق عند الطلب عند أحداث التحديث.
  • الصفحة الرئيسية للأخبار: ISR مع TTL قصير (15-60 ثانية) + التخزين المؤقت على الحافة.
  • لوحة تحكم المسؤول: SSR مع جلسة المستخدم؛ تخزين الأجزاء مؤقتًا في المراحل النهائية حيثما كان آمنًا.
  • المستندات/التسويق: SSG مع الجلب المسبق للروابط.

الحافة والبرامج الوسيطة

ضع التخصيص البسيط واختبارات A/B على الحافة دون فرض SSR لصفحات كاملة. استخدم البرامج الوسيطة على الحافة لإعادة التوجيه، واكتشاف اللغة، والمتغيرات المستندة إلى ملفات تعريف الارتباط.

المزالق والعلاجات

  • الإفراط في SSR: الخوادم تحت الحمل؛ انقل الكتل الثابتة إلى أجزاء ثابتة وقم بترطيب الجزر.
  • تدافع ISR: حماية نقاط نهاية إعادة التحقق؛ استخدم قوائم الانتظار و TTL الناعم.
  • إبطال ذاكرة التخزين المؤقت: ربط إعادة التحقق عند الطلب بـ CMS/webhooks وتضمين مفاتيح بديلة.

الرؤوس التي تهم

اضبط Cache-Control بحكمة:

Cache-Control: public, s-maxage=3600, stale-while-revalidate=60

بالنسبة لاستجابات SSR الخاصة بالمستخدم، استخدم private, no-store وقم بتخزين أجزاء CDN مؤقتًا فقط عندما يكون آمنًا.

قياس النجاح

تتبع LCP و TTFB عبر المسارات. قم بالتحميل المسبق للأصول الهامة وتمكين الجلب المسبق للمسارات التالية المحتملة لتقليل زمن الوصول الملموس.

الخلاصة

اختر SSR أو SSG أو ISR لكل صفحة بناءً على احتياجات البيانات. استخدم الحافة والتخزين المؤقت للحصول على أفضل ما في العالمين، وقم بأتمتة إعادة التحقق حتى يظل المحتوى محدثًا دون التضحية بالسرعة.

مقتطفات التنفيذ

مثال SSR (getServerSideProps)

export async function getServerSideProps() {
  const data = await fetch("https://api.example.com/data", {
    cache: "no-store",
  }).then((r) => r.json());
  return { props: { data } };
}

مثال SSG (getStaticProps)

export async function getStaticProps() {
  const posts = await getAllPosts();
  return { props: { posts } };
}

مثال ISR (مقطع مسار Next 13+)

export const revalidate = 60; // seconds

export default async function Page() {
  const res = await fetch("https://api.example.com/top-products", {
    next: { revalidate },
  });
  const data = await res.json();
  return <Products data={data} />;
}

إعادة التحقق عند الطلب (مسار API)

export default async function handler(req, res) {
  if (req.query.secret !== process.env.REVALIDATE_TOKEN) {
    return res.status(401).json({ message: "Invalid token" });
  }
  await res.revalidate("/products");
  return res.json({ revalidated: true });
}

مقالات ذات صلة