تعرَّف على كيفية تحسين مقياس "مدى استجابة الصفحة لتفاعلات المستخدم" لموقعك الإلكتروني.
تاريخ النشر: 19 مايو 2023، تاريخ آخر تعديل: 2 سبتمبر 2025
مدى استجابة الصفحة لتفاعلات المستخدم (INP) هو مقياس ثابت من مؤشرات أداء الويب الأساسية يقيّم مدى استجابة الصفحة بشكل عام لتفاعلات المستخدم من خلال رصد وقت الاستجابة لجميع التفاعلات المؤهلة التي تحدث طوال الفترة التي يزور فيها المستخدم الصفحة. تمثّل قيمة INP النهائية أطول تفاعل تم رصده (مع تجاهل القيم الشاذة أحيانًا).
لتقديم تجربة جيدة للمستخدم، يجب أن تسعى المواقع الإلكترونية إلى أن تكون قيمة مقياس "مدى استجابة الصفحة لتفاعلات المستخدم" 200 ملّي ثانية أو أقل. لتحقيق هذا الهدف لدى معظم مستخدمي موقعك، فإنّ المعيار الجيد للقياس هو أن تتحقق هذه القيمة في %75 على الأقل من عمليات تحميل الصفحات، موزعةً بين أجهزة الجوّال وأجهزة الكمبيوتر المكتبية.
استنادًا إلى الموقع الإلكتروني، قد يكون هناك تفاعلات قليلة أو معدومة، مثل صفحات تحتوي في الغالب على نصوص وصور مع عناصر تفاعلية قليلة أو معدومة. أو في حالة المواقع الإلكترونية مثل محرّرات النصوص أو الألعاب، قد يكون هناك مئات أو حتى آلاف التفاعلات. في كلتا الحالتين، إذا كان مقياس INP مرتفعًا، تكون تجربة المستخدم معرّضة للخطر.
يتطلّب تحسين مقياس INP وقتًا وجهدًا، ولكنّ النتيجة هي تجربة أفضل للمستخدم. في هذا الدليل، سنستكشف طريقة لتحسين مقياس INP.
تحديد سبب انخفاض مقياس INP
قبل أن تتمكّن من إصلاح التفاعلات البطيئة، ستحتاج إلى بيانات تخبرك ما إذا كان مقياس INP لموقعك الإلكتروني ضعيفًا أو يحتاج إلى تحسين. بعد الحصول على هذه المعلومات، يمكنك الانتقال إلى المختبر لبدء تشخيص التفاعلات البطيئة والعمل على إيجاد حلّ لها.
العثور على التفاعلات البطيئة في الميدان
من الأفضل أن تبدأ رحلتك في تحسين مقياس INP باستخدام البيانات الميدانية. في أفضل الأحوال، لن تمنحك البيانات الميدانية من مقدّم خدمة "مراقبة المستخدمين الحقيقيين" (RUM) قيمة INP للصفحة فحسب، بل ستمنحك أيضًا بيانات سياقية توضّح التفاعل المحدّد الذي كان مسؤولاً عن قيمة INP نفسها، وما إذا كان التفاعل قد حدث أثناء تحميل الصفحة أو بعده، ونوع التفاعل (نقرة أو ضغطة مفتاح أو نقرة)، ومعلومات قيّمة أخرى.
إذا لم تكن تعتمد على مقدّم خدمة RUM للحصول على بيانات الاستخدام الفعلي، ينصحك دليل بيانات الاستخدام الفعلي لمقياس مدى استجابة الصفحة لتفاعلات المستخدم (INP) باستخدام إحصاءات PageSpeed للاطّلاع على بيانات "تقرير تجربة المستخدم على Chrome" (CrUX) للمساعدة في سدّ الثغرات. CrUX هي مجموعة بيانات Google لبرنامج Core Web Vitals، وتوفّر ملخّصًا عالي المستوى للمقاييس لملايين المواقع الإلكترونية، بما في ذلك مقياس INP. ومع ذلك، لا يوفّر CrUX غالبًا البيانات السياقية التي يمكنك الحصول عليها من مقدّم خدمة RUM لمساعدتك في تحليل المشاكل. لهذا السبب، ننصح المواقع الإلكترونية بالاستعانة بمقدّم خدمة RUM عندما يكون ذلك ممكنًا، أو تنفيذ حلّ RUM خاص بها لتكملة ما هو متاح في CrUX.
تشخيص التفاعلات البطيئة في المختبر
من الأفضل أن تبدأ الاختبار في المختبر بعد الحصول على بيانات ميدانية تشير إلى أنّ التفاعلات بطيئة. في حال عدم توفّر بيانات ميدانية، هناك بعض الاستراتيجيات لتحديد التفاعلات البطيئة في المختبر. وتشمل هذه الاستراتيجيات اتّباع مسارات المستخدمين الشائعة واختبار التفاعلات على طول المسار، بالإضافة إلى التفاعل مع الصفحة أثناء التحميل، عندما يكون مؤشر التعليمات البرمجية الرئيسي مشغولاً في أغلب الأحيان، وذلك لتحديد التفاعلات البطيئة خلال هذا الجزء المهم من تجربة المستخدم.
تحسين التفاعلات
بعد تحديد تفاعل بطيء وإعادة إنتاجه يدويًا في بيئة الاختبار، تكون الخطوة التالية هي تحسينه.
يمكن تقسيم التفاعلات إلى ثلاثة أجزاء فرعية:
- مهلة الاستجابة للإدخال، والتي تبدأ عندما يبدأ المستخدم تفاعلاً مع الصفحة، وتنتهي عندما تبدأ عمليات استدعاء الأحداث للتفاعل.
- مدة المعالجة، والتي تتألف من الوقت الذي تستغرقه عمليات معاودة الاتصال بالأحداث حتى تكتمل.
- تأخير العرض، وهو الوقت الذي يستغرقه المتصفّح لعرض الإطار التالي الذي يحتوي على النتيجة المرئية للتفاعل.
ومجموع هذه الأجزاء الفرعية الثلاثة هو إجمالي وقت استجابة التفاعل. يساهم كل جزء فرعي من التفاعل في مقدار معيّن من الوقت في إجمالي وقت استجابة التفاعل، لذا من المهم معرفة كيفية تحسين كل جزء من التفاعل ليعمل في أقل وقت ممكن.
تحديد مهلة الاستجابة للإدخال وتقليلها
عندما يتفاعل المستخدم مع صفحة، يكون الجزء الأول من هذا التفاعل هو مهلة الاستجابة للإدخال. بناءً على الأنشطة الأخرى على الصفحة، قد تكون فترات تأخير الاستجابة طويلة بشكل كبير. قد يرجع ذلك إلى النشاط الذي يحدث في سلسلة التعليمات الرئيسية (ربما بسبب تحميل النصوص البرمجية وتحليلها وتجميعها) أو معالجة الجلب أو دوال الموقّت أو حتى من التفاعلات الأخرى التي تحدث في تتابع سريع وتتداخل مع بعضها البعض.
أيًا كان مصدر تأخير الإدخال في التفاعل، عليك تقليل تأخير الإدخال إلى الحد الأدنى حتى تتمكّن التفاعلات من بدء تشغيل عمليات استدعاء الأحداث في أقرب وقت ممكن.
العلاقة بين تقييم النصوص البرمجية والمهام التي يستغرق تنفيذها وقتًا طويلاً أثناء بدء التشغيل
يُعدّ بدء التشغيل جانبًا مهمًا من جوانب التفاعل في مراحل نشاط الصفحة. عند تحميل صفحة، سيتم عرضها في البداية، ولكن من المهم تذكُّر أنّ عرض الصفحة لا يعني بالضرورة أنّ الصفحة قد انتهت من التحميل. استنادًا إلى عدد الموارد التي تتطلّبها الصفحة لتعمل بشكل كامل، من الممكن أن يحاول المستخدمون التفاعل مع الصفحة أثناء تحميلها.
من الأمور التي يمكن أن تزيد من مهلة الاستجابة للتفاعل أثناء تحميل الصفحة هي تقييم النص البرمجي. بعد جلب ملف JavaScript من الشبكة، لا يزال لدى المتصفّح عمل يجب إنجازه قبل تشغيل ملف JavaScript هذا، ويشمل ذلك تحليل نص برمجي للتحقّق من صحة بنيته، وتجميعه في رمز بايت، ثم تنفيذه في النهاية.
بناءً على حجم النص البرمجي، يمكن أن يؤدي هذا العمل إلى تنفيذ مهمة يستغرق تنفيذها وقتًا طويلاً على سلسلة التعليمات الرئيسية، ما سيؤدي إلى تأخير المتصفّح في الاستجابة لتفاعل المستخدمين الآخر. للحفاظ على استجابة صفحتك لإدخالات المستخدم أثناء تحميل الصفحة، من المهم فهم ما يمكنك فعله لتقليل احتمالية حدوث مهام يستغرق تنفيذها وقتًا طويلاً أثناء تحميل الصفحة حتى تظل الصفحة سريعة.
تحسين عمليات استدعاء الأحداث
تأخير الإدخال هو الجزء الأول فقط مما يقيسه مقياس INP. عليك أيضًا التأكّد من أنّ عمليات استدعاء الأحداث التي يتم تنفيذها استجابةً لتفاعل المستخدم يمكن إكمالها في أسرع وقت ممكن.
التنازل عن سلسلة التعليمات الرئيسية بشكل متكرر
أفضل نصيحة عامة لتحسين عمليات استدعاء الأحداث هي تنفيذ أقل قدر ممكن من العمل فيها. ومع ذلك، قد يكون منطق التفاعل معقّدًا، وقد تتمكّن فقط من تقليل العمل الذي يؤديه بشكل هامشي.
إذا تبيّن لك أنّ هذا هو الحال في موقعك الإلكتروني، يمكنك محاولة تقسيم العمل في عمليات الاستدعاء للأحداث إلى مهام منفصلة. يمنع ذلك العمل الجماعي من أن يصبح مهمة يستغرق تنفيذها وقتًا طويلاً تحظر سلسلة التعليمات الرئيسية، ما يسمح بتفاعلات أخرى كانت ستنتظر في سلسلة التعليمات الرئيسية ليتم تشغيلها في وقت أقرب.
setTimeout هي إحدى الطرق لتقسيم المهام، لأنّ دالة الاستدعاء التي يتم تمريرها إليها يتم تنفيذها في مهمة جديدة. يمكنك استخدام setTimeout بمفرده أو تلخيص استخدامه في دالة منفصلة للحصول على نتائج أكثر كفاءة.
إنّ التنازل بشكل عشوائي أفضل من عدم التنازل على الإطلاق، ولكن هناك طريقة أكثر دقة للتنازل إلى سلسلة التعليمات الرئيسية، وهي التنازل فورًا بعد استدعاء حدث يحدّث واجهة المستخدم حتى يتم تشغيل منطق العرض في وقت أقرب.
التنازل للسماح بحدوث عمل العرض في وقت أقرب
تتضمّن تقنية التنازل الأكثر تقدّمًا تنظيم الرمز البرمجي في عمليات استدعاء الأحداث للحدّ من ما يتم تشغيله على المنطق المطلوب فقط لتطبيق التعديلات المرئية للإطار التالي. ويمكن تأجيل كل شيء آخر إلى مهمة لاحقة. لا يساعد ذلك في الحفاظ على خفة وسرعة عمليات الاستدعاء فحسب، بل يحسِّن أيضًا الوقت المستغرَق للعرض في التفاعلات من خلال عدم السماح للتحديثات المرئية بحظر رمز استدعاء الأحداث.
على سبيل المثال، تخيَّل محرِّر نصوص منسَّقة ينسِّق النص أثناء الكتابة، ولكنه يحدِّث أيضًا جوانب أخرى من واجهة المستخدم استجابةً لما كتبته (مثل عدد الكلمات وتمييز الأخطاء الإملائية والملاحظات المرئية المهمة الأخرى). بالإضافة إلى ذلك، قد يحتاج التطبيق أيضًا إلى حفظ ما كتبته حتى لا تفقد أي عمل إذا غادرت وعدت.
في هذا المثال، يجب أن تحدث الأمور الأربعة التالية استجابةً للأحرف التي يكتبها المستخدم. ومع ذلك، يجب تنفيذ العنصر الأول فقط قبل تقديم الإطار التالي.
- عدِّل مربّع النص بما كتبه المستخدم وطبِّق أي تنسيق مطلوب.
- تعديل الجزء من واجهة المستخدم الذي يعرض عدد الكلمات الحالي
- تشغيل المنطق للتحقق من الأخطاء الإملائية.
- حفظ أحدث التغييرات (إما على الجهاز أو في قاعدة بيانات عن بُعد)
قد يبدو الرمز البرمجي لتنفيذ ذلك على النحو التالي:
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 الكبير مشكلة في حالتَين:
- أثناء العرض الأوّلي للصفحة، حيث يتطلّب نموذج DOM الكبير الكثير من العمل لعرض الحالة الأولية للصفحة.
- استجابةً لتفاعل المستخدم، حيث يمكن أن يؤدي حجم عناصر 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 هذا وعرضه.
من المهم أن تتذكّر أنّه حتى المواقع الإلكترونية التي ليست تطبيقات صفحة واحدة قد تتضمّن قدرًا من عرض HTML من خلال JavaScript نتيجة للتفاعلات. لا بأس بذلك بشكل عام، طالما أنّك لا تعرض كميات كبيرة من HTML على العميل، ما قد يؤدي إلى تأخير عرض اللقطة التالية. ومع ذلك، من المهم فهم تأثيرات هذا النهج في الأداء على عرض HTML في المتصفّح، وكيف يمكن أن يؤثر في مدى استجابة موقعك الإلكتروني لإدخالات المستخدمين إذا كنت تعرض الكثير من محتوى HTML باستخدام JavaScript.
الخاتمة
إنّ تحسين مقياس INP لموقعك الإلكتروني هو عملية متكررة. عند إصلاح تفاعل بطيء في الميدان، من المرجّح أن تبدأ في العثور على تفاعلات بطيئة أخرى، خاصةً إذا كان موقعك الإلكتروني يوفّر الكثير من التفاعل، وستحتاج إلى تحسينها أيضًا.
يكمن مفتاح تحسين مقياس INP في المثابرة. بمرور الوقت، يمكنك تحسين مدى استجابة صفحتك إلى مستوى يرضي المستخدمين عن التجربة التي تقدّمها لهم. ومن المرجّح أيضًا أنّه أثناء تطوير ميزات جديدة للمستخدمين، قد تحتاج إلى اتّباع العملية نفسها لتحسين التفاعلات الخاصة بهم. سيستغرق الأمر وقتًا وجهدًا، ولكنّهما يستحقان ذلك.