العرض على الويب

أين ينبغي أن ننفذ المنطق والعرض في تطبيقاتنا؟ هل يجب استخدام العرض من جهة الخادم؟ ماذا عن الجفاف؟ لنعثر على بعض الإجابات.

بصفتنا مطورين، غالبًا ما نواجه قرارات من شأنها أن تؤثر على البنية الكاملة لتطبيقاتنا. أحد القرارات الأساسية التي يجب أن يتّخذها مطوّرو الويب هو مكان تنفيذ المنطق والعرض في تطبيقاتهم. قد يكون هذا أمرًا صعبًا، نظرًا لوجود عدد من الطرق المختلفة لإنشاء موقع ويب.

استندنا إلى فهمنا لهذه المساحة من خلال عملنا في Chrome على التواصل مع المواقع الإلكترونية الكبيرة على مدار السنوات القليلة الماضية. وبشكل عام، ننصح المطوّرين بالتفكير في العرض من جهة الخادم أو العرض الثابت بدلاً من منهج معالجة البيانات الكاملة.

من أجل فهم أفضل للبِنى التي نختارها عند اتخاذ هذا القرار، يجب أن يكون لدينا فهم قوي لكل نهج ومصطلحات متسقة لاستخدامها عند التحدث عنها. وتساعد الاختلافات بين هذه الأساليب في توضيح المفاضلات بين العرض على الويب من خلال منظور الأداء.

المصطلحات

العرض

• العرض من جهة الخادم (SSR): عرض تطبيق من جهة العميل أو تطبيق عام بتنسيق HTML على الخادم.
• العرض من جهة العميل (CSR): هو عرض تطبيق في متصفّح من خلال JavaScript لتعديل نموذج العناصر في المستند (DOM).
• إعادة المعالجة: "تشغيل" طرق عرض JavaScript على البرنامج بحيث يعيدون استخدام شجرة بيانات DOM وبياناتها المعروضة على الخادم في رمز HTML.
• العرض المُسبَق: تشغيل تطبيق من جهة العميل في وقت الإصدار للحصول على حالته الأولية كرمز HTML ثابت.

الأداء

• وقت وصول أول بايت (TTFB): يشير إلى الوقت بين النقر على رابط والجزء الأول من المحتوى.
• سرعة عرض المحتوى على الصفحة (FCP): الوقت الذي يصبح فيه المحتوى المطلوب (نص المقالة وما إلى ذلك) مرئيًا.
• مدى استجابة الصفحة لتفاعلات المستخدم (INP): يُستخدم كمقياس تمثيلي يقيّم ما إذا كانت الصفحة تستجيب بسرعة وبشكل ثابت للبيانات التي أدخلها المستخدمون.
• إجمالي وقت الحظر (TBT): مقياس خادم وكيل لـ INP، يحتسب مقدار الوقت الذي تم فيه حظر سلسلة التعليمات الرئيسية أثناء تحميل الصفحة.

العرض من جهة الخادم

يؤدي العرض من جهة الخادم إلى إنشاء ترميز HTML الكامل لصفحة على الخادم استجابةً لعملية التنقّل. يؤدي ذلك إلى تجنُّب الرحلات ذهابًا وإيابًا إضافية لاسترجاع البيانات وإنشاء نماذجها على العميل، حيث تتم معالجتها قبل تلقّي المتصفِّح ردًّا.

بشكل عام، يؤدي العرض من جهة الخادم إلى سرعة عرض المحتوى على الصفحة (FCP). يتيح تشغيل منطق الصفحة والعرض على الخادم تجنب إرسال الكثير من JavaScript إلى العميل. يساعد ذلك في تقليل الوقت المحدَّد لاحقًا في الصفحة، ما قد يؤدي أيضًا إلى انخفاض INP، لأنّ سلسلة التعليمات الرئيسية لا يتم حظرها بشكل متكرّر أثناء تحميل الصفحة. عندما يتم حظر سلسلة التعليمات الرئيسية بوتيرة أقل، ستتوفر فرص أكبر لتفاعلات المستخدمين بسرعة أكبر. وهذا أمر منطقي، لأنّه باستخدام العرض من جهة الخادم، فإنّك ترسل في الحقيقة نصوصًا وروابط إلى متصفّح المستخدم. وقد ينجح هذا الأسلوب في مجموعة كبيرة من حالات الأجهزة والشبكات، كما يفتح تحسينات مثيرة للاهتمام للمتصفح مثل تحليل المستندات لبث المستندات.

