ऐनिमेशन के स्मूदनेस मेट्रिक की ओर

ऐनिमेशन को मापने, ऐनिमेशन फ़्रेम के बारे में सोचने, और पेज की पूरी समानता के बारे में जानें.

आपने शायद ऐसे पेजों का अनुभव किया होगा जो स्क्रोल या ऐनिमेशन के दौरान "अटकते" या "फ़्रीज़" होते हैं. हम आपको यह बताना चाहते हैं कि यहां आपको कभी भी, कोई एक जैसा अनुभव नहीं मिलता. इस तरह की समस्याओं को हल करने के लिए, Chrome टीम ऐनिमेशन की पहचान करने के लिए, हमारे लैब टूल में ज़्यादा मदद जोड़ रही है. साथ ही, वह Chromium में रेंडरिंग पाइपलाइन डाइग्नोस्टिक्स को लगातार बेहतर बना रही है.

हम आपको हाल में हुई प्रोग्रेस के बारे में बताएंगे. साथ ही, टूल के इस्तेमाल से जुड़े ठोस दिशा-निर्देश भी बताएंगे और आने वाले समय में, ऐनिमेशन को बेहतर बनाने के लिए मेट्रिक के इस्तेमाल से जुड़े आइडिया भी बताएंगे. हमेशा की तरह, हमें आपके सुझाव जानकर खुशी होगी.

इस पोस्ट में तीन मुख्य विषय शामिल होंगे:

• ऐनिमेशन और ऐनिमेशन फ़्रेम पर एक नज़र.
• ऐनिमेशन के स्मूदता को मापने के बारे में हमारे मौजूदा विचार.
• लैब टूल के इस्तेमाल से जुड़े कुछ व्यावहारिक सुझाव.

ऐनिमेशन क्या होते हैं?

ऐनिमेशन, कॉन्टेंट में जान डाल देते हैं! खास तौर पर, लोगों के इंटरैक्शन की वजह से, कॉन्टेंट को ज़्यादा स्वाभाविक, समझने में आसान, और मज़ेदार बनाया जा सकता है.

लेकिन खराब तरीके से लागू किए गए ऐनिमेशन या बहुत ज़्यादा ऐनिमेशन जोड़ने से अनुभव खराब हो सकता है और यह बिलकुल मज़ेदार नहीं हो सकता. शायद हम सभी ने ऐसे इंटरफ़ेस से इंटरैक्ट किया है जिससे बहुत सारे "मददगार" ट्रांज़िशन इफ़ेक्ट जोड़े गए हैं. ये खराब परफ़ॉर्म करने पर, अनुभव को खराब करने वाले इफ़ेक्ट बन जाते हैं. इसलिए, हो सकता है कि कुछ उपयोगकर्ता कम मोशन का इस्तेमाल करना चाहें. यह एक ऐसी प्राथमिकता है जिस पर आपको ध्यान देना चाहिए.

ऐनिमेशन कैसे काम करते हैं?

फटाफट याद दिला दें कि रेंडरिंग पाइपलाइन में कुछ क्रम से जुड़े चरण होते हैं:

1. स्टाइल: एलिमेंट पर लागू होने वाली स्टाइल कैलकुलेट करें.
2. लेआउट: हर एलिमेंट के लिए जियोमेट्री और पोज़िशन जनरेट करता है.
3. पेंट: लेयर में हर एलिमेंट के पिक्सल भरें.
4. कंपोज़िट: लेयर को स्क्रीन पर ड्रॉ करें.

ऐनिमेशन तय करने के कई तरीके हैं, लेकिन ये सभी बुनियादी तौर पर इनमें से किसी एक तरीके से काम करते हैं:

• लेआउट प्रॉपर्टी में बदलाव करना.
• पेंट प्रॉपर्टी में बदलाव करना.
• कंपोज़िट प्रॉपर्टी में बदलाव करना.

ये चरण क्रम में होते हैं, इसलिए ऐनिमेशन को उन प्रॉपर्टी के हिसाब से तय करना ज़रूरी है जो पाइपलाइन में बहुत नीचे हों. अपडेट की प्रोसेस जितनी जल्दी शुरू होगी उतने ही ज़्यादा शुल्क लिया जाएगा और इस प्रोसेस के आसान होने की संभावना कम होगी. (ज़्यादा जानकारी के लिए रेंडरिंग परफ़ॉर्मेंस देखें.)

