🐝 🛡️ ⚰️ वेबसाइट एनीमेशन प्रदर्शन 🏊 🌕 ✋🏾

जब विकासशील जगहें जो सशर्त बूटस्ट्रैप के ढांचे से परे जाती हैं, तो एनिमेशन के प्रदर्शन के संबंध में जल्दी या बाद में सवाल उठते हैं। वे डिजाइन साइटों में विशेष रूप से महत्वपूर्ण हैं, जैसे कि वे जो कैटलॉग Awwwards, FWA, CSS Design Awards आदि में आते हैं। हालांकि, अक्सर एनिमेशन और बाद में अनुकूलन बनाने का कार्य, यदि आवश्यक हो, तो बहुत अनुभवी डेवलपर्स के कंधों पर टिकी हुई है, जो यह भी नहीं जानते हैं कि कहां से शुरू करना है। आमतौर पर, यह सब उन निरोधात्मक साइटों में तब्दील हो जाता है जिनका उपयोग करना असंभव है, और इस तरह की परियोजनाओं के पूरे वर्ग के लिए बाद का नकारात्मक रवैया। इस लेख में, हम यह पता लगाने की कोशिश करेंगे कि स्वीकार्य एनीमेशन प्रदर्शन की सीमा कहाँ है, क्या अड़चनें आम हैं और पहली जगह में डेवलपर टूल में कहाँ देखना है।

एक छोटी सी टिप्पणी: चूंकि यह लेख शुरुआती डेवलपर्स के लिए अधिक है और इसका लक्ष्य एनिमेशन के अनुकूलन के लिए सामान्य दृष्टिकोण दिखाना है, बहुत सी चीजें एक सरलीकृत में दी जाएंगी, न कि काफी अकादमिक रूप में।

ब्राउज़र पृष्ठ को कैसे प्रदर्शित करता है

सबसे पहले, यह समझना उपयोगी है कि जब ब्राउज़र हमें पृष्ठ की वर्तमान स्थिति दिखाता है तो क्या होता है। चार मुख्य चरण हैं:

शैली गणना (ब्राउज़र सीएसएस चयनकर्ताओं को पार्स करता है, यह निर्धारित करता है कि कौन सी शैलियों को लागू किया जाना चाहिए)
लेआउट निर्माण (पेज लेआउट वास्तव में बनता है)
पेंटिंग (बाद के प्रतिपादन के लिए तत्वों का पिक्सेल निरूपण बनाता है)
परत रचना (ब्राउज़र स्क्रीन पर सब कुछ एक साथ एकत्र करता है और प्रदर्शित करता है)

इसके अलावा, ब्राउज़र हमेशा इस क्रम में कार्य करता है और अंत तक जाता है। जब पृष्ठ को शुरू में लोड करने के बाद प्रदर्शित किया जाता है, तो सभी चार चरण गुजरते हैं। भविष्य में, हमारे कार्यों में से एक का निष्पादन हो सकता है, लेकिन एक ही समय में सभी बाद वाले को निष्पादित किया जाएगा। लेकिन पिछले वाले नहीं।

हम इनमें से प्रत्येक चरण की बाधाओं पर विचार करेंगे, और अब हम पहली नज़र में एक मूर्खतापूर्ण प्रश्न पूछेंगे, जिसमें से, सिद्धांत रूप में, आपको शुरू करने की आवश्यकता है ...

यह धीमा है या नहीं, यह सवाल है ...

बहुत बार आप ऐसे लोगों से मिल सकते हैं जो स्पष्ट रूप से धीमी वेबसाइट के साथ कुछ भी नहीं कर रहे हैं और कहते हैं "लेकिन मेरे पृष्ठ की गति 100 अंक देती है, सब कुछ ठीक है।" या इसके विपरीत, एक अच्छी तरह से काम करने वाली साइट पर, लोग लंबे समय से किसी प्रकार के अनुकूलन में लगे हुए हैं, क्योंकि कुछ एल्गोरिथ्म कुछ रहस्यमय मैट्रिक्स के आधार पर अक्षमता से काम करते हैं। लेकिन इन चरम सीमाओं के बीच सामान्य ज्ञान का मध्य होना चाहिए, तो यह कहां है?

कि ~~पता है ज़ेन~~ यह समझने के लिए कि क्या आपको अपने एनिमेशन को अनुकूलित करने की आवश्यकता है, आपको एक गहरे दार्शनिक विचार को महसूस करने की आवश्यकता है:

यदि आप देखते हैं कि साइट धीमा है, तो इसका मतलब है कि यह धीमा है। यदि आप नहीं देखते हैं कि साइट धीमा हो रही है, तो यह धीमा नहीं है।

