تعرَّف على كيفية تحديد متغيّرات التصميم وإصلاحها.
يتناول الجزء الأول من هذه المقالة أدوات تصحيح أخطاء متغيّرات التصميم بينما يناقش الجزء الثاني عملية التفكير التي يجب استخدامها عند تحديد سبب تغيُّر التصميم.
الأدوات
واجهة برمجة تطبيقات عدم استقرار التنسيق
واجهة برمجة التطبيقات Layout Instability API آلية المتصفّح لقياس متغيّرات التصميم والإبلاغ عنها جميع الأدوات الخاصة بـ ففي نهاية الأمر، يتم تصميم متغيّرات التصميم لتصحيح الأخطاء، بما في ذلك "أدوات مطوري البرامج"، استنادًا إلى واجهة برمجة تطبيقات 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
حتى سلسلة المحادثات غير نشطة للإبلاغ عن متغيّرات التصميم. نتيجة لذلك، اعتمادًا على مدى مشغولاً بسلسلة التعليمات الرئيسية، فقد يكون هناك تأخير بسيط بين وقت تنفيذ Shift وعند تسجيل الدخول إلى وحدة التحكم. - يتجاهل هذا النص البرمجي متغيّرات التصميم التي حدثت خلال 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 أدناه مع متغيّر تصميم يتضمّن مصدرًا واحدًا:
الانتقال للأسفل في عنصر DOM <div id='banner'>
من 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
الإحداثي السيني والإحداثي y. على التوالي في الزاوية العلوية اليسرى من العنصر - تعرض السمتان
width
وheight
بيانات عن العرض والارتفاع على التوالي. للعنصر. - تُبلغ السمات
top
وright
وbottom
وleft
عن س أو ص. القيم الإحداثية المقابلة للحافة المحددة للعنصر. بعبارة أخرى، كلمة، قيمةtop
تساويy
؛ قيمةbottom
تساويy+height
إذا تم ضبط جميع خصائص previousRect
على 0، فهذا يعني أن العنصر
تحولت إلى وضع العرض. يعني ذلك أنّه إذا تم ضبط جميع خصائص currentRect
على 0.
أن العنصر قد تحيد عن إطار العرض.
ومن أهم الأشياء التي يجب فهمها عند تفسير هذه المخرجات العناصر المدرَجة على أنّها مصادر هي العناصر التي تغيّرت متغيّرات التصميم. ومع ذلك، من الممكن أن تكون هذه العناصر بشكل غير مباشر المتعلقة بـ "السبب الجذري" لعدم استقرار التخطيط. وفي ما يلي بعض الأمثلة.
المثال 1
سيتم الإبلاغ عن متغيّرات التصميم هذا باستخدام مصدر واحد، وهو العنصر "ب". ومع ذلك، السبب الأساسي لمتغيّرات التصميم هذا هو التغيّر في حجم العنصر A.
المثال الثاني
سيتم الإبلاغ عن متغيّرات التصميم في هذا المثال من خلال مصدرَين: العنصر A. والعنصر B. يكمن السبب الأساسي لمتغيّرات التصميم هذا في التغيير في موضع العنصر A.
المثال الثالث
سيتم الإبلاغ عن متغيّرات التصميم في هذا المثال باستخدام مصدر واحد: العنصر B. أدى تغيير موضع العنصر B إلى متغيّرات التصميم هذا.
المثال الرابع
على الرغم من تغيير حجم العنصر B، فلا يوجد متغير تخطيط في هذا المثال.
يمكنك الاطّلاع على عرض توضيحي لكيفية الإبلاغ عن تغييرات نموذج العناصر في المستند (DOM) من خلال واجهة برمجة التطبيقات Layout Instability API.
أدوات مطوري البرامج
لوحة الأداء
يعرض جزء التجربة في لوحة أداء "أدوات مطوّري البرامج" الكل متغيّرات التصميم التي تحدث خلال تتبُّع أداء معيّن، حتى في حال حدوثها خلال 500 ملّي ثانية من تفاعل المستخدم، وبالتالي لا يتم احتسابها ضمن متغيّرات التصميم التراكمية (CLS). تمرير مؤشر الماوس فوق متغيّر تصميم معيّن في أبرز ميزات لوحة التجربة عنصر DOM المتأثر.
للاطّلاع على مزيد من المعلومات حول متغيّرات التصميم، انقر على متغيّر التصميم، ثم
افتح درج الملخّص. يتم سرد التغييرات التي يتم إجراؤها على أبعاد العنصر
باستخدام التنسيق [width, height]
؛ يتم سرد التغييرات التي تطرأ على موضع العنصر
باستخدام التنسيق [x,y]
. تشير الخاصية تحتوي على إدخال حديث إلى ما إذا كان
حدث متغيّرات التصميم في غضون 500 ملّي ثانية من تفاعل المستخدِم.
للحصول على معلومات عن مدة متغيّرات التصميم، افتح علامة التبويب سجلّ الأحداث. يمكن أيضًا تقدير مدة متغيّرات التصميم من خلال الاطّلاع على لوحة التجربة لطول مستطيل متغيّرات التصميم الأحمر.
لمزيد من المعلومات عن استخدام لوحة الأداء، يمكنك الرجوع إلى مقالة الأداء. تحليل المرجع:
تمييز مناطق متغيّرات التصميم
يمكن أن يكون إبراز مناطق متغيّرات التصميم طريقة مفيدة للحصول على نظرة سريعة وسريعة على الموقع وتوقيت متغيرات التصميم تحدث على الصفحة.
لتفعيل ميزة "مناطق متغيّرات التصميم" في "أدوات مطوري البرامج"، انتقِل إلى الإعدادات > المزيد من الأدوات > العرض > مناطق متغيّرات التصميم ثم إعادة تحميل الصفحة التي تريد تصحيح أخطائها سيتم تمييز مناطق متغيّرات التصميم لفترة وجيزة باللون الأرجواني.
عملية فكرية لتحديد سبب تغيُّرات التصميم
يمكنك اتّباع الخطوات التالية لتحديد سبب متغيّرات التصميم بغض النظر عن وقت أو كيفية حدوث متغيّر التصميم. يمكن تنفيذ هذه الخطوات مع تشغيل Lighthouse، يُرجى العلم أن لتحديد متغيّرات التصميم التي حدثت أثناء التحميل الأولي للصفحة فقط. ضِمن بالإضافة إلى ذلك، يمكن لأداة Lighthouse أيضًا تقديم اقتراحات لبعض أسباب تصميم التحولات — على سبيل المثال، عناصر الصور التي ليس لها عرض وارتفاع واضحان.
تحديد سبب تغيُّر التصميم
يمكن أن تنتج متغيّرات التصميم عن الأحداث التالية:
- تغييرات موضع عنصر DOM
- التغييرات في أبعاد عنصر DOM
- إدراج عنصر DOM أو إزالته
- الصور المتحركة التي تؤدي إلى تشغيل التنسيق
على وجه الخصوص، يُعد عنصر DOM الذي يسبق العنصر الذي تم نقله مباشرةً العنصر الأكثر احتمالاً أن يشارك في "السبب" متغيّرات التصميم. وبالتالي، عندما التحقيق في سبب حدوث متغيّرات التصميم:
- هل تغير موضع أو أبعاد العنصر السابق؟
- هل تم إدراج عنصر DOM أو إزالته قبل العنصر الذي تم نقله؟
- هل تم تغيير موضع العنصر الذي تم نقله بشكل صريح؟
إذا لم يؤدِّ العنصر السابق إلى حدوث متغيّرات التصميم، يمكنك مواصلة البحث من خلال مع الأخذ في الاعتبار العناصر السابقة والمجاورة الأخرى.
بالإضافة إلى ذلك، يمكن أن يقدّم اتجاه متغيّرات التصميم ومسافتها تلميحات حول السبب الجذري. فعلى سبيل المثال، غالبًا ما يشير التحوّل الكبير المتجه للأسفل إلى إدراج عنصر DOM، في حين يشير متغيّرات التصميم 1 بكسل أو 2 بكسل غالبًا إلى تطبيق أنماط 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 مع أداة تسجيل الواجهة الأمامية الاختيار لجمع المزيد من المعلومات حول هذه المشكلات. إتمام الدفع مثال على الرمز البرمجي لكيفية تتبُّع أكبر عنصر متغيّرة في الصفحة.