💪 🧒 🧟 शैलियों की महंगी कीमत। यैंडेक्स रिपोर्ट ☝🏻 ⤴️ 🕤

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

- सभी को नमस्कार। मैं आपको शैलियों के बारे में बताता हूँ। हर कोई आज टाइपस्क्रिप्ट और टाइपस्क्रिप्ट के बारे में बात कर रहा है। और मैं कैस्केड शैली की स्क्रिप्ट के बारे में बात करूंगा।

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

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

किस लिए?

के साथ शुरू करने के लिए - क्यों सीएसएस अनुकूलन के बारे में बात करते हैं?

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

यदि आप Google को देखते हैं, तो JS के बारे में 111 मिलियन परिणाम हैं, और CSS के बारे में सिर्फ 26 मिलियन हैं।

तो शायद यह कोई फर्क नहीं पड़ता? इसके बारे में बात क्यों करें? यदि आप जेएस प्रदर्शन रिपोर्ट की तलाश करते हैं, तो आप उनमें से बहुत कुछ पाएंगे। प्रतिक्रिया के बारे में है, सभी प्रकार के अन्य ढांचे के बारे में, वेनिला के बारे में, आदि। लेकिन सीएसएस के बारे में, मुझे केवल एक रिपोर्ट मिली। 2018 में हैरी रॉबर्ट्स ने सीएसएस प्रदर्शन के बारे में एक अच्छी रिपोर्ट पढ़ी । मुझे लगा कि मुझे एक दूसरी रिपोर्ट मिली हैरोमा Dvornova द्वारा, "पारसीम सीएसएस: प्रदर्शन युक्तियाँ और चालें"। लेकिन यह एक जेएस रिपोर्ट निकला जो सीएसएस को पार्स करती है। ठीक वैसा नहीं जैसा हमें चाहिए।

यह पता चला है कि वे सीएसएस के बारे में ज्यादा नहीं सोचते हैं। यह शर्मनाक है।

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

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

वैसे, इस तथ्य के बारे में अध्ययन हैं कि मुख्य बात पहली छाप बनाना है।38% उपयोगकर्ता साइट पर जा सकते हैं, और यदि वे देखते हैं कि यह सीधे घृणित है, तो वे तुरंत निकल जाएंगे। और 88% सहन करेंगे, एक बार इसका उपयोग करें, और फिर वे कभी वापस नहीं आएंगे और आपकी साइट को सलाह देने की संभावना नहीं है।

अब जब हम सभी घर बैठे हैं, इंटरनेट ट्रैफिक विशेष रूप से बढ़ गया है। और हमें यह सोचने की ज़रूरत है कि उपयोगकर्ताओं को किसी भी संसाधन को कुशलता से कैसे वितरित किया जाए।

आइए Yandex के दृष्टिकोण से गिनने का प्रयास करें। यदि हम प्रत्येक Yandex डिलीवरी को 100 ms के लिए ऑप्टिमाइज़ कर सकते हैं और कह सकते हैं, प्रति दिन 200 मिलियन पेज (मैं सटीक संख्या नहीं जानता), तो इस दिन हम 0.1 s * 200 मिलियन = 232 व्यक्ति-दिन बचाएंगे। बस 100 मिलीसेकंड के लिए आउटपुट का अनुकूलन करके। और CSS वो भी करता है।

आइए थोड़ा जासूस खेलें और पता करें कि लोडिंग शैलियों का सबसे अधिक उपयोग कैसे करें।

उपाय!

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

माप उपकरण क्या हैं?

- यदि आप अधिक या कम वास्तविक उपकरणों को मापना चाहते हैं, तो धीमा, आपके जैसा शांत नहीं है, WebPageTest का उपयोग करें । मैं आमतौर पर वहां माप लेता हूं।

- यदि आपके पास क्रोमियम-आधारित ब्राउज़र का उपयोग है तो आपके पास लाइटहाउस है। वह, स्थानीय माप की तरह, काफी अच्छी चीजें दिखाता है।

- यदि आप सुनिश्चित हैं कि आप सब कुछ स्वयं कर सकते हैं, तो DevTools पर जाएं, प्रदर्शन टैब पर। इसमें बहुत सारे विवरण हैं, आप अपने स्वयं के मैट्रिक्स शुरू कर सकते हैं और उनका विश्लेषण कर सकते हैं।

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

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

