النقاط الرئيسية في اختيار SSR والمسؤولية الاجتماعية للشركات والعرض المتدفق

تناقش العديد من الفرق SSR، والمسؤولية الاجتماعية للشركات، والعرض المتدفق، وأول ما يسألون عنه هو الأداء.

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

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

ما يفسد الصفحة حقًا ليس عادةً طريقة العرض نفسها.

لقد رأيت العديد من الصفحات، وكانت في البداية مجرد صفحة تفاصيل محتوى عادية جدًا:

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

حتى هذه اللحظة، يمكن تبرير كل قرار.

المشكلة هي أنه بعد تجميع هذه القرارات معًا، هناك في الواقع أربعة مسارات على الأقل “لوصول البيانات إلى المشهد” على الصفحة:

1. البيانات التي تم الحصول عليها أثناء العرض الأول للخادم؛
2. البيانات التي يتم جلبها عندما يكون المتصفح رطبًا؛
3. بعد تثبيت العميل، يقوم بإعادة إرسال الطلب للحصول على البيانات الجديدة؛
4. البيانات المشتقة التي يتم تحديثها محليًا بعد تفاعل المستخدم.

إذا لم تكن هناك أولوية واضحة بين هذه المسارات الأربعة، فستبدأ الصفحة في ظهور بعض المشكلات الغريبة المألوفة:

• ما تراه في HTML هو السعر القديم، وسوف يتحول إلى السعر الجديد بعد الترطيب؛
• يظهر عرض الشاشة الأول “مفضل”، ولكن بعد تولي العميل المسؤولية، يتغير مرة أخرى إلى “غير مفضل”؛
• الكتلة الموصى بها متأخرة بخطوة واحدة، ويتم دفع الصفحة المحدثة جزئيًا إلى القيمة القديمة؛
• عندما أبلغ الخادم عن خطأ، أظهر مجموعة واحدة من التفاصيل، وبعد إعادة محاولة العميل، عرض مجموعة أخرى من التفاصيل.

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

يحل SSR مشكلة رؤية الشاشة الأولى، ولكنه لا يحل مصدر حقيقة البيانات تلقائيًا.

من المواقف الشائعة التفكير في SSR على أنه “أخرج الصفحة الصحيحة أولاً”، لكن هذه الجملة صحيحة فقط في ظل فرضية ضيقة جدًا: ** البيانات التي حصل عليها الخادم هي البيانات النهائية التي يجب على المستخدم رؤيتها حقًا هذه المرة. **

في الواقع، هذه الفرضية لا تكون صحيحة في كثير من الأحيان.

على سبيل المثال، يتم عرض معلومات المنتج على الشاشة الرئيسية لصفحة التفاصيل بواسطة الخادم، ولكن المعلومات التالية لا يتم عرضها غالبًا:

• ما إذا كان المستخدم قد قام بالنقر على المفضلة؛
• ما هي مجموعة التوصيات التي تم الوصول إليها حاليًا في المجموعة التجريبية؟
• المخزون ذات الصلة جغرافيا.
• الأسعار أو الحقوق المتعلقة بتسجيل الدخول؛
• اكتملت التحديثات غير المتزامنة بعد تثبيت الصفحة مباشرةً.

في هذا الوقت، لا يمكن لـ SSR سوى ضمان “إصدار نسخة واحدة أولاً لعرض النتائج”، ولكن لا يمكن ضمان أن تكون هذه النسخة من النتائج هي الحقيقة النهائية للصفحة بأكملها.

بمجرد أن يطلب الفريق أيضًا أن “يقوم الخادم بإنتاج HTML أولاً، ويتولى العميل المسؤولية ثم يضيف التخصيص”، فسوف ينقسم النظام بشكل طبيعي إلى مجموعتين من الأحكام:

• يحدد الخادم الشكل الذي يجب أن تبدو عليه الصفحة أولاً؛
• يحدد العميل الشكل الذي يجب أن تبدو عليه الصفحة في النهاية.

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

لذا فإن ما يجب أن يطرحه إصلاح القطاع الأمني (SSR) حقًا هو:

• إلى متى يمكن أن تظل البيانات التي يخرجها الخادم محدثة هذه المرة؛
• ما هي الحقول المسموح بتغطيتها بعد الترطيب؟
• ما هي الحقول التي يجب أن تعتمد على أحدث النتائج من العميل؟
• هل الفشل من جانب الخادم والفشل من جانب العميل هو نفس مجموعة الدلالات؟

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

المشكلة الحقيقية في المسؤولية الاجتماعية للشركات هي أنه من السهل كتابة دلالات التحديث بشكل فضفاض

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

تتم تهيئة الصفحة وسحبها مرة واحدة؛ اقطع اللسان واسحبه مرة واحدة؛ اسحب تركيز النافذة مرة أخرى؛ بعد نجاح عملية المستخدم، اسحبه مرة أخرى بسهولة؛ تقوم مكتبة الطلبات تلقائيًا بإعادة المحاولة مرة أخرى.

يبدو الكود طبيعيًا، لكن التأثير النهائي قد يكون:

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

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

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

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

التكلفة الأكثر سهولة في تقدير تكلفة عرض البث هي تكلفة تفسير الحالة الناتجة عن “وصول الدفعة”

يمكن القول بسهولة أن عرض البث المباشر في العامين الماضيين يمثل فائدة صافية:

• الهيكل العظمي يصل في وقت سابق؛
• المحتوى الرئيسي يخرج أولا؛
• لا يهم إذا كانت الكتلة الثانوية لاحقة؛
• تجربة المستخدم ستكون أكثر سلاسة.

هذه كلها صحيحة. ولكن لها سعرًا نادرًا ما يتم أخذه في الاعتبار بجدية في مراجعات الخطة: لم تعد الصفحة ** تحتوي على حالتين فقط: “وصل” أو “لم يصل”، ولكن بدلاً من ذلك تحتوي على كتل متعددة تصل على دفعات، وأخطاء على دفعات، وعمليات تراجع على دفعات. **

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

• ما إذا كان إصدار البيانات الرئيسية الذي تعتمد عليه كتلة معينة متأخرة الوصول وإصدار الشاشة الأول متماثلان؛
• عندما تنجح الكتلة الرئيسية وتفشل الكتلة الثانوية، ما إذا كان لا يزال من الممكن اعتبار الصفحة بأكملها ناجحة؛
• ما إذا كان المحتوى الذي تم إخراجه بالفعل في الدفق يمكن قلبه بواسطة الأجزاء اللاحقة؛
• لقد بدأ المستخدم العملية بالفعل بعد وصول جزء الصفحة الأولى. هل ستحل الأجزاء اللاحقة محل نتائج التفاعل؟

هذه التكلفة ليست مجردة. لقد رأيت صفحة تعرض SSRs المعلومات الرئيسية وتضيف التوصيات ذات الصلة وحقوق المستخدم بتنسيق دفق. اتضح أن أصعب خطأ في استكشاف الأخطاء وإصلاحها عبر الإنترنت هو “أن نسخة الحقوق التي شاهدها بعض المستخدمين سيتم تبديلها مرتين خلال ثانيتين.”

وأخيراً تم التأكد من أنه:

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

تبدو المجموعات الثلاث من المصادر منطقية، ولكن عند تجميعها معًا، لا تبدو الصفحة وكأنها نظام.

ما يجب تصميمه أولاً هو خط البيانات الرئيسي للصفحة.

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

ما يسمى بخط البيانات الرئيسي هو تحديد الأمور التالية مسبقًا:

1. ما هي البيانات التي تمثل خط الأساس الأول للشاشة؟

عند ظهور HTML للشاشة الأولى، يجب تحديد الحقول التي يمكن بالفعل اعتبارها قيمًا حقيقية قابلة للعرض وأيها مجرد نتائج نائبة بوضوح.

على سبيل المثال:

• يمكن أن يستند نص المقال إلى نتائج SSR؛
• لا يمكن تحديد حالة إعجاب المستخدم إلا من خلال طلب حالة تسجيل الدخول الخاص بالعميل؛
• تم الإعلان عن الكتلة الموصى بها منذ البداية على أنها “إكمال غير متزامن، ولا تشارك في القيمة الحقيقية للشاشة الأولى”.

طالما لم يتم تعريف هذه الطبقة، فإن كل جولة لاحقة من الطلبات سوف تتنافس مع الجولة السابقة للحصول على حقوق التفسير.

2. ما هي الحقول المسموح بالكتابة فوقها، وما هي الحقول التي لا يمكن ملؤها إلا بشكل تدريجي؟

تتم كتابة العديد من الصفحات بشكل مزدحم لأن جميع البيانات التي تأتي لاحقًا يتم تعيينها بشكل افتراضي على “الأحدث والأكثر جدارة بالثقة”. ليس حقيقيًا.

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

إذا لم تكن هناك قواعد تجاوز على مستوى الحقل، فكلما زاد عدد الطلبات اللاحقة، زاد احتمال أن تحل القيمة القديمة محل القيمة الجديدة.

3. هل الفشل من جانب الخادم والفشل من جانب العميل هما نفس الدلالات؟

يتم التغاضي عن هذا بسهولة.