किसी कारण के लिए, बहुत से लोग इस कथन को बहुत बेवकूफ समझते हैं, लेकिन क्या ऐसा है? अंतिम उपयोगकर्ता के लिए, प्रदर्शन कठोर गणितीय औचित्य के साथ कुछ प्रकार के मैट्रिक्स या आदर्श एल्गोरिदम नहीं हैं। उसके लिए, प्रदर्शन दो चीजों में से एक है: यह धीमा हो जाता है या धीमा नहीं होता है।

वह यह कैसे निर्धारित करता है? मॉनिटर के पीछे बहुत समय बिताने वाले व्यक्ति की आंखें एफपीएस में गिरावट पर तेजी से प्रतिक्रिया करना शुरू कर देती हैं। यह एक अजीब सी बेचैनी का कारण बनता है। तदनुसार, हमारा कार्य, डेवलपर्स के रूप में, निर्वाह को रोकना है। क्या उपयोगकर्ता 60fps पर काम करने वाले ब्राउज़र को देखने के लिए उपयोग किया जाता है? ठीक है, तो हम सब कुछ कर रहे हैं ताकि सब कुछ उसी तरह से रहे। हम मध्यम लोहे के साथ एक लैपटॉप लेते हैं और देखो। हम 60fps से बहुत कम देखते हैं - हम अनुकूलन करते हैं। हम लगभग 60 देखते हैं - कुछ भी छूना नहीं है। उपयोगकर्ता को वैसे भी अंतर दिखाई नहीं देगा, और हम अनुकूलन के लिए अनुकूलन पर बहुत समय बिताएंगे।

अनुकूलन के लिए अनुकूलन न करें।

16.5ms

अपने आप को एफपीएस के संदर्भ में व्यक्त करना सुविधाजनक नहीं है, तो आइए मिलिसेकंड पर जाएं। 1000ms / 60fps के सरल विभाजन के साथ, हमें प्रति फ्रेम लगभग 16.5ms का समय मिलता है।

इसका क्या मतलब है? 16.5ms के लिए, ब्राउज़र को हमें एनीमेशन के साथ पृष्ठ की वर्तमान स्थिति दिखानी चाहिए, ऊपर दिए गए चरणों का पालन करते हुए, और उसी समय, अन्य लिपियों के काम के लिए संसाधन बने रहना चाहिए, सर्वर के साथ संचार, आदि। यदि पृष्ठ की वर्तमान स्थिति को प्रदर्शित करने में अधिक समय व्यतीत किया जाता है, तो हम अपनी आंखों के अंतराल के माध्यम से देखेंगे। यदि लगभग 16ms, तो कोई सबसिडी नहीं होगी, लेकिन यह संभावना है कि लोहे का भार बहुत अधिक होगा, कूलर गुलजार होंगे, और फोन गर्म हो जाएंगे। इस प्रकार, हमें यह सुनिश्चित करने की आवश्यकता है कि एक फ्रेम का प्रतिपादन समय में इस मूल्य के करीब नहीं आता है, और इससे भी बेहतर 10ms से अधिक नहीं है, ताकि प्रदर्शन में एक मार्जिन हो। यह मत भूलो कि परीक्षण हमेशा मध्य हार्डवेयर पर किए जाते हैं - उदाहरण के लिए, निम्नलिखित उदाहरणों में, एकीकृत ग्राफिक्स के साथ पेंटियम सिल्वर पर स्क्रीनशॉट लिया जाएगा।

आपके उपयोगकर्ताओं के हार्डवेयर पर परीक्षण अधिक होने की संभावना है। यदि आपके कार्यस्थल में टेबल के नीचे एक टॉप-एंड प्रोसेसर और एक खनन फार्म है, तो आपके लिए सब कुछ ठीक रहेगा, जबकि बजट लैपटॉप वाले आपके उपयोगकर्ता बहुत दुखी हो सकते हैं।

केवल अपनी अच्छी आंख और अंतर्ज्ञान पर भरोसा नहीं करने के लिए, यह डेवलपर टूल को मास्टर करने के लिए उपयोगी है, कम से कम एक बुनियादी स्तर पर। वे न केवल सटीक प्रदर्शन डेटा देंगे, बल्कि आपको यह भी बताएंगे कि समस्या की तलाश कहां करें, अगर सब कुछ बहुत अच्छा काम नहीं करता है।

Google Chrome में डेवलपर टूल

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

जब प्रदर्शन की बात आती है, तो हम प्रदर्शन टैब में अधिकांश समय बिताएंगे और एक ही बटन दबाएंगे।