सबसे महत्वपूर्ण: वास्तविक उपयोगकर्ताओं पर माप। ऐसी एक मीट्रिक है, अधिक सटीक रूप से, मैट्रिक्स का एक पूरा सेट - RUM, वास्तविक उपयोगकर्ता निगरानी। यह तब होता है जब आप मापते हैं कि आपके कोड में क्या कृत्रिम रूप से नहीं होता है, लेकिन उत्पादन में वास्तविक उपयोगकर्ताओं पर मैट्रिक्स होता है। उदाहरण के लिए, पेज लोड करने से लेकर एक्शन तक। एक कार्रवाई, उदाहरण के लिए, कुछ ऐसा है जो ब्राउज़र में काम करता है या यहां तक कि कुछ महत्वपूर्ण तत्व पर भी क्लिक करता है।

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

ऐसे मैट्रिक्स हैं जिन पर ध्यान केंद्रित करना महत्वपूर्ण है। यह फर्स्ट कंटेंटफुल पेंट है, जब आपके पेज पर पहला कंटेंट दिखाई देता है जिसके साथ आप कुछ कर सकते हैं, पढ़ें। यह मीट्रिक क्रोमियम ब्राउज़रों में भेजा जाता है, आप इसे प्राप्त कर सकते हैं।

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

सीएसएस लोड हो रहा है

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

<!DOCTYPE html>
<html lang="ru">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>CSS —  </title>
    <link rel="stylesheet" href="/main.ac74gsac.css">
</head>

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

 <!DOCTYPE html>
<html lang="ru">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>CSS —  </title>
    <link rel="stylesheet" href="/main.ac74gsac.css">
</head>
<body>
    <h1>-!</h1>
</body>
</html>

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

<Link>

चलो गहराई से खुदाई करें - जब आप लिंक तक पहुंचते हैं तो क्या होता है?

हम जहां जाते हैं वहां रिकॉर्डिंग करना मानक है। एक सीएसएस शैली है जो कहीं न कहीं निहित है। अब CDN पर सभी स्टैटिक्स डालना फैशनेबल है।

कहाँ जाना है?

सबसे पहले, ब्राउज़र को समझने की आवश्यकता है कि कहां जाना है।

वह URL देखता है, और उसे इस URL को समझने की आवश्यकता है - यह क्या है? हम इस तथ्य के लिए उपयोग किए जाते हैं कि URL एक साइट पहचानकर्ता है।

लेकिन शारीरिक रूप से हमें इस URL का IP पता प्राप्त करने और IP पते पर वास्तविक भौतिक मशीन पर जाने की आवश्यकता है।

आपके CDN के लिए, यह DNS में एक रिकॉर्ड प्राप्त करेगा और वास्तव में सीधे IP पते पर जाएगा। इस मामले में कोई कैसे तेजी ला सकता है?

एक पागल विचार उपयोगकर्ता से DNS सर्वर की दूरी को कम करना है। उपयोगकर्ता को लें और ट्रांसप्लांट करें। उदाहरण के लिए, संदेश प्रदर्शित करने के लिए: "करीब बैठो" या "करीब चलो"।

आप तुरंत लिंक में आईपी पते को निर्दिष्ट कर सकते हैं। हमें DNS की तलाश करने, डोमेन को हल करने की आवश्यकता क्यों है, यदि आप तुरंत आईपी पते द्वारा परिणाम दे सकते हैं? यह एक पागल तरीका है, लेकिन DDoS ग्लोबल DNS सर्वर के मामले में यह आपको बचा भी सकता है।

और हम एक IP पता प्राप्त करने से छुटकारा पा सकते हैं।

अपने index.html या किसी अन्य फ़ाइल की ओर मुड़ते हुए, आप पहले से ही उस डोमेन पते को जानते हैं जहाँ आप जाते हैं। यहाँ केवल ऐसा मामला है, जब एक अलग डोमेन या उपडोमेन पर स्टैटिक्स को संग्रहीत करने के बजाय, आप स्टैटिक्स को अपने डोमेन के करीब रख सकते हैं, अर्थात् यह डोमेन। तब DNS को हल करने की आवश्यकता नहीं है, यह पहले से ही है।