مع العرض من جهة الخادم، يقل احتمال أن ينتظر المستخدمون تشغيل JavaScript المرتبط بوحدة المعالجة المركزية (CPU) قبل أن يتمكنوا من استخدام موقعك الإلكتروني. حتى في الحالات التي لا يمكن فيها تجنُّب محتوى JavaScript من جهة خارجية، يمكن أن يمنحك استخدام العرض من جهة الخادم لتقليل تكاليف JavaScript الخاصة بالطرف الأول مزيدًا من الميزانية لبقية الباقي. ومع ذلك، هناك بعض المفاضلة المحتملة مع هذا المنهج، وهو أن إنشاء الصفحات على الخادم يستغرق بعض الوقت، ما قد ينتج عنه ارتفاع في مقياس TTFB.

ما إذا كان العرض من جهة الخادم كافيًا لتطبيقك يعتمد إلى حد كبير على نوع التجربة التي تنشئها. هناك جدل طويل حول التطبيقات الصحيحة للعرض من جهة الخادم مقابل العرض من جهة العميل، ولكن من المهم تذكّر أنّه يمكنك اختيار استخدام العرض من جهة الخادم لبعض الصفحات دون غيرها. وقد نجحت بعض المواقع الإلكترونية في تطبيق تقنيات العرض المختلط بنجاح. يعرض خادم Netflix صفحاته المقصودة الثابتة نسبيًا، مع الجلب المسبق لمحتوى JavaScript للصفحات ذات التفاعل الكبير، ما يمنح هذه الصفحات التي يعرضها العميل فرصة أفضل للتحميل بسرعة أكبر.

تتيح العديد من أطر العمل والمكتبات والبُنى الأساسية الحديثة إمكانية عرض التطبيق نفسه على كل من العميل والخادم. يمكن استخدام هذه الأساليب للعرض على جهة الخادم. ومع ذلك، من المهم ملاحظة أنّ البُنى الأساسية التي يحدث فيها العرض على كل من الخادم وعلى العميل هي فئة الحلول الخاصة بها ذات خصائص الأداء المختلفة والمقايضات المختلفة جدًا. يمكن للمستخدمين المتفاعلين استخدام واجهات برمجة تطبيقات DOM للخادم أو الحلول التي تم إنشاؤها فوقها، مثل Next.js للعرض من جهة الخادم. يمكن لمستخدمي Vue الاطّلاع على دليل العرض من جهة الخادم في Vue أو Nuxt. يحتوي Angular على Universal. وتستخدم معظم الحلول الشائعة شكلاً من أشكال ترطيب الماء، لذلك كن على دراية بالنهج المتبع قبل اختيار أداة.

العرض الثابت

يتم العرض الثابت في وقت الإصدار. يوفّر هذا الأسلوب سرعة عرض المحتوى على الصفحة، بالإضافة إلى انخفاض في مقياس TBT وINP، مع افتراض أنّ مقدار JavaScript من جهة العميل محدود. وعلى عكس العرض من جهة الخادم، ينجح هذا البرنامج أيضًا في تحقيق سرعة ثابتة FTFB، لأنّه لا يلزم إنشاء HTML للصفحة بشكل ديناميكي على الخادم. بشكل عام، يعني العرض الثابت إنتاج ملف HTML منفصل لكل عنوان URL في وقت مبكر. مع إنشاء استجابات HTML مسبقًا، يمكن نشر العروض الثابتة إلى شبكات توصيل محتوى (CDN) متعددة للاستفادة من التخزين المؤقت عند الحافة.

وتتوفّر حلول العرض الثابت بجميع الأشكال والأحجام. أدوات مثل Gatsby مصمّمة لمنح المطوّرين شعورًا بأنّه يتم عرض تطبيقاتهم بشكل ديناميكي بدلاً من إنشاؤها كخطوة إصدار. إنّ أدوات إنشاء المواقع الإلكترونية الثابتة، مثل 11ty وJekyll وMetalsmith، تستخدم طبيعة ثابتة، ما يوفّر أسلوبًا يستند إلى النماذج بشكل أكبر.

