تعرّف على كيفية قياس الرسوم المتحركة وكيفية التفكير في إطارات الصور المتحركة وسلاسة الصفحة بشكل عام.
ربما تكون قد واجهت صفحات "تتذبذب" أو "تتجمد" أثناء التمرير أو الرسوم المتحركة. نود أن نقول إن هذه التجارب ليست سلسة. لمعالجة هذه الأنواع من المشاكل، يعمل فريق Chrome على إضافة المزيد من الدعم إلى أدواتنا الاختبارية لرصد الصور المتحركة، بالإضافة إلى إجراء تحسينات ثابتة على بيانات تشخيص مسار العرض في Chromium.
نود مشاركة بعض التقدم الأخير وتقديم إرشادات ملموسة حول الأدوات، ومناقشة أفكار لمقاييس سلاسة الرسوم المتحركة المستقبلية. كالعادة، يسعدنا تلقّي ملاحظاتك.
سنتناول في هذه المشاركة ثلاثة مواضيع رئيسية:
- نظرة سريعة على الصور المتحركة وإطارات الصور المتحركة.
- أفكارنا الحالية حول قياس سلاسة الصور المتحركة بشكل عام
- إليك بعض الاقتراحات العملية التي يمكنك الاستفادة منها اليوم في أدوات المختبر.
ما هي الرسوم المتحركة؟
الصور المتحركة تنبض بالحياة! من خلال تحريك المحتوى، خاصة استجابةً لتفاعلات المستخدم، يمكن أن تجعل الرسوم المتحركة التجربة تبدو أكثر طبيعية وفهمة ومتعة.
لكن الرسوم المتحركة التي تم تنفيذها بشكل سيئ، أو مجرد إضافة عدد كبير جدًا من الرسوم المتحركة، يمكن أن تخفض التجربة وتجعلها غير ممتعة على الإطلاق. ربما تفاعلنا جميعًا باستخدام واجهة أضافت للتو الكثير من تأثيرات الانتقال "المفيدة"، والتي أصبحت في الواقع عدوانية عندما يكون أداؤها ضعيفًا. لذلك، قد يفضّل بعض المستخدمين الحركة المنخفضة، وهو تفضيل للمستخدم يجب الالتزام به.
كيف تعمل الصور المتحركة؟
باختصار، يتألّف مسار العرض من بضع مراحل تسلسلية:
- النمط: احسب الأنماط التي تنطبق على العناصر.
- التنسيق: أنشئ الشكل الهندسي والموضع لكل عنصر.
- رسم: املأ وحدات البكسل لكل عنصر إلى طبقات.
- المُركّب: ارسم الطبقات على الشاشة.
في حين أن هناك العديد من الطرق لتعريف الرسوم المتحركة، إلا أنها تعمل جميعها بشكل أساسي عبر أحد الأشياء التالية:
- ضبط خصائص layout.
- ضبط خصائص paint.
- تعديل الخصائص المركبة.
نظرًا لأن هذه المراحل متسلسلة، فمن المهم تحديد الرسوم المتحركة من حيث الخصائص التي تقع في أسفل المسار. كلما حدث التحديث في وقت مبكر في العملية، زادت التكاليف ومن المرجح أن يكون سلسًا. (راجع أداء العرض للحصول على مزيد من التفاصيل).
على الرغم من أنّه قد يكون من السهل تحريك خصائص التخطيط، إلا أن هناك تكاليف لإجراء ذلك، حتى لو لم تظهر هذه التكاليف على الفور. يجب تعريف الرسوم المتحركة من حيث تغييرات الخصائص المركّبة كلما أمكن ذلك.
يُعدّ تحديد الصور المتحركة في CSS التعريفية أو استخدام Web Animations والتأكد من تحريك الخصائص المركّبة خطوة أولى رائعة لضمان الحصول على صور متحركة سلسة وفعّالة. ولكن لا يزال، هذا وحده لا يضمن السلاسة لأنه حتى الرسوم المتحركة الفعالة على الويب لديها حدود للأداء. لهذا السبب من المهم دائمًا القياس!
ما هي إطارات الرسوم المتحركة؟
تستغرق التعديلات على التمثيل المرئي للصفحة بعض الوقت لتظهر. سيؤدي التغيير المرئي إلى إطار رسوم متحركة جديد، والذي يتم عرضه في النهاية على شاشة المستخدم.
لعرض التحديث عند حدوث بعض الفترات الزمنية، بحيث يتم تجميع التحديثات المرئية. يتم تحديث العديد من شاشات العرض بعد فاصل زمني ثابت، مثلاً 60 مرة في الثانية (أي 60 هرتز). ويمكن لبعض الشاشات الحديثة توفير معدّلات تحديث أعلى (من 90 إلى 120 هرتز). وغالبًا ما تتوافق شاشات العرض هذه بشكل نشط بين معدلات التحديث حسب الحاجة أو يمكنها أيضًا توفير عدد لقطات متغيّر بالكامل في الثانية.
يكمن الهدف من أي تطبيق، مثل لعبة أو متصفح، في معالجة كل هذه التحديثات المرئية المجمّعة وإنتاج إطار صور متحركة كامل مرئيًا خلال الموعد النهائي، في كل مرة. تجدر الإشارة إلى أنّ هذا الهدف يختلف تمامًا عن مهام المتصفّح المهمة الأخرى، مثل تحميل المحتوى من الشبكة بسرعة أو تنفيذ مهام JavaScript بكفاءة.
في مرحلة ما، قد يصبح من الصعب جدًا إكمال جميع التحديثات المرئية ضمن الموعد النهائي المخصص الذي تحدده الشاشة. عندما يحدث هذا، يسقط المتصفّح إطارًا. لن تتحول الشاشة إلى اللون الأسود، بل تكرر نفسها. ترى نفس التحديث المرئي لفترة أطول قليلاً - نفس إطار الرسوم المتحركة الذي تم تقديمه في فرصة الإطار السابقة.
هذا يحدث في الواقع غالبًا! ليس بالضرورة أن يتم رصده، خاصةً بالنسبة إلى المحتوى الثابت أو الشبيه بالمستندات، وهو أمر شائع على منصة الويب على وجه الخصوص. لا تظهر الإطارات المسقطة إلا عند وجود تحديثات مرئية مهمة، مثل الرسوم المتحركة، والتي نحتاج من أجلها إلى تدفق مستمر من تحديثات الرسوم المتحركة لإظهار حركة سلسة.
ما الذي يؤثر في إطارات الصور المتحركة؟
يمكن لمطوّري الويب التأثير بشكل كبير في قدرة المتصفح على عرض التحديثات المرئية وتقديمها بسرعة وكفاءة!
إليك بعض الأمثلة:
- استخدام محتوى كبير جدًا أو يتطلب موارد كثيرة جدًا بحيث يتعذّر فك ترميزه بسرعة على الجهاز المستهدف
- استخدام عدد كبير جدًا من الطبقات يتطلب مساحة كبيرة جدًا من ذاكرة وحدة معالجة الرسومات.
- تحديد أنماط CSS المعقدة للغاية أو الصور المتحركة على الويب.
- استخدام أنماط مضادة للأنماط تعمل على إيقاف تحسينات العرض السريع
- يعمل مقدار كبير جدًا من JavaScript على سلسلة التعليمات الرئيسية، مما يؤدي إلى مهام طويلة تحظر التحديثات المرئية.
ولكن كيف يمكنك معرفة متى فات إطار الرسوم المتحركة الموعد النهائي وتسبب في إسقاط الإطار؟
إحدى الطرق الممكنة هي استخدام
requestAnimationFrame()
الاستطلاع، ولكن له العديد من الجوانب السلبية. يخبر requestAnimationFrame()، أو "rAF"، المتصفّح بأنّك تريد تنفيذ رسم متحرك، ويطلب
فرصة لإجراء ذلك قبل مرحلة الرسم التالية من مسار العرض. إذا لم يتم استدعاء دالة معاودة الاتصال في الوقت الذي تتوقعه، فهذا يعني
عدم تنفيذ الرسم وأنه تم تخطي إطار واحد أو أكثر. من خلال الاستطلاع وحساب عدد مرات استدعاء rAF، يمكنك حساب نوع من مقاييس "الإطارات في الثانية" (FPS).
let frameTimes = [];
function pollFramesPerSecond(now) {
frameTimes = [...frameTimes.filter(t => t > now - 1000), now];
requestAnimationFrame(pollFramesPerSecond);
console.log('Frames per second:', frameTimes.length);
}
requestAnimationFrame(pollFramesPerSecond);
لا ننصحك باستخدام استطلاع requestAnimationFrame() لعدة أسباب:
- يجب أن يعد كل نص برمجي حلقة استطلاع خاصة به.
- يمكنه حجب المسار الحرج.
- حتى إذا كان استطلاع RAF سريعًا، يمكن أن يمنع
requestIdleCallback()من إمكانية جدولة أجزاء طويلة غير مستخدَمة من قِبل البحث عند استخدامها بشكلٍ مستمر (أي الوحدات التي يتجاوز حجمها إطارًا واحدًا). - وبالمثل، يؤدي عدم حظر عمليات الحظر الطويل الأمد إلى منع المتصفِّح من جدولة المهام الأخرى طويلة الأمد (مثل جمع البيانات غير المرغوب فيها لفترة أطول وغيرها من العمليات التي يتم تنفيذها في الخلفية أو التوقُّع).
- إذا تم تفعيل ميزة "استطلاعات الرأي" أو إيقافها، لن يفوتك الحالات التي تم فيها تجاوز ميزانية الإطار.
- سيتم الإبلاغ عن نتائج الاستطلاع عن حالات إيجابية خاطئة في الحالات التي يستخدم فيها المتصفِّح معدّل تكرار متغير للتحديثات (على سبيل المثال، بسبب حالة الطاقة أو مستوى الرؤية).
- والأهم من ذلك، أنها لا تلتقط في الواقع جميع أنواع تحديثات الرسوم المتحركة!
يمكن أن يؤدي بذل الكثير من الجهد في سلسلة التعليمات الرئيسية إلى التأثير في إمكانية رؤية إطارات الصور المتحركة. يمكنك الاطّلاع على نموذج Jankلمعرفة كيف تؤدي الصور المتحركة التي تعتمد على RAF، مع وجود الكثير من العمل في سلسلة التعليمات الرئيسية (مثل التنسيق)، إلى تجاهل الإطارات وتقليل عدد عمليات استدعاء RAF وانخفاض عدد اللقطات في الثانية.
عندما تتوقف سلسلة التعليمات الرئيسية، تبدأ التحديثات المرئية في التعثر. هذا غير صحيح!
ركزت العديد من أدوات القياس بشكل كبير على قدرة سلسلة التعليمات الرئيسية على تحقيق أرباح في الوقت المناسب، وعلى تشغيل إطارات الصور المتحركة بسلاسة. لكن هذه ليست القصة الكاملة! راجع المثال التالي:
يعرض الفيديو أعلاه صفحة تُدخل مهامًا طويلة بشكل دوري في سلسلة التعليمات الرئيسية. تؤدي هذه المهام الطويلة إلى تدمير قدرة الصفحة على توفير أنواع معيّنة من التعديلات المرئية، ويمكنك رؤية انخفاض مماثل في أعلى يسار الصفحة لـ requestAnimationFrame() بقيمة 0 لقطة في الثانية.
وعلى الرغم من هذه المهام الطويلة، يستمر الانتقال في الصفحة بسلاسة. وذلك لأنه في المتصفحات الحديثة، غالبًا ما يكون التمرير مترابطًا، ويتم التحكم فيه من خلال المكوّن بالكامل.
هذا مثال يحتوي في وقت واحد على العديد من الإطارات التي تم إسقاطها في سلسلة التعليمات الرئيسية، ولكن لا يزال به العديد من الإطارات التي تم تسليمها بنجاح من التمرير في سلسلة التعليمات للمكون. بعد اكتمال هذه المهمّة التي تستغرق وقتًا طويلاً، لن يكون هناك أي تغيير مرئي يمكن أن يقدّمه تحديث الرسم البياني لسلسلة المحادثات الرئيسية على أي حال. اقترحت استطلاعات rAF انخفاض الإطار إلى 0، ولكن من الناحية المرئية، لن يكون بإمكان المستخدم ملاحظة أي فرق.
بالنسبة لإطارات الرسوم المتحركة، فإن القصة ليست بهذه البساطة.
إطارات الصور المتحركة: التحديثات المهمة
يوضِّح المثال أعلاه أنّ القصة تتضمّن المزيد من التفاصيل بالإضافة إلى السمة requestAnimationFrame().
متى تُعتبر تحديثات الصور المتحركة وإطارات الصور المتحركة أمرًا مهمًا؟ فيما يلي بعض المعايير التي نأخذها في الاعتبار ونرغب في الحصول على ملاحظات بشأنها:
- إشعارات سلسلة التعليمات الرئيسية وأداة إنشاء الرسائل
- تحديثات عرض محتوى الصفحة غير متوفرة
- اكتشاف الرسوم المتحركة
- الجودة مقابل الكمية
إشعارات سلسلة التعليمات الرئيسية وأداة إنشاء الرسائل
تعديلات إطار الصور المتحركة ليست منطقية. ليس الأمر أن يتم إسقاط الإطارات بشكل كامل أو تقديمها بالكامل فقط. هناك أسباب عديدة وراء احتمال تقديم إطار صور متحركة جزئيًا. بعبارة أخرى، يمكن أن يتضمّن التطبيق بعض المحتوى القديم مع عرض بعض التحديثات المرئية الجديدة.
ويتمثل المثال الأكثر شيوعًا على ذلك في الحالات التي يتعذّر فيها على المتصفِّح إصدار تحديث مترابط لسلسلة تعليمات رئيسية جديد خلال الموعد النهائي للإطار ولكن عند توفُّر تحديث جديد لسلسلة تعليمات المكوّن الإضافي (مثل مثال التمرير المتسلسل في وقت سابق).
من بين الأسباب المهمة التي تجعل استخدام الرسوم المتحركة التعريفية لتحريك الخصائص المركّبة هو أن ذلك يتيح إدارة الرسوم المتحركة بشكل كامل بواسطة مؤشر ترابط المؤلف حتى عندما يكون مؤشر الترابط الرئيسي مشغولاً. يمكن لهذه الأنواع من الرسوم المتحركة أن تستمر في إنتاج تحديثات مرئية بكفاءة وبشكل موازي.
من ناحية أخرى، قد تكون هناك حالات يصبح فيها تحديث سلسلة التعليمات الرئيسي متاحًا أخيرًا للعرض التقديمي، ولكن فقط بعد تفويت العديد من المواعيد النهائية للإطارات. هنا سيتم تثبيت بعض التحديثات الجديدة على المتصفّح، ولكنه قد لا يكون الأحدث.
بشكل عام، نعتبر اللقطات التي تتضمّن بعض التعديلات المرئية الجديدة، بدون كل التحديثات المرئية الجديدة، باعتبارها إطارًا جزئيًا. الإطارات الجزئية شائعة إلى حد ما. من الناحية المثالية، ستتضمّن التحديثات الجزئية على الأقل أهم التحديثات المرئية، مثل الرسوم المتحركة، ولكن هذا لا يمكن أن يحدث إلا إذا كانت الرسوم المتحركة يتم تشغيلها بواسطة سلسلة التعليمات.
تحديثات عرض محتوى الصفحة غير متوفرة
هناك نوع آخر من التحديث الجزئي وهو عندما لا تنتهى من فك ترميز الوسائط مثل الصور وتحويلها إلى نقطية في الوقت المناسب لعرض الإطار.
أو حتى إذا كانت الصفحة ثابتة تمامًا، قد تتخلّف المتصفحات عن عرض التحديثات المرئية أثناء التمرير السريع. وذلك لأنه قد يتم تجاهل إصدارات وحدات البكسل للمحتوى الموجود خارج إطار العرض المرئي لتوفير ذاكرة وحدة معالجة الرسومات. يستغرق عرض وحدات البكسل بعض الوقت، وقد يستغرق عرض كل عناصر الصورة بعد تمرير كبير، مثلاً تمرير الإصبع على الشاشة أكثر من إطار واحد. ويُعرف ذلك عادةً باسم لوحة التحقق.
مع كل فرصة لعرض إطار، يمكن تتبع مقدار آخر التحديثات المرئية التي وصلت إلى الشاشة. يُعرف قياس إمكانية تنفيذ ذلك على العديد من الإطارات (أو الوقت) على نطاق واسع باسم سرعة نقل بيانات الإطار.
إذا كانت وحدة معالجة الرسومات متوقفة فعلاً، فقد يبدأ المتصفح (أو النظام الأساسي) في تقييد معدّل محاولته إجراء تحديثات مرئية وبالتالي تقليل عدد اللقطات الفعّالة في الثانية. على الرغم من أنه يمكن من الناحية الفنية تقليل عدد تحديثات الإطارات التي تم إفلاتها، سيظل يظهر بشكل مرئي كإنتاج بيانات إطار منخفض.
ومع ذلك، ليست كل أنواع سرعة معالجة الإطارات المنخفضة سيئة. إذا كانت الصفحة في الغالب غير نشطة ولا تتوفّر فيها صور متحركة نشطة، يكون عدد اللقطات المنخفض في الثانية جذابًا بصريًا مثل العدد المرتفع للقطات في الثانية (ويمكن أن يؤدي ذلك إلى توفير استهلاك البطارية).
إذًا، متى تكون سرعة نقل الإطار مهمة؟
اكتشاف الرسوم المتحركة
يكون معدل نقل بيانات الإطار المرتفع مهمًا بشكل خاص خلال الفترات التي تحتوي على صور متحركة مهمة. ستعتمد أنواع الرسوم المتحركة المختلفة على التحديثات المرئية من سلسلة رسائل محددة (رئيسي أو أداة إنشاء أو عامل)، لذا يعتمد التحديث المرئي على سلسلة التعليمات هذه التي توفر تحديثها خلال الموعد النهائي. ونقول إنّ سلسلة محادثات معيّنة تؤثّر في سلاستها كلّما كانت هناك حركة نشطة تعتمد على تحديث سلسلة المحادثات هذا.
من السهل تحديد واكتشاف بعض أنواع الرسوم المتحركة من غيرها. تكون الرسوم المتحركة التعريفية أو الرسوم المتحركة التي يُدخلها المستخدم أكثر وضوحًا من الرسوم المتحركة التي تعتمد على JavaScript والمنفذة كتحديثات دورية لخصائص النمط المتحرك.
حتى باستخدام requestAnimationFrame()، لا يمكنك دائمًا افتراض أنّ كل طلب من طلبات RAF يؤدي بالضرورة إلى إنشاء تحديث مرئي أو صورة متحركة. على سبيل المثال، إنّ استخدام استطلاع rAF لتتبّع عدد اللقطات في الثانية (كما هو موضّح أعلاه) يجب ألا يؤثر بحد ذاته في قياسات السلاسة لأنّه لا يتوفّر أي تحديث مرئي.
الجودة مقابل الكمية
أخيرًا، لا يزال اكتشاف الرسوم المتحركة وتحديثات إطار الرسوم المتحركة جزءًا فقط من القصة لأنه يلتقط كمية تحديثات الرسوم المتحركة فقط، وليس الجودة.
على سبيل المثال، قد تلاحظ أثناء مشاهدة فيديو عدد لقطات ثابتًا يبلغ 60 لقطة في الثانية. من الناحية الفنية، هذا سلس تمامًا، ولكن قد يكون معدّل نقل بيانات الفيديو نفسه منخفضًا، أو مشاكل متعلقة بالتخزين المؤقت للشبكة. لا يتم رصد ذلك من خلال مقاييس سلاسة الرسوم المتحركة مباشرةً، ومع ذلك قد لا يزال الأمر مزعجًا للمستخدم.
في المقابل، قد تكون الألعاب التي تستخدم <canvas> (وربما تستخدم أساليب مثل لوحة الرسم خارج الشاشة لضمان عدد ثابت للقطات في الثانية) سلسة تمامًا من الناحية الفنية في ما يتعلق بإطارات الصور المتحركة، وكل ذلك بدون تحميل أصول ألعاب عالية الجودة في المشهد أو عرض عناصر في العرض.
وبالطبع، قد يتضمّن الموقع الإلكتروني بعض الصور المتحركة السيئة جدًا 🙂.
أعني، أعتقد أنهم كانوا رائعين جدًا في وقتهم!
حالات إطار رسوم متحركة واحد
نظرًا لأنه قد يتم عرض الإطارات جزئيًا أو قد تحدث الإطارات التي تم إسقاطها بطرق لا تؤثر على السلاسة، فقد بدأنا باعتبار كل إطار على أنه يحصل على درجة اكتمال أو سلاسة.
في ما يلي مجموعة من الطرق التي نفسر بها حالة إطار رسوم متحركة واحد، مرتبة من الأفضل إلى الأسوأ:
| ما مِن تحديث مطلوب | وقت عدم النشاط، تكرار الإطار السابق |
| معروض بالكامل | تم تعديل سلسلة التعليمات الرئيسية إما خلال الموعد النهائي، أو لم تكن بحاجة إلى إجراء تعديل على سلسلة التعليمات الرئيسية. |
| معروض جزئيًا | المؤلف فقط، لم يحدث أي تغيير مرئي في التحديث الذي تأخّر في سلسلة التعليمات الرئيسية. |
| معروض جزئيًا | المكوّن فقط: تضمنت سلسلة التعليمات الرئيسية تعديلاً مرئيًا، إلا أنّ هذا التحديث لم يتضمّن صورًا متحركة تؤثر في سلاسة سلسلة التعليمات. |
| معروض جزئيًا | المكوّن فقط: تضمّنت سلسلة التعليمات الرئيسية تعديلاً مرئيًا يؤثر في السلاسة، ولكن وصل إطار قديم وتم استخدامه بدلاً من ذلك. |
| معروض جزئيًا | المكوِّن فقط: بدون التحديث الرئيسي المطلوب، ويحتوي تحديث المكوّن على صورة متحركة تؤثّر في سلاسة عملية الدمج. |
| معروض جزئيًا | المكوِّن فقط، ولكن لا يحتوي تحديث المكوِّن على صورة متحركة تؤثر في السلاسة. |
| الإطار الذي تم إسقاطه | ما مِن تحديث. لم يكن هناك أي تحديث مطلوب للمكوّن، وتم تأخير العنصر الرئيسي. |
| الإطار الذي تم إسقاطه | كان المطلوب تحديثًا للمكوِّن، ولكن تم تأخيره. |
| إطار قديم | كان من المطلوب تحديثًا، حيث أنتجه العارض، لكن وحدة معالجة الرسومات لم تُقدمه قبل الموعد النهائي للمزامنة. |
ويمكن تحويل هذه الحالات إلى نتيجة إلى حدٍ ما. وربما إحدى الطرق لتفسير هذه النتيجة هي اعتبارها احتمالية أن يلاحظها المستخدم. قد لا يكون من الممكن ملاحظة إطار واحد تم إسقاطه، ولكن من المؤكد أن هناك سلسلة من الإطارات المسقطة التي تؤثر في السلاسة على التوالي في صف واحد.
وضع كل شيء معًا: مقياس النسبة المئوية للّقطات التي تم إفلاتها
في حين أنه قد يكون من الضروري أحيانًا التعمق في حالة كل إطار رسوم متحركة، إلا أنه من المفيد أيضًا تعيين نتيجة سريعة "نظرة سريعة" لتجربة ما.
بما أنّه قد يتم عرض اللقطات جزئيًا، ولأنّ تحديثات الإطارات التي يتم تخطّيها بالكامل قد لا تؤثِّر في سلاستها في الواقع، لا يهمّنا سوى التركيز على الحدّ الذي لا يمكن فيه للمتصفّح توفير تحديثات كاملة مرئيًا متى يكون ذلك مهمًا.
يجب أن ينتقل النموذج العقلي من:
- لقطات في الثانية، إلى
- يؤدي اكتشاف تحديثات الرسوم المتحركة المفقودة والمهمة،
- النسبة المئوية للانخفاض خلال فترة زمنية معيّنة.
المهم هو: نسبة الوقت الذي تستغرقه في انتظار التحديثات المهمة. نعتقد أن هذا يتوافق مع الطريقة الطبيعية التي يختبر بها المستخدمون سلاسة محتوى الويب عمليًا. حتى الآن، نستخدم ما يلي كمجموعة أولية من المقاييس:
- متوسط النسبة المئوية للانخفاض: لجميع إطارات الصور المتحركة غير نشِطة لفترة قصيرة على مدار المخطط الزمني بأكمله
- أسوأ حالة للّقطات التي تم إفلاتها: وفقًا لما تم قياسه على مدى ثانية واحدة من فترات الانزلاق.
- الشريحة المئوية الـ 95 للنسبة المئوية للّقطات التي تم إفلاتها: حسب ما تم قياسه على مدار ثانية واحدة من النوافذ الزمنية الانتقائية.
ويمكنك العثور على هذه النتائج في بعض أدوات مطوّري برامج Chrome اليوم. على الرغم من أنّ هذه المقاييس تركّز فقط على إجمالي سرعة معالجة البيانات، إلا أنّنا نقيّم أيضًا عوامل أخرى، مثل وقت استجابة اللقطات.
جرِّب ذلك بنفسك في أدوات المطوّرين.
شاشة HUD للأداء
يتضمّن Chromium شاشة عرض رقمية (HUD) أنيقة للأداء مخفي خلف علامة
(chrome://flags/#show-performance-metrics-hud). ويمكنك من خلاله العثور على نتائج مباشرة لأشياء مثل "مؤشرات أداء الويب الأساسية" بالإضافة إلى بعض التعريفات التجريبية
لسلاسة الصور المتحركة بناءً على النسبة المئوية للإطارات التي تم استبعادها بمرور الوقت.
إحصاءات عرض الإطار
فعِّل "إحصاءات عرض الإطارات" في أدوات مطوّري البرامج من خلال إعدادات العرض للاطّلاع على عرض مباشر لإطارات الصور المتحركة الجديدة، والتي يتم ترميزها بالألوان للتمييز بين التحديثات الجزئية من تحديثات الإطارات المستخرَجة بالكامل. عدد اللقطات في الثانية التي يتم الإبلاغ عنها هو للّقطات المقدَّمة بالكامل فقط.
أداة Frame Viewer في تسجيلات الملفات الشخصية لأداء أدوات مطوّري البرامج
لطالما كانت لوحة أداء أدوات مطوّري البرامج تضم أداة عرض الإطارات. مع ذلك، لم يكن هذا المسار متزامنًا مع طريقة عمل مسار العرض الحديث. لقد شهدنا الكثير من التحسينات مؤخرًا، حتى في أحدث إصدار من Chrome Canary، والذي نعتقد أنه سيسهل إلى حد كبير مشكلات تصحيح أخطاء الرسوم المتحركة.
ستجد اليوم أنّ الإطارات في عارض الإطارات تتماشى بشكل أفضل مع حدود vsync، ويتم ترميزها بالألوان بناءً على الحالة. لا يزال هناك تصور كامل لكل الفروقات الدقيقة المذكورة أعلاه، لكننا نخطط لإضافة المزيد في المستقبل القريب.
تتبُّع Chrome
وأخيرًا، باستخدام Chrome Tracing، أداة الاختيار للتعمق أكثر في التفاصيل، يمكنك تسجيل تتبُّع "عرض محتوى الويب" عبر واجهة مستخدم Perfetto الجديدة (أو about:tracing) والتعمق أكثر في مسار الرسومات في Chrome. قد تكون مهمة شاقة، ولكن هناك بعض الأشياء
التي تمت إضافتها مؤخرًا إلى Chromium لتسهيل الأمر. يمكنك الحصول على نظرة عامة حول ما
هو متاح في وثيقة Life of a
Frame.
من خلال أحداث التتبُّع، يمكنك تحديد ما يلي بشكل نهائي:
- الصور المتحركة التي يتم تشغيلها (باستخدام أحداث تحمل اسم
TrackerValidation). - الحصول على المخطط الزمني الدقيق لإطارات الصور المتحركة (باستخدام أحداث باسم
PipelineReporter). - بالنسبة إلى تحديثات الرسوم المتحركة غير التقليدية، اكتشف بالضبط السبب الذي يمنع عرض الرسوم المتحركة بشكل أسرع (باستخدام تقسيمات الأحداث ضمن
PipelineReporterأحداث). - بالنسبة إلى الصور المتحركة التي تعتمد على الإدخال، يمكنك معرفة المدة التي يستغرقها الحصول على تعديل مرئي
(باستخدام أحداث باسم
EventLatency).
الخطوات التالية
تهدف مبادرة مؤشرات أداء الويب إلى توفير مقاييس وإرشادات لإنشاء تجارب رائعة للمستخدمين على الويب. تكون المقاييس المستندة إلى المختبر مثل إجمالي وقت الحظر (TBT) أساسية لرصد المشاكل المحتملة في التفاعل وتشخيصها. نحن نخطط لتصميم مقياس مشابه مختبري لسلاسة الرسوم المتحركة.
سنبقيك على اطلاع بينما نواصل العمل على أفكار لتصميم مقياس شامل بناءً على بيانات إطار الرسوم المتحركة الفردية.
في المستقبل، نريد أيضًا تصميم واجهات برمجة تطبيقات تتيح قياس سلاسة الرسوم المتحركة بشكل فعال للمستخدمين الحقيقيين في الحقل وكذلك في المختبر. يمكنك متابعتنا لمعرفة آخر الأخبار أيضًا.
إضافة ملاحظات
نحن متحمسون بشأن جميع التحسينات الأخيرة وأدوات المطورين التي تم شحنها في Chrome لقياس سلاسة الرسوم المتحركة. يُرجى تجربة هذه الأدوات وقياس أداء الرسوم المتحركة وإخبارنا إلى أين تقودنا!
يمكنك إرسال تعليقاتك إلى مجموعة web-vitals-feedback على Google مع "[Smoothness Metrics]" في سطر الموضوع. نحن نتطلع حقًا إلى سماع رأيك!