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

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

Jeremy Wagner

Philip Walton

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

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

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

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

معرفة سبب انخفاض معدّل INP

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

العثور على التفاعلات البطيئة في الميدان

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

إذا لم تكن تعتمد على موفّر خدمة RUM للحصول على بيانات الحقول، ينصحك دليل بيانات حقل INP باستخدام "تقرير تجربة المستخدم على Chrome" (CrUX) من خلال "إحصاءات PageSpeed" للمساعدة في سد الثغرات. CrUX هي مجموعة البيانات الرسمية لبرنامج "مؤشرات أداء الويب الأساسية"، وتقدّم ملخّصًا عالي المستوى للمقاييس لملايين المواقع الإلكترونية، بما في ذلك مقياس "مدى استجابة الصفحة لتفاعلات المستخدم". ومع ذلك، لا تقدّم 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 الكبير مشكلة في حالتَين:

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.