رواد التقنية

شو هما طرق عرض الصفحات (Rendering) في (ISR, CSR, SSR, SSG)

١٧ مارس ٢٠٢٥

في عالم تطوير الويب، دايمًا بنسمع عن Client-Side Rendering و Server-Side Rendering ، خصوصًا إذا كنت بتشتغل بـ React أو Next.js. بس شو الفرق بينهم؟ ومتى نستخدم كل واحد فيهم؟ وهل في طرق تانية ممكن تساعدنا نحصل على أداء أفضل؟ تعالوا نحكي عن الموضوع بطريقة واضحة وسلسة! 

أولًا: شو يعني Client-Side Rendering ؟

باختصار: في CSR، المتصفح بتحميل صفحة HTML فاضية تقريبًا، وبعدها JavaScript (وبالأخص React) بتشتغل وبتبني الصفحة بالكامل على جهاز المستخدم.

كيف بتتم العملية ؟

اول شي المتصفح بيطلب الصفحة.بعدها السيرفر بيرجع HTML بسيط جدًا + ملفات JS. و اخر شي المتصفح بيشغل JavaScript، بيعمل Fetch للبيانات، وبعدها React بترندر الصفحة بشكل ديناميكي.

مثال عليها : لما تفتح Facebook أو Twitter، وبتلاحظ إنه الصفحة بتتحمل بسرعة، بس بعدها البيانات بتبدأ تظهر تدريجيًا (البوستات، الصور، التعليقات...الخ).

وين بنشوف الاشي هاد : لما تفتح Facebook أو Twitter، الصفحة بتتحمل بسرعة، بس بعدها البيانات بتبدأ تظهر تدريجيًا (البوستات، الصور، التعليقات...).

متى نستخدم CSR؟

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

بس في شوية مشاكل ممكن تصير في CSR زي:

  • SEO ضعيف: محركات البحث ممكن تواجه مشاكل في قراءة المحتوى، لأنه ما بيكون ظاهر مباشرة في كود HTML.
  • التحميل الأولي بطيء : لأنه المتصفح لازم يحمل React + بيانات التطبيق قبل ما يشوف المستخدم أي شيء.

ثانيًا: Server-Side Rendering

في SSR، السيرفر بيعمل كل الشغل! لما تطلب الصفحة، بيرجعلك HTML جاهز بالبيانات، والمتصفح بس بيعرضه مباشرة.

كيف بتم؟

لما المتصفح بيطلب الصفحة , السيرفر بيعمل Fetch للبيانات , وبيرندر الصفحة بـ React و بيرجع HTML كامل والمتصفح بيعرض الصفحة مباشرة، وبعدها React بيشتغل بالـ background.و بنشوف الشي هاد في مواقع الأخبار مثل BBC أو New York Times.

متى نستخدم SSR؟

    • إذا كان عندك موقع محتوى (مثل مدونات أو مواقع أخبار).
    • إذا كنت بحاجة لـ SEO قوي عشان محركات البحث تفهم المحتوى بسهولة.
    • إذا كنت بدك الصفحة تنعرض بسرعة للمستخدم حتى قبل ما React يشتغل.

زي ما في ال CRS مشاكل ف ع الأكيد في ف ال SSR شوية مشاكل ممكن تواجهك زي :

    • أداء السيرفر بيكون عليه ضغط: لأنه لازم يرندر كل صفحة لكل مستخدم جديد.
    • لو زادت الطلبات ف ممكن السرعة تبطأ, لأن في حالتنا هاي السيرفر بيعمل كل الشغل بدل المتصفح.

طيب، هل في طرق تانية؟

أكيد! Next.js بتقدم طريقتين رهيبات ال هما :

أول طريقة Static Site Generation

SSG يعني إنك بتحضّر الصفحات بشكل ثابت وقت البناء (build time)، وبتنحفظ كملفات HTML جاهزة. يعني لما المستخدم يطلب الصفحة، السيرفر بس بيرجع ملف HTML موجود مسبقًا، بدون حسابات أو جلب بيانات.

كيف بتم؟

في عملية الـ build، السيرفر بيجيب البيانات وبيرندر HTML ثابت. وهاي الملفات بتنحط على CDN أو السيرفر. المستخدم لما يفتح الموقع، بيشوف الصفحة فورًا.

اكبر مثال ع استخدامهم في صفحات الـ Landing Pages أو صفحات "About Us".

و من مميزات SSG:

    • أداء عالي جدًا.
    • أمان أكثر لأن المحتوى مش ديناميكي.
    • استهلاك قليل جدًا من موارد السيرفر.

بس شو مشكلته؟ إذا المحتوى كتير (زي التعليقات أو أخبار لحظية)، فSSG لحاله مش كافي.

ثاني طريقة : :Incremental Static Regeneration

ISR هو تحسين ذكي على SSG! بعطيك أفضل ما في العالمين: صفحات ثابتة بس بتتحدث لحالها كل فترة بتحددها.

كيف بشتغل؟

أول مرة المستخدم يطلب الصفحة، السيرفر برجع نسخة ثابتة, بـ الخلفية، Next.js بتشيّك إذا مر وقت كافي (مثلاً 10 دقايق)، فبيرجع يبني نسخة جديدة من الصفحة ويستبدلها. اما المستخدمين الجدد بشوفوا النسخة الجديدة بدون تأخير. هاي الطريقة مفيدة لما عندك محتوى بيتحدث كل فترة، بس مش لحظيًا.

أكبر مثال ل إستخدامه: متجر إلكتروني فيه منتجات بتتحدث كل كم ساعة.

مميزات ISR:

    • أسرع من SSR.
    • أقل استهلاك للموارد.
    • مناسب لمواقع فيها محتوى بيتحدث بشكل غير لحظي.

طيب، أي واحد لازم أستخدم؟

  • لو عندك تطبيق تفاعلي معقد استخدم CSR.
  • موقع ثابت محتوى استخدم SSG.
  • موقع بيحتاج SEO و محدث بإستمرار استخدم SSR.
  • موقع بيحدث كل فترة استخدم ISR.

لكن ازا بدك تستخدم كل الطرق حسب الصفحة ف استخدم Next.js لانها بتدعمهم كلهم.

Dana Tarik