Ctrl-E शॉर्टकट या बाईं ओर का गोल बटन शुरू होता है और जो हो रहा है उसकी रिकॉर्डिंग बंद कर देता है। परिणाम यहां प्रदर्शित हैं। ब्राउज़र बहुत सी चीजें लिखता है, लेकिन इसे कई बार पढ़ने की तुलना में एक बार देखना बेहतर होता है, इसलिए आइए किसी तरह का एनीमेशन लें और इसे देखें। यह शुरुआत के लिए एक सरल सीएसएस एनीमेशन होने दें। यदि आप इसे पूर्ण स्क्रीन में खोलते हैं, तो आप देख सकते हैं कि यह ध्यान देने योग्य जाम के साथ काम करता है:

हम पूर्ण स्क्रीन मोड में कुछ सेकंड रिकॉर्ड करेंगे और देखेंगे कि वहां क्या होता है:

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

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

आगे हम कई लाइनें देखते हैं जिसमें लोड अलग-अलग रंगों में प्रदर्शित होता है - आप देख सकते हैं कि ब्राउज़र ने विभिन्न प्रकार की गतिविधियों पर कितना समय बिताया है। हमारा एनीमेशन एक समान है और प्रत्येक फ्रेम के लिए एक ही संचालन किया जाता है, जिसे बैंगनी और हरे रंग से दर्शाया जाता है। यदि आप रंगीन ब्लॉकों पर माउस को घुमाते हैं, तो यह स्पष्ट हो जाएगा कि हम उन वस्तुओं से निपट रहे हैं जो शुरुआत में बताई गई थीं - पुनर्गणना शैली और अपडेट लेयर ट्री बैंगनी हैं, और पेंट और मिश्रित परतें हरे हैं।

एक और एनीमेशन पर विचार करें। स्क्रिप्ट के साथ इस बार - एक साधारण शोर जनरेटर। यह एक काफी निराशाजनक उदाहरण है, हालांकि यह डिजाइन के दृष्टिकोण से कोई दिलचस्पी नहीं है:

आप देख सकते हैं कि पीले ब्लॉक जोड़े गए हैं जो स्क्रिप्ट के निष्पादन को प्रदर्शित करते हैं। यदि कई फ़ंक्शन कॉल होंगे, तो प्रत्येक कॉल के लिए एक और ब्लॉक जोड़ा जाएगा - उनके आकार से "सबसे भारी" फ़ंक्शन को ढूंढना आसान है, जिसके साथ, शायद, यह अनुकूलन शुरू करने के लायक है।

उदाहरण में, एक फ्रेम पर बिताया गया समय 80ms के आसपास उतार-चढ़ाव करता है। लेकिन वहाँ क्या है, यहां तक कि नग्न आंखों से आप स्पष्ट रूप से देख सकते हैं कि सब कुछ कैसे दुर्घटनाग्रस्त होता है। नीचे सारांश अनुभाग को देखते हुए, हम देखते हैं कि स्क्रिप्ट में सबसे अधिक समय लगता है। उनकी तुलना में, प्रतिपादन और पेंटिंग उन त्रुटियों की तरह दिखती हैं जिन्हें उपेक्षित किया जा सकता है। हमेशा नहीं, बेशक, ऐसा होता है, लेकिन अक्सर।

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

क्या करें अगर ...

हमने सीखा कि किसी ब्राउज़र में किसी पृष्ठ की वर्तमान स्थिति प्रदर्शित करते समय कौन से चरण होते हैं, और यह देखने के लिए कि सबसे अधिक समय कौन सा लगता है। यह सबसे सामान्य कारणों से परिचित होने का समय है कि क्यों इस या उस कदम के लिए बहुत सारे संसाधनों की आवश्यकता होती है और इस या उस मामले में क्या करना है, इस पर कुछ सुझाव दिए जाएं।

शैली गणना

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

पृष्ठ पर तत्वों की संख्या कम करें, लेआउट को सरल बनाएं। रैपर के साथ कोड के टुकड़ों को दोहराने पर विशेष ध्यान दें, यह संभावना है कि उन्हें हटाया जा सकता है।

पहला सीएसएस सेलेक्टर्स से जुड़ा दूसरा कारण है। यदि छोटे पृष्ठों पर गहरे घोंसले के शिकार, पड़ोसी तत्वों के साथ मुश्किल हैक आदि का उपयोग करना संभव है, तो वास्तव में बड़े पृष्ठ पर यह सब खराब प्रदर्शन का कारण बन सकता है।

CSS चयनकर्ताओं को सरल करें, BEM का उपयोग करें।

लेआउट निर्माण

