تاريخ النشر: 14 أكتوبر 2025
مدى استجابة الصفحة لتفاعلات المستخدم (INP) هو مقياس مهم من Core Web Vitals لقياس مستوى التجاوب. في Fotocasa، سلّطت Google Search Console الضوء على عدد كبير من الصفحات التي انتقلت إلى حالة "تحتاج إلى تحسين" و"ضعيفة" عندما حلّ مقياس "مدى استجابة الصفحة لتفاعلات المستخدم" (INP) محلّ مقياس "مهلة الاستجابة الأولى" (FID) في عام 2024. توضّح دراسة الحالة هذه الأدوات والاستراتيجيات المستخدَمة لتشخيص هذه المشاكل وحلّها، ما أدّى في النهاية إلى تحسين مقياس INP بشكل كبير.
نقطة انطلاق فريق Fotocasa
قبل الانتقال من FID إلى INP، كانت كل صفحة تقريبًا على كلّ من أجهزة الكمبيوتر المكتبي والأجهزة الجوّالة ضمن الحدّ الأدنى "جيّد"، ما يعني أنّ جميع "مؤشرات أداء الويب الأساسية" في ذلك الوقت (LCP وCLS وFID) كانت تعمل بشكل جيد. ومع ذلك، بعد الانتقال إلى مقياس INP، انتقلت جميع الصفحات تقريبًا إلى حالة "تحتاج إلى تحسين"، وبعضها إلى حالة "ضعيفة"، لأنّ قيم INP تجاوزت باستمرار 200 ملي ثانية لمعظم تفاعلات المستخدمين.
أدرك فريق Fotocasa من خلال هذا التغيير أنّه كان يتجاهل جانبًا مهمًا من تجربة المستخدم. في حين أنّ مقياس FID كان يقيس فقط تأخّر التفاعل الأول، يقيّم مقياس INP مدى استجابة جميع التفاعلات، مع الأخذ في الاعتبار تأخّر معالجة الإدخال والعرض. هذا القياس الأوسع نطاقًا هو مؤشر أفضل بكثير على التفاعل الحقيقي (كما ذكرت Google)، وقد سلّط الضوء على الفرص غير المستغَلّة.
على الرغم من أنّ خدمة Google Search Console تقدّم بيانات حول أداء الحقول، إلا أنّها لا تقدّم إحصاءات في الوقت الفعلي. يتم تجميع بياناتها على مدار فترة 28 يومًا، ما يصعّب تحديد التفاعلات التي كانت تتسبّب في حدوث مشاكل في الوقت الحالي.
كانت هناك حاجة إلى طريقة لتتبُّع مقياس INP في الوقت الفعلي من أجل تحديد التفاعلات الأبطأ والأكثر استخدامًا من قِبل المستخدمين، وإعادة إنتاجها بشكل موثوق في بيئات التطوير الخاصة بالفريق. كان من المهم أيضًا فهم تأثير التغييرات التي تم إجراؤها، وليس فقط الإصلاحات التي ساعدت، ولكن أيضًا التعديلات التي أدّت عن غير قصد إلى تفاقم المشاكل.
لهذه الأسباب، تم استخدام مجموعة من الأدوات للمساعدة في تشخيص المشاكل وحلّها. وكانت أهمها ما يلي:
- "أدوات مطوّري البرامج في Google Chrome"، وتحديدًا علامة التبويب "الأداء"
- نظام مخصّص لمراقبة تجربة المستخدم الحقيقية (Real User Monitoring) أنشأه فريق Fotocasa في Datadog باستخدام مكتبة web-vitals.
- React Developer Tools
أدوات لتشخيص المشكلة
لتشخيص مشاكل أداء مقياس INP وتصحيح أخطائها، تم استخدام الأدوات التالية.
أدوات مطوّري البرامج في Google Chrome
من أفضل الطرق لرصد المشاكل المتعلقة بمؤشرات Core Web Vitals وإعادة إنتاجها في أحد تطبيقات الويب هي استخدام علامة التبويب "الأداء" في "أدوات مطوّري البرامج في Google Chrome". تقيس علامة التبويب "الأداء" مقاييس Core Web Vitals تلقائيًا، ما يتيح الحصول على ملاحظات فورية حول مقاييس التحميل والتفاعل وتغيير التصميم. وهي تتوافق بشكل عام مع طريقة عرض هذه المقاييس في أدوات Google الأخرى.
لتحديد مشاكل مقياس INP وحلّها، كان فريق Fotocasa يبدأ عادةً بتقييد أداء وحدة المعالجة المركزية لمحاكاة أداء الأجهزة المنخفضة والمتوسطة المستوى. وقد سمح ذلك لفريق Fotocasa بمراقبة سلوك الصفحة في ظل ظروف أكثر تقييدًا. تم بعد ذلك تسجيل الجلسة باستخدام أداة Profiler وتحليل عمليات التتبُّع بعناية، مع التركيز على تفاعل المستخدم لتحديد مشاكل الأداء.
عند تحديد المشاكل التي تؤدي إلى بطء الأداء، من المفيد بشكل خاص فحص الأجزاء الفرعية لمؤشر INP والمهام التي ينفّذها المتصفّح في كل جزء منها. على سبيل المثال، في الصورة التالية، يمكن ملاحظة أنّ مقياس INP مرتفع جدًا بسبب إعادة احتساب نمطَين ناتجة عن تغييرات في نمط نص المستند.
أنشأت شركة Fotocasa نظامًا لتتبُّع مقياس INP ومقاييس Core Web Vitals الأخرى، ما يضمن رصد أي مشاكل في الأداء ومعالجتها بسرعة. عندما يتجاوز مقياس حدًا معيّنًا (استنادًا إلى النطاقات التي تحدّدها Google)، يتم تسجيل تحديد المصدر حتى يمكن تحليل المشكلة وحلّها.
بالنسبة إلى هذا النظام، تم استخدام مكتبة web-vitals لتسجيل هذه المقاييس من المستخدمين الفعليين بطريقة تتطابق بدقة مع طريقة قياسها في Chrome وإرسالها إلى أدوات Google الأخرى (مثل "تقرير تجربة المستخدم في Chrome" وPage Speed Insights و"تقرير السرعة" في Search Console وغيرها).
للحصول على نظرة شاملة وتتبُّع مركزي، استخدمت Fotocasa أداة Datadog لجمع البيانات وعرضها بشكل مرئي، ما مكّن الفريق من اتخاذ قرارات مستنيرة تستند إلى البيانات. تساعد المقاييس المخصّصة في الحفاظ على فعالية التكلفة، كما أنّها تتيح إمكانية أفضل لتتبُّع جميع المستخدمين تقريبًا على موقع Fotocasa الإلكتروني.
يتيح هذا النظام لفريق Fotocase مراقبة ما إذا كانت التعديلات تؤثر في المقاييس أو ما إذا كانت تحدث تغييرات غير متوقعة، ما قد يؤدي إلى تعريضها للخطر. يمكن بعد ذلك تقسيم مقياس INP إلى أجزاء، مثل تأخير الإدخال ومدة المعالجة وتأخير العرض، لتحديد الجزء المسؤول بشكل أساسي عن أوقات التفاعل الطويلة.
عند رصد أي حالات غير طبيعية، مثل تلك الموضّحة في الشكلين 7 و8، استجابت Fotocasa على الفور واستخدمت OpenSearch، وهي أداة أخرى ساعدت في تحديد المكان الذي قد يحدث فيه التغيير. ساعدت البيانات التي توفّرها مكتبة web-vitals في تحديد الهدف (عنصر DOM الذي قد يكون مسؤولاً عن ارتفاع قيمة المقياس)، كما ساعدت الفريق في التركيز بشكل أكبر على حلّ المشكلة.
علاوةً على ذلك، يمكن تحديد فلاتر مختلفة، مثل نوع الصفحة أو الجهاز أو حالة التحميل، لتبسيط السيناريوهات والحصول على فهم أكثر دقة لتأثير مقياس INP.
React Developer Tools
تم استخدام أدوات مطوّري React لتحسين إمكانات تصحيح الأخطاء في Fotocasa، ما يوفّر ميزة قوية تتيح لك تمييز المكوّنات التي تمت إعادة عرضها بشكل مرئي.
يمكن تفعيل هذه الميزة من خلال الانتقال إلى علامة التبويب أداة تحليل الأداء. بعد ذلك، انقر على رمز الترس في الجانب الأيسر من الشريط العلوي، وانتقِل إلى علامة التبويب عام، ثم ضَع علامة في مربّع الاختيار تمييز التعديلات عند عرض المكوّنات. عند تفعيل هذه الميزة، يتم تمييز المكوّنات عند إعادة عرضها، ما يوفّر تمثيلاً مرئيًا ديناميكيًا.
معرفة سبب إعادة العرض
بعد تحديد المكوّن الذي تمّت إعادة عرضه، يكون السؤال التالي هو "لماذا حدث ذلك؟". تقدّم React DevTools إجابة عن هذا السؤال من خلال تلميح أداة مفيد في عرض الرسم البياني الشريطي.
للوصول إلى هذه المعلومات، سجِّل جلسة أداة تحليل الأداء. من خلال تحليل نتائج أداة Profiler، ستعثر على معلومات مفيدة:
- في أعلى يسار الصفحة، يظهر عدد عمليات تثبيت React.
- يمثّل الرسم البياني الشعلة شجرة المكوّنات بشكل مرئي، ويشير اللون الرمادي إلى المكوّنات التي لم تتم إعادة عرضها. يمثّل كل شريط لحظة تم فيها تغيير شجرة مكونات React، وعندما تم إجراء تغيير مطابق على DOM.
- سيؤدي تمرير مؤشر الماوس فوق كل مكوّن في الرسم البياني الشريطي إلى عرض سبب إعادة عرضه ضمن العنوان الفرعي لماذا تمّ عرض هذا المكوّن؟.
قد تشمل أسباب إعادة عرض أحد المكوّنات ما يلي:
- هذه هي المرة الأولى التي يتم فيها عرض المكوّن
- تم تغيير السياق
- تم تغيير خطافات الربط
- تم تغيير الخصائص
- تم تغيير الولاية
- تم عرض المكوّن الرئيسي
التعرّف على مدة العرض
تعرض الألوان في الرسم البياني الشعلة معلومات مفيدة. تشير الألوان، مثل درجات اللون الأزرق المختلفة، إلى أنّ أحد المكوّنات استغرق وقت عرض قصيرًا نسبيًا مقارنةً بالمكوّنات الأخرى. في المقابل، تشير ألوان مثل البرتقالي والأحمر إلى أنّ أحد المكوّنات استغرق وقتًا أطول في العرض.
كيف حلّ فريق Fotocasa المشكلة؟
إزالة عمليات إعادة العرض غير الضرورية
تحدث عمليات إعادة العرض عندما يحتاج React إلى تعديل واجهة المستخدم باستخدام بيانات جديدة. ويحدث ذلك عادةً نتيجة إجراء يتخذه المستخدم أو استجابة من واجهة برمجة التطبيقات أو أحداث مهمة أخرى تتطلّب تعديل واجهة المستخدم. بما أنّ كل عملية إعادة عرض تشغّل JavaScript، فإنّ إجراء عدد كبير منها في الوقت نفسه، خاصةً في شجرة مكونات كبيرة، يمكن أن يؤدي إلى حظر سلسلة التعليمات الرئيسية والتسبّب في حدوث مشاكل في الأداء.
هناك نوعان من عمليات إعادة العرض:
- عمليات إعادة العرض الضرورية: عندما يحتاج أحد المكوّنات إلى التعديل لأنّه يملك بيانات جديدة أو يستخدمها.
- إعادة العرض غير الضرورية: عندما يتم تعديل أحد المكوّنات بدون أي تغيير مهم، غالبًا ما يكون ذلك بسبب إدارة الحالة غير الفعّالة أو معالجة الخصائص غير السليمة.
عادةً، لا تشكّل عمليات إعادة العرض غير الضرورية مشكلة كبيرة، لأنّ React سريع بما يكفي لدرجة أنّ المستخدمين لن يلاحظوا ذلك بشكل عام. ومع ذلك، إذا حدثت هذه العمليات بشكل متكرر جدًا أو في شجرة مكوّنات كبيرة، يمكن أن تؤثر سلبًا في تجربة المستخدم وفي مقياس INP الخاص بالصفحة.
كان هذا هو الحال مع فريق Fotocasa. لقد أدركوا أنّ الموقع الإلكتروني كان يعيد عرض الكثير من العناصر بدون داعٍ. حدثت هذه المشاكل في سيناريوهَين رئيسيَّين:
- أثناء تحميل الصفحة: زيادة عدد المهام الطويلة في سلسلة التعليمات الرئيسية وتأخير التفاعل الأول، ما أثّر سلبًا في مقياس INP للصفحة
- أثناء تفاعلات المستخدمين: زيادة وقت معالجة معظم التفاعلات، ما أضرّ أيضًا بمؤشر INP
تم تحسين الكثير من عمليات إعادة العرض غير الضرورية على موقع Fotocasa الإلكتروني. أحد أهم التحسينات التي تم إجراؤها كان على صفحة "بحث Google". حدثت ثلاث عمليات إعادة عرض غير ضرورية عند تحميل الصفحة. بعد إزالة هذه الروابط، لاحظنا النتائج التالية:
- عدد أقل من المهام الطويلة (راجِع الشكل التالي)
- انخفاض إجمالي وقت الحظر (قارِن بين الشكلَين 14 و15)
الخوادم المشترَكة في الولاية
يمكن أن يؤدي وضع حالة React بشكل غير صحيح إلى إبطاء التطبيق وجعل واجهة المستخدم تبدو غير مستجيبة. عندما تتغير حالة أحد المكوّنات، ستتم إعادة عرض مكوّناته الفرعية تلقائيًا ما لم يتم استخدام آلية للتحكّم في ذلك (مثل memo).
كما هو موضّح في القسم السابق، لا تكون عمليات إعادة العرض سيئة بطبيعتها، ولكن يمكن أن تؤدي إعادة عرض الصفحة بأكملها بسبب تعديل حالة معيّنة إلى تفاعلات أبطأ، لأنّ تعديلات نموذج المستند (DOM) تحدث بعد العرض.
على سبيل المثال، في صفحة "البحث"، يظهر مربّع حوار يعرض جميع الفلاتر عند النقر على أحد الأزرار.
تم وضع الحالة التي تتحكّم في حالة فتح مربّع الحوار في هذه الحالة في صفحة "البحث". عندما تتغير هذه الحالة، تتم إعادة عرض الصفحة بأكملها، ما يؤدي إلى حدوث تفاعل سيئ مع الإدخال، خاصةً على الأجهزة الأبطأ كما يظهر عند استخدام ميزة تقييد سرعة وحدة المعالجة المركزية في "أدوات مطوّري البرامج":
يؤدي تغيير الحالة بالقرب من المكوّن الذي يؤدي إلى التغيير إلى حلّ هذه المشكلة. في هذه الحالة تحديدًا، يمكن وضع الحالة في مكوّن زر الفلاتر، وبالتالي عند تغيُّر الحالة، سيتم إعادة عرض الزر فقط.
إزالة الحالات غير الضرورية
يجب ألا تحتوي الحالات على معلومات مكرّرة أو زائدة. وفي حال حدوث ذلك، قد يؤدي إلى إعادة عرض غير ضرورية، ويسبب مشاكل.
على سبيل المثال، في شريط فلاتر Fotocasa، يظهر نص يمثّل عدد الفلاتر المطبَّقة على عملية بحث معيّنة:
يتم احتساب عدد الفلاتر المُطبَّقة من حالة التطبيق. ومع ذلك، لم يؤدِّ ذلك إلى إعادة عرض غير ضرورية للمكوّن بأكمله فحسب، بل أدّى أيضًا في بعض الحالات إلى تغيير في التصميم لأنّ هذا المكوّن يتم عرضه من جهة الخادم:
const [filtersCount, setFiltersCount] = useState(DEFAULT_COUNTER)
useEffect(() => {
const counter = filters
? Object.keys(filters)
?.reduce(reducerCounter, [])
?.filter((param) => searchParams?.[param]).length
: DEFAULT_COUNTER
setFiltersCount(counter)
}, [searchParams]);
لحلّ هذه المشكلة، تم استخلاص القيمة من عنصر الفلاتر باستخدام متغيّر بدلاً من استخدام الحالة:
const counter = filters
? Object.keys(filters)
?.reduce(reducerCounter, [])
?.filter((param) => searchParams?.[param]).length
: DEFAULT_COUNTER;
تقليل عمليات العرض المكلفة
عند حدوث تفاعل في تطبيق React، يؤدي ذلك عادةً إلى تغيير الحالة. كما هو موضّح سابقًا، عندما تتغيّر حالة أحد المكوّنات، ستتم إعادة عرضه مع جميع العناصر الفرعية.
إذا كانت إحدى وظائف عرض هذه المكوّنات بطيئة، سيؤثر ذلك سلبًا في مؤشر INP للصفحة، لأنّه من المحتمل أن يتم إنشاء مهمة طويلة، وسيستغرق تعديل نموذج المستند وقتًا أطول.
حاول فريق Fotocasa تقليل العمليات الحسابية التي تستغرق وقتًا طويلاً إلى أقصى حدّ ضمن دالة العرض للمكوّنات. كانت "أدوات مطوّري البرامج في Chrome" و"أدوات مطوّري React" مفيدة جدًا في رصد عمليات العرض البطيئة.
تأخير تنفيذ الرمز البرمجي
بالإضافة إلى تحسين دالة العرض للمكوّنات، تم تحسين دوال أخرى لتقليل المهام الطويلة قدر الإمكان. ومع ذلك، تعذّر تحسين بعض المهام لأنّها كانت تعتمد على رمز تابع لجهة خارجية.
أحد الأمثلة على ذلك هو التحليلات. في هذه الحالة، تمّ اتّخاذ قرار بتأخير تنفيذ رمز الإحصاءات وتحديد أولويات تعديلات نموذج المستند (DOM) عند حدوث تفاعلات المستخدم. لتحقيق ذلك، استخدم فريق Fotocasa مكتبة باسم idlefy، والتي تضمن أيضًا استمرار تشغيل رمز الإحصاءات حتى إذا تم إغلاق المتصفح بعد ذلك مباشرةً.
ثقافة الأداء
لا يقتصر العمل على الأداء على جهد لمرة واحدة، بل يجب مراعاته مع كل ميزة يتم طرحها في مرحلة الإنتاج. يجب أن يكون كل فرد في الفريق على دراية بهذه المقاييس، وإلا سيكون من المحتمل حدوث تراجع في "مؤشرات أداء الويب الأساسية".
للبقاء على اطّلاع على هذه المشكلة، شارك فريق Fotocasa المعلومات بشكل نشط مع أعضاء الفريق ووضع إطارًا واضحًا لتحديد مشاكل الأداء استنادًا إلى بيانات Datadog RUM الخاصة بـ Fotocasa، بما في ذلك كيفية إعادة إنتاجها. تم إعداد تنبيهات بشأن مؤشرات Core Web Vitals، لا سيما مؤشر INP، في نظام مراقبة تجربة المستخدم الحقيقية، وتم ضبطها لإرسال إشعارات إلى فريق Fotocasa مباشرةً في Slack. ساعد هذا النهج في إبقاء الأداء في مقدّمة الأولويات، كما ساعد في رصد المشاكل قبل أن تتفاقم.
النتائج
تطلّب تحسين مقياس INP في Fotocasa مزيجًا من التحسينات الفنية والتغييرات الثقافية. من خلال إلغاء عمليات إعادة العرض غير الضرورية، وتحسين موضع الحالة، وتقليل عمليات العرض المكلفة، وتأجيل الرموز غير المهمة، تمكّن فريق Fotocasa من نقل جميع صفحات الكمبيوتر المكتبي من "بحاجة إلى تحسين" إلى "جيدة"، وتحسين صفحات الأجهزة الجوّالة بشكل كبير من خلال ترقية جميع الصفحات المصنّفة على أنّها "ضعيفة" و "بحاجة إلى تحسين" تقريبًا إلى "جيدة".
وقد أدّت هذه التغييرات إلى تحسين تجربة المستخدمين بشكل عام في Fotocasa، كما أدّت إلى زيادة بنسبة 27% في الإعلانات التي تحثّ على التواصل والإعلانات على الهاتف، ما ساهم بشكل مباشر في تعزيز مقاييس الأداء الرئيسية للشركة.
أتاحت المراقبة في الوقت الفعلي باستخدام Datadog لفريق Fotocasa التحقّق من التحسينات التي تم إجراؤها على مقياس INP، ورصد الحالات الشاذة بسرعة، ومنع حدوث أي تراجع. بالإضافة إلى هذه الإنجازات، تمكّنت Fotocasa أيضًا من دمج أداء الويب في ثقافة التطوير لديها، ما يضمن بقاء مقياس "مدى استجابة الصفحة لتفاعلات المستخدم" (INP) وCore Web Vitals من الأولويات في كل إصدار.