हमें लगा कि कहां जाना है। लेकिन हम ब्राउज़र के लिए ऐसी चीजें पहले से कर सकते हैं। यदि, उदाहरण के लिए, आपकी शैली पत्रक DOM ट्री के माध्यम से बहुत बाद में भरी हुई है, तो आप ब्राउज़र को <लिंक rel = "dns-prefetch"> का उपयोग करके बता सकते हैं कि "मैं अभी तक वहां नहीं गया हूं, लेकिन आप संसाधनों को गर्म कर देंगे, मुझे बाद में उनकी आवश्यकता होगी। "।

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

ठीक है, ब्राउज़र जानता है कि कहां जाना है। उसे समझने की जरूरत है कि कैसे जाना है।

कैसे जाएं

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

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

यहाँ मैंने अपने शब्दों में कहा है कि https कैसे काम करता है। सबसे पहले आपको अपने सर्वर से एक SSL प्रमाणपत्र मिलता है। फिर आपको एक प्रमाणन प्राधिकरण में प्रमाण पत्र की जांच करनी चाहिए। ये विशेष सर्वर हैं जो जानते हैं कि क्या मान्य है और क्या नहीं है, और ब्राउज़र को संकेत दे सकता है: "हाँ, यहाँ सब कुछ ठीक है, इस प्रमाणपत्र का उपयोग करें"।

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

हम फिर से उपयोगकर्ता को सर्वर के करीब स्थानांतरित कर सकते हैं। हमारे पास पहले से ही एक डीएनएस है, अब हम इसे प्रमाणीकरण प्राधिकरण के करीब रख सकते हैं। और इन सर्वरों के बीच रखना सही रहेगा।

आप https से बाहर निकल सकते हैं, हमें इसकी आवश्यकता क्यों है? हम एक प्रमाण पत्र, एन्क्रिप्ट, डिक्रिप्ट होने में समय बिताते हैं। ज़रुरी नहीं। रिपोर्ट में यह सबसे हानिकारक सलाह है, ऐसा न करें। https उपयोगकर्ता डेटा सुरक्षा है, और बिना https http / 2 काम नहीं करेगा, और http / 2 तेजी लाने का एक और तरीका है।

इसमें OCSP स्टेपलिंग तकनीक भी है। आप एक प्रमाणीकरण प्राधिकारी के बिना एक प्रमाण पत्र सत्यापित कर सकते हैं। यह शायद DevOps के करीब है। आपको अपने सर्वर को एक निश्चित तरीके से कॉन्फ़िगर करने की आवश्यकता है ताकि यह प्रमाणन प्राधिकरण की प्रतिक्रिया को कैश कर सके और उपयोगकर्ता को जारी कर सके: "मेरा विश्वास करो, मेरा प्रमाण पत्र वास्तव में वास्तविक है।" इस प्रकार, हम कम से कम उस चरण को बचा सकते हैं जिस पर हम प्रमाणन प्राधिकरण में जाते हैं।

लेकिन एक अति सूक्ष्म अंतर है - क्रोम में यह काम नहीं करता है, और लंबे समय तक। लेकिन अन्य ब्राउज़रों के उपयोगकर्ता के लिए, आप इस प्रक्रिया को तेज कर सकते हैं।

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

चलो गहरी खुदाई करें। अनुरोध में और क्या चल रहा है? वास्तव में, http http पर केवल एक आवरण है। सिर्फ एक शांत आवरण नहीं। और अगर यह और भी गहरा है, तो http टीसीपी / आईपी परिवार से ऐसा अनुरोध है।

नेटवर्क पर पैकेट और बाइट कैसे भेजे जाते हैं ताकि सभी ब्राउज़र, क्लाइंट और सर्वर एक दूसरे के साथ संवाद करें? पहली चीज़ जो एक क्लाइंट / सर्वर टीसीपी / आईपी कनेक्शन पर करता है वह एक हैंडशेक है।

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

क्या उठाऊं?

ग्राहक को सर्वर से क्या चुनना चाहिए, यह पता लगाने दें। मुख्य बात यह नहीं है कि क्लाइंट सर्वर से कुछ लेता है, लेकिन सर्वर क्लाइंट को डेटा देता है। तब आप सोच सकते हैं: उपयोगकर्ता-एजेंट। मैं क्लाइंट से उपयोगकर्ता-एजेंट प्राप्त कर सकता हूं, यह पता कर सकता हूं कि उपयोगकर्ता ने किस ब्राउज़र में लॉग इन किया है। यह ब्राउज़र मुझे धोखा नहीं देता है, तो लगभग पता लगाएं।