यह आइटम पहले से ही डिजाइन और एनिमेशन के करीब है, यहां दिलचस्प चीजें शुरू होती हैं। पहली चीज जो समझना महत्वपूर्ण है, वह यह है कि पूरा लेआउट बनता है। यदि हम कुछ बदलते हैं, तो यह नए सिरे से बनता है। इस कारण से, बड़े पृष्ठ पर भी छोटे परिवर्तन इस कदम पर ध्यान देने योग्य देरी का कारण बन सकते हैं।

एनिमेशन बनाते समय हमारा मुख्य नियम है कि किसी भी कीमत पर लेआउट के पुनर्गठन की अनुमति नहीं है। इसलिए, हम आमतौर पर इसे अनुकूलित करने की कोशिश नहीं करते हैं (और कोई विशेष अवसर नहीं हैं), अर्थात्, हम इससे बचने की कोशिश करते हैं।

कई गुण हैं जो लेआउट के पुनर्निर्माण का कारण बन सकते हैं, आप इंटरनेट पर सूचियां पा सकते हैं, उदाहरण के लिए, csstriggers.com खराब नहीं है। एनिमेशन में दूसरों की तुलना में अधिक बार आप गुण पा सकते हैं:

display position / top / left / right / bottom width / height padding / margin border font-size / font-weight / line-height ...

आप देख सकते हैं कि ये सभी गुण एक चीज से एकजुट हैं - वे तत्वों की ज्यामितीय विशेषताओं का वर्णन करते हैं - प्रदर्शन पैरामीटर, आकार और भौतिक स्थान। इसलिए उन सभी को याद करने के बजाय, याद रखें कि वे क्या संदर्भित करते हैं।

तत्वों के ज्यामितीय गुणों में बदलाव न करें, परिवर्तन और अस्पष्टता का उपयोग करना बेहतर है।

अलग-अलग, यह ध्यान देने योग्य है कि तत्व की पृष्ठभूमि को बदलना भी हमें इस कदम पर लौटा देगा। वे लगातार इस बारे में भूल रहे हैं, इसलिए हम एक अलग सिफारिश पर प्रकाश डालते हैं:

पृष्ठभूमि तत्वों को न बदलें।

कुछ ब्राउज़रों में ( ~~मैं फ़ायरफ़ॉक्स में एक उंगली प्रहार नहीं करूँगा~~ ) परिवर्तनों के साथ सीएसएस एनिमेशन का एक विशिष्ट अंतराल दिखाई दे सकता है, खासकर यदि प्रति यूनिट समय में एक से अधिक एनीमेशन किए जाते हैं। बाह्य रूप से, यह न केवल उसके काम में एक ठहराव के रूप में दिखाई दे सकता है, बल्कि इसकी शुरुआत में एनीमेशन के "टूटने" के रूप में भी हो सकता है। ऐसा लगता है कि ब्राउज़र लगातार कुछ गणना कर रहा है। बैक-विज़िबिलिटी प्रॉपर्टी का उपयोग करके इस व्यवहार को लगभग हमेशा ठीक किया जाता है।

यदि संभव हो तो, बैक-विज़िबिलिटी जोड़ें: एनिमेटेड तत्वों के लिए छिपा हुआ।

इसके अलावा, लेआउट का पुनर्निर्माण लिपियों से तत्वों को हमारी कॉल के कारण होता है। इसके अलावा, यह सीएसएस के लिए एक सीधा परिवर्तन नहीं है, यह कुछ गुणों और तत्वों के तरीकों के लिए एक अपील भी हो सकता है। सबसे आम हैं:

 offset*** client*** inner*** scroll***

एनिमेशन में, आपको उनसे सावधान रहना चाहिए, क्योंकि यदि हम बड़ी संख्या में तत्वों के लिए इन गुणों और विधियों का उल्लेख करना शुरू करते हैं, तो हर बार यह लेआउट के पुनर्गठन का कारण होगा।

लूप में व्यक्तिगत तत्वों के लिए उल्लिखित गुणों और विधियों का उल्लेख करने से बचें।

पेंटिंग और परत रचना

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

