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

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

Jeremy Wagner

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

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

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

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

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

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)، وبالتالي يرتبط هذا المقياس ارتباطًا وثيقًا بمقياس INP.

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

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

تقييد مقدار عُقد DOM التي تم إنشاؤها على العميل

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

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

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

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

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