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

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

Jeremy Wagner

Philip Walton

Barry Pollard

تاريخ النشر: 19 مايو 2023، تاريخ آخر تعديل: 2 سبتمبر 2025

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

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

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

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

معرفة سبب ضعف مقياس INP

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

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

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

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

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

تقليل مهلة عرض النتيجة

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

تصغير حجم عناصر DOM

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

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

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

استخدام content-visibility لعرض العناصر خارج الشاشة بشكل غير متزامن

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

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

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

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

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

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

الخاتمة

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

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

الصورة الرئيسية من Unsplash، من إعداد David Pisnoy وتم تعديلها وفقًا لترخيص Unsplash.