डेवलपर के लिए सुझाव, शिकायत या राय देना ज़रूरी है - फ़्रेम टाइमिंग एपीआई

पॉल लुईस

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

हालांकि, हम में से ज़्यादातर लोगों के लिए अपने डिवाइस पर सही तरीके से जांच करने की सुविधा और उपयोगकर्ताओं के अनुभव में अंतर होता है. अगर उन्हें 60fps (फ़्रेम प्रति सेकंड) नहीं मिलता है, तो उनका अनुभव खराब होता है. आखिर में, वे कहीं और चले जाएंगे और हमें नुकसान होगा. इसके साथ ही, W3C एक नए एपीआई पर चर्चा कर रहा है. इससे हमें यह समझने में मदद मिलेगी कि हमारे उपयोगकर्ताओं को क्या दिखता है: Frame Timing API.

जेक आर्किबाल्ड और मैंने हाल ही में इस एपीआई का खास जानकारी वाला वीडियो रिकॉर्ड किया है. अगर आपको पढ़ने के बजाय, इसे देखना ज़्यादा पसंद है, तो इसे एक नज़र में देखें:

Frame Timing API के लिए इस्तेमाल किए जाने वाले सभी टूल

Frame Timing API के साथ कई काम किए जा सकते हैं. साथ ही, सबसे अहम बात यह है कि आप यह मेज़र करें कि आपके और आपके प्रोजेक्ट के लिए क्या ज़रूरी है. फिर भी, यहां कुछ आइडिया दिए गए हैं:

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

झलक (एलिवेटर पिच)

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

var rendererEvents = window.performance.getEntriesByType("renderer");

आपको वापस मिलने वाले रेंडरर थ्रेड के हर रिकॉर्ड कुछ इस तरह दिखते हैं:

    {
      sourceFrameNumber: 120,
      startTime: 1342.549374253
      cpuTime: 6.454313323
    }

हर रिकॉर्ड एक ऑब्जेक्ट है, जिसमें एक यूनीक फ़्रेम नंबर होता है. यह एक हाई रिज़ॉल्यूशन टाइमस्टैंप होता है, जो फ़्रेम शुरू होने के समय के लिए होता है. साथ ही, रिकॉर्ड यह भी बताता है कि उसने कितने सीपीयू समय का इस्तेमाल किया. इन रेंज की मदद से, हर startTime वैल्यू को देखा जा सकता है. साथ ही, यह पता लगाया जा सकता है कि मुख्य थ्रेड 60 FPS (फ़्रेम प्रति सेकंड) पर चल रहा है या नहीं. असल में, "क्या हर फ़्रेम का startTime करीब 16 मि॰से॰ के हिसाब से बढ़ रहा है?"

इसके अलावा, आपको cpuTime भी मिलता है. इससे आपको पता चल जाएगा कि आप 16 मि॰से॰ की सीमा में हैं या नहीं. अगर cpuTime 16 मि॰से॰ की सीमा के पास है, तो कचरा इकट्ठा करने जैसी चीज़ों के लिए ज़्यादा जगह नहीं होगी. साथ ही, सीपीयू का इस्तेमाल ज़्यादा होने पर, बैटरी की खपत भी ज़्यादा होगी.

रेंडरर थ्रेड के अलावा, आपको कंपोज़िटर थ्रेड के समय का डेटा भी मिलता है, जहां पेंटिंग और कंपोज़िटिंग होती है:

var compositeThreadEvents = window.performance.getEntriesByType("composite");

इनमें से हर लेवल के साथ एक सोर्स फ़्रेम नंबर भी मिलता है. इसका इस्तेमाल करके मुख्य थ्रेड के इवेंट से जुड़ा जा सकता है:

{
    sourceFrameNumber: 120,
    startTime: 1352.343235321
}

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

ज़्यादा जानकारी

इस एपीआई की मदद से अभी शिपिंग नहीं की जा रही है. हमें उम्मीद है कि यह जल्द ही उपलब्ध हो जाएगी. इस बीच यहां कुछ चीज़ें दी गई हैं, जिन्हें आप पढ़ और कर सकते हैं: