SSR مقابل CSR: فهم آليات عرض صفحات الويب

ما هو الفرق في بناء المواقع بين طريقة العرض من جانب الخادم (Server-Side Rendering - SSR)، والتي عادةً ما تستخدم فيها تقنيات الواجهة الخلفية لإنتاج صفحات HTML وCSS وJavaScript بشكلها التقليدي، وبين طريقة العرض من جانب العميل (Client-Side Rendering - CSR)، والتي تكون شائعة عند استخدام أطر عمل الجافا سكريبت المختلفة؟

لفهم الفرق بينهما، لنتذكر الطريقة التي تعمل بها المواقع التقليدية.

آلية عمل المواقع التقليدية (SSR)

لنفترض على سبيل المثال أنك قمت بزيارة موقع example.com. هنا، توجد ثلاثة مكونات رئيسية تجري من خلالها رحلة طلبك للموقع حتى حصولك على النتيجة:

عندما تكتب example.com في المتصفح، تحدث الخطوات التالية:

  1. يتم إرسال طلب (Request) إلى الخادم الذي يحتوي على الملفات الخاصة بالموقع.
  2. يستقبل الخادم الطلب ويتجه إلى قاعدة البيانات ليطلب منها البيانات المخصصة للصفحة المطلوبة.
  3. تقوم قاعدة البيانات بإرجاع البيانات اللازمة لهذه الصفحة.
  4. بعد ذلك، يأخذ الخادم هذه البيانات وينشئ ملف HTML، ثم يقوم بتعبئة البيانات التي حصل عليها من قاعدة البيانات داخل هذا الملف.
  5. بذلك، تصبح صفحة الـ HTML جاهزة، فيقوم الخادم بإرجاعها إلى المتصفح عبر ما يُعرف بالاستجابة (Response).
  6. تكون الاستجابة في هذه الحالة عبارة عن ملف HTML كامل يحتوي على كل ما طلبه المتصفح.
  7. أخيرًا، يقوم المتصفح بترجمة أكواد HTML وعرضها بشكل مرئي للمستخدم على الشاشة.

التنقل بين الصفحات في SSR

الآن، لنفترض أن المستخدم يزور نفس الموقع لكنه انتقل إلى صفحة أخرى عبر الرابط example.com/helloworld. سيتم تكرار نفس الخطوات تمامًا:

وبالمثل، إذا انتقلت إلى رابط آخر مثل /test، سيتم تنفيذ نفس الخطوات، وسينشئ الخادم ملفًا جديدًا باسم test.html ويتم إرجاعه إلى المتصفح لعرضه للمستخدم.

ملاحظة: هذه هي الطريقة التقليدية في بناء المواقع. في هذه الطريقة، الجهة التي تقوم بإنشاء أو بناء ملف HTML هي الخادم نفسه. فهو الذي يأخذ كل المكونات ويشكل صفحة HTML الكاملة، ويقتصر دور المتصفح على عرضها فقط. هذا ما يُعرف بـ SSR أو Server-Side Rendering، لأن عملية تجهيز الصفحة وعرضها (Rendering) تتم من جانب الخادم.

آلية عمل أطر الجافا سكريبت (CSR)

الآن، لنرَ ما الذي يحدث في حالة استخدام أطر عمل الجافا سكريبت التي تعتمد على العرض من جانب العميل.

مرة أخرى، عند زيارة موقع example.com، تحدث الخطوات التالية:

  1. ينطلق طلب (Request) من العميل إلى الخادم.
  2. الخادم هذه المرة لا يتصل بقاعدة البيانات، بل يقوم بإرجاع ملف HTML واحد فقط. هذا الملف يكون بمثابة هيكل أساسي يحتوي على عدد قليل جدًا من أكواد HTML وهو غير مكتمل المحتوى.
  3. يقوم الخادم بإرجاع هذا الملف إلى المتصفح كجزء من الاستجابة (Response).
  4. يبدأ المتصفح في عرض ملف HTML للمستخدم، لكن العملية لم تنتهِ بعد، فالجزء الأكبر من العمل سيحدث الآن في المتصفح. الملف أصبح موجودًا في المتصفح، لكنه لا يحتوي على جميع العناصر المرئية التي يجب أن تظهر للمستخدم.

