تعرَّف على كيفية تحسين مدى استجابة موقعك الإلكتروني لسرعة عرض اللقطة.
مدى استجابة الصفحة لتفاعلات المستخدم (INP) هو مقياس ثابت لمؤشرات أداء الويب الأساسية يقيّم مدى استجابة الصفحة بشكل عام لتفاعلات المستخدم من خلال ملاحظة وقت الاستجابة لجميع التفاعلات المؤهِّلة التي تحدث طوال فترة زيارة المستخدم للصفحة. قيمة INP النهائية هي أطول تفاعل يتم ملاحظته (في بعض الأحيان يتم تجاهل القيم الاستثنائية).
لتقديم تجربة جيدة للمستخدمين، يجب أن تسعى المواقع الإلكترونية إلى أن تكون مدة التفاعل مع الصفحة التالية 200 ملّي ثانية أو أقل. ولضمان تحقيق هذا الهدف لمعظم المستخدمين، هناك حد أدنى جيد يمكن قياسه هو الشريحة المئوية الخامسة والسبعين من عمليات تحميل الصفحات، مقسّمة على مستوى الأجهزة الجوّالة وأجهزة الكمبيوتر المكتبي.
واعتمادًا على الموقع الإلكتروني، قد يكون هناك عدد قليل من التفاعلات أو لا تكون هناك تفاعلات على الإطلاق - مثل الصفحات التي تشتمل في الغالب على نصوص وصور مع القليل من العناصر التفاعلية أو لا تحتوي على أي عناصر تفاعلية. أو، في حالة مواقع الويب مثل محررات النصوص أو الألعاب، يمكن أن يكون هناك مئات - حتى الآلاف - من التفاعلات. وفي كلتا الحالتَين، عندما يكون مقياس INP مرتفعًا، تكون تجربة المستخدم عرضة للخطر.
يستغرق تحسين مدى استجابة الصفحة لتفاعلات المستخدم (INP) وقتًا وجهدًا، لكنّ المكافأة هي تجربة أفضل للمستخدم. في هذا الدليل، سيتم استكشاف مسار لتحسين INP.
تحديد أسباب ضعف مقياس INP
قبل أن تتمكّن من حلّ مشكلة التفاعلات البطيئة، ستحتاج إلى بيانات لمعرفة ما إذا كان مقياس "مدى استجابة الصفحة لتفاعلات المستخدم" (INP) الخاص بموقعك الإلكتروني ضعيفًا أو بحاجة إلى تحسين. وبمجرد حصولك على هذه المعلومات، يمكنك الانتقال إلى المعمل لبدء تشخيص التفاعلات البطيئة، والعمل في طريقك نحو التوصل إلى حل.
العثور على التفاعلات البطيئة في الحقل
من المفترض أن تبدأ رحلتك لتحسين مقياس "مدى استجابة الصفحة لتفاعلات المستخدم" (INP) باستخدام البيانات الفعلية. وفي أفضل حالاتها، ستقدّم لك بيانات الحقل من مقدّم خدمة "تتبُّع المستخدم الفعلي" (RUM) قيمة مقياس "مدى استجابة الصفحة لتفاعلات المستخدم" (INP) للصفحة فحسب، بل توفّر أيضًا البيانات السياقية التي تسلّط الضوء على التفاعل المحدّد المسؤول عن قيمة مقياس "مدى استجابة الصفحة لتفاعلات المستخدم" (INP) نفسها، وما إذا كان التفاعل قد حدث أثناء تحميل الصفحة أو بعدها، بالإضافة إلى نوع التفاعل (النقر أو الضغط على المفاتيح أو النقر) وغيرها من المعلومات القيّمة.
وإذا كنت لا تعتمد على موفّر RUM للحصول على بيانات الحقول، ينصح دليل بيانات حقول INP باستخدام "تقرير تجربة المستخدم على Chrome" من خلال "إحصاءات PageSpeed" للمساعدة في سد الثغرات. إنّ تقرير تجربة المستخدم على Chrome هو مجموعة البيانات الرسمية لبرنامج "مؤشرات أداء الويب الأساسية" ويقدّم ملخّصًا عالي المستوى للمقاييس الخاصة بملايين المواقع الإلكترونية، بما في ذلك مقياس INP. ومع ذلك، لا يوفر تقرير تجربة المستخدم على Chrome غالبًا البيانات السياقية التي يمكنك الحصول عليها من مزود 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 هو المثابرة. وبمرور الوقت، يمكنك تحسين استجابة صفحتك لمكان يرضى المستخدمون فيه بالتجربة التي تقدمها لهم. من المحتمل أيضًا أنه عندما تقوم بتطوير ميزات جديدة للمستخدمين، قد تحتاج إلى إجراء نفس العملية في تحسين التفاعلات الخاصة بهم. سيستغرق الأمر وقتًا وجهدًا، لكن هناك وقت وجهد يتم بذله بشكل جيد.
صورة رئيسية من UnLaunch، للفنان David Pisnoy وتمّ تعديلها وفقًا لترخيص Unسبلاش