من سلبيات العرض الثابت أنه يجب إنشاء ملفات HTML فردية لكل عنوان URL ممكن. وقد يشكّل ذلك تحديًا أو حتى غير قابل للتنفيذ عندما لا يكون بإمكانك توقّع ما ستكون عناوين URL هذه مسبقًا أو المواقع الإلكترونية التي تضم عددًا كبيرًا من الصفحات الفريدة.

قد يكون المستخدمون المتفاعلون على دراية بلغة Gatsby أو Next.js static Export أو Navi، وكل ذلك يجعل من السهل جدًا التعامل مع صفحات المؤلفين باستخدام المكونات. مع ذلك، من المهم فهم الفرق بين العرض الثابت والعرض المُسبَق: تكون الصفحات الثابتة المعروضة تفاعلية بدون الحاجة إلى تنفيذ الكثير من محتوى JavaScript من جهة العميل، في حين يعمل العرض المُسبَق على تحسين سرعة عرض المحتوى على الصفحة (FCP) لتطبيق صفحة واحدة يجب تشغيله على جهاز العميل حتى تكون الصفحات تفاعلية حقًا.

وإذا لم تكن متأكدًا ممّا إذا كان أحد الحلول التي تبحث عنها هو العرض الثابت أو العرض المُسبَق، جرِّب إيقاف JavaScript وحمِّل الصفحة التي تريد اختبارها. بالنسبة إلى الصفحات المعروضة بشكل ثابت، ستظل معظم الوظائف متوفّرة بدون تفعيل JavaScript. بالنسبة إلى الصفحات المعروضة مُسبقًا، قد تتوفّر بعض الوظائف الأساسية مثل الروابط، ولكن معظم الصفحة ستكون غير نشِطة.

ومن الاختبارات المفيدة الأخرى استخدام تقييد الشبكة في "أدوات مطوري البرامج في Chrome" ومراقبة عدد رموز JavaScript التي تم تنزيلها قبل أن تصبح الصفحة تفاعلية. بشكل عام، يتطلّب العرض المُسبَق المزيد من محتوى JavaScript ليصبح تفاعليًا، كما تكون لغة JavaScript أكثر تعقيدًا من أسلوب التحسين التدريجي الذي يستخدمه العرض الثابت.

العرض من جهة الخادم مقابل العرض الثابت

لا يُعد العرض من جهة الخادم حلاً حاسمًا، إذ يمكن أن يصاحب طبيعته الديناميكية تكاليف حوسبة أساسية كبيرة. لا يتم تدفق العديد من حلول العرض من جهة الخادم في وقت مبكر، أو قد تؤدي إلى تأخير تحويل النص إلى كلام (TFB) أو مضاعفة البيانات التي يتم إرسالها (على سبيل المثال، الحالة المضمّنة التي تستخدمها JavaScript على البرنامج). في التفاعل، يمكن أن يكون 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 والبيانات المستخدمة للعرض في المستند الناتج. وعند إجراء ذلك بعناية، يؤدّي ذلك إلى تحقيق سرعة عرض أكبر محتوى سريع تمامًا مثل العرض من جهة الخادم، ثم "يتزايد" من خلال العرض مرّة أخرى على البرنامج باستخدام تقنية تُعرف باسم (re)Hydration. هذا حل فعال، ولكن يمكن أن يصاحبه عيوب كبيرة في الأداء.

ويتمثل الجانب السلبي الأساسي للعرض من جهة الخادم مع ميزة الجفاف في أنّه يمكن أن يكون له تأثير سلبي كبير على TBT وINP، حتى إذا أدى إلى تحسين سرعة عرض المحتوى على الصفحة. قد تبدو الصفحات المعروضة من جهة الخادم بطريقة مخادعة أنّها محمَّلة وتفاعلية، ولكن لا يمكنها الاستجابة للإدخال حتى يتم تنفيذ النصوص البرمجية من جهة العميل للمكوّنات وإرفاق معالِجات الأحداث. يمكن أن يستغرق هذا الإجراء ثوانٍ أو حتى دقائق على الأجهزة الجوّالة.