التنقل وجلب البيانات في CSR

لنفترض الآن أن المستخدم انتقل إلى الرابط example.com/helloworld.

  1. هذه المرة، لن يرسل العميل طلبًا جديدًا إلى الخادم. بدلاً من ذلك، سيتواصل المتصفح مع الجزء المسؤول عن التوجيه (Routing)، وهو في هذه الحالة إطار عمل الجافا سكريبت.
  2. يخبر المتصفح إطار العمل أن المستخدم يزور /helloworld ويسأل عن المكون (Component) الذي يجب عرضه.
  3. يقوم إطار العمل بتحديد المكون الذي يقابل هذا الرابط.
  4. بعد ذلك، يتم ترجمة هذا المكون (المكتوب بلغة مثل React.js على سبيل المثال) إلى اللغة التي يفهمها المتصفح، وهي وسوم HTML التقليدية، ثم يتم إرجاع هذه الأكواد إلى المتصفح.

لكن الأمر لا ينتهي هنا. ما حدث حتى الآن هو مجرد تجهيز العنصر المرئي الذي يجب أن يظهر لإكمال واجهة المستخدم (UI)، ولكن لا تزال هناك بيانات معينة يجب جلبها.

  1. للحصول على البيانات، سيتم التواصل مع الخادم مرة أخرى عن طريق ما يُعرف بطلب الواجهة البرمجية (API Request).
  2. يذهب الخادم لجلب البيانات من قاعدة البيانات، والتي بدورها ترجع البيانات المطلوبة.
  3. يقوم الخادم بتجهيز هذه البيانات وتنسيقها (عادة بصيغة JSON)، ولكن لاحظ أنه هنا لم ينشئ ملف HTML، بل جهز ملف بيانات فقط.
  4. سيتم إرجاع ملف البيانات هذا إلى المتصفح.
  5. بعد ذلك، يقوم المتصفح، من خلال أكواد جافا سكريبت، بأخذ هذه البيانات وتعبئتها في الصفحة، وبذلك يكتمل بناؤها.

وإذا أخذنا مثالاً آخر بالانتقال إلى /test، ستتكرر نفس العملية: يحدد إطار العمل المكون المناسب، يحوله إلى HTML، يرسل طلب API لجلب البيانات، ثم يعبئ البيانات في الصفحة لتكتمل أمام المستخدم.

ملاحظة: هذه الطريقة في بناء المواقع هي ما يُعرف بـ CSR أو Client-Side Rendering. والسبب في هذه التسمية هو أن مسؤولية تجهيز صفحة HTML، وتحديد العناصر التي تظهر وتختفي بناءً على تنقل المستخدم (أي عملية التوجيه Routing)، تقع على عاتق المكونات الموجودة في المتصفح، وهي الجافا سكريبت وأطر عملها. العميل هو الذي قام ببناء (Rendering) وتعبئة ملف HTML بالشكل الذي يجب أن يظهر به للمستخدم.

تطبيقات الصفحة الواحدة (Single-Page Applications)

سؤال أخير: كم عدد الصفحات الفعلية في موقع مبني بتقنية CSR؟

الجواب هو: صفحة واحدة فقط.

السبب هو أنك جلبت ملف HTML واحدًا فقط من الخادم في بداية الجلسة. ما يحدث داخل هذه الصفحة هو أن المكونات (Components) تتبدل الواحدة تلو الأخرى بناءً على تنقل المستخدم بين الروابط المختلفة، وهذا يخلق إيحاءً أو محاكاة لعملية الانتقال بين صفحات متعددة.

لكن في نهاية الأمر، هي صفحة واحدة وملف HTML واحد. لهذا السبب، تُسمى المواقع المبنية بهذه الطريقة “تطبيقات الصفحة الواحدة” (Single-Page Applications أو SPAs).

شارك المقال

أحدث المقالات

CONNECTED
ONLINE: ...
SECURE
00:00:00