ब्राउज़र पृष्ठ की पिक्सेल छवि तैयार नहीं करता है, लेकिन भागों में - परतें। कई हो सकते हैं। प्रत्येक परत मौजूद है जैसे कि अपने आप में और बाकी को प्रभावित नहीं करती है, जो कुछ सीएसएस हैक के लिए आधार बनाता है। लेकिन हम उनके बारे में दूसरी बार बात करेंगे। फिर इन परतों से अंतिम छवि एकत्र की जाती है। एनिमेशन के संदर्भ में, एनिमेटेड तत्वों को एक अलग परत में रखना बहुत उपयोगी है ताकि उनके परिवर्तन आसपास की हर चीज को प्रभावित न करें। यह वांछनीय है कि तत्वों की सामग्री छोटी है। हम विल-चेंज प्रॉपर्टी का उपयोग करके ऐसा कर सकते हैं या, जैसा कि हमने पहले किया था, ट्रांसफॉर्म: ट्रांसलेट (0) । याद रखने वाली एकमात्र बात यह है कि आप परतों की संख्या अनिश्चित काल तक नहीं बढ़ा सकते हैं। कुछ बिंदु पर, यह एक चाल चलाएगा और विपरीत प्रदर्शन छोड़ देगा। तो दो सुझाव होंगे:

वसीयत-परिवर्तन या परिवर्तन का उपयोग करें: एनिमेटेड तत्वों को एक अलग परत में स्थानांतरित करने के लिए TranslZ (0)।

लेकिन एक ही समय में

इस व्यवसाय के साथ इसे ज़्यादा मत करो। डेवलपर टूल में जांचें कि यह बदतर नहीं है।

बहुत बार, गंभीर समस्याएं फिल्टर के कारण होती हैं जो किसी भी तरह तत्वों की छवि को बदल देती हैं। यह एसवीजी के साथ ब्लर या भ्रमित विकल्पों के साथ सरल सीएसएस फिल्टर हो सकता है, लेकिन प्रभाव समान होगा - प्रदर्शन में ध्यान देने योग्य कमी।

जटिल फिल्टर का उपयोग न करें। यदि आपको अभी भी इच्छित प्रभाव की आवश्यकता है, तो इसे WebGL पर लागू करने पर विचार करें।

ये टिप्स कैसे काम करते हैं?

वे काम करते हैं, लेकिन आपको उनसे चमत्कार की उम्मीद करने की आवश्यकता नहीं है। नेट पर, newbies कभी-कभी कहते हैं, "मैंने एक इच्छा-परिवर्तन जोड़ा, लेकिन कुछ भी नहीं बदला है।" आमतौर पर इसका मतलब है कि मुख्य समस्या एक और जगह पर थी, और इस तकनीक ने उत्पादकता में इतनी छोटी वृद्धि दी कि यह किसी का ध्यान नहीं गया। यही कारण है कि डेवलपर के औजारों का उपयोग यह स्पष्ट रूप से समझने के लिए महत्वपूर्ण है कि अड़चन कहां है और समय और प्रयास को खर्च करने का प्रयास नहीं करना है जो वैसे भी ठीक काम कर रहा है।

इस सब से हम यह निष्कर्ष निकाल सकते हैं कि एक पृष्ठ के प्रतिपादन को प्रभावित करने के कई तरीके नहीं हैं, और उनका प्रभाव हमेशा महत्वपूर्ण नहीं होगा। ये चालें चांदी की गोलियां नहीं हैं, बल्कि उन्हें एनीमेशन चमकाने के लिए आवश्यक है। यदि हम वास्तव में खराब प्रदर्शन वाली साइटों को देखते हैं, तो हम देखेंगे कि अधिकांश मामलों में हमारी अपनी स्क्रिप्ट को दोष देना है, और ब्राउज़र की आंतों में कहीं सीएसएस पार्सिंग के साथ रहस्यमय समस्याएं नहीं हैं।

लिपियों ...

क्या आप जानते हैं कि निरोधात्मक एनिमेशन के साथ समस्याएं अक्सर (मेरी टिप्पणियों के अनुसार) कैसे बढ़ती हैं? यहाँ इस विकास दृष्टिकोण से:

यह मूर्खतापूर्ण लगता है, लेकिन यह है। लगातार समाधान हैं, स्पष्ट रूप से कहीं से पूरी तरह से नकल किए बिना यह समझे कि क्या हो रहा था। यह भी होता है कि आप आधे कोड निकाल सकते हैं और सब कुछ काम करना जारी रखेगा। अक्सर एसओ या टोस्टर के जवाब में कोड आपके उत्पादन के लिए अभिप्रेत नहीं है। यह स्पष्ट होना चाहिए। वह विचार दिखाता है, सवाल का जवाब देता है, लेकिन आपके विशिष्ट कार्य के लिए इष्टतम अंतिम विकल्प नहीं है।

यदि आप पहले से ही नकल कर रहे हैं, तो कम से कम अनावश्यक कार्यों के लिए कोड को देखें।

RequestAnimationFrame

