تحسين التفاعل مع سرعة عرض المحتوى على الصفحة التالية

تعرَّف على كيفية تحسين مقياس "مدة عرض الاستجابة لتفاعل المستخدم" لموقعك الإلكتروني.

Jeremy Wagner

Philip Walton

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

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

استنادًا إلى الموقع الإلكتروني، قد تكون هناك تفاعلات قليلة أو معدومة، مثل الصفحات التي تتضمّن نصوصًا وصورًا في الغالب مع عناصر تفاعلية قليلة أو معدومة. وفي ما يتعلّق بالمواقع الإلكترونية، مثل محرّرات النصوص أو الألعاب، يمكن أن يكون هناك مئات أو حتى آلاف التفاعلات. وفي كلتا الحالتَين، تكون تجربة المستخدم في خطر عندما يكون معدّل INP مرتفعًا.

يستغرق تحسين INP بعض الوقت والجهد، ولكنّ المكافأة هي تجربة مستخدم أفضل. في هذا الدليل، سيتم استكشاف مسار لتحسين INP.

معرفة سبب ضعف مؤشر INP

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

العثور على التفاعلات البطيئة في الحقل

من الأفضل أن تبدأ رحلتك في تحسين INP من خلال بيانات الحقل. في أفضل حالاتها، لن تمنحك بيانات الحقول من مقدّم خدمة "مراقبة المستخدِمين الفعليين" (RUM) قيمة INP للصفحة فحسب، بل ستمنحك أيضًا بيانات سياقية تُبرز التفاعل المحدّد المسؤول عن قيمة INP نفسها، سواء حدث التفاعل أثناء تحميل الصفحة أو بعدها، ونوع التفاعل (النقر أو الضغط على مفتاح أو النقر)، ومعلومات قيّمة أخرى.

إذا كنت لا تعتمد على مقدّم خدمة RUM للحصول على بيانات الاستخدام الفعلي، ينصحك دليل بيانات الاستخدام الفعلي في تجارب المستخدمين باستخدام "تقرير تجربة مستخدمي Chrome" (CrUX) من خلال "إحصاءات PageSpeed" للمساعدة في سدّ الفجوات. CrUX هي مجموعة البيانات الرسمية لبرنامج "مؤشرات أداء الويب الأساسية"، وتقدّم ملخّصًا عالي المستوى للمقاييس لملايين المواقع الإلكترونية، بما في ذلك مقياس "مدى استجابة الصفحة لتفاعلات المستخدم" (INP). ومع ذلك، لا يوفّر CrUX غالبًا البيانات السياقية التي يمكنك الحصول عليها من موفّر RUM لمساعدتك في تحليل المشاكل. لهذا السبب، ما زلنا نقترح على المواقع الإلكترونية استخدام موفِّر RUM متى أمكن ذلك، أو تنفيذ حلّ RUM الخاص بها لدعم ما هو متاح في CrUX.

تشخيص التفاعلات البطيئة في المختبر

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

تحسين التفاعلات

بعد تحديد تفاعل بطيء والقدرة على إعادة إنتاجه يدويًا في المختبر، تكون الخطوة التالية هي تحسينه. يمكن تقسيم التفاعلات إلى ثلاث مراحل:

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

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

تحديد مهلة الاستجابة للإدخال وتقليلها

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

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

العلاقة بين تقييم النصوص والمهام الطويلة أثناء بدء التشغيل

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

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

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

تحسين عمليات استدعاء الأحداث

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

التنازل عن سلسلة التعليمات الرئيسية بشكل متكرر

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

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

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

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

التراجع للسماح ببدء عملية التقديم في وقت أقرب

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

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

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

1. عدِّل مربّع النص بما كتبه المستخدم وطبِّق أي تنسيق مطلوب.
2. عدِّل الجزء من واجهة المستخدم الذي يعرض عدد الكلمات الحالي.
3. يمكنك تنفيذ منطق للتحقّق من الأخطاء الإملائية.
4. حفظ أحدث التغييرات (إما على الجهاز أو في قاعدة بيانات عن بُعد)

قد يبدو الرمز البرمجي لتنفيذ ذلك على النحو التالي:

textBox.addEventListener('input', (inputEvent) => {
  // Update the UI immediately, so the changes the user made
  // are visible as soon as the next frame is presented.
  updateTextBox(inputEvent);

  // Use `setTimeout` to defer all other work until at least the next
  // frame by queuing a task in a `requestAnimationFrame()` callback.
  requestAnimationFrame(() => {
    setTimeout(() => {
      const text = textBox.textContent;
      updateWordCount(text);
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

يوضّح الرسم البياني التالي كيف يمكن أن يؤدي تأجيل أي تعديلات غير ضرورية إلى أن تتم بعد اللقطة التالية إلى تقليل مدة المعالجة وبالتالي وقت الاستجابة الإجمالي للتفاعل.

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

تجنُّب تغييرات التصميم المفاجئة

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

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

تقليل وقت استجابة العرض

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

تقليل حجم DOM

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

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

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

استخدام content-visibility لعرض العناصر التي لا تظهر على الشاشة بشكل بطيء

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

الانتباه إلى تكاليف الأداء عند عرض صفحات HTML باستخدام JavaScript

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

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

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

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

الخاتمة

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

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

الصورة الرئيسية من Unsplash، لأحد أعمال ديفيد بيسنوي وتم تعديلها بما يتوافق مع ترخيص Unsplash.