लेआउट प्रॉपर्टी को ऐनिमेट करना आसान हो सकता है, लेकिन ऐसा करने में कुछ खर्च आता है, भले ही वे तुरंत साफ़ तौर पर न दिखें. जहां भी मुमकिन हो, ऐनिमेशन को प्रॉपर्टी में होने वाले कंपोज़िट बदलावों के हिसाब से परिभाषित किया जाना चाहिए.

डिक्लेरेटिव सीएसएस ऐनिमेशन या वेब ऐनिमेशन का इस्तेमाल करना और कंपोज़िट प्रॉपर्टी को ऐनिमेट करना, बेहतरीन ऐनिमेशन बनाने का पहला कदम है. हालांकि, इस बात की कोई गारंटी नहीं है कि बेहतर अनुभव देने के लिए, वेब ऐनिमेशन का भी इस्तेमाल किया जा सकता है. इसलिए, आकलन करना हमेशा ज़रूरी होता है!

ऐनिमेशन फ़्रेम क्या होते हैं?

किसी पेज के विज़ुअल प्रज़ेंटेशन को अपडेट होने में समय लगता है. विज़ुअल बदलाव करने से एक नया ऐनिमेशन फ़्रेम बन जाएगा, जिसका ऐनिमेशन उपयोगकर्ता के डिसप्ले पर दिखेगा.

कुछ इंटरवल पर अपडेट दिखाता है, इसलिए विज़ुअल अपडेट बैच में होते हैं. कई ऐप्लिकेशन एक तय अंतराल पर अपडेट होते हैं, जैसे कि एक सेकंड में 60 बार (60 हर्ट्ज़). कुछ और आधुनिक डिसप्ले में ज़्यादा रीफ़्रेश दर मिल सकती है (90–120 हर्ट्ज़ आम तौर पर होने वाले हैं). ये डिसप्ले अक्सर ज़रूरत के हिसाब से रीफ़्रेश रेट के बीच बदलाव कर सकते हैं या पूरी तरह अलग-अलग फ़्रेम रेट भी दे सकते हैं.

गेम या ब्राउज़र जैसे किसी भी ऐप्लिकेशन का मकसद, इन सभी विज़ुअल अपडेट को प्रोसेस करना और हर बार समयसीमा में, विज़ुअल तौर पर पूरा ऐनिमेशन फ़्रेम तैयार करना होता है. ध्यान दें कि यह लक्ष्य, ब्राउज़र से जुड़े दूसरे अहम टास्क से पूरी तरह अलग है. जैसे, नेटवर्क से तेज़ी से कॉन्टेंट लोड करना या JavaScript के टास्क को बेहतर तरीके से लागू करना.

कभी-कभी, डिसप्ले के लिए तय समयसीमा में सभी विज़ुअल अपडेट पूरा करना बहुत मुश्किल हो सकता है. ऐसा होने पर ब्राउज़र एक फ़्रेम ड्रॉप करता है. आपकी स्क्रीन काले रंग की नहीं होगी, यह बस अपने-आप दोहराती रहेगी. आपको वही विज़ुअल अपडेट कुछ देर तक दिखता है—यानी वही ऐनिमेशन फ़्रेम जो पिछले फ़्रेम के अवसर पर दिखाया गया था.

ऐसा अक्सर अक्सर होता है! ज़रूरी नहीं है कि यह दिखाई दे, खास तौर पर स्टैटिक या दस्तावेज़ जैसी कॉन्टेंट के लिए, जो वेब प्लैटफ़ॉर्म पर खास तौर पर आम तौर पर होता है. ड्रॉप हुए फ़्रेम सिर्फ़ तब दिखते हैं, जब ऐनिमेशन जैसे ज़रूरी विज़ुअल अपडेट होते हैं. इसके लिए, हमें ऐनिमेशन अपडेट की एक तय स्ट्रीम की ज़रूरत होती है, ताकि लगातार एक अच्छा मूवमेंट दिखे.

ऐनिमेशन फ़्रेम पर क्या असर पड़ता है?

वेब डेवलपर, ब्राउज़र की विज़ुअल अपडेट को झटपट और सही तरीके से रेंडर करने और उसे पेश करने की क्षमता पर काफ़ी असर डाल सकते हैं!

कुछ उदाहरण:

• ऐसे कॉन्टेंट का इस्तेमाल करना जो बहुत बड़ा या बहुत ज़्यादा संसाधन वाला हो और जिसे टारगेट किए गए डिवाइस पर तुरंत डिकोड न किया जा सके.
• बहुत ज़्यादा लेयर इस्तेमाल करने में, बहुत ज़्यादा जीपीयू मेमोरी की ज़रूरत पड़ती है.
• बहुत मुश्किल सीएसएस स्टाइल या वेब ऐनिमेशन तय करना.
• ऐसे एंटी-पैटर्न डिज़ाइन का इस्तेमाल करना जो तेज़ रेंडरिंग को ऑप्टिमाइज़ नहीं करते.
• मुख्य थ्रेड पर बहुत ज़्यादा JS काम करते हैं. इस वजह से, विज़ुअल अपडेट ब्लॉक करने वाले लंबे टास्क होते हैं.

हालांकि, यह कैसे पता किया जा सकता है कि किसी ऐनिमेशन फ़्रेम की समयसीमा खत्म होने की वजह से फ़्रेम ड्रॉप हो गया या नहीं?

ऐसा हो सकता है कि एक तरीका requestAnimationFrame() पोलिंग का इस्तेमाल करना हो. हालांकि, इसके कई नुकसान हैं. requestAnimationFrame() या "rAF" से, ब्राउज़र को यह पता चलता है कि आपको ऐनिमेशन चलाना है. साथ ही, रेंडर करने की पाइपलाइन के अगले पेंट स्टेज पर जाने से पहले, ब्राउज़र से ऐसा करने का अनुरोध करता है. अगर आपके कॉलबैक फ़ंक्शन को उम्मीद के मुताबिक समय पर कॉल नहीं किया जाता है, तो इसका मतलब है कि पेंट नहीं किया गया है और एक या उससे ज़्यादा फ़्रेम छूट गए हैं. पोलिंग और आरएएफ़ को कितनी बार कॉल किया जाता है, इसकी गिनती करके, एक तरह की "फ़्रेम प्रति सेकंड" (एफ़पीएस) मेट्रिक का हिसाब लगाया जा सकता है.

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() पोल का इस्तेमाल करना सही नहीं है:

• हर स्क्रिप्ट को अपना पोलिंग लूप सेट करना होता है.
• यह अहम पाथ को ब्लॉक कर सकता है.
• अगर आरएएफ़ पोल तेज़ी से काम करता है, तब भी requestIdleCallback() को लगातार इस्तेमाल किए जाने पर, लंबे समय तक इस्तेमाल में न रहने वाले ब्लॉक को शेड्यूल करने से रोका जा सकता है (एक फ़्रेम से ज़्यादा ब्लॉक वाले ब्लॉक).
• इसी तरह, लंबे समय तक काम न करने वाले ब्लॉक की कमी से, ब्राउज़र लंबे समय तक चलने वाले दूसरे कामों (जैसे कि लंबे समय तक चलने वाले टास्क को शेड्यूल नहीं कर पाता) (जैसे, लंबे समय तक चलने वाले कचरा और दूसरे बैकग्राउंड या अनुमान पर किए जाने वाले काम).
• अगर पोल की सुविधा को चालू और बंद किया जाता है, तो आपको ऐसे मामले नहीं दिखेंगे जिनमें फ़्रेम बजट तय सीमा से ज़्यादा हो गया हो.
• अगर ब्राउज़र, वैरिएबल अपडेट फ़्रीक्वेंसी का इस्तेमाल कर रहा है, तो पोल गलत होने पर रिपोर्ट करेगा. उदाहरण के लिए, पावर या विज़िबिलिटी की स्थिति की वजह से.
• सबसे अहम बात, यह असल में सभी तरह के ऐनिमेशन अपडेट को कैप्चर नहीं करता!

मुख्य थ्रेड पर बहुत ज़्यादा काम करने से, ऐनिमेशन फ़्रेम देखने की सुविधा पर असर पड़ सकता है. मुख्य थ्रेड पर बहुत ज़्यादा काम (जैसे कि लेआउट) करने के बाद, किस तरह आरएएफ़ पर चलने वाले ऐनिमेशन का इस्तेमाल किया जाता है, यह जानने के लिए जैंक सैंपल देखें. इससे फ़्रेम ड्रॉप हो जाएंगे और आरएएफ़ कॉलबैक और कम FPS (फ़्रेम प्रति सेकंड) की कमी आएगी.

मुख्य थ्रेड के उलझ जाने पर, विज़ुअल अपडेट हिलने लगते हैं. यह जैंक है!

