تعرَّف على كيفية تحديد تغيُّرات التنسيق وإصلاحها.
يتناول الجزء الأول من هذه المقالة أدوات تصحيح أخطاء تغييرات التنسيق، ويتناول الجزء الثاني عملية التفكير التي يجب اتّباعها عند تحديد سبب تغيير التنسيق.
الأدوات
واجهة برمجة التطبيقات Layout Instability API
واجهة برمجة التطبيقات Layout Instability API هي آلية المتصفّح لقياس متغيّرات التصميم والإبلاغ عنها. جميع أدوات debugging تغيُّرات التصميم، بما في ذلك DevTools، تستند في النهاية إلى واجهة برمجة التطبيقات Layout Instability API. ومع ذلك، يُعدّ استخدام واجهة برمجة التطبيقات Layout Instability API مباشرةً أداة فعّالة لتصحيح الأخطاء بسبب مرونتها.
الاستخدام
يمكن أن يُستخدَم أيضًا المقتطف نفسه من الرمز الذي يقيس متغيّرات التصميم التراكمية (CLS) لتحديد أخطاء تغيّرات التصميم وإصلاحها. يسجل المقتطف أدناه معلومات حول التنسيق إلى وحدة التحكم. سيوفّر لك فحص هذا السجلّ معلومات. حول وقت ومكان وكيفية حدوث متغيّرات التصميم.
let cls = 0;
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
if (!entry.hadRecentInput) {
cls += entry.value;
console.log('Current CLS value:', cls, entry);
}
}
}).observe({type: 'layout-shift', buffered: true});
عند تشغيل هذا النص البرمجي، يُرجى مراعاة ما يلي:
- يشير الخيار
buffered: true
إلى أنّPerformanceObserver
التحقق من إدخال أداء المتصفح المخزن المؤقت لإدخالات الأداء التي تم إنشاؤها قبل إدارة التهيئة. نتيجةً لذلك، سيُبلغPerformanceObserver
عن التحولات في ملف التنسيق التي حدثت قبل بدء التشغيل وبعده. يُرجى مراعاة ذلك عند فحص سجلّات وحدة التحكّم. يمكن أن يعكس العدد الكبير من عمليات تغيير التنسيق في البداية تأخّر إعداد التقارير، بدلاً من حدوث العديد من عمليات تغيير التنسيق بشكل مفاجئ. - لتجنّب التأثير في الأداء، ينتظر
PerformanceObserver
إلى أن يصبح مثيل السلسلة الأساسية غير نشِط لإعداد تقارير عن تغييرات التنسيق. ونتيجةً لذلك، استنادًا إلى مدى مشغولية السلسلة الرئيسية، قد يحدث تأخير طفيف بين وقت حدوث عملية تغيير التنسيق ووقت تسجيلها في وحدة التحكّم. - يتجاهل هذا النص البرمجي تغييرات التنسيق التي حدثت خلال 500 ملي ثانية من إدخال المستخدم، وبالتالي لا يتم احتسابها ضمن مقياس CLS.
يتم الإبلاغ عن المعلومات المتعلّقة بمتغيّرات التصميم باستخدام مزيج من واجهتَي برمجة تطبيقات:
LayoutShift
و
LayoutShiftAttribution
من الواجهات. يتم شرح كل واجهة من هذه الواجهات بمزيد من التفصيل في ال
أقسام التالية.
LayoutShift
يتم تسجيل كلّ تغيير في التنسيق باستخدام واجهة LayoutShift
. محتويات
المدخل على النحو التالي:
duration: 0
entryType: "layout-shift"
hadRecentInput: false
lastInputTime: 0
name: ""
sources: (3) [LayoutShiftAttribution, LayoutShiftAttribution, LayoutShiftAttribution]
startTime: 11317.934999999125
value: 0.17508567530168798
يشير الإدخال أعلاه إلى متغيّرات التصميم الذي تم خلاله تغيير ثلاثة عناصر DOM.
الموقع. نتيجة متغيّرات التصميم لمتغيّرات التصميم هذا بالتحديد كانت 0.175
.
هذه هي سمات مثيل LayoutShift
الأكثر صلة بـ
تصحيح أخطاء متغيّرات التصميم:
الموقع | الوصف |
---|---|
sources |
تعرِض السمة sources عناصر DOM التي تم نقلها أثناء متغيّرات التصميم. يمكن أن تحتوي هذه المصفوفة على ما يصل إلى خمسة مصادر. في حال وجود أكثر من خمسة عناصر متأثرة بمتغيّرات التصميم، يتم الإبلاغ عن أكبر خمسة مصادر (وفقًا لقياس التأثير على ثبات التصميم) لمتغيّرات التصميم. ويتم تسجيل هذه المعلومات باستخدام واجهة LayoutShiftAttribution (يتم شرحها بالتفصيل أدناه). |
value |
تُبلغ السمة value عن نتيجة متغيّرات التصميم لمتغيّر تصميم معيّن. |
hadRecentInput |
تشير السمة hadRecentInput إلى ما إذا كان متغيّر التصميم قد حدث خلال 500 مللي ثانية من البيانات التي أدخلها المستخدم. |
startTime |
تشير السمة startTime إلى وقت حدوث متغيّر تصميم. يتمّ التعبير عن startTime بالمللي ثانية ويتم قياسه نسبةً إلى الوقت الذي بدأ فيه تحميل الصفحة. |
duration |
سيتم ضبط السمة duration دائمًا على 0 . هذا الموقع مكتسَب من واجهة PerformanceEntry (توسِّع واجهة LayoutShift واجهة PerformanceEntry ). ومع ذلك، لا ينطبق مفهوم المدة على أحداث متغيّرات التصميم، لذا تم ضبطها على 0 . للحصول على معلومات عن واجهة PerformanceEntry ، يُرجى الرجوع إلى المواصفات. |
LayoutShiftAttribution
تصف واجهة LayoutShiftAttribution
عملية نقل واحدة لعنصر DOM
واحد. في حال تغيُّر عناصر متعددة أثناء متغيّرات التصميم، ستتغيّر السمة sources
على إدخالات متعددة.
على سبيل المثال، يتوافق تنسيق JSON أدناه مع تغيير في التنسيق من مصدر واحد:
الانتقال للأسفل لعنصر <div id='banner'>
DOM من y: 76
إلى
y:246
.
// ...
"sources": [
{
"node": "div#banner",
"previousRect": {
"x": 311,
"y": 76,
"width": 4,
"height": 18,
"top": 76,
"right": 315,
"bottom": 94,
"left": 311
},
"currentRect": {
"x": 311,
"y": 246,
"width": 4,
"height": 18,
"top": 246,
"right": 315,
"bottom": 264,
"left": 311
}
}
]
تحدّد السمة node
عنصر HTML الذي تم نقله. يؤدي تمرير مؤشر الماوس فوق هذه
السمة في أدوات مطوّري البرامج إلى تمييز عنصر الصفحة المقابل.
تُبلِغ السمتَان previousRect
وcurrentRect
عن حجم
العقدة وموضعها.
- تُستخدَم الإحداثيتان
x
وy
لعرض إحداثي x وإحداثي y للزاوية العلوية اليسرى من العنصر على التوالي. - تعرض السمتان
width
وheight
بيانات عن العرض والارتفاع على التوالي. للعنصر. - تُبلغ السمات
top
وright
وbottom
وleft
عن س أو ص. القيم الإحداثية المقابلة للحافة المحددة للعنصر. بعبارة أخرى، كلمة، قيمةtop
تساويy
؛ قيمةbottom
تساويy+height
إذا تم ضبط جميع سمات previousRect
على 0، يعني ذلك أنّ العنصر
انتقَل إلى العرض. إذا تم ضبط جميع سمات currentRect
على 0، يعني ذلك
أنّ العنصر قد تم نقله خارج نطاق العرض.
ومن أهم الأشياء التي يجب فهمها عند تفسير هذه المخرجات العناصر المدرَجة على أنّها مصادر هي العناصر التي تغيّرت متغيّرات التصميم. ومع ذلك، من الممكن أن تكون هذه العناصر بشكل غير مباشر المتعلقة بـ "السبب الجذري" لعدم استقرار التخطيط. وفي ما يلي بعض الأمثلة.
المثال 1
سيتم الإبلاغ عن متغيّرات التصميم هذا باستخدام مصدر واحد، وهو العنصر "ب". ومع ذلك، فإنّ السبب الأساسي لتغيير التنسيق هذا هو التغيير في حجم العنصر "أ".
المثال الثاني
سيتم تسجيل تغيير التنسيق في هذا المثال من خلال مصدرَين: العنصر "أ" والعنصر "ب". إنّ السبب الأساسي لمتغيّرات التصميم هذا هو التغيّر في موضع العنصر A.
المثال الثالث
سيتم الإبلاغ عن متغيّرات التصميم في هذا المثال باستخدام مصدر واحد: العنصر B. أدّى تغيير موضع العنصر "ب" إلى حدوث هذا التغيُّر في التنسيق.
المثال 4
على الرغم من أنّ حجم العنصر "ب" يتغيّر، لا يحدث أيّ تغيير في التنسيق في هذا المثال.
يمكنك الاطّلاع على عرض توضيحي لكيفية الإبلاغ عن تغييرات نموذج العناصر في المستند (DOM) من خلال واجهة برمجة التطبيقات Layout Instability API.
أدوات مطوري البرامج
لوحة الأداء
يعرض جزء التجربة في لوحة أداء "أدوات مطوّري البرامج" الكل متغيّرات التصميم التي تحدث خلال تتبُّع أداء معيّن، حتى في حال حدوثها خلال 500 ملّي ثانية من تفاعل المستخدم، وبالتالي لا يتم احتسابها ضمن متغيّرات التصميم التراكمية (CLS). تمرير مؤشر الماوس فوق متغيّر تصميم معيّن في أبرز ميزات لوحة التجربة عنصر DOM المتأثر.
للاطّلاع على مزيد من المعلومات عن تغيُّر التصميم، انقر على تغيُّر التصميم، ثم
افتح الدرج الملخّص. يتم إدراج التغييرات على أبعاد العنصر
باستخدام التنسيق [width, height]
، ويتم إدراج التغييرات على موضع العنصر
باستخدام التنسيق [x,y]
. تشير الخاصية تحتوي على إدخال حديث إلى ما إذا كان
حدث متغيّرات التصميم في غضون 500 ملّي ثانية من تفاعل المستخدِم.
للحصول على معلومات عن مدة تغيير التنسيق، افتح علامة التبويب سجلّ الأحداث. يمكن أيضًا تقدير مدة تغيير التنسيق من خلال البحث في لوحة التجربة عن طول المستطيل الأحمر لتغيير التنسيق.
لمزيد من المعلومات عن استخدام لوحة الأداء، يمكنك الرجوع إلى مقالة الأداء. تحليل المرجع:
تسليط الضوء على مناطق التغيّر في التصميم
يمكن أن يكون تمييز مناطق متغيّرات التصميم من الأساليب المفيدة للحصول على تصوّر سريع ومباشر عن الموقع الجغرافي وتوقيت متغيّرات التصميم التي تحدث في الصفحة.
لتفعيل ميزة "مناطق متغيّرات التصميم" في "أدوات مطوري البرامج"، انتقِل إلى الإعدادات > المزيد من الأدوات > العرض > مناطق متغيّرات التصميم ثم إعادة تحميل الصفحة التي تريد تصحيح أخطائها سيتم تمييز مناطق تغيُّر التصميم مؤقتًا باللون الأرجواني.
عملية التفكير لتحديد سبب حدوث تغييرات في التنسيق
يمكنك اتّباع الخطوات التالية لتحديد سبب متغيّرات التصميم بغض النظر عن وقت أو كيفية حدوث متغيّر التصميم. يمكن تنفيذ هذه الخطوات مع تشغيل Lighthouse، يُرجى العلم أن لتحديد متغيّرات التصميم التي حدثت أثناء التحميل الأولي للصفحة فقط. بالإضافة إلى ذلك، يمكن أن يوفّر Lighthouse أيضًا اقتراحات لبعض أسباب التحولات في التنسيق، مثل عناصر الصور التي لا تتضمّن عرضًا وارتفاعًا واضحَين.
تحديد سبب تغيُّر التنسيق
يمكن أن تنتج متغيّرات التصميم عن الأحداث التالية:
- تغييرات موضع عنصر DOM
- التغييرات في أبعاد عنصر DOM
- إدراج عنصر DOM أو إزالته
- الصور المتحركة التي تؤدي إلى عرض التنسيق
وعلى وجه الخصوص، فإنّ عنصر DOM الذي يسبق العنصر الذي تمّ نقله مباشرةً هو العنصر الأكثر احتمالًا أن يكون "سببًا" في حدوث تغيير في التصميم. وبالتالي، عند التحقيق من سبب حدوث تغيير في التصميم، يجب مراعاة ما يلي:
- هل تغيّر موضع العنصر السابق أو أبعاده؟
- هل تم إدراج عنصر DOM أو إزالته قبل العنصر الذي تم نقله؟
- هل تم تغيير موضع العنصر الذي تم نقله بشكل صريح؟
إذا لم يتسبب العنصر السابق في تغيير التنسيق، يمكنك مواصلة البحث من خلال مراعاة العناصر السابقة والعناصر المجاورة الأخرى.
بالإضافة إلى ذلك، يمكن أن يقدّم اتجاه ومدى تغيُّر التصميم إشارات حول السبب الأساسي. على سبيل المثال، غالبًا ما يشير التحول الكبير للأسفل إلى إدراج عنصر DOM، في حين يشير التحول في التنسيق بمقدار بكسل واحد أو اثنين غالبًا إلى تطبيق أنماط CSS متضاربة أو تحميل ملف خط ويب وتطبيقه.
في ما يلي بعض السلوكيات المحدّدة التي تؤدي غالبًا إلى حدوث متغيّرات التصميم الأحداث:
التغييرات في موضع عنصر (التي لا ترجع إلى حركة عنصر آخر)
غالبًا ما يكون هذا النوع من التغيير نتيجة:
- جداول الأنماط التي يتم تحميلها متأخرًا أو تستبدل الأنماط التي تمّ الإعلان عنها سابقًا
- تأثيرات الرسوم المتحركة والانتقالات
التغييرات في أبعاد أحد العناصر
غالبًا ما يكون هذا النوع من التغييرات نتيجةً لما يلي:
- جداول الأنماط التي يتم تحميلها متأخرًا أو تستبدل الأنماط التي تمّ الإعلان عنها سابقًا
- الصور وإطارات iframe بدون السمتين
width
وheight
التي يتم تحميلها بعد "خانة" "تم عرضه". - المجموعات النصية التي لا تحتوي على السمتَين
width
أوheight
والتي تبدِّل الخطوط بعد تم عرض النص.
إدراج عناصر DOM أو إزالتها
غالبًا ما يحدث ذلك نتيجة:
- إدراج إعلانات وعمليات تضمين أخرى تابعة لجهات خارجية
- إدراج إعلانات البانر والتنبيهات والنوافذ المنبثقة
- التمرير اللا نهائي وأنماط تجربة المستخدم الأخرى التي تُحمِّل محتوى إضافيًا أعلاه المحتوى الحالي.
الصور المتحركة التي تؤدي إلى تشغيل التنسيق
يمكن لبعض تأثيرات الرسوم المتحركة أن تؤدي
. من الشائع
مثال على ذلك عندما تكون عناصر DOM "متحرّكة" من خلال زيادة عدد السمات
مثل top
أو left
بدلاً من استخدام
transform
الموقع. اطّلِع على كيفية إنشاء صور متحركة عالية الأداء باستخدام CSS
لمزيد من المعلومات.
إعادة إنشاء متغيّرات التصميم
لا يمكنك إصلاح تغييرات التنسيق التي لا يمكنك إعادة إنتاجها. من أبسط الإجراءات التي يمكنك اتّخاذها، وأحد أكثرها فعالية في الوقت نفسه، للتعرّف بشكل أفضل على ثبات تنسيق موقعك الإلكتروني هو تخصيص 5 إلى 10 دقائق للتفاعل مع موقعك الإلكتروني بهدف بدء عمليات تغيير التنسيق. اترك وحدة التحكّم مفتوحة أثناء إجراء ذلك واستخدِم واجهة برمجة التطبيقات Layout Instability API لإعداد تقارير عن تغييرات التنسيق.
لصعوبة تحديد موقع متغيّرات التصميم، ضع في اعتبارك تكرار هذا التمرين مع
أجهزة وسرعات اتصال مختلفة. على وجه الخصوص، يمكن أن يسهّل استخدام سرعة اتصال
أبطأ تحديد التحولات في التنسيق. بالإضافة إلى ذلك،
يمكنك استخدام عبارة debugger
لتسهيل التنقل بين التنسيقات
التبديلات.
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
if (!entry.hadRecentInput) {
cls += entry.value;
debugger;
console.log('Current CLS value:', cls, entry);
}
}
}).observe({type: 'layout-shift', buffered: true});
وأخيرًا، بالنسبة إلى مشاكل التنسيق التي لا يمكن تكرارها أثناء التطوير، باستخدام واجهة برمجة التطبيقات Layout Instability API مع أداة تسجيل الواجهة الأمامية الاختيار لجمع المزيد من المعلومات حول هذه المشكلات. إتمام الدفع مثال على الرمز البرمجي لكيفية تتبُّع أكبر عنصر يتغيّر في إحدى الصفحات.