ربما عانيت هذا بنفسك — لفترة زمنية معينة بعد أن يبدو أن الصفحة قد حمَّلت، أو أن النقر أو النقر لا يؤدي إلى أي شيء. وسرعان ما يصبح هذا الأمر محبطًا، إذ يبقى المستخدم يتساءل عن سبب عدم حدوث أي شيء عند محاولة التفاعل مع الصفحة.

مشكلة في الجفاف: تطبيق واحد بسعر اثنين

غالبًا ما تكون مشاكل الجفاف أسوأ من التفاعل المتأخر بسبب JavaScript. لكي يتمكن برنامج JavaScript من جهة العميل من "التقاط" البيانات بدقة من حيث توقف الخادم بدون الحاجة إلى إعادة طلب جميع البيانات التي استخدمها الخادم لعرض رمز HTML الخاص به، تعمل حلول العرض الحالية من جهة الخادم بشكل عام على إنشاء تسلسل للاستجابة من تبعيات بيانات واجهة المستخدم في المستند كعلامات نص برمجي. يحتوي مستند HTML الناتج على مستوى عالٍ من التكرار:

كما ترى، يعرض الخادم وصفًا لواجهة المستخدم في التطبيق استجابةً لطلب تنقّل، ولكنّه يعرض أيضًا بيانات المصدر المستخدَمة لإنشاء واجهة المستخدم تلك، ونسخة كاملة من عملية تنفيذ واجهة المستخدم التي يتم تشغيلها بعد ذلك على جهاز العميل. لا تصبح واجهة المستخدم هذه تفاعلية إلا بعد انتهاء bundle.js من التحميل والتنفيذ.

تشير مقاييس الأداء التي تم جمعها من مواقع إلكترونية حقيقية باستخدام العرض من جهة الخادم ومعالجة الجفاف إلى عدم تشجيع استخدامه. في النهاية، يرجع السبب إلى تجربة المستخدم: من السهل للغاية ترك المستخدمين في "وادي صعب"، حيث يبدو التفاعل مفقودًا على الرغم من ظهور الصفحة جاهزة.

ومع ذلك، ثمة أمل في العرض من جهة الخادم باستخدام ميزة معالجة الجفاف. على المدى القصير، إنّ استخدام العرض من جهة الخادم فقط للمحتوى القابل للتخزين المؤقت بشكل كبير يمكن أن يؤدي إلى تقليل حجم TTFB، ما يؤدي إلى نتائج مشابهة للعرض المُسبَق. قد يكون شرب السوائل بشكل تدريجي أو بشكل تدريجي أو جزئي هو العامل الأساسي لجعل هذه التقنية أكثر قابلية للتطبيق في المستقبل.

العرض من جهة الخادم والإملاء التدريجي

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

يسمح لك العرض المباشر من جهة الخادم بإرسال HTML في أجزاء يمكن للمتصفّح عرضها تدريجيًا عند تلقّيها. ويمكن أن يؤدي ذلك إلى سرعة عرض المحتوى على الصفحة، لأنّ الترميز يصل إلى المستخدمين بشكل أسرع. في التفاعل، تكون عمليات البث غير المتزامنة في [renderToPipeableStream()]، مقارنةً بالترميز renderToString() المتزامن، تتيح التعامل مع الضغط العكسي بشكل جيد.

ومن المفيد أيضًا التفكير في عملية إمهاء السوائل التدريجي، وقد توصّلت إليها React. ومن خلال هذه الطريقة، يتم "تشغيل" الأجزاء الفردية من التطبيق الذي يعرضه الخادم بمرور الوقت، وذلك بدلاً من الأسلوب الشائع الحالي لإعداد التطبيق بأكمله في آنٍ واحد. ويمكن أن يساعد ذلك في تقليل مقدار محتوى JavaScript المطلوب لجعل الصفحات تفاعلية، حيث يمكن تأجيل الترقية من جهة العميل للأجزاء ذات الأولوية المنخفضة من الصفحة لمنع حظر سلسلة التعليمات الرئيسية، ما يسمح بحدوث تفاعلات المستخدم في وقت أقرب بعد أن يبدأ المستخدم تشغيلها.