कई मेज़रमेंट टूल में इस बात पर बहुत ज़्यादा ध्यान दिया गया है कि मुख्य थ्रेड, सही समय पर काम करे और ऐनिमेशन फ़्रेम आसानी से काम करें. हालांकि, यह पूरी कहानी नहीं है! यह उदाहरण देखें:

ऊपर दिए गए वीडियो में एक पेज दिखाया गया है, जो समय-समय पर मुख्य थ्रेड में लंबे टास्क जोड़ता है. लंबे समय तक चलने वाले ये टास्क, कुछ खास तरह के विज़ुअल अपडेट देने की पेज की क्षमता को पूरी तरह से खत्म कर देते हैं. साथ ही, आपको सबसे ऊपर बाएं कोने में, FPS (फ़्रेम प्रति सेकंड) से लेकर requestAnimationFrame() की गिरावट 0 हो जाती है.

फिर भी, इतने लंबे टास्क के बावजूद, पेज को आसानी से स्क्रोल किया जा रहा है. ऐसा इसलिए है, क्योंकि मॉडर्न ब्राउज़र पर अक्सर स्क्रोलिंग, थ्रेड की जाती है और यह पूरी तरह से कंपोज़िटर के ज़रिए चलती है.

यह एक उदाहरण है जिसमें एक साथ कई मुख्य थ्रेड पर छोड़े गए कई फ़्रेम शामिल हैं, फिर भी कंपोज़िटर थ्रेड पर स्क्रोल करने के ऐसे कई फ़्रेम हैं जो डिलीवर हो गए हैं. बड़ा टास्क पूरा होने के बाद, मुख्य थ्रेड पेंट अपडेट में कोई विज़ुअल बदलाव नहीं है. आरएएफ़ पोल ने फ़्रेम को 0 पर सेट करने का सुझाव दिया है. हालांकि, विज़ुअल तौर पर, उपयोगकर्ता को कोई फ़र्क़ नहीं दिखेगा!

ऐनिमेशन फ़्रेम के मामले में, कहानी इतनी आसान नहीं है.

ऐनिमेशन फ़्रेम: अहम अपडेट

ऊपर दिया गया उदाहरण दिखाता है कि कहानी में requestAnimationFrame() के अलावा और भी बहुत कुछ है.

ऐनिमेशन अपडेट और ऐनिमेशन फ़्रेम कब मायने रखते हैं? यहां कुछ ऐसे मानदंड दिए गए हैं जिन पर हम विचार कर रहे हैं और हमें सुझाव या राय चाहिए:

• मुख्य और कंपोज़िटर थ्रेड के अपडेट
• पेंट अपडेट मौजूद नहीं हैं
• ऐनिमेशन का पता लगाना
• क्वालिटी बनाम संख्या

मुख्य और कंपोज़िटर थ्रेड के अपडेट

ऐनिमेशन फ़्रेम अपडेट बूलियन नहीं हैं. ऐसा नहीं है कि फ़्रेम सिर्फ़ पूरी तरह से छोड़े गए या पूरी तरह से दिखाए जा सकते हैं. किसी ऐनिमेशन फ़्रेम के आंशिक रूप से पेश होने की कई वजहें हो सकती हैं. दूसरे शब्दों में कहें, तो इसमें कुछ नया विज़ुअल अपडेट होने के साथ-साथ, कुछ नया विज़ुअल अपडेट भी हो सकता है.

इसका सबसे सामान्य उदाहरण यह है कि ब्राउज़र, फ़्रेम की समयसीमा के अंदर नया मुख्य थ्रेड अपडेट नहीं दिखा पाता, लेकिन कंपोज़िटर थ्रेड का नया अपडेट होता है. जैसे, पहले से थ्रेड की गई स्क्रोलिंग का उदाहरण.

कंपोज़िट प्रॉपर्टी को ऐनिमेट करने के लिए डिक्लेरेटिव ऐनिमेशन का इस्तेमाल करने का सुझाव दिया जाता है. इसकी एक वजह यह है कि ऐसा करने से, मुख्य थ्रेड के व्यस्त होने पर भी कंपोज़िटर थ्रेड से ऐनिमेशन को पूरी तरह से चलाया जा सकता है. इस तरह के ऐनिमेशन, बेहतर तरीके से और साथ-साथ विज़ुअल अपडेट देते रह सकते हैं.

