عرض HTML والتفاعل من جهة العميل

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

جيريمي واغنر

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

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

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

كيفية عرض المتصفِّح لصفحات HTML التي يوفّرها الخادم

يتضمن نمط التنقل المستخدم في عمليات تحميل الصفحات التقليدية تلقي HTML من الخادم في كل عملية تنقل. في حال إدخال عنوان URL في شريط العناوين في المتصفّح أو النقر على رابط في MPA، ستحدث سلسلة الأحداث التالية:

1. يرسل المتصفّح طلب التنقّل لعنوان URL الذي تم تقديمه.
2. يستجيب الخادم باستخدام HTML في المقاطع.

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

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

ما النصيحة الرئيسية؟ عند بث محتوى HTML من الخادم، يمكنك الحصول على تحليل وعرض تدريجي لـ HTML، والحصول على نتائج تلقائية لسلسلة التعليمات الرئيسية مجانًا. ولن تحصل على ذلك عند استخدام العرض من جهة العميل.

كيفية عرض المتصفِّح لمحتوى HTML المقدَّم من JavaScript

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

قد يحدث العرض من جهة العميل أيضًا في غير SPA في حالات محدودة أكثر حيث تتم إضافة HTML ديناميكيًا إلى DOM من خلال JavaScript.

هناك بعض الطرق الشائعة لإنشاء HTML أو الإضافة إلى DOM من خلال JavaScript:

1. تسمح لك السمة innerHTML بضبط المحتوى في عنصر حالي من خلال سلسلة يحلّلها المتصفّح في نموذج العناصر في المستند (DOM).
2. تسمح لك طريقة document.createElement بإنشاء عناصر جديدة لإضافتها إلى DOM بدون استخدام أي تحليل HTML في المتصفّح.
3. تسمح لك الطريقة document.write بكتابة HTML في المستند (ويحلّله المتصفّح تمامًا كما في الطريقة رقم 1). ومع ذلك، لعدة أسباب، لا ننصح بشدة باستخدام document.write.

يمكن أن تكون العواقب المترتبة عن إنشاء HTML/DOM باستخدام JavaScript من جهة العميل كبيرة:

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

الإجراءات التي يمكنك اتّخاذها بشأن تأثير العرض من جهة العميل في الأداء

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

مهما كان السبب، إليك بعض الأسباب المحتمَلة التي يمكنك استكشافها لمساعدتك في عودة الأمور إلى مسارها الصحيح.

تقديم أكبر قدر ممكن من محتوى HTML من الخادم

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

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

• بالنسبة إلى React، عليك الاستفادة من Server DOM API لعرض ترميز HTML على الخادم. ولكن عليك أن تعرف أنّ الطريقة التقليدية للعرض من جهة الخادم تستخدم أسلوبًا متزامنًا، ما قد يؤدي إلى زيادة مدة الوقت المستغرق حتى أول بايت (TTFB)، بالإضافة إلى مقاييس لاحقة مثل سرعة عرض أول محتوى مرئي (FCP) وسرعة عرض أكبر جزء من المحتوى على الصفحة (LCP). حيثما أمكن، تأكّد من أنك تستخدم واجهات برمجة تطبيقات البث لـ Node.js أو أوقات تشغيل JavaScript أخرى حتى يتمكن الخادم من بدء بث HTML إلى المتصفح في أقرب وقت ممكن. Next.js، إطار عمل قائم على التفاعل، يوفّر العديد من أفضل الممارسات تلقائيًا. بالإضافة إلى عرض HTML تلقائيًا على الخادم، يمكن أيضًا أن يُنشئ HTML بشكل ثابت للصفحات التي لا تتغير بناءً على سياق المستخدم (مثل المصادقة).
• تُجري Vue أيضًا العرض من جهة العميل تلقائيًا. ومع ذلك، يمكن لتطبيق Vue أيضًا عرض رمز HTML للمكوِّن على الخادم، كما هو الحال في React. يمكنك إما الاستفادة من واجهات برمجة التطبيقات من جهة الخادم هذه متى أمكن، أو استخدام التجريد على مستوى أعلى لمشروع Vue لتسهيل تطبيق أفضل الممارسات.
• يعرض Svelte ترميز HTML على الخادم افتراضيًا، ومع ذلك إذا كان رمز المكون يتطلب الوصول إلى مساحات الاسم الحصرية للمتصفح (window، على سبيل المثال)، قد لا تتمكن من عرض ترميز HTML لهذا المكون على الخادم. استكشِف طرقًا بديلة كلما أمكن ذلك لكي لا تتسبب في عرض غير ضروري من جهة العميل. SvelteKit - وهو اختصار لـ Svelte مثل Next.js هو React - يضم العديد من أفضل الممارسات في مشاريع Svelte بقدر الإمكان، بحيث يمكنك تجنب الصعوبات المحتملة في المشروعات التي تستخدم Svelte وحدها.

الحد من عدد عُقد DOM التي يتم إنشاؤها في العميل

عندما تكون نماذج DOM كبيرة، يزيد وقت المعالجة المطلوب لعرضها. سواء كان موقعك الإلكتروني عبارة عن SPA كامل، أو يُدخِل عُقد جديدة في نموذج كائن المستند (DOM) الحالي كنتيجة تفاعل مع MPA، ننصحك بإبقاء نماذج DOM هذه صغيرة قدر الإمكان. سيساعد ذلك في تقليل الجهد المطلوب أثناء العرض من جهة العميل لعرض HTML هذا، ونأمل أن يساعد ذلك في إبقاء مقياس INP لموقعك الإلكتروني منخفضًا.

مراعاة بنية مشغّل خدمات البث

هذه التقنية متقدّمة - قد لا تعمل بسهولة مع كل حالة استخدام - ولكنّها تقنية يمكنها تحويل موافقة جهات متعددة إلى موقع إلكتروني يبدو أنّه يتم تحميله على الفور عندما ينتقل المستخدمون من صفحة إلى أخرى. يمكنك استخدام أحد مشغّلي الخدمات لتخزين الأجزاء الثابتة من موقعك الإلكتروني بشكل مسبق في CacheStorage أثناء استخدام ReadableStream API لجلب بقية محتوى HTML للصفحة من الخادم.

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

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

الخلاصة

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

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

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

صورة رئيسية من UnLaunch، للفنان ماك جونيتز.