वे अक्सर इस पद्धति के बारे में बात करते हैं और एनिमेशन में सेटटाइमआउट / सेटइंटरवल के बजाय इसका उपयोग करने की सलाह देते हैं। यह समझ में आता है, क्योंकि उन विधियों में फ़्रेम के साथ सिंक से बाहर होने की संपत्ति है जो ब्राउज़र को फिर से बनाता है, जिसके परिणामस्वरूप छोटे अंतराल होते हैं। लेकिन दो बिंदु हैं।

सबसे पहले, यदि पृष्ठ पर एक से अधिक तत्व एनिमेटेड हैं और हम कई बार कॉल करते हैं, तो कई बार हमें पता चलता है कि इससे एफपीएस की तीव्र कमी होगी। सिद्धांत रूप में, यह नहीं होना चाहिए, लेकिन व्यवहार में, सब कुछ उसी तरह होता है। आप यहां परीक्षणों से खुद को परिचित कर सकते हैं ।

सभी एनीमेशन कॉलबैक को एक अनुरोध में जोड़ दें।

दूसरा बिंदु उस स्थिति से जुड़ा होने की अधिक संभावना है, जहां हमारे पास पहले से ही भारी एनीमेशन है, शायद कैनवास के उपयोग के साथ, जिसे हम छुटकारा नहीं पा सकते हैं या इसके पास कोई समय नहीं है, और निम्न होता है: मान लें कि एनीमेशन को एन सेकंड में पूरा किया जाना चाहिए और हम पहले से ही अनुरोध को हटा दें । लेकिन वर्तमान स्थिति की गणना करने के लिए बहुत सारे संसाधन लगते हैं और हम इस तस्वीर को देखते हैं: एनीमेशन सुचारू रूप से, खूबसूरती से काम करता है, लेकिन 2N में, या 3N सेकंड भी। नतीजतन, सब कुछ soooooooooo माना जाता है। किसी भी तरह से इस व्यवहार को ठीक करने के लिए, आप सभी सिफारिशों के खिलाफ जा सकते हैं, जिससे setInterval / setTimeout का उपयोग करें और एनिमेटेड तत्वों की अवस्थाओं को भौतिक समय पर बाँधें , न कि अमूर्त फ़्रेमों को। परिणामस्वरूप, हमें एफपीएस में औपचारिक कमी मिलती है, लेकिन उत्पादकता लाभ के मनोवैज्ञानिक प्रभाव के साथ।

अत्यंत धीमे एनिमेशन के मामले में, यह अनुरोध करने से इंकार कर सकता है।

कैनवस एंड शेड्स

गैर-मानक साइटों पर एनिमेशन का एक महत्वपूर्ण हिस्सा कैनवास से संबंधित है। यह समझने योग्य है, सीएसएस एक सीमित चीज है, लेकिन यहां हम किसी भी डिजाइनर की कल्पनाओं को महसूस कर सकते हैं। लेकिन आपको यह ध्यान रखने की आवश्यकता है कि सामान्य 2 डी-कैनवास सबसे अधिक उत्पादक तकनीक से दूर है। यदि आप इस पर बहुत सारे तत्वों को आकर्षित करना शुरू करते हैं या सीधे पिक्सेल के साथ काम करते हैं, तो आप जल्दी से इस तथ्य के साथ आएंगे कि एफपीएस डूब रहा है, या काफी अचानक पेंटिंग और परत की रचना में बहुत समय लगने लगा है। इस समस्या को उदाहरण में स्पष्ट रूप से देखा जा सकता है:

आइए देखें कि ब्राउज़र क्या करता है (लिनक्स के तहत नवीनतम Google Chrome):

ध्यान दें कि लेयर कंपोजिशन स्टेप का कितना विस्तार हुआ है। यह थोड़ा अतार्किक लगता है, क्योंकि एक ही तत्व है, इतने लंबे समय तक वहां क्या इकट्ठा किया जा सकता है? लेकिन 2d कैनवास का उपयोग करते समय, यह व्यवहार असामान्य नहीं है, और इसके साथ कुछ करना बहुत समस्याग्रस्त है। यह एक कारण है कि हम आमतौर पर वेबजीएल का उपयोग करते हैं, ऐसे कोई सवाल नहीं हैं।

यदि 2d कैनवास और WebGL के बीच कोई विकल्प है, तो दूसरा चुनें। यह एक ही कार्य पर एक प्रारंभिक प्रदर्शन बोनस देगा।