दूसरी ओर, कुछ ऐसे मामले हो सकते हैं जिनमें मुख्य थ्रेड का एक अपडेट प्रज़ेंटेशन के लिए उपलब्ध हो जाए, लेकिन ऐसा तब ही हो सकता है, जब कोई फ़्रेम तय समय से पहले सबमिट न किया गया हो. यहां ब्राउज़र में कुछ नए अपडेट होंगे, लेकिन हो सकता है कि वह सबसे नया न हो.

मोटे तौर पर, हम ऐसे फ़्रेम को पार्शियल फ़्रेम के तौर पर इस्तेमाल करते हैं जिनमें कुछ नए विज़ुअल अपडेट शामिल होते हैं. हालांकि, इसमें नए विज़ुअल अपडेट नहीं होते. कुछ हिस्से रेंडर होने की सुविधा काफ़ी सामान्य हैं. आम तौर पर, कुछ हद तक अपडेट में सबसे ज़रूरी विज़ुअल अपडेट शामिल किए जाएंगे, जैसे कि ऐनिमेशन. हालांकि, ऐसा सिर्फ़ तब हो सकता है, जब ऐनिमेशन कंपोज़िटर थ्रेड से बने हों.

पेंट अपडेट मौजूद नहीं हैं

एक तरह का आंशिक अपडेट तब होता है, जब इमेज जैसे मीडिया ने फ़्रेम प्रज़ेंटेशन के लिए, समय में डिकोड और रास्टराइज़ नहीं किया हो.

इसके अलावा, पेज पूरी तरह से स्टैटिक होने पर भी, ब्राउज़र तेज़ी से स्क्रोल करने के दौरान विज़ुअल अपडेट रेंडर नहीं कर पाएंगे. ऐसा इसलिए होता है, क्योंकि जीपीयू मेमोरी सेव करने के लिए, दिखने वाला व्यूपोर्ट के बाहर के कॉन्टेंट की पिक्सल रेंडरिंग को खारिज किया जा सकता है. पिक्सल को रेंडर करने में समय लगता है और बड़े स्क्रोल के बाद सब कुछ रेंडर करने में, एक फ़्रेम से ज़्यादा समय लग सकता है, जैसे कि एक उंगली का फ़्लिंग. इसे आम तौर पर, चेकरबोर्डिंग के नाम से जाना जाता है.

हर फ़्रेम को रेंडर करने के अवसर से, यह ट्रैक किया जा सकता है कि नए विज़ुअल अपडेट में से कितने नए विज़ुअल अपडेट स्क्रीन पर आए. कई फ़्रेम (या समय) पर ऐसा करने की क्षमता को मापने को फ़्रेम थ्रूपुट कहा जाता है.

अगर जीपीयू असल में किसी तरह की रुकावट में आ जाता है, तो हो सकता है कि ब्राउज़र (या प्लैटफ़ॉर्म) उस रेट को थ्रॉटल करना शुरू कर दे जिस पर यह विज़ुअल अपडेट की कोशिश करता है. इस वजह से, फ़्रेम रेट कम हो जाता है. तकनीकी तौर पर, जो फ़्रेम के छूटे हुए अपडेट को कम कर सकता है, लेकिन विज़ुअल तौर पर यह अब भी निचले फ़्रेम थ्रूपुट के तौर पर दिखेगा.

हालांकि, सभी तरह के लो फ़्रेम थ्रूपुट खराब नहीं होते. अगर ज़्यादातर पेज कुछ समय से इस्तेमाल में नहीं है और उस पर कोई ऐनिमेशन नहीं दिख रहा है, तो कम फ़्रेम रेट देखने में उतना ही आकर्षक होता है जितना कि ज़्यादा फ़्रेम रेट. इससे बैटरी भी बचती है!

इसलिए, फ़्रेम थ्रूपुट कब मायने रखता है?

ऐनिमेशन का पता लगाना

खास तौर पर, अहम ऐनिमेशन वाले समय के दौरान हाई फ़्रेम थ्रूपुट बहुत मायने रखता है. अलग-अलग तरह के ऐनिमेशन, किसी खास थ्रेड (मुख्य, कंपोज़िटर या वर्कर) के विज़ुअल अपडेट पर निर्भर करेंगे. इसलिए, इसका विज़ुअल अपडेट उस थ्रेड पर निर्भर करता है जो तय समयसीमा में अपना अपडेट देता है. हम कहते हैं कि दिया गया थ्रेड एक जैसा अनुभव देने वाले नतीजे को प्रभावित करता है. ऐसा तब होता है, जब कोई ऐक्टिव ऐनिमेशन मौजूद होता है और यह थ्रेड के अपडेट पर निर्भर होता है.

