जब आप "फ्रंटएंड ऑप्टिमाइज़ेशन" सुनते हैं तो आपके दिमाग में क्या आता है? हम में से ज्यादातर के लिए यह नेटवर्क अनुरोधों को कम करना, बंडल को छोटा करना, या कैश का अच्छा उपयोग करना जैसी चीजें हैं। इसके अलावा, शायद री-रेंडर को कम करना या संसाधनों के लोड होने का समय ट्यून करना। मेन थ्रेड आमतौर पर सामने नहीं आता, और इसके लिए एक कारण है: ज्यादातर स्क्रीन पर यह कभी समस्या नहीं बनता। लेकिन बहुत अधिक इंटरैक्शन वाली स्क्रीन पर, जहां डेटा लाइव स्ट्रीम होता है और स्क्रॉलिंग, एनिमेशन, और इनपुट सभी आपस में उलझे होते हैं, तस्वीर बदल जाती है। आप नेटवर्क और बंडल आकार पर कितना भी बचत करें, स्क्रीन उसी पल जम जाती है जब मेन थ्रेड ब्लॉक हो जाता है। आप शायद एक ऐसी वेबसाइट से मिले होंगे जहां स्क्रॉलिंग कभी-कभी हकलाती है, एक बटन थोड़ी देर से प्रतिक्रिया देता है, या सर्च बॉक्स में टाइप किए गए अक्षर आधी बीट पीछे दिखाई देते हैं। यह इतना बुरा नहीं है कि परेशान करे, लेकिन यह एक सूक्ष्म तरीके से आपकी नसों पर चढ़ जाता है। उस तरह का जैंक वही है जो ब्लॉक्ड मेन थ्रेड जैसा दिखता है। जब हम डेवलपर्स के रूप में इस तरह के जैंक में पड़ते हैं, तो सामान्य प्रतिक्रिया यह सोचना होता है "क्या मेरा कोड धीमा है?" और एल्गोरिदम को चुनना या बर्बाद गणना की तलाश शुरू करना। हालांकि ज्यादातर मामलों में, कोड की गति समस्या नहीं है। कोड धीमा नहीं है। यह बस होता है कि वह कोड है जो मेन थ्रेड को पकड़े हुए है। ब्राउज़र में कई थ्रेड होते हैं, लेकिन लगभग हर चीज जिसे हम कोड से छू सकते हैं, मेन थ्रेड पर केंद्रित होती है। गणना, रेंडरिंग, इवेंट हैंडलिंग, नेटवर्क रिस्पॉन्स हैंडलिंग, और आपके फ्रेमवर्क के इंटरनल सभी वहीं प्रोसेस होते हैं। एक संसाधन, काम का पहाड़। ब्राउज़र का मेन थ्रेड महंगा है। ज्यादातर समय यह परेशानी नहीं खड़ी करता, लेकिन एक बार जब आप कुछ महत्वाकांक्षी करने की कोशिश करते हैं, तो मेन थ्रेड से निपटना महत्वपूर्ण हिस्सा बन जाता है। यह लेख उस महंगे संसाधन को कैसे संभालना है, इसके बारे में है। आइए शुरू करते हैं कि मेन थ्रेड वास्तव में क्या करता है। इसका काम दो व्यापक श्रेणियों में आता है। पहला है जावास्क्रिप्ट चलाना। हम जो कोड लिखते हैं, इवेंट हैंडलर, टाइमर, नेटवर्क रिस्पॉन्स कॉलबैक, और फ्रेमवर्क के इंटरनल, सभी यहां चलते हैं। ये टास्क कतार में प्रवेश करने के क्रम में निष्पादित होते हैं, जब भी कोई अंतराल होता है, स्क्रीन रिफ्रेश साइकिल से कोई संबंध नहीं। दूसरा है स्क्रीन ड्रॉ करना। जब DOM या स्टाइल बदलते हैं और स्क्रीन को अपडेट करने की आवश्यकता होती है, तो ब्राउज़र एक फ्रेम बनाने के लिए लगभग इन चरणों से गुजरता है, क्रम में। रिक्वेस्ट एनिमेशन फ्रेम कॉलबैक चलाएं — फ्रेम ड्रॉ होने से ठीक पहले चलने के लिए रजिस्टर्ड जावास्क्रिप्ट स्टाइल गणना — प्रत्येक एलिमेंट के लिए अंतिम CSS मानों की गणना लेआउट — प्रत्येक एलिमेंट की स्थिति और आकार की गणना (जिसे रिफ्लो भी कहा जाता है) पेंट — पेंट कमांड उत्पन्न करना जो वर्णन करता है कि क्या ड्रॉ करना है, किन रंगों में यदि कुछ नहीं बदला, तो ये चरण पूरी तरह से छोड़ दिए जाते हैं, इसलिए वे जरूरी नहीं कि हर फ्रेम चलें। केवल अंतिम कंपोजिटिंग चरण, जो उत्पादित आउटपुट लेता है और इसे स्क्रीन पर असेंबल करता है, कंपोजिटर थ्रेड को सौंप दिया जाता है। दूसरे शब्दों में, स्क्रीन ड्रॉ करने वाली पाइपलाइन का अधिकांश फ्रंट हाफ मेन थ्रेड की जिम्मेदारी है। स्क्रीन अपडेट करने के लिए रेंडरिंग पाइपलाइन स्क्रीन को स्मूथ दिखाने के लिए, फ्रेम को डिस्प्ले के रिफ्रेश रेट पर ड्रॉ करना होगा। सबसे आम 60Hz डिस्प्ले पर, इसका मतलब है 60 फ्रेम प्रति सेकंड, या लगभग 16.6 मिलीसेकंड प्रति फ्रेम। और आप इसका पूरा उपयोग नहीं कर सकते। एक बार ब्राउज़र की अपनी प्रोसेसिंग लागत घट जाने के बाद, व्यावहारिक बजट आमतौर पर लगभग 10 मिलीसेकंड माना जाता है, और 120Hz डिवाइस पर बजट आधा हो जाता है। समस्या यह है कि ऊपर दिए गए दो प्रकार के काम एक ही थ्रेड पर एक लाइन में खड़े हैं। जावास्क्रिप्ट को सिंगल-थ्रेडेड इवेंट लूप मॉडल के आसपास डिजाइन किया गया था। मेन थ्रेड एक समय में एक टास्क प्रोसेस करता है, और जब वह टास्क चल रहा होता है, तो कुछ और नहीं हो सकता। अगर एक जावास्क्रिप्ट फंक्शन 200 मिलीसेकंड तक चलता है, तो उन 200 मिलीसेकंड के लिए ब्राउज़र न तो स्क्रीन को रीपेंट कर सकता है और न ही यूजर से क्लिक प्राप्त कर सकता है। लगभग 10 मिलीसेकंड के फ्रेम बजट के मुकाबले, यह समय घातक है। एक टास्क जो रु...