TL;DR
بدءًا من الإصدار 53 من Chrome، تتم إعادة تحويل جميع المحتوى إلى شبكة بكسل عند تغيُّر مقياس التحويل
، إذا لم يكن يحتوي على خاصية will-change: transform في CSS. بعبارة أخرى، will-change: transform تعني "يُرجى إضافة حركة سريعة".
لا ينطبق ذلك إلا على مقاييس التحويل التي تحدث من خلال التلاعب بالنصوص البرمجية، ولا ينطبق على الصور المتحركة في CSS أو Web Animations.
وهذا يعني أنّه من المرجّح أن يحصل موقعك الإلكتروني على محتوى يبدو أفضل، ولكن قد يكون أيضًا أبطأ بدون إجراء بعض التغييرات البسيطة الموضّحة أدناه.
الآثار المترتبة على مطوّري الويب
بموجب هذا التغيير، يمكن اعتبار will-change: transform أنّه يفرض
تحويل المحتوى إلى صورة نقطية ثابتة، والتي لا تتغيّر أبدًا بعد ذلك
بموجب تعديلات التحويل. يتيح ذلك للمطوّرين زيادة سرعة
الرسوم المتحركة للتحويل على الصورة النقطية هذه، مثل نقلها أو تدويرها أو
تكبيرها أو تصغيرها.
لا نفرق بين عمليات التحويل على مستوى الحجم والترجمة.
الإجراءات المقترَحة
ضَع الرمز will-change: transform على العناصر عندما تحتاج إلى سرعات تحول سريعة جدًا (بمعنى آخر، 60 لقطة في الثانية) للصور المتحركة، ومن المتوقّع أنّ تحويل will-change: transformالعنصر بجودة عالية في كل لقطة ليس سريعًا بما يكفي. وبخلاف ذلك، تجنَّب
will-change: transform.
لتحسين موازنة الأداء والجودة، قد تحتاج إلى إضافة will-change:
transform عند بدء الصور المتحركة وإزالتها عند انتهائها. يُرجى العِلم أنّه
غالبًا ما تكون هناك تكلفة أداء كبيرة لمرة واحدة عند إضافة
will-change: transform أو إزالتها.
اعتبارات إضافية متعلقة بالتنفيذ
تؤدي إزالة will-change: transform إلى إعادة تحويل المحتوى إلى شبكة بكسل بدرجة دقة
عالية، ولكن في إطار الصورة المتحركة التالي فقط (من خلال requestAnimationFrame)). وبالتالي،
إذا كانت لديك طبقة تحتوي على will-change: transform وأردت ببساطة
بدء عملية إعادة تحويل إلى شبكة بكسل ولكن مواصلة إضافة الحركة، عليك إزالة will-change:
transform، ثم إعادة إضافتها في requestAnimationFrame() callback.
إذا أردت في أي وقت أثناء عرض صورة متحركة استخدام تنسيق رسومات نقطية بالحجم الحالي،
طبِّق التقنية أعلاه لإزالتها في إطار واحد، ثم أعِد إضافتها will-change:
transform في إطار لاحق.
وقد يؤدي ذلك إلى فقدان المحتوى لطبقته المركبة،
مما يجعل الاقتراح أعلاه ذا تكلفة مرتفعة إلى حد ما. إذا كانت هذه مشكلة،
ننصح بإضافة transform: translateZ(0) إلى المحتوى أيضًا لضمان
بقائه في طبقة مركبة أثناء هذه العملية.
ملخّص التأثير
يؤثر هذا التغيير في جودة المحتوى المعروض وأدائه ومقدار التحكّم الذي يمارسه المطوّر.
- جودة المحتوى المعروض: ستكون النتيجة المعروضة للعناصر التي تُحرِّك تحوّل حجمها دائمًا واضحة بشكلٍ تلقائي.
- الأداء: سيكون التحريك سريعًا عند استخدام
will-change: transform. - تحكّم المطوّر: يمكن للمطوّرين الاختيار بين الجودة والسرعة، وذلك
على أساس كل عنصر وكل إطار من إطارات الصور المتحركة من خلال إضافة
will-change: transformوإزالته.
اطّلِع على مستند التصميم المُشار إليه أعلاه للحصول على مزيد من التفاصيل.
أمثلة
في هذا المثال، سيظلّ العنصر الذي يحمل المعرّف
remainsBlurry مموّهًا بعد هذا التغيير، ولكن سيظهر العنصر الذي يحمل المعرّف
noLongerBlurry بوضوح. ويعود السبب في ذلك إلى أنّ الصفحة الأولى تحتوي على خاصية will-
change: transform CSS.
أمثلة على الرسوم المتحركة لتغيير الحجم من تطبيقات حقيقية
- من هذا الخطأ: تكبير صورة نمر
- خرائط Google على الأجهزة الجوّالة (maps.google.com): تكبير/تصغير الخريطة
- "خرائط Google" في الوضع البسيط على الكمبيوتر المكتبي
- خريطة مقاعد Ticketmaster