في بعض الأنظمة، عندما يفشل طلب الخادم، سيتم إرجاعه مباشرةً إلى الوحدة الافتراضية؛ عندما يفشل العميل، يتم عرض زر إعادة المحاولة لخطأ مستقل. النتيجة التي يراها المستخدم هي:

• عند تحديث الصفحة، يختفي هذا المحتوى بهدوء؛
• بعد تثبيت الصفحة، يظهر هذا المحتوى فجأة بحالة خطأ.

وذلك لأن النظام ليس لديه تفسير موحد لـ “الفشل”.

في نفس الكتلة، إذا كانت دلالات فشل الخادم والعميل مختلفة، فسيكون من الصعب الإجابة عليها عند استكشاف الأخطاء وإصلاحها: هل هذا تخفيض عادي أم عرض غير طبيعي؟

سوء فهم شائع: اعتبار “الحصول على أحدث البيانات مرة أخرى” بمثابة تأمين

عندما تواجه العديد من الفرق مشاكل في الاتساق، يكون رد فعلهم الأول هو “بعد ذلك سيقوم العميل بسحب أحدث البيانات مرة أخرى.”

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

الرابط الفاشل الأكثر شيوعًا هو هذا:

1. يأخذ الخادم أولاً بيانات الإصدار A ويعرض الشاشة الأولى؛
2. بعد تثبيت المتصفح، يقوم العميل تلقائيًا بسحب الإصدار B؛
3. نقر المستخدم على الفور على المجموعة، وتغير التحديث المحلي المتفائل إلى C؛
4. يطلب الإصدار B إرجاعًا متأخرًا ويدفع C للخلف؛
5. ارجع إلى واجهة المجموعة وستتغير الصفحة مرة أخرى إلى D.

من الناحية الفنية، كل خطوة “صحيحة”.

لكن بالنسبة للمستخدمين، غيرت الصفحة الإجابات أربع مرات في ثلاث ثوانٍ. في هذه المرحلة، من الصعب تحديد ما إذا كان جوهر المشكلة هو SSR أو CSR، لأن المشكلة الحقيقية هي: **لا تحدد الصفحة الأولوية التي يجب إعطاؤها للكتابة التفاعلية أو التحديث الكامل. **

مثال مضاد: ليست كل الصفحات تستحق SSR أو البث المباشر

هناك أيضًا سوء فهم حقيقي جدًا، وهو اعتبار استراتيجية العرض قائمة بقدرات النظام الأساسي.

إذا كان الإطار يدعم SSR، فإنه يميل إلى أن يكون SSR على مستوى الموقع؛ دعم عرض البث والبدء في إزالة الكتل؛ إذا كنت قلقًا بشأن تحسين محركات البحث (SEO)، فاستخدم جانب الخادم لجميع صفحات التفاصيل بشكل افتراضي؛ إذا كنت قلقًا بشأن البطء، فأضف طبقة أخرى من ذاكرة التخزين المؤقت للعميل.

وأخيرا، ارتفعت تكاليف الترجمة الفورية للنظام بشكل كبير.

بعض الصفحات لا تستحق ببساطة استراتيجيات عرض معقدة:

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

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

على العكس من ذلك، تعد صفحات التفاصيل القائمة على المحتوى، والصفحات المقصودة العامة، وصفحات المعلومات ذات البنية المستقرة أكثر ملاءمة لتحقيق أقصى استفادة من SSR أو إيرادات البث. لا تزال الفرضية هي ما إذا كان من الممكن فصل حدود بيانات الصفحة بشكل واضح **.

لاختيار طريقة ما، انظر إلى ثلاثة أشياء أولاً

إذا كنت تريد حقًا الحكم بين SSR، وCSR، والعرض المتدفق، فإنني أوصي بقراءة هذه الأشياء الثلاثة أولاً بدلاً من قراءة الصفحة الترويجية لإطار العمل أولاً.

أولاً، تحقق مما إذا كان المحتوى الموجود على الشاشة الأولى له قيمة حقيقية ثابتة.

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

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

ثانيًا، تحقق مما إذا كانت الصفحة تسمح بشرح الدفعة

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

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

ثالثًا، معرفة ما إذا كانت الكتابة التفاعلية ستتعارض مع مسار التحديث.

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

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

الحدود القابلة للتطبيق

تتناول هذه المقالة بشكل رئيسي:- متابعة تحسين محركات البحث (SEO) والسرعة الفائقة وصفحات الويب المخصصة في نفس الوقت؛

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

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

ملخص

إن SSR وCSR والعرض المتدفق ليست خاطئة. الخطأ هو اعتبارها مفاتيح أداء خالصة.

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

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

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