पिछले कुछ सालों में, ब्राउज़र की परफ़ॉर्मेंस में काफ़ी सुधार हुआ है. खास तौर पर, मोबाइल पर. पहले, किसी भी जटिल गेम के लिए, फ़्रेम रेट को स्मूद रखने की उम्मीद नहीं की जा सकती थी. हालांकि, अब थोड़ी सावधानी बरतकर, ऐसा किया जा सकता है.
हालांकि, हममें से ज़्यादातर लोगों के लिए, अपने डिवाइसों पर टेस्ट करने और उपयोगकर्ताओं को मिलने वाले अनुभव में अंतर होता है. अगर उन्हें 60fps की स्मूद क्वालिटी नहीं मिलती है, तो उन्हें अच्छा अनुभव नहीं मिलता. इसलिए, वे किसी दूसरी जगह चले जाते हैं और हमें नुकसान होता है. इसलिए, यह अच्छी बात है कि W3C एक नए एपीआई पर चर्चा कर रहा है. इसकी मदद से, हमें यह पता चल सकता है कि हमारे उपयोगकर्ताओं को क्या दिखता है: फ़्रेम टाइमिंग एपीआई.
जैक आर्चबोल्ड और मैंने हाल ही में एपीआई के बारे में खास जानकारी देने वाला वीडियो रिकॉर्ड किया है. अगर आपको पढ़ने के बजाय वीडियो देखना पसंद है, तो यह वीडियो देखें:
Frame Timing API के इस्तेमाल
Frame Timing API की मदद से, कई काम किए जा सकते हैं. सबसे अहम बात यह है कि आपको अपने और अपने प्रोजेक्ट के लिए ज़रूरी चीज़ों को मेज़र करने का विकल्प मिलता है. इसके बावजूद, यहां कुछ आइडिया दिए गए हैं:
- अपने JavaScript और सीएसएस ऐनिमेशन के फ़्रेम प्रति सेकंड (एफ़पीएस) को ट्रैक करना.
- आपके पेज के स्क्रोल की आसानी को ट्रैक करना (या शायद आपकी असीमित स्क्रोलिंग वाली सूची को ट्रैक करना.)
- डिवाइस के मौजूदा लोड के आधार पर, शोबिज़ इफ़ेक्ट को अपने-आप कम करना.
- रनटाइम परफ़ॉर्मेंस मेट्रिक पर रिग्रेशन टेस्टिंग.
झलक (एलिवेटर पिच)
यहां बताया गया है कि एपीआई, खास जानकारी में फ़िलहाल कैसा दिखता है: इसकी मदद से, आपको रेंडरर थ्रेड के टाइमिंग पर डेटा मिलेगा. यहां JavaScript, स्टाइल, और लेआउट काम करते हैं. (आपने शायद रेंडरर थ्रेड को मुख्य थ्रेड के नाम से सुना हो. यह एक ही चीज़ है, जिसे अलग नाम दिया गया है.)
var rendererEvents = window.performance.getEntriesByType("renderer");
आपको मिलने वाले हर रेंडरर थ्रेड रिकॉर्ड कुछ इस तरह दिखते हैं:
{
sourceFrameNumber: 120,
startTime: 1342.549374253
cpuTime: 6.454313323
}
हर रिकॉर्ड एक ऑब्जेक्ट होता है. इसमें फ़्रेम का यूनीक नंबर, फ़्रेम शुरू होने का हाई रिज़ॉल्यूशन टाइमस्टैंप, और सीपीयू के इस्तेमाल का समय होता है. इनमें से किसी भी ऐरे की मदद से, हर startTime वैल्यू देखी जा सकती है और यह पता लगाया जा सकता है कि मुख्य थ्रेड 60fps पर चल रहा है या नहीं. इसका मतलब है कि "क्या हर फ़्रेम का startTime, करीब 16 मिलीसेकंड के हिस्सों में बढ़ता है?"
इसके अलावा, आपको cpuTime भी दिखेगा. इससे आपको पता चलेगा कि आपका रिस्पॉन्स 16 मिलीसेकंड के अंदर है या नहीं. अगर cpuTime 16 मिलीसेकंड की सीमा के आस-पास है, तो गैर-ज़रूरी डेटा हटाने जैसी चीज़ों के लिए ज़्यादा जगह नहीं है. साथ ही, सीपीयू के ज़्यादा इस्तेमाल से बैटरी की खपत भी ज़्यादा होगी.
रेंडरर थ्रेड के अलावा, आपको कंपोजिटर थ्रेड के टाइमिंग पर भी डेटा खींचने की सुविधा मिलती है. यहां पेंटिंग और कंपोजिटिंग होती है:
var compositeThreadEvents = window.performance.getEntriesByType("composite");
इनमें से हर इवेंट, सोर्स फ़्रेम नंबर के साथ भी वापस आता है. इसका इस्तेमाल, मुख्य थ्रेड के इवेंट से जोड़ने के लिए किया जा सकता है:
{
sourceFrameNumber: 120,
startTime: 1352.343235321
}
ब्राउज़र में कॉम्पोज़ करने की प्रोसेस अक्सर इस तरह से काम करती है कि हर रेंडरर थ्रेड रिकॉर्ड में इनमें से कई रिकॉर्ड हो सकते हैं. इसलिए, इन्हें फिर से एक साथ जोड़ने के लिए, sourceFrameNumber का इस्तेमाल किया जा सकता है. इस बारे में भी चर्चा की जा रही है कि क्या इन रिकॉर्ड में सीपीयू टाइम भी शामिल होना चाहिए. अगर आपको इस बारे में ज़्यादा जानकारी चाहिए, तो GitHub की समस्याओं के बारे में ज़्यादा जानें.
ज़्यादा जानकारी
यह एपीआई अभी उपलब्ध नहीं है. हालांकि, हमें उम्मीद है कि यह जल्द ही उपलब्ध हो जाएगा. इस बीच, यहां कुछ ऐसी चीज़ें दी गई हैं जिन्हें पढ़ा और किया जा सकता है:
- रिपोज़िटरी में मौजूद, जानकारी देने वाला दस्तावेज़ पढ़ें. फ़्रेम डेटा को बेहतर तरीके से रिकॉर्ड करने के बारे में बहुत कुछ कहा जा सकता है, ताकि वह काम का हो. इस बारे में यहां कुछ जानकारी दी गई है.
- स्पेसिफ़िकेशन का नया ड्राफ़्ट देखें. यह बहुत छोटा है और इसे पढ़ना ज़रूरी है.
- अगर आपको कोई सुविधा नहीं मिल रही है या कोई समस्या आ रही है, तो उसकी शिकायत करें. आपको पता है कि आपको क्या मेज़र करना है. इसलिए, अगर आपको लगता है कि एपीआई की मदद से कोई ऐसा काम नहीं किया जा सकता जिसे आपको करना है, तो कृपया हमें सुझाव/राय दें या शिकायत करें.