आमतौर पर WebGL के साथ क्या संबद्ध है? शेड्स के साथ। और शेडिंग डिबगिंग उन लोगों के लिए सिरदर्द है जो उनके साथ काम करते हैं। और यहां डेवलपर उपकरण व्यावहारिक रूप से शक्तिहीन हैं। आमतौर पर, यदि शेड में बहुत अधिक गणनाएँ होती हैं, तो हम नीचे दिए गए सारांश में देखते हैं कि सबसे अधिक समय "सरल" है, जो वास्तव में ब्राउज़र की परवाह किए बिना हमारे शेड्स का निष्पादन है, और हमें कोई उपयोगी विवरण नहीं मिल सकता है।

अलग-अलग सिफारिशें हैं जिनके बारे में कार्य करना पसंद करते हैं, क्योंकि वे बेहतर रूप से अनुकूलित किए गए हैं। या कि अवरुद्ध संचालन से बचा जाना चाहिए। यह सब सच है, लेकिन मेरी टिप्पणियों के अनुसार, ज्यादातर मामलों में, साइट को बहुत धीमा करने वाले शेड केवल बहुत बड़े शेड हैं। यदि आपने एक स्थान पर 100 GLSL लाइनें लिखी हैं, तो यह लगभग खराब काम करने की गारंटी है। और अगर अलग-अलग नेस्टेड कंस्ट्रक्शन हैं, लूप हैं, तो सब कुछ - राइट हो गया है। जब तक यहाँ कोई भी सिफारिश देना मुश्किल है:

यदि आपको काम के दौरान एहसास हुआ कि शुरुआत में सब कुछ अधिक जटिल है, और यह कि बहुत अधिक कोड होगा और यह धीमा हो जाएगा - यह जल्द से जल्द डिजाइनर और ग्राहक के साथ चर्चा करना बेहतर है और सोचें कि क्या बदला जा सकता है।

अक्सर आप इस निष्कर्ष पर आ सकते हैं कि एक पूर्व-तैयार वीडियो वास्तविक समय में किसी प्रकार की भ्रमित चीज़ को प्रस्तुत करने की कोशिश करने से बेहतर काम करेगा। इसे याद रखें। हां, हर कोई खुद को दिखाना चाहता है, वे "दिखावा करना चाहते हैं, लेकिन मैं इसे ऐसे ही कर सकता हूं", लेकिन अंतिम उपयोगकर्ताओं के बारे में मत भूलना।

इस विचार के संबंध में, मैं उस "बीमारी" को याद करता हूं जिसमें पूर्व ओलंपियाड विशेष रूप से अतिसंवेदनशील है। किसी कारण से, कैनवास के साथ काम करते समय यह दृढ़ता से प्रकट होता है। इसके कारण के लिए, आपको हमेशा ऐसे लोगों के कोड को सावधानीपूर्वक कॉपी करना चाहिए। वे "सटीकता" गणितीय एल्गोरिदम, जटिल भौतिक फ़ार्मुलों का उपयोग करने की कोशिश करते हैं, जहां तत्वों की सभी आंदोलनों को महान सटीकता के साथ गणना करने के लिए, जहां यह पूरी तरह से बेकार है। यह प्रोसेसर पर लोड को बढ़ाता है और इस तथ्य की ओर जाता है कि हमारे सशर्त 10ms के लिए कुछ भी गिनने का समय नहीं है। व्यवहार में, आप अक्सर भौतिक विज्ञान के अनुमानित सूत्रों और स्कूल ज्ञान के साथ प्राप्त कर सकते हैं। चीजों को जटिल करना आवश्यक नहीं है, हम बैलिस्टिक मिसाइलों के लिए सॉफ्टवेयर नहीं, वेबसाइट बनाते हैं।

सरल एल्गोरिदम का उपयोग करें।

RayMarching नामक एक और चाल है। कुछ लोग इसके साथ विभिन्न प्रभावों के निर्माण को चुनौती के रूप में मानते हैं, मन के लिए एक वार्म-अप, और कभी-कभी परिणाम बहुत प्रभावशाली होते हैं। उदाहरण के लिए, एक पूरी पानी के नीचे की दुनिया यहां उत्पन्न होती है (मैंने एक वीडियो डाला, क्योंकि वास्तविक समय में इस गणना से फोन / लैपटॉप खुद को लटका सकते हैं):

यहां खुद ही शेडर पाया जा सकता है ।

व्यवहार में, इस सभी को काम करने के लिए अविश्वसनीय संसाधनों की आवश्यकता होती है। पूर्ण-स्क्रीन मोड में, हमारे पास प्रति फ्रेम 400-800ms हैं (सामान्य तौर पर, इस उदाहरण में, यह 1500 ग्राम तक जा सकता है):

इसलिए यदि आपने खुद को एक युद्ध स्थल पर कुछ ऐसा करने की सोच कर पकड़ा है - अपने आप को सिर पर एक कीबोर्ड दें, चाय पीएं और प्रभाव को लागू करने के लिए वैकल्पिक विकल्पों के बारे में सोचें।

RayMarching का उपयोग न करें, यह प्रदर्शन को मारने का एक निश्चित तरीका है।

व्यावहारिक उदाहरण

उत्पादकता के बारे में लेखों में अक्सर पर्याप्त उदाहरण नहीं होते हैं, लेकिन एक शब्द लेना मुश्किल हो सकता है। तो एक दो पर विचार करें। पहला CSS कताई सुरंग उदाहरण याद है? ब्राउज़र ने बहुत कुछ किया:

हम चीजों को थोड़ा गति देना चाहते हैं। कहाँ से शुरू करें? हम बैंगनी ब्लॉक देखते हैं, जिसका अर्थ है कि ब्राउज़र लेआउट का लगातार पुनर्निर्माण कर रहा है। वहां कोई स्क्रिप्ट नहीं है, लेकिन सीएसएस एनिमेशन हैं जिसमें कुछ परिवर्तन होता है। आइए उनके कोड को देखें:

 @keyframes rotate { from { transform: rotate(0); } to { transform: rotate(360deg); } } @keyframes move-block { from { transform: translateX(0); background: @color1; } to { transform: translateX(-@block-size * 6); background: @color2; } }

रूपांतरण हमें डराता नहीं है, लेकिन हम तत्वों की पृष्ठभूमि में बदलाव देखते हैं। हमें याद है कि यह लेआउट के पुनर्गठन का कारण बन सकता है, और हमें लगता है कि इस स्थिति में क्या किया जा सकता है ...

पृष्ठभूमि को हर कीमत पर हटाने की आवश्यकता है, इसलिए एनीमेशन के सामान्य विचार के आधार पर, हम तय करते हैं कि आप शीर्ष पर एक रेडियल ढाल डाल सकते हैं, जो लगभग एक ही वॉल्यूम प्रभाव पैदा करेगा। कोई कहेगा कि ग्रेडिएंट्स के प्रदर्शन पर बुरा प्रभाव पड़ता है, लेकिन हम इसे बदलने नहीं जा रहे हैं। एक बार इसे बुरी तरह से प्रभावित करने दें इससे बेहतर होगा कि हमारे पास तत्वों को लगातार प्रभावित करने वाला एक पूरा पहाड़ हो। परिणाम है:

आइए देखें कि ब्राउज़र क्या करता है:

वाह ... क्रियाओं के एक समूह के बजाय, हम GPU के लिए दुर्लभ कॉल देखते हैं और कुछ नहीं, जबकि एनीमेशन ने खुद को ध्यान देने योग्य काम करना शुरू कर दिया।

एक और उदाहरण

याद रखें कि शोर जनरेटर में ब्राउज़र कैसा दिखता है:

समस्या निश्चित रूप से लिपियों में है। यह देखा जा सकता है कि "रेंडर" ब्लॉक सबसे बड़ा है। छवि प्रदान करने के लिए यह हमारा मुख्य कार्य है। चलो उसे देखो:

 function render() { let imageData = CTX.createImageData(CTX.canvas.width, CTX.canvas.height); for (let i = 0; i < imageData.data.length; i += 4) { const color = getRandom(); imageData.data[i] = color; imageData.data[i + 1] = color; imageData.data[i + 2] = color; imageData.data[i + 3] = 255; } CTX.putImageData(imageData, 0, 0); requestAnimationFrame(render); }

व्यक्तिगत पिक्सेल के साथ निश्चित रूप से काम चल रहा है। यह बहुत स्वस्थ नहीं है। हमने कहा कि यदि संभव हो तो 2d-कैनवास का उपयोग करना बेहतर है, लेकिन WebGL, और यह कार्य केवल एक shader का उपयोग करके समानांतर किया जाना चाहता है। चलो इसे करते हैं:

इसका परिणाम क्या होगा? अपने लिए देखें:

एक फ्रेम के लिए समय लगभग 16ms तक कम हो गया। बेशक यह आदर्श नहीं है, लेकिन अभी भी 80ms से बेहतर है। जटिल सुंदर एनिमेशन में, ऐसा प्रदर्शन लाभ बहुत ध्यान देने योग्य हो सकता है। मैं यह अनुशंसा करने का अवसर लेता हूं कि शुरुआती प्रोग्रामिंग में छायांकन की शुरुआत और उदाहरणों के साथ निरंतरता के साथ खुद को परिचित करते हैं ।

निष्कर्ष

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

वेबसाइट एनीमेशन प्रदर्शन