تاريخ النشر: 6 فبراير 2019، تاريخ آخر تعديل: 5 يناير 2026
من القرارات الأساسية التي يجب على مطوِّري تطبيقات الويب اتخاذها هو مكان تنفيذ المنطق والعرض في تطبيقاتهم. قد يكون هذا صعبًا لأن هناك العديد من الطرق لإنشاء موقع ويب.
يستند فهمنا لهذا المجال إلى عملنا في Chrome من خلال التواصل مع المواقع الإلكترونية الكبيرة على مدار السنوات القليلة الماضية. بشكل عام، نشجّع المطوّرين على استخدام العرض من جهة الخادم أو العرض الثابت بدلاً من نهج إعادة التحويل الكامل لصفحة الويب الثابتة إلى صفحة ديناميكية.
لفهم البُنى التي نختار من بينها بشكل أفضل عند اتخاذ هذا القرار، نحتاج إلى مصطلحات متسقة وإطار عمل مشترك لكل نهج. بعد ذلك، يمكنك تقييم المفاضلات لكل نهج عرض من منظور أداء الصفحة بشكل أفضل.
المصطلحات
أولاً، سنعرّف بعض المصطلحات التي سنستخدمها.
العرض
- العرض من جهة الخادم (SSR)
- عرض تطبيق على الخادم لإرسال HTML، بدلاً من JavaScript، إلى العميل.
- العرض من جهة العميل (CSR)
- عرض تطبيق في متصفّح باستخدام JavaScript لتعديل نموذج العناصر في المستند (DOM)
- العرض المُسبَق
- تشغيل تطبيق من جهة العميل في وقت الإنشاء لتسجيل حالته الأولية كملف HTML ثابت. يُرجى العِلم أنّ "العرض المُسبق" في هذا السياق يختلف عن العرض المُسبق لعمليات التنقّل المستقبلية في المتصفّح.
- ترطيب
- تشغيل النصوص البرمجية من جهة العميل لإضافة حالة التطبيق والتفاعل إلى HTML المعروض من الخادم. تفترض عملية الإحياء أنّ نموذج DOM لا يتغيّر.
- إعادة الترطيب
- على الرغم من أنّ مصطلح "إعادة التنشيط" يُستخدم غالبًا للإشارة إلى المعنى نفسه الذي يشير إليه مصطلح "التنشيط"، فإنّ إعادة التنشيط تعني تحديث نموذج DOM بانتظام بأحدث حالة، بما في ذلك بعد التنشيط الأولي.
الأداء
- مدة تحميل أول بايت (TTFB)
- الوقت بين النقر على رابط وتحميل أول بايت من المحتوى على الصفحة الجديدة
- سرعة عرض أول محتوى مرئي (FCP)
- الوقت الذي يصبح فيه المحتوى المطلوب (نص المقالة وما إلى ذلك) مرئيًا
- مدى استجابة الصفحة لتفاعلات المستخدم (INP)
- هو مقياس تمثيلي يقيّم ما إذا كانت الصفحة تستجيب باستمرار وبسرعة لإدخالات المستخدم.
- إجمالي وقت الحظر (TBT)
- هو مقياس بديل لـ INP يحتسب مدة حظر سلسلة التعليمات الرئيسية أثناء تحميل الصفحة.
العرض من جهة الخادم
يؤدي العرض من جهة الخادم إلى إنشاء ترميز HTML الكامل لصفحة معيّنة على الخادم استجابةً لعملية التنقّل. يؤدي ذلك إلى تجنُّب عمليات الذهاب والعودة الإضافية لجلب البيانات وإنشاء النماذج على العميل، لأنّ المعالج يتعامل معها قبل أن يتلقّى المتصفّح ردًا.
يؤدي العرض على جهة الخادم بشكل عام إلى سرعة عرض أول محتوى مرئي (FCP). يتيح لك تشغيل منطق الصفحة وعرضها على الخادم تجنُّب إرسال الكثير من JavaScript إلى العميل. يساعد ذلك في تقليل إجمالي وقت الحظر (TBT) في الصفحة، ما قد يؤدي أيضًا إلى خفض مقياس مدى استجابة الصفحة لتفاعلات المستخدم (INP)، لأنّ سلسلة التعليمات الرئيسية لا يتم حظرها كثيرًا أثناء تحميل الصفحة. عندما يتم حظر سلسلة التعليمات الرئيسية بمعدّل أقل، تزداد فرص تشغيل تفاعلات المستخدمين بشكل أسرع.
وهذا منطقي، لأنّ العرض من جهة الخادم يقتصر على إرسال النصوص والروابط إلى متصفّح المستخدم. يمكن أن يعمل هذا النهج بشكل جيد مع مجموعة متنوعة من ظروف الأجهزة والشبكات ويفتح تحسينات مثيرة للاهتمام في المتصفح، مثل تحليل المستندات المتدفقة.
من خلال العرض من جهة الخادم، يقل احتمال انتظار المستخدمين لتشغيل JavaScript المرتبط بوحدة المعالجة المركزية قبل أن يتمكنوا من استخدام موقعك الإلكتروني. حتى في حال عدم تمكّنك من تجنُّب JavaScript التابعة لجهات خارجية، يمكن أن يمنحك استخدام العرض من جهة الخادم لتقليل تكاليف JavaScript الخاصة بالطرف الأول مزيدًا من الميزانية للباقي. ومع ذلك، هناك عيب محتمل في هذا النهج: يستغرق إنشاء الصفحات على الخادم وقتًا، ما قد يؤدي إلى زيادة مدة تحميل أول بايت (TTFB) لصفحتك.
يعتمد تحديد ما إذا كانت المعالجة من جهة الخادم كافية لتطبيقك إلى حد كبير على نوع التجربة التي تنشئها. هناك جدل طويل حول التطبيقات الصحيحة للعرض من جهة الخادم مقابل العرض من جهة العميل، ولكن يمكنك دائمًا اختيار استخدام العرض من جهة الخادم لبعض الصفحات دون غيرها. نجحت بعض المواقع الإلكترونية في استخدام تقنيات العرض المختلط. على سبيل المثال، يعرض Netflix صفحاته المقصودة الثابتة نسبيًا من جهة الخادم، بينما prefetching JavaScript للصفحات التي تتضمّن تفاعلات كثيرة، ما يمنح هذه الصفحات الأثقل التي يتم عرضها من جهة العميل فرصة أفضل للتحميل بسرعة.
باستخدام العديد من أُطر العمل والمكتبات والبُنى الحديثة، يمكنك عرض التطبيق نفسه على كل من العميل والخادم. يمكنك استخدام هذه الأساليب للعرض من جهة الخادم. ومع ذلك، فإنّ البُنى التي يتم فيها العرض على كل من الخادم والعميل هي فئة خاصة من الحلول ذات خصائص أداء ومفاضلات مختلفة جدًا. يمكن لمستخدمي React استخدام واجهات برمجة تطبيقات DOM للخادم أو الحلول المستندة إليها، مثل Next.js، للعرض من جهة الخادم. يمكن لمستخدمي Vue استخدام دليل العرض من جهة الخادم في Vue أو Nuxt. يحتوي Angular على Universal.
ومع ذلك، تستخدم معظم الحلول الشائعة شكلاً من أشكال الإماهة، لذا يجب الانتباه إلى الأساليب التي تستخدمها أداتك.
العرض الثابت
يحدث العرض الثابت في وقت الإنشاء. يوفّر هذا النهج سرعة عرض أول محتوى مرئي (FCP) سريعة، بالإضافة إلى وقت تفاعل أقل (TBT) ومقياس INP، طالما أنّك تحدّ من مقدار JavaScript من جهة العميل على صفحاتك. وعلى عكس العرض من جهة الخادم، يحقّق هذا الأسلوب أيضًا مدة تحميل أول بايت (TTFB) سريعة باستمرار، لأنّه لا يلزم إنشاء رمز HTML لصفحة ما بشكل ديناميكي على الخادم. بشكل عام، تعني العرض الثابت إنشاء ملف HTML منفصل لكل عنوان URL مسبقًا. من خلال إنشاء ردود HTML مسبقًا، يمكنك نشر عمليات العرض الثابتة على شبكات توصيل محتوى (CDN) متعددة للاستفادة من ميزة التخزين المؤقت على الأجهزة الطرفية.
تتوفّر حلول العرض الثابت بجميع الأشكال والأحجام. تم تصميم أدوات مثل Gatsby لتجعل المطوّرين يشعرون بأنّ تطبيقاتهم يتم عرضها بشكل ديناميكي، وليس كخطوة إنشاء. تعتمد أدوات إنشاء المواقع الإلكترونية الثابتة، مثل 11ty وJekyll وMetalsmith، على طبيعتها الثابتة، ما يوفّر نهجًا يعتمد بشكل أكبر على النماذج.
من سلبيات العرض الثابت أنّه يجب إنشاء ملفات HTML فردية لكل عنوان URL محتمل. قد يكون ذلك صعبًا أو حتى مستحيلاً عندما تحتاج إلى توقّع عناوين URL هذه مسبقًا، وكذلك بالنسبة إلى المواقع الإلكترونية التي تتضمّن عددًا كبيرًا من الصفحات الفريدة.
قد يكون مستخدمو React على دراية بـ Gatsby أو Next.js static export أو Navi، وكلها تجعل من السهل إنشاء صفحات من المكونات. ومع ذلك، يختلف سلوك العرض الثابت عن العرض المُسبق: فالصفحات المعروضة بشكل ثابت تكون تفاعلية بدون الحاجة إلى تنفيذ الكثير من رموز JavaScript من جهة العميل، في حين أنّ العرض المُسبق يحسّن سرعة عرض أول محتوى مرئي (FCP) لتطبيق من صفحة واحدة يجب تشغيله على العميل لجعل الصفحات تفاعلية بشكل فعلي.
إذا لم تكن متأكدًا مما إذا كان الحلّ المحدّد هو العرض الثابت أو العرض المُسبق، جرِّب إيقاف JavaScript وتحميل الصفحة التي تريد اختبارها. بالنسبة إلى الصفحات المعروضة بشكل ثابت، تظل معظم الميزات التفاعلية متاحة بدون JavaScript. قد تظل الصفحات المعروضة مسبقًا تتضمّن بعض الميزات الأساسية، مثل الروابط التي تم إيقاف JavaScript فيها، ولكن معظم الصفحة يكون غير نشط.
من الاختبارات المفيدة الأخرى استخدام ضبط الحد الأقصى المسموح لعرض نطاق الشبكة في "أدوات مطوّري البرامج في Chrome" والاطّلاع على مقدار JavaScript الذي يتم تنزيله قبل أن تصبح الصفحة تفاعلية. يتطلّب العرض المُسبَق عادةً المزيد من JavaScript ليصبح تفاعليًا، ويميل هذا الرمز إلى أن يكون أكثر تعقيدًا من نهج التحسين التدريجي المستخدَم في العرض الثابت.
العرض من جهة الخادم مقابل العرض الثابت
لا يُعدّ العرض من جهة الخادم الحلّ الأفضل لكل شيء، لأنّ طبيعته الديناميكية يمكن أن تؤدي إلى تكاليف إضافية كبيرة في الحوسبة. لا تتيح العديد من حلول العرض من جهة الخادم إمكانية الإرسال المبكر للبيانات، أو تأخير مدة تحميل أول بايت، أو مضاعفة البيانات التي يتم إرسالها (على سبيل المثال، الحالات المضمّنة التي تستخدمها JavaScript على العميل). في React،
يمكن أن يكون renderToString() بطيئًا لأنّه متزامن وأحادي السلسلة.
تتيح واجهات برمجة تطبيقات DOM الأحدث لخادم React استخدام البث، ما يتيح الحصول على الجزء الأولي من استجابة HTML للمتصفّح في وقت أقرب بينما لا يزال الجزء المتبقي قيد الإنشاء على الخادم.
قد يتطلّب تنفيذ العرض على جهة الخادم بشكل صحيح العثور على حلّ أو إنشاء حلّ لتخزين المكوّنات مؤقتًا وإدارة استهلاك الذاكرة واستخدام تقنيات الحفظ وغيرها من المسائل. غالبًا ما تتم معالجة التطبيق نفسه أو إعادة إنشائه مرتين، مرة على العميل ومرة على الخادم. إنّ عرض المحتوى بشكل أسرع من خلال العرض من جهة الخادم لا يعني بالضرورة أنّك ستنجز العمل بشكل أسرع، فإذا كان لديك الكثير من العمل على جهة العميل بعد وصول استجابة HTML التي تم إنشاؤها من جهة الخادم إلى جهة العميل، قد يؤدي ذلك إلى زيادة وقت الاستجابة التفاعلي (TBT) ومقياس "التفاعل مع الصفحة التالية" (INP) لموقعك الإلكتروني.
يؤدي العرض من جهة الخادم إلى إنشاء ترميز HTML عند الطلب لكل عنوان URL، ولكن قد يكون أبطأ من عرض المحتوى الثابت. إذا كان بإمكانك بذل المزيد من الجهد، يمكن أن يؤدي العرض من جهة الخادم بالإضافة إلى التخزين المؤقت لملفات HTML إلى تقليل الوقت المستغرَق للعرض من جهة الخادم بشكل كبير. تتمثّل ميزة العرض من جهة الخادم في إمكانية سحب المزيد من البيانات "المباشرة" والاستجابة لمجموعة أكثر اكتمالاً من الطلبات مقارنةً بالعرض الثابت. الصفحات التي تحتاج إلى تخصيص هي مثال ملموس على نوع الطلب الذي لا يعمل بشكل جيد مع العرض الثابت.
يمكن أن يقدّم العرض من جهة الخادم أيضًا قرارات مثيرة للاهتمام عند إنشاء PWA. هل من الأفضل استخدام التخزين المؤقت لصفحة كاملة من خلال مشغّل الخدمات، أم عرض أجزاء فردية من المحتوى على الخادم؟
العرض من جهة العميل
يعني العرض من جهة العميل عرض الصفحات مباشرةً في المتصفّح باستخدام JavaScript. تتم معالجة جميع عمليات المنطق وجلب البيانات وإنشاء النماذج والتوجيه على العميل بدلاً من الخادم. النتيجة الفعّالة هي أنّه يتم نقل المزيد من البيانات إلى جهاز المستخدم من الخادم، وهذا يأتي مع مجموعة من المفاضلات.
قد يكون من الصعب إنشاء عرض من جهة العميل والحفاظ على سرعته على الأجهزة الجوّالة.
من خلال بذل بعض الجهد للحفاظ على ميزانية JavaScript محدودة
وتقديم القيمة بأقل عدد ممكن من عمليات الذهاب والعودة،
يمكنك جعل العرض من جهة العميل يماثل تقريبًا
أداء العرض من جهة الخادم فقط. يمكنك تسريع عمل المحلل اللغوي من خلال عرض النصوص البرمجية والبيانات المهمة باستخدام <link rel=preload>. ننصحك أيضًا باستخدام أنماط مثل PRPL لضمان أن تبدو عمليات التنقّل الأولية واللاحقة فورية.
الجانب السلبي الأساسي للعرض من جهة العميل هو أنّ مقدار JavaScript المطلوب يميل إلى الزيادة مع نمو التطبيق، ما قد يؤثر في مقياس INP للصفحة. ويصبح ذلك صعبًا بشكل خاص مع إضافة مكتبات JavaScript جديدة ورموز polyfill ورموز برمجية تابعة لجهات خارجية، والتي تتنافس على قوة المعالجة وغالبًا ما يجب معالجتها قبل عرض محتوى الصفحة.
بالنسبة إلى التجارب التي تستخدم العرض من جهة العميل وتعتمد على حِزم JavaScript كبيرة، يجب استخدام تقسيم الرموز البرمجية بشكل مكثّف لخفض وقت الاستجابة للحدث (TBT) ومقياس INP أثناء تحميل الصفحة، بالإضافة إلى استخدام تقنية التحميل الكسول لملفات JavaScript من أجل عرض ما يحتاجه المستخدم فقط عند الحاجة إليه. بالنسبة إلى التجارب التي تتضمّن تفاعلاً قليلاً أو لا تتضمّن أي تفاعل، يمكن أن يمثّل العرض من جهة الخادم حلاً أكثر قابلية للتوسّع لهذه المشاكل.
بالنسبة إلى مطوّري التطبيقات من صفحة واحدة، يتيح تحديد الأجزاء الأساسية من واجهة المستخدم التي تشترك فيها معظم الصفحات تطبيق تقنية تخزين هيكل التطبيق مؤقتًا. وعند استخدام هذه الميزة مع مشغّلي الخدمات، يمكن أن تحسّن بشكل كبير
الأداء الملحوظ في الزيارات المتكررة، لأنّ الصفحة يمكنها تحميل
ملف HTML لهيكل التطبيق والتبعيات من CacheStorage بسرعة كبيرة.
تجمع عملية إعادة التحميل بين العرض من جهة الخادم والعرض من جهة العميل
الترطيب هو نهج يقلّل من المفاضلات بين العرض من جهة العميل والعرض من جهة الخادم من خلال تنفيذ كليهما. تتم معالجة طلبات التنقّل، مثل عمليات تحميل الصفحات الكاملة أو إعادة تحميلها، من خلال خادم يعرض التطبيق بتنسيق HTML. بعد ذلك، يتم تضمين JavaScript والبيانات المستخدَمة للعرض في المستند الناتج. عند تنفيذ ذلك بعناية، يتم تحقيق سرعة عرض أول محتوى مرئي (FCP) مثل العرض من جهة الخادم، ثم "يتم استئناف" العرض مرة أخرى على جهة العميل.
هذا حلّ فعّال، ولكن يمكن أن يكون له عيوب كبيرة في الأداء.
يتمثّل العيب الأساسي في العرض من جهة الخادم مع إعادة التحميل في أنّه يمكن أن يكون له تأثير سلبي كبير في مقياسَي TBT وINP، حتى إذا كان يحسّن مقياس FCP. قد تظهر الصفحات المعروضة من جهة الخادم على أنّها محمّلة وتفاعلية، ولكن لا يمكنها الاستجابة للإدخال إلى أن يتم تنفيذ النصوص البرمجية من جهة العميل للمكوّنات وإرفاق معالِجات الأحداث. على الأجهزة الجوّالة، قد يستغرق ذلك دقائق، ما يربك المستخدم ويُشعره بالإحباط.
مشكلة في إعادة التثبيت: تطبيق واحد بسعر تطبيقَين
لكي يتولّى JavaScript من جهة العميل بدقة ما توقّف عنده الخادم، بدون إعادة طلب جميع البيانات التي عرض الخادم رمز HTML الخاص بها، فإنّ معظم حلول العرض من جهة الخادم تجعل الاستجابة من تبعيات بيانات واجهة المستخدم متسلسلة كعلامات برمجية في المستند. بما أنّ هذه العملية تكرّر الكثير من رموز HTML، يمكن أن تؤدي إلى مشاكل أكثر من مجرد تأخير التفاعل.
يعرض الخادم وصفًا لواجهة مستخدم التطبيق استجابةً لطلب التنقّل، ولكنه يعرض أيضًا بيانات المصدر المستخدَمة لإنشاء واجهة المستخدم هذه، ونسخة كاملة من تنفيذ واجهة المستخدم التي يتم تشغيلها بعد ذلك على العميل. لا تصبح واجهة المستخدم تفاعلية إلا بعد انتهاء تحميل bundle.js وتنفيذه.
تشير مقاييس الأداء التي تم جمعها من مواقع إلكترونية حقيقية تستخدم العرض من جهة الخادم وإعادة التحميل إلى أنّ هذا الخيار نادرًا ما يكون الأفضل. السبب الأهم هو تأثيره على تجربة المستخدم، عندما تبدو الصفحة جاهزة ولكن لا تعمل أي من ميزاتها التفاعلية.
هناك أمل في العرض من جهة الخادم من خلال عملية تحويل صفحة الويب الثابتة إلى صفحة ديناميكية. على المدى القصير، يمكن أن يؤدي استخدام العرض من جهة الخادم فقط للمحتوى الذي يمكن تخزينه مؤقتًا بشكل كبير إلى تقليل مدة تحميل أول بايت (TTFB)، ما يؤدي إلى نتائج مشابهة للعرض المُسبق. قد تكون إعادة الترطيب تدريجيًا أو جزئيًا هي المفتاح لجعل هذه التقنية أكثر قابلية للتطبيق في المستقبل.
العرض على جهة الخادم بشكل متواصل وإعادة تحميل المحتوى تدريجيًا
شهدت عملية العرض من جهة الخادم عددًا من التطورات على مدار السنوات القليلة الماضية.
العرض من جهة الخادم من خلال البث:
يتيح لك إرسال HTML في أجزاء يمكن للمتصفّح عرضها تدريجيًا عند
تلقّيها. يمكن أن يؤدي ذلك إلى وصول الترميز إلى المستخدمين بشكل أسرع، ما يسرّع عرض أول محتوى مرئي (FCP). في
React، تكون عمليات البث غير متزامنة في renderToPipeableStream()، مقارنةً
بالعمليات المتزامنة في renderToString()، ما يعني أنّه يتم التعامل مع الضغط العكسي بشكل جيد.
إعادة التنشيط التدريجي هي أيضًا ميزة تستحق النظر فيها (نفّذتها React). باستخدام هذا الأسلوب، يتم "تشغيل" أجزاء فردية من تطبيق يتم عرضه على الخادم بمرور الوقت، بدلاً من الأسلوب الشائع الحالي المتمثل في تهيئة التطبيق بأكمله مرة واحدة. يمكن أن يساعد ذلك في تقليل مقدار JavaScript اللازم لجعل الصفحات تفاعلية، لأنّه يتيح لك تأجيل ترقية الأجزاء ذات الأولوية المنخفضة من الصفحة من جهة العميل لمنعها من حظر سلسلة التعليمات الرئيسية، ما يتيح حدوث تفاعلات المستخدمين في وقت أقرب بعد أن يبدأها المستخدم.
يمكن أن تساعدك إعادة التحميل التدريجية أيضًا في تجنُّب إحدى المشاكل الأكثر شيوعًا في إعادة التحميل من جهة الخادم: يتم تدمير شجرة نموذج العناصر في المستند التي تم عرضها من جهة الخادم ثم إعادة إنشائها على الفور، وغالبًا ما يكون ذلك بسبب أنّ العرض الأولي المتزامن من جهة العميل يتطلب بيانات لم تكن جاهزة تمامًا، وغالبًا ما يكون ذلك بسبب Promise لم يتم حلّه بعد.
إعادة ترطيب جزئي
وقد ثبتت صعوبة تنفيذ عملية إعادة الترطيب الجزئي. هذا النهج هو امتداد لعملية إعادة التحميل التدريجي التي تحلّل أجزاء فردية من الصفحة (المكوّنات أو طرق العرض أو الأشجار) وتحدّد الأجزاء التي تتضمّن تفاعلاً قليلاً أو لا تتضمّن أي تفاعل. بالنسبة إلى كل جزء من هذه الأجزاء الثابتة في الغالب، يتم بعد ذلك تحويل رمز JavaScript المقابل إلى مراجع خاملة وميزات تزيينية، ما يقلل من أثرها على جهة العميل إلى الصفر تقريبًا.
يأتي نهج إعادة التنشيط الجزئي مع مشاكله وتنازلاته الخاصة. ويؤدي ذلك إلى بعض التحديات المثيرة للاهتمام في ما يتعلق بالتخزين المؤقت، كما أنّ التنقّل من جهة العميل يعني أنّه لا يمكننا افتراض أنّ ترميز HTML المعروض من جهة الخادم للأجزاء غير النشطة من التطبيق متاح بدون تحميل الصفحة بالكامل.
عرض ثلاثي الأبعاد
إذا كان بإمكانك استخدام مشغّلي الخدمات، ننصحك باستخدام العرض الثلاثي الشكل. تتيح لك هذه التقنية استخدام العرض من جهة الخادم للبث لعمليات التنقّل الأولية أو غير المستندة إلى JavaScript، ثم جعل مشغّل الخدمات يتولى عرض HTML لعمليات التنقّل بعد تثبيته. يمكن أن يساعد ذلك في إبقاء المكوّنات والنماذج المخزّنة مؤقتًا محدّثة، كما يتيح التنقّل بأسلوب SPA لعرض طرق عرض جديدة في الجلسة نفسها. يعمل هذا الأسلوب بشكل أفضل عندما يمكنك مشاركة رمز النماذج والتوجيه نفسه بين الخادم وصفحة العميل ومشغّل الخدمات.
اعتبارات تحسين محركات البحث
عند اختيار استراتيجية عرض الويب، غالبًا ما تأخذ الفِرق في الاعتبار تأثير تحسين محركات البحث. يُعدّ العرض من جهة الخادم خيارًا شائعًا لتقديم تجربة "كاملة المظهر" يمكن لبرامج الزحف تفسيرها. يمكن لبرامج الزحف فهم JavaScript، ولكن غالبًا ما تكون هناك قيود على كيفية عرضها. يمكن استخدام العرض من جهة العميل، ولكن غالبًا ما يتطلّب ذلك إجراء اختبارات إضافية وتحمُّل أعباء إضافية. ومؤخرًا، أصبح العرض الديناميكي أيضًا خيارًا يستحق النظر فيه إذا كانت بنية موقعك الإلكتروني تعتمد بشكل كبير على JavaScript من جهة العميل.
الخاتمة
عند اختيار طريقة للعرض، عليك قياس وفهم المشاكل التي تواجهك. فكِّر في ما إذا كان العرض الثابت أو العرض من جهة الخادم يمكن أن يساعدك في تحقيق معظم أهدافك. لا بأس في استخدام HTML في الغالب مع الحد الأدنى من JavaScript للحصول على تجربة تفاعلية. في ما يلي مخطّط بياني مفيد يعرض نطاق الخادم والعميل:
الساعات المعتمَدة
نشكر الجميع على مراجعاتهم وأفكارهم الملهمة:
"جيفري بوسنيك" و"حسين جردة" و"شوبي بانيكر" و"كريس هارلسون" و"سيباستيان ماركباج"