कुछ तरह के ऐनिमेशन को तय करना और दूसरे ऐनिमेशन के मुकाबले उनका पता लगाना आसान होता है. एलान वाले ऐनिमेशन या उपयोगकर्ता इनपुट पर आधारित ऐनिमेशन, ऐनिमेट किए जा सकने वाले स्टाइल की प्रॉपर्टी के लिए समय-समय पर लागू किए गए JavaScript से चलने वाले ऐनिमेशन की तुलना में ज़्यादा साफ़ होते हैं.

requestAnimationFrame() के साथ भी, आप हमेशा यह नहीं मान सकते कि हर आरएएफ़ कॉल कोई विज़ुअल अपडेट या ऐनिमेशन दे रहा है. उदाहरण के लिए, सिर्फ़ फ़्रेम रेट को ट्रैक करने के लिए आरएएफ़ पोल का इस्तेमाल करें (जैसा कि ऊपर दिखाया गया है), इससे स्मूदनेस मेज़रमेंट पर असर नहीं पड़ेगा, क्योंकि कोई विज़ुअल अपडेट नहीं होता.

क्वालिटी बनाम संख्या

आख़िर में, ऐनिमेशन और ऐनिमेशन फ़्रेम अपडेट का पता लगाना अब भी कहानी का सिर्फ़ एक हिस्सा है, क्योंकि यह सिर्फ़ ऐनिमेशन अपडेट की संख्या दिखाता है, क्वालिटी को नहीं.

उदाहरण के लिए, आपको वीडियो देखते समय 60 FPS (फ़्रेम प्रति सेकंड) की स्थिर फ़्रेमरेट दिख सकती है. तकनीकी रूप से यह आसान है, लेकिन वीडियो की बिट रेट कम हो सकती है या नेटवर्क बफ़रिंग की समस्या हो सकती है. यह ऐनिमेशन को स्मूदनेस मेट्रिक में सीधे कैप्चर नहीं करता है, फिर भी यह उपयोगकर्ता को परेशान कर सकता है.

इसके अलावा, अगर कोई गेम <canvas> की मदद से, फ़्रेम रेट को बनाए रखने के लिए ऑफ़स्क्रीन कैनवस जैसी तकनीकों का इस्तेमाल करता है, तो भी वह ऐनिमेशन फ़्रेम के मामले में तकनीकी तौर पर बेहतर हो सकता है. हालांकि, यह सीन में अच्छी क्वालिटी वाली गेम एसेट लोड नहीं कर पाता या आर्टफ़ैक्ट दिखाता है.

और हां, किसी साइट पर कुछ बेहद खराब ऐनिमेशन हो सकते हैं 🙂

मेरा मतलब है कि मुझे लगता है कि वे अपने समय के हिसाब से बहुत अच्छे थे!

सिंगल ऐनिमेशन फ़्रेम की स्थितियां

फ़्रेम का कुछ हिस्सा प्रज़ेंट हो सकता है या फ़्रेम इस तरह से दिख सकते हैं जिससे फ़्रेम के हटाने की स्थिति पर कोई असर नहीं पड़ता. इसलिए, हमने हर फ़्रेम को पूरी तरह से या स्मूदनेस स्कोर के तौर पर देखना शुरू कर दिया है.

यहां पर एक ऐनिमेशन फ़्रेम की स्थिति को समझने के कई तरीके दिए गए हैं.

इन स्थितियों को कुछ हद तक स्कोर में बदला जा सकता है. इस स्कोर को समझने का एक तरीका यह है कि उपयोगकर्ता के देखे जाने की संभावना को समझा जाए. हो सकता है कि छोड़े गए किसी एक फ़्रेम का पता आसानी से न लगाया जा सके, लेकिन गिरने वाले कई फ़्रेम के क्रम की वजह से पंक्ति में स्मूदनेस पर असर पड़ सकता है!

सभी जानकारी को एक साथ रखना: प्रतिशत ड्रॉप हुए फ़्रेम की मेट्रिक

हालांकि, कभी-कभी हर ऐनिमेशन फ़्रेम की स्थिति को गहराई से समझना ज़रूरी होता है. हालांकि, अनुभव के लिए सिर्फ़ "एक नज़र में" स्कोर असाइन करना भी फ़ायदेमंद होता है.