يمكن أن تساعد عملية إعادة الإماهة التدريجي أيضًا في تجنّب إحدى أكثر المشاكل شيوعًا المتعلّقة بالعرض من جهة الخادم، حيث يتم تدمير شجرة نموذج العناصر في المستند (DOM) التي يعرضها الخادم ثم إعادة تركيبها فورًا، وغالبًا ما يكون ذلك بسبب أنّ العرض المتزامن من جهة العميل يتطلّب بيانات لم تكن جاهزة بعد، وربما تكون في انتظار حلّ Promise.

الجفاف الجزئي

لقد ثبت صعوبة تنفيذ عملية الجفاف الجزئية. يمثّل هذا المنهج امتدادًا لفكرة الجفاف التدريجي، حيث يتم تحليل القطع الفردية (المكوّنات/العناصر/الأشجار) المطلوب تجفيفها تدريجيًا، كما يتم تحديد العناصر التي لا يتفاعل معها التفاعل أو لا يتفاعل معها. وفي كل جزء من هذه الأجزاء الثابتة غالبًا، يتم تحويل رمز JavaScript المقابل إلى مراجع غير صالحة ووظائف زخرفية، ما يقلل من تأثيرها من جهة العميل إلى الصفر تقريبًا.

يأتي منهج الترطيب الجزئي مع مشاكله وحلول وسط لها. وهي تطرح بعض التحديات المثيرة للاهتمام في ما يتعلق بالتخزين المؤقت، كما أن التنقل من جهة العميل يعني أنه لا يمكننا افتراض أن ترميز HTML المعروض من قِبل الخادم للأجزاء الخاملة من التطبيق سيكون متاحًا بدون تحميل الصفحة بالكامل.

عرض ثلاثي الشكل

إذا كان عاملو الخدمة خيارًا مناسبًا لك، قد يكون من الملائم أيضًا استخدام العرض بتنسيق "ثلاثية الشكل". وهو أسلوب يمكنك من خلاله استخدام العرض من جهة الخادم للبث لعمليات الانتقال الأولية/غير JavaScript، ثم توجيه عامل الخدمة إلى تفعيل عرض HTML لعمليات التنقّل بعد تثبيته. يمكن أن يؤدي ذلك إلى الحفاظ على حداثة المكونات والنماذج المخزّنة مؤقتًا، وتفعيل عمليات التنقّل بأسلوب "SPA" لعرض طرق عرض جديدة في الجلسة نفسها. ويعمل هذا الأسلوب بشكل أفضل عندما يمكنك مشاركة رمز النموذج والتوجيه نفسه بين الخادم وصفحة العميل وعامل الخدمة.

اعتبارات تحسين محركات البحث

غالبًا ما تؤثر الفِرق في تأثير تحسين محركات البحث عند اختيار استراتيجية للعرض على الويب. غالبًا ما يتم اختيار العرض من جهة الخادم لتقديم تجربة "شكل كامل" يمكن لبرامج الزحف تفسيرها بسهولة. قد تفهم برامج الزحف لغة JavaScript، ولكن هناك غالبًا قيود يجب أن تكون على دراية بطريقة عرضها. قد يُجدي العرض من جهة العميل، ولكن في أغلب الأحيان لا يحدث بدون إجراء اختبارات إضافية وجهد إضافي. وفي الآونة الأخيرة، أصبح العرض الديناميكي خيارًا يجب أخذه في الاعتبار إذا كانت البنية الأساسية تعتمد بشكل كبير على JavaScript من جهة العميل.

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

ملخص

وعند اتخاذ قرار بشأن طريقة العرض، عليك قياس المؤثِّرات السلبية وفهمها. فكِّر في ما إذا كان العرض الثابت أو العرض من جهة الخادم يتيح لك تحقيق أقصى استفادة من العرض. لا مانع من نشر محتوى HTML غالبًا باستخدام أقل قدر من JavaScript للحصول على تجربة تفاعلية. في ما يلي مخطّط معلومات بياني مفيد يوضح طيف الخادم-العميل:

المساهمون

نتوجّه بالشكر إلى الجميع على مراجعاتهم وأفكارهم المُلهمة:

و"جيفري بوسنيك" و"حسين دجيرديه" و"شوبي بانيكر" و"كريس هاريلسون" و"سيباستيان ماركباغ"