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

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

آدي عثمانية
آدي عثمانية

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

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

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

المصطلحات

العرض

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

الأداء

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

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

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

مخطّط يوضّح العرض من جهة الخادم وتنفيذ JavaScript الذي يؤثر في FCP وTTI.

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

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

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

العرض الثابت

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

مخطّط بياني يُظهر العرض الثابت وتنفيذ JavaScript الاختياري الذي يؤثر في FCP وTTI.

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

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

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

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

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

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

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

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

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

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

العرض من جهة العميل

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

قد يكون من الصعب الحصول على العرض من جهة العميل والحفاظ عليه بسرعة على الأجهزة الجوّالة. إذا لم يتم بذل الكثير من الجهد، يمكن أن يتناسب العرض من جهة العميل مع أداء العرض الخالص من جهة الخادم، مع الحفاظ على ميزانية محدودة على JavaScript وتقديم قيمة في أقل عدد ممكن من عمليات الإرسال والاستقبال. يمكن تسليم النصوص البرمجية والبيانات المهمة بشكل أسرع باستخدام <link rel=preload>، ما يجعل المحلل يعمل من أجلك في وقت أقرب. تستحق أنماط مثل PRPL أيضًا التقييم لضمان أن عمليات التنقل الأولية واللاحقة تظهر بشكل فوري.

مخطّط بياني يعرض العرض من جهة العميل ويؤثر في سرعة عرض المحتوى على الصفحة ومؤشر جودة الهواء (TI)

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

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

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

الجمع بين العرض من جهة الخادم والعرض من جهة العميل عن طريق عملية إعادة الإماهة

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

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

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

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

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

مستند HTML يحتوي على واجهة مستخدم متسلسلة
وبيانات مضمنة ونص برمجي package.js

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

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

رسم بياني يوضّح عرض العميل بشكل سلبي، ما يؤثر سلبًا في TTI.

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

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

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

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

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

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

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

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

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

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

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

رسم بياني لعرض Trisomorphic يُظهر متصفّحًا ومشغّل خدمات يتواصلان مع الخادم

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

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

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

لقطة شاشة لواجهة مستخدم فحص التوافق مع الأجهزة الجوّالة.

ملخص

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

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

المساهمون

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

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