हो सकता है कि फ़्रेम आंशिक रूप से प्रज़ेंट किए गए हों और ऐसा भी हो सकता है कि पूरी तरह से स्किप किए गए फ़्रेम अपडेट से स्मूदता पर असर न पड़े. इसलिए, हम सिर्फ़ फ़्रेम की गिनती करने पर कम फ़ोकस करना चाहते हैं. साथ ही, हम उन सीमाओं पर ज़्यादा ध्यान देना चाहते हैं जिनके लिए ब्राउज़र विज़ुअल तौर पर पूरा अपडेट ज़रूरी होने पर नहीं दे पाता.

मानसिक मॉडल को इनसे आगे बढ़ना चाहिए:

1. फ़्रेम प्रति सेकंड, से लेकर
2. छूटे हुए और महत्वपूर्ण एनिमेशन अपडेट का पता लगाना,
3. किसी तय समयावधि में प्रतिशत में कमी.

सबसे अहम बात यह है: ज़रूरी अपडेट मिलने में लगने वाला समय. हमें लगता है कि इससे लोगों को वेब कॉन्टेंट के इस्तेमाल में आसान अनुभव मिलता है. अब तक हम मेट्रिक के शुरुआती सेट के तौर पर, इन मेट्रिक का इस्तेमाल करते आ रहे हैं:

• औसत प्रतिशत में गिरावट: पूरी टाइमलाइन में मौजूद उन सभी ऐनिमेशन फ़्रेम के लिए जो इस्तेमाल नहीं किए गए हैं
• प्रतिशत में गिरावट वाले फ़्रेम के सबसे खराब मामले: एक सेकंड के लिए स्लाइड होने वाली विंडो में इसे मापा गया है.
• छूटे हुए प्रतिशत का 95वां पर्सेंटाइल: यह एक सेकंड की स्लाइडिंग विंडो के हिसाब से मापा जाता है.

आपको ये स्कोर, आज Chrome डेवलपर के कुछ टूल में मिल सकते हैं. ये मेट्रिक, सिर्फ़ फ़्रेम की क्षमता पर फ़ोकस करती हैं. हालांकि, हम फ़्रेम के रेंडर होने में लगने वाले समय जैसी दूसरी चीज़ों का भी आकलन कर रहे हैं.

डेवलपर टूलिंग में इसे खुद आज़माएं!

परफ़ॉर्मेंस HUD