.example {
    display: -ms-grid;
    display: grid;
    -webkit-transition: all .5s;
    -o-transition: all .5s;
    transition: all .5s;
    -webkit-user-select: none;
       -moz-user-select: none;
        -ms-user-select: none;
            user-select: none;
    background: -webkit-gradient(linear, left top, left bottom, from(white), to(black));
    background: -o-linear-gradient(top, white, black);
    background: linear-gradient(to bottom, white, black);
}

मान लीजिए कि उसने फ़ायरफ़ॉक्स से लॉग इन किया है। मैं, हमेशा की तरह, एक असेंबली है जिसमें ऑटोप्रिफ़र कॉर्न जुड़ा हुआ है, इसने मेरे लिए कोड का एक गुच्छा तैयार किया है। हां, यह एक शांत दृष्टिकोण है कि हर जगह हर चीज काम करेगी। लेकिन मुझे पहले से ही पता है कि उपयोगकर्ता ने फ़ायरफ़ॉक्स से लॉग इन किया है।

सभी अतिरिक्त बंद क्यों नहीं? सहमत हूं, बहुत कम लाइनें हैं, हम कम बाइट भेजते हैं, यह अच्छा है।

हमारे पास SERP, ग्रैनी का लाइट वर्जन है। विटाली खारिसोव ने उसके बारे में बात कीvithar, वेब मानक दिनों पर कक्षा रिपोर्ट । यह बिल्कुल इस दृष्टिकोण का उपयोग करता है। हम कई बंडल बना सकते हैं और उन्हें अलग-अलग तरीकों से अलग-अलग क्लाइंट को दे सकते हैं। उनका वज़न बहुत कम है, क्योंकि फ़ायरफ़ॉक्स को अपना, वेबिट को अपना, और यह काम करता है, सत्यापित है।

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

जेम्स अकुव ने इसके बारे में एक अच्छी रिपोर्ट पढ़ी“सर्वर-साइड रेंडरिंग। यह स्वयं करो"। मुद्दा क्या है? आप पहले से ही जानते हैं कि आपके पास HTML और कुछ प्रकार के CSS हैं जो सभी उपयोगकर्ताओं के लिए समान हैं। किसी भी डेटा के लिए जाने से पहले, आप इस स्थैतिक डेटा से आउटपुट उत्पन्न कर सकते हैं, तुरंत सर्वर से स्ट्रीम में सबसे उपयोगी भेज सकते हैं। और उसके बाद - डेटा के लिए जाएं, इसे जल्दी से प्राप्त करें, इसे टेम्प्लेट में परिवर्तित करें और इसे क्लाइंट को दें। और उपयोगकर्ता को पहले से ही कुछ उपयोगी दिखाई देगा।

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

यही है, हमारे पास एक खोज पट्टी है जिसे उपयोगकर्ता सब कुछ लोड करने से पहले उपयोग करना शुरू कर सकता है। यह धीमे कनेक्शन पर उपयोगी है। हम इसे करते हैं, यह काम करता है।

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

सर्वर पुश एक शांत तकनीक है जो कहती है: "ब्राउज़र, मैंने अभी तक आपको यह ज्ञान नहीं दिया है कि आपको किसी प्रकार के सीएसएस की आवश्यकता है। लेकिन मुझे पता है कि वास्तव में क्या जरूरत है। इसलिए इसे पकड़ें, इसे पहले से लोड करें। ”

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

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

इसलिए, एक निश्चित डेटा खंड पहले भेजा जाता है। डिफ़ॉल्ट रूप से, (यह आप सेटिंग में बदल सकते हैं) यह 1460 बाइट्स है। सर्वर एक सेगमेंट पर जानकारी नहीं भेजता है। वह खिड़कियां भेजता है।

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

एक महत्वपूर्ण अति सूक्ष्म अंतर। जब आप एक पूरा खंड भरते हैं, तो यह एक खंड होता है। लेकिन अगर आप केवल एक अतिरिक्त बाइट भेजते हैं, तो सर्वर अभी भी एक अतिरिक्त खंड भेजेगा।

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

