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

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

Jeremy Wagner

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

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

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

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

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

1. يرسل المتصفّح طلب انتقال إلى عنوان URL المقدَّم.
2. يستجيب الخادم بعرض HTML في أجزاء.

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

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

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

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

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

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

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

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

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

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

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

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

بغض النظر عن السبب، إليك بعض الأسباب المحتمَلة التي يمكنك استكشافها للمساعدة في استعادة الأداء الطبيعي.

تقديم أكبر قدر ممكن من صفحات HTML من الخادم

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

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

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

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

الصورة الرئيسية من Unsplash، لأحد أعمال Maik Jonietz.