Chromium में एक फ़्लैग (chrome://flags/#show-performance-metrics-hud) के पीछे एक साफ़ परफ़ॉर्मेंस HUD छिपा हुआ है. इसमें, वेबसाइट की परफ़ॉर्मेंस की अहम जानकारी देने जैसी चीज़ों के लिए लाइव स्कोर देखे जा सकते हैं. साथ ही, समय-समय पर प्रतिशत में हुए फ़्रेम के आधार पर, ऐनिमेशन स्मूदनेस के लिए प्रयोग के तौर पर कुछ परिभाषाएं भी देखी जा सकती हैं.

फ़्रेम रेंडरिंग के आंकड़े

"फ़्रेम रेंडरिंग आंकड़े" रेंडरिंग सेटिंग के ज़रिए DevTools में नए ऐनिमेशन फ़्रेम का लाइव व्यू देखने के लिए, रेंडरिंग सेटिंग के ज़रिए DevTools की सुविधा चालू करें. ये ऐनिमेशन फ़्रेम, पूरी तरह से बंद हुए फ़्रेम के अपडेट और पार्शियल अपडेट में फ़र्क़ करने के लिए कलर कोड होते हैं. रिपोर्ट किया गया FPS (फ़्रेम प्रति सेकंड) सिर्फ़ पूरी तरह से पेश किए गए फ़्रेम के लिए है.

DevTools परफ़ॉर्मेंस प्रोफ़ाइल की रिकॉर्डिंग में फ़्रेम व्यूअर

DevTool का परफ़ॉर्मेंस पैनल लंबे समय से फ़्रेम व्यूअर के साथ काम करता है. हालांकि, आधुनिक रेंडरिंग पाइपलाइन के काम करने के तरीके के साथ, यह ठीक से काम नहीं कर रहा था. हाल ही में, Chrome कैनरी में भी कई सुधार किए गए हैं. हमें लगता है कि इससे ऐनिमेशन को डीबग करने में काफ़ी आसानी होगी.

अब आपको दिखेगा कि फ़्रेम व्यूअर में मौजूद फ़्रेम, vsync सीमाओं के साथ बेहतर तरीके से अलाइन हैं और स्थिति के मुताबिक कलर-कोड किए गए हैं. ऊपर बताई गई सभी बारीकियों के लिए अब भी पूरा विज़ुअलाइज़ेशन मौजूद नहीं है. हालांकि, हम आने वाले समय में और ज़्यादा चीज़ें जोड़ने पर काम कर रहे हैं.

Chrome ट्रेस करने की सुविधा

आख़िर में, ज़्यादा जानकारी के लिए सबसे अच्छे टूल Chrome ट्रेसिंग की मदद से नए Perfetto यूज़र इंटरफ़ेस (या about:tracing) की मदद से "वेब कॉन्टेंट रेंडरिंग" ट्रेस रिकॉर्ड की जा सकती है. साथ ही, Chrome के ग्राफ़िक पाइपलाइन को गहराई से समझा जा सकता है. यह मुश्किल काम हो सकता है, लेकिन इसे आसान बनाने के लिए, Chromium में हाल ही में कुछ चीज़ें जोड़ी गई हैं. फ़्रेम की लाइफ़ वाले दस्तावेज़ में उपलब्ध चीज़ों की खास जानकारी देखी जा सकती है.

ट्रेस इवेंट की मदद से, यह तय किया जा सकता है कि:

• कौनसे ऐनिमेशन चल रहे हैं (TrackerValidation नाम वाले इवेंट का इस्तेमाल करके).
• ऐनिमेशन फ़्रेम की सटीक टाइमलाइन पाना (PipelineReporter नाम वाले इवेंट का इस्तेमाल करके).
• जानकी ऐनिमेशन अपडेट के लिए, पता लगाएं कि आपके ऐनिमेशन को तेज़ी से चलाने में क्या रुकावट आ रही है (PipelineReporter इवेंट में इवेंट ब्रेकडाउन का इस्तेमाल करके).
• इनपुट-ड्रिवन ऐनिमेशन के लिए, देखें कि विज़ुअल अपडेट पाने में कितना समय लगता है. इसके लिए, EventLatency नाम वाले इवेंट का इस्तेमाल करें.

आगे क्या करना है

वेब की परफ़ॉर्मेंस की अहम जानकारी पहल का मकसद, मेट्रिक और दिशा-निर्देश देना है, ताकि वेब पर उपयोगकर्ताओं को बेहतर अनुभव दिया जा सके. लैब पर आधारित मेट्रिक, जैसे कि टोटल ब्लॉकिंग टाइम (टीबीटी), इंटरैक्टिविटी से जुड़ी संभावित समस्याओं का पता लगाने और उनका पता लगाने के लिए बेहद ज़रूरी होती हैं. हम ऐनिमेशन को बेहतर बनाने के लिए, इससे मिलती-जुलती लैब आधारित मेट्रिक डिज़ाइन करने की योजना बना रहे हैं.

हम आपको व्यक्तिगत एनिमेशन फ़्रेम के डेटा के आधार पर एक व्यापक मेट्रिक डिज़ाइन करने के आइडिया पर काम करते रहने के दौरान आपको इसकी जानकारी देते रहेंगे.

आने वाले समय में, हम ऐसे एपीआई डिज़ाइन करना चाहते हैं जिनसे फ़ील्ड के साथ-साथ लैब में भी, असली उपयोगकर्ताओं के लिए ऐनिमेशन की स्मूदनेस को बेहतर तरीके से मेज़र किया जा सके. वहां भी अपडेट पाने के लिए हमारे साथ बने रहें!

सुझाव/राय दें या शिकायत करें

हम ऐनिमेशन की बेहतरी को मापने के लिए, Chrome में हाल ही में किए गए सभी सुधारों और डेवलपर टूल को लेकर उत्साहित हैं. कृपया ये टूल आज़माएं, अपने ऐनिमेशन के लिए मानदंड तय करें, और हमें बताएं कि वह आपको कहां ले जाता है!

अपनी टिप्पणियों को web-vitals-feedback Google ग्रुप को भेजा जा सकता है. इसके लिए, सब्जेक्ट लाइन में "[स्मूदनेस मेट्रिक्स]" का इस्तेमाल करें. हम आपके विचार जानने के लिए उत्सुक हैं!