अजीब बात है: मैं एक टाइपसेटर हूं, और मैं ऐसे जटिल सर्वर चीजों को बताता हूं। चलिए असली CSS के और भी करीब आते हैं।

जहाज कम

तो, हम उपयोगकर्ता को कम भेजते हैं, कम खंड, तेजी से आता है, उपयोगकर्ता खुश है।

Minification। वह सभी अपनी परियोजनाओं पर स्थापित थी। वहाँ शांत उपकरणों, वेबपैक प्लगइन्स, गुल सेटिंग्स की एक गुच्छा है - सामान्य तौर पर, आप इसे अपने लिए समझेंगे। आप इसे हाथ से अनुकूलित कर सकते हैं, लेकिन यह केवल तभी लगता है जब आप सुनिश्चित हों कि आप अपने CSS कूलर को किसी भी CSSO से कम कर सकते हैं।

संपीड़न को सक्षम करने के लिए याद रखें। यदि 2020 में कम से कम गज़िप चालू नहीं होता है, तो आप निश्चित रूप से कुछ गलत कर रहे हैं, क्योंकि यह एक प्राचीन संपीड़न तकनीक है। सामान्य तौर पर, 2020 में, यह ब्रेटली का उपयोग करने का समय है। क्रोमियम ब्राउज़र में आउटपुट को थोड़ा कम करने का यह एक अच्छा तरीका है। या, यदि आप ब्रतली का समर्थन नहीं करना चाहते हैं, तो कम से कम आप ज़ोफ़ली की कोशिश कर सकते हैं।

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

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

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

कोड का अनुकूलन कैसे करें? मैं minification की बात नहीं कर रहा हूँ। प्रोजेक्ट में जो आप उपयोग नहीं कर रहे हैं, उसे दूर करें। सबसे अधिक संभावना है कि आपके पास कोड है जो कभी भी क्लाइंट पर निष्पादित नहीं करेगा। किस लिए?

ताकि आप इसे स्वचालित कर सकें, विशेष टैब ब्राउज़र में बनाए जाते हैं, उदाहरण के लिए, क्रोम DevTools में, यह कवरेज है, जो आपको बताता है: "मैंने इस CSS या इस JS का उपयोग नहीं किया, आप इसे काट सकते हैं।"

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

Booking.com से एंटोन खोलकिन की एक अच्छी रिपोर्ट है , जहाँ उन्होंने विरासत कोड के ढेर को हटाने की कोशिश की है। लेकिन उनके पास एक ख़ासियत थी: एक विरासत कोड जो बाहरी परियोजनाओं से आया था। इसे हटाना जरूरी था। देखें कि वे कौन से दिलचस्प समाधान हैं।

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

मेरे सहकर्मी आदित्य खोम्यकोवविजेता-homyakovएक पृष्ठ पर डुप्लिकेट और शैली खोजने जैसे मेरी अपनी स्क्रिप्ट बनाई । बस ले, कॉपी और पेस्ट। वह आपको सांत्वना में लिखेंगे: "यह चयनकर्ता, ऐसा लगता है, आपको ज़रूरत नहीं है।" इस बिंदु तक कि बस DevTools में दर्ज करें। यह विस्मयकारी है।

एक विशेषता जो मुझे फ़ायरफ़ॉक्स डेवलपर्स के उपकरणों के बारे में वास्तव में पसंद है: शैलियों को देखने का एक अवसर जो उपयोग किया जा रहा है, लेकिन वास्तव में ब्राउज़र उन्हें लागू नहीं करता है।

उदाहरण के लिए, आप डिस्प्ले: इनलाइन सेट कर सकते हैं, और ऐसा लगता है कि यह डिस्प्ले: इनलाइन आकार सेट करने के लिए समझ में नहीं आता है। या ऊर्ध्वाधर-संरेखित करें, यह केवल इनलाइन या टेबल-सेल के लिए काम करता है। अब तक, मैंने केवल फ़ायरफ़ॉक्स में देखा है कि यह हाइलाइट कर सकता है: "आपको इस लाइन की आवश्यकता नहीं है।"

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

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

असेम्बली का सही उपयोग करने का प्रयास करें। लगभग सभी आधुनिक सीएसएस फ्रेमवर्क आपको असेंबली के लिए स्रोत कोड का उपयोग करने की अनुमति देते हैं और केवल वही चुनें जो आपको चाहिए। यह सीएसएस बंडल के आकार को काफी कम कर सकता है।

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

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

यहां तक कि Google के लोग कहते हैं : BEM का उपयोग करें, यह वास्तव में अनुकूलन के लिए आपकी मदद कर सकता है।

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

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

कम शैलियों - महान! लेकिन यह फिर से एक पागल विचार है। CSS को HTML के बारे में जानने की जरूरत नहीं है, क्योंकि यह एक शैली है। यह काफी स्वतंत्र है, आपको इसे किसी अन्य परियोजना से जोड़ना होगा, इसे वहां काम करना चाहिए। और हाँ, इसे बनाए रखना कठिन है। टैग बदलें - सब कुछ टूट जाता है। वादा के अनुसार पागल विचार।

चरों का उपयोग करें। CSS में currentColor जैसे बहुत पुराने चर हैं।

अक्सर एक पैटर्न होता है: आप चाहते हैं, उदाहरण के लिए, एक बटन बनाने के लिए जिसका पाठ और सीमा रंग में समान हैं। और हॉवर द्वारा हम उन दोनों को बदलते हैं। किस लिए?

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

यह देखने के लिए कभी-कभी बहुत दुख होता है कि बेस 64 का उपयोग कैसे किया जाता है। CSS में, इसे पहले सक्रिय रूप से अनुशंसित किया गया था: छोटे माउस को इंजेक्ट करने के लिए base64 का उपयोग करें। अगर यह TCP के एक सेगमेंट में फिट बैठता है, तो यह आपके लिए अच्छा है।

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

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

और कृपया एसवीजी के लिए बेस 64 का उपयोग न करें। क्योंकि SVG URL-encoder का उपयोग करने के लिए बहुत अच्छा है। जूलिया बुखवलोवा के पास एक शांत उपकरण है: आओ, अपना एसवीजी पेस्ट करें और यह सीएसएस को तैयार-से-पेस्ट फॉर्म में दे देगा। आप देख सकते हैं कि कोई बेस 64 नहीं है, लेकिन कुछ चीजें बच गई हैं कि सीएसएस को सही ढंग से नहीं माना जा सकता है। यह बहुत अधिक कुशल है।

औसतन, बेस 64 आपको जो कंप्रेस करता है उसके आकार को 30% का प्लस देता है। किस लिए?

आधुनिक तकनीक का प्रयोग करें। ग्रिड के बारे में बात करते समय हमें इंटरनेट एक्सप्लोरर - सामान्य तर्कों का समर्थन करने की आवश्यकता हो सकती है।

लेकिन इसके बारे में सोचें: यदि आपके पास IE समर्थन नहीं है, और आप अभी भी फ्लोट या टेबल पर टाइपसेट कर रहे हैं, तो आप 20-पिक्सेल अंतर के साथ तीन-स्तंभ लेआउट बनाने के लिए ग्रिड का उपयोग कर सकते हैं - यह कॉलम के बीच की दूरी है। तीन लाइनें। खैर, पाँच, खुद घोषणा पर विचार कर रहे हैं।

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

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

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

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

यहाँ यह कैसे करना है पर एक लेख है । निर्माण करते समय आप वेबपैक या किसी अन्य प्लगइन को कॉन्फ़िगर कर सकते हैं। लेकिन यह हमसे दूर नहीं हुआ। हमने कोशिश की।

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

सामान्य तौर पर, इसने हमें लगभग कोई लाभ नहीं दिया। लेकिन, उदाहरण के लिए, आपके पास BEM और असमान वर्गों का समूह नहीं है, तो आप कोशिश कर सकते हैं।

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

डाउनलोड करो!

अब तक, मैंने केवल एक फ़ाइल डाउनलोड करने के तरीके के बारे में बात की है। हमने इसे डाउनलोड किया। उपयोगकर्ता ने इस समय क्या देखा है?

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

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

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

इसलिए आयात एक बुरी चीज है। यदि शैलियों HTML में सुसंगत हैं, तो ब्राउज़र देखेगा कि हम किसी अन्य फ़ाइल के लिए आगे बढ़ेंगे।

और यदि आप इसे सीधे आयात में सम्मिलित करते हैं, तो उसे पहले अपना style.css डाउनलोड करना चाहिए, फिर उसमें आयात देखें। वह इस सीएसएस को पार्स करना शुरू कर देता है ... हाँ, हम एक नए तरीके से सब कुछ ब्लॉक करते हैं और फ़ाइल के लिए जाते हैं! तो आप साइट पर deoptimization के साथ एक शांत झरना बना सकते हैं।

आयात भूल जाओ, या कॉन्फ़िगर करें ताकि निर्माण के बाद कोई आयात न हो। देव वातावरण के लिए, ठीक है, लेकिन उपयोगकर्ता के लिए नहीं।

अगला हम कैस्केड का उपयोग करके पेड़ों के निर्माण के चरणों से गुजरते हैं।

यह सब भी लंबे समय तक वर्णित है। CSS Object Model बनाया गया है - ब्राउज़र को टैग करने के लिए कैसे शैलियों का एक विशेष पेड़, कक्षाओं में शैली। वह इसे सभी डोम से जोड़ता है और इन कनेक्शनों को बहुत जल्दी बनाता है। जब आप कुछ बदलते हैं, तो यह उसके लिए पेड़ के अंदर बदलने के लिए पर्याप्त है।

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

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

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

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

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

यह भी बहुत ही अजीब सलाह है, लेकिन अगर आप सीएसएस ओम को तेजी से बनाना चाहते हैं, तो आप तुरंत सभी गुणों को एक बार में सेट कर सकते हैं। वह काम कर सकता है। लेकिन बंडल का आकार बहुत बढ़ जाएगा। आपको मापने की आवश्यकता है। मुझे संदेह है कि यह एक लाभ देगा, लेकिन अचानक!

जब CSS OM बनाया जाता है, तो JS को इस बिंदु पर भी लॉक कर दिया जाता है। यदि OM CSS का निर्माण करने में दो सेकंड लगते हैं, तो JS विफल हो जाता है। हालाँकि मैं यह नहीं सोच सकता कि आप सीएसएस में इतना लिखने में कैसे कामयाब रहे कि पेड़ दो सेकंड के लिए बनाया गया है।

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

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

यह बस किया जाता है। ऐसे सभी उपकरण हैं जो वेबपैक और रिएक्ट के लिए प्लगइन्स सहित यह सब स्वचालित करते हैं। बस सही ढंग से खोज और कॉन्फ़िगर करें।

- github.com/addyosmani/critical
- github.com/pocketjoso/penthouse
- github.com/anthonygore/html-critical-webpack-plugin
- github.com/GoogleChromeLabs/critters

एक अच्छा दृष्टिकोणफिलामेंट ग्रुप से - CSS को ब्लॉक किए बिना एसिंक्रोनस रूप से लोड कैसे करें। सब कुछ काफी सरल है।

जब आप <लिंक rel = preload> डालते हैं, तो ब्राउज़र को बताएं: "मुझे इस शैली की आवश्यकता होगी, लेकिन अब हम कुछ भी ब्लॉक नहीं कर रहे हैं। आप इसे अभी डाउनलोड करते हैं, इसे कैश करते हैं, और जब मैं इसे चालू करता हूं, तो सीएसएस ओम का निर्माण शुरू करें। और आपको बस ऑनलोड और प्रक्रिया करने की आवश्यकता है कि "ठीक है, जब से मैंने इसे डाउनलोड किया है, इसे rel = स्टाइलशीट, पार्सिंग सक्षम करें।"

एक काफी सरल दृष्टिकोण है, लेकिन इसे बुद्धिमानी से भी उपयोग करें। यदि आपके पास बहुत अधिक प्रीलोड है, तो आप बदतर कर सकते हैं।

आप मीडिया के भावों के साथ भी खेल सकते हैं। उन्हें सम्मिलित करें और ब्राउज़र को बताएं: "इस शैली की अब आवश्यकता नहीं है, लेकिन जब यह मीडिया अभिव्यक्ति काम करती है, तो इसकी आवश्यकता होगी।" ब्राउज़र भी नियमित रूप से डाउनलोड करेगा, लेकिन कम प्राथमिकता के साथ और बिना ब्लॉक किए।

एक और पागल दृष्टिकोण, लेकिन इतना पागल नहीं - जब आपके पास http / 2 धक्का हो। आप ब्लॉक के ठीक सामने CSS एम्बेड कर सकते हैं। CSS के बिना, आपका ब्लॉक बहुत अच्छा नहीं लगेगा। तो इस ब्लॉक से पहले अगले ब्लॉक के लिए सीएसएस की आवश्यकता क्यों नहीं है? यह तार्किक है, और http / 2 पुश आपको इसे अनुकूलित करने की अनुमति देगा।

एक सरल दृष्टिकोण। यदि आप इसका विस्तार करते हैं, तो आलसी लोडिंग का उपयोग करें। उपयोगकर्ता को कुछ ऐसा क्यों डाउनलोड करना चाहिए जिसका वह उपयोग नहीं करेगा? आप प्रतिक्रिया घटकों को कॉन्फ़िगर कर सकते हैं ताकि अगर यह पृष्ठ दृश्यता क्षेत्र में कभी हिट न हो, तो इसे अपने लिए शैलियों को क्यों डाउनलोड करना चाहिए?

इंटरसेक्शन ऑब्जर्वर एपीआई का अन्वेषण करें और आप नाटकीय रूप से अपने पृष्ठ को गति देने में सक्षम हो सकते हैं।

अंतिम चरण समग्र परतों को खींचना और उन्हें लागू करना है, उन्हें गोंद करना और इसी तरह।

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

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

कम परत बनाएं - वर्तमान अनुकूलन के लिए जितनी आवश्यक हो उतनी ही।

महान, हम सभी को खुशी हुई।

और अगर मैं वापस आऊं?

और क्या होगा अगर मैं पेज पर वापस आऊं? यह केवल पहली बार है जब मैं गया था।

पृष्ठ पर वापस लौटने पर, मुझे लगता है कि सब कुछ तुरंत डाउनलोड करने में सक्षम हो गया। मैंने पहले ही सभी संसाधनों को डाउनलोड कर लिया है, तो दूसरी बार उनका उपयोग क्यों नहीं किया?

यदि सर्वर कैश-कंट्रोल हेडर नहीं देता है, तो ब्राउज़र इसे पुनः उपयोग करने के लिए आपकी फ़ाइल को कैश करने का प्रयास करेगा। आप अपने सर्वर को डिफ़ॉल्ट रूप से कॉन्फ़िगर कर सकते हैं, कह सकते हैं: "इस फ़ाइल को पूरे वर्ष के लिए कैश करें।" बदलेगा नहीं। लेकिन अगर ऐसा है, तो आपको वैश्विक कैश अमान्य समस्या से निपटने की आवश्यकता है। लेकिन यह एक अलग रिपोर्ट का विषय है।

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

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

आप स्थानीय संग्रहण का उपयोग करके देख सकते हैं। लेकिन वह बेतहाशा धीमा है। किसी फ़ाइल को डाउनलोड करना स्थानीय संग्रहण API पर जाने से कभी-कभी तेज़ होता है।

आप अंतर्निहित ब्राउज़र डेटाबेस आज़मा सकते हैं। लेकिन इसे मापें। शायद एक कमजोर प्रोसेसर के कारण जेएस की यात्रा में आपको अधिक समय लगेगा।

आप ब्राउज़र को पहले से भी बता सकते हैं कि आप कुछ डाउनलोड करेंगे।

<लिंक rel> - जानें कि यह विशेषता कैसे काम करती है। प्रीकनेक्ट, प्रीफैच, प्रियरेंडर है - मैं इसके बारे में अलग से बात करना चाहता हूं। वह कहता है: “अब मैं इस पृष्ठ पर हूँ, और फिर अगले पर जाऊँगा। पृष्ठभूमि टैब में इस पृष्ठ के लिए सब कुछ डाउनलोड करें और ड्रा करें। ” सुन्दर सामान। कहीं काम नहीं करता।

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

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

आगे क्या होगा? बहुत सारे लिंक थे। मैं आपको वान्या अकुलोव की हर चीज के अनुकूलन का एक अद्भुत संग्रह देखने की सलाह भी देता हूंiamakulov। HTML, और JS और असेंबली दोनों को ऑप्टिमाइज़ करने का तरीका देखें।

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

शैलियों की महंगी कीमत। यैंडेक्स रिपोर्ट