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

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

डिफ़ॉल्ट रूप से, इंटरनेट धीमा है

आइए देखें कि यदि आप प्रीलोड का उपयोग नहीं करते हैं तो क्या होता है। ब्राउज़र केवल संसाधनों को लोड करना शुरू कर सकता है क्योंकि यह पता चला है कि उन्हें उनकी आवश्यकता है। यह उन संसाधनों के लिए होने की संभावना है जो दस्तावेज़ के प्रारंभिक पार्सिंग के दौरान HTML में हैं (उदाहरण के लिए, <script> , <link rel=stylesheet> और <img> )।

रेंडर ट्री बनाने के बाद पाए जाने वाले संसाधनों को धीमी गति से डाउनलोड किया जाता है (यह वह जगह है जहां पेज लोड होने के कारण धीमा हो जाता है, क्योंकि इसे समझने के लिए, आपको पहले स्टाइलशीट लोड करना होगा, पार्स करना होगा, CSS ऑब्जेक्ट मॉडल बनाना होगा, और फिर ट्री रेंडर करना होगा)।

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

लिंक rel = प्रीलोड बहुत मदद करता है

पिछले कुछ वर्षों में, लिंक rel = preload के कारण स्थिति में सुधार हुआ है। उदाहरण के लिए:

 Link: </resources/fonts/myfont.woff>; rel=preload; as=font; crossorigin Link: </resources/css/something.css>; rel=preload; as=style Link: </resources/js/main.js>; rel=preload; as=script 

इन निर्देशों के लिए धन्यवाद, ब्राउज़र हेडर प्राप्त करने के तुरंत बाद और HTML बॉडी का विश्लेषण शुरू करने से पहले संसाधनों को लोड करना शुरू कर सकता है:



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

हालांकि, हम और अधिक कर सकते हैं। आखिरकार, ब्राउज़र उस क्षण के बीच कुछ नहीं करता जब वह अनुरोध भेजना समाप्त करता है, और जब उसे प्रतिक्रिया के पहले बाइट्स मिलते हैं (प्रारंभिक अनुरोध पर बड़ा हरा टुकड़ा अधिक होता है)।

हम "शुरुआती सुझावों" की मदद से "सर्वर सोच" के समय का उपयोग करते हैं

दूसरी ओर, सर्वर वास्तव में व्यस्त है। यह एक प्रतिक्रिया उत्पन्न करता है और यह निर्धारित करता है कि यह सफल है या नहीं। डेटाबेस तक पहुंचने के बाद, एपीआई कॉल, प्रमाणीकरण, आदि। सर्वर तय कर सकता है कि 404 त्रुटि सही उत्तर है।

कभी-कभी सर्वर ध्यान का समय नेटवर्क विलंबता से कम होता है। कभी-कभी बहुत अधिक। लेकिन यह समझना महत्वपूर्ण है कि वे ओवरलैप नहीं करते हैं। जबकि सर्वर सोच रहा है, हम क्लाइंट को डेटा नहीं भेज रहे हैं।

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

 HTTP/1.1 103 Early Hints Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" HTTP/1.1 404 Not Found Date: Fri, 26 May 2017 10:02:11 GMT Content-Length: 1234 Content-Type: text/html; charset=utf-8 Link: <some-font-face.woff2>; rel="preload"; as="font"; crossorigin Link: <main-styles.css>; rel="preload"; as="style" 

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



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

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

लेकिन HTTP / 2 सर्वर पुश के बारे में क्या?

HTTP / 2 के साथ, सर्वर पुश नाम की एक नई तकनीक है जो लिंक के समान समस्या को हल करने के लिए लगती है। प्रारंभिक संकेत उत्तर में लिंक rel = preload। हालांकि यह वास्तव में काम करता है (और आप फास्ट सर्वर में एज सर्वर से कस्टम पुश जल्दी से उत्पन्न कर सकते हैं), कई बिंदुओं पर महत्वपूर्ण अंतर हैं:

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

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

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

अतिरिक्त बोनस: तेज़ अनुरोध पतन

यद्यपि प्रारंभिक संकेत को मुख्य रूप से ब्राउज़र में उपयोग करने के लिए माना जाता है, सीडीएन के लिए एक दिलचस्प संभावित लाभ है। जब तेजी से एक ही संसाधन के लिए कई अनुरोध प्राप्त होते हैं, तो हम आमतौर पर उनमें से केवल एक स्रोत को भेजते हैं, और बाकी को प्रतीक्षा कतार में रख देते हैं। इस प्रक्रिया को अनुरोध के पतन के रूप में जाना जाता है। यदि स्रोत से प्रतिक्रिया में Cache-Control: private , तो आपको कतार से सभी अनुरोधों को हटा देना चाहिए और उन्हें स्रोत पर अलग से भेजना चाहिए, क्योंकि हम कई अनुरोधों को पूरा करने के लिए एक उत्तर का उपयोग नहीं कर सकते हैं।

जब तक पहले अनुरोध पर प्रतिक्रिया नहीं मिल जाती, तब तक हम निर्णय नहीं कर सकते, लेकिन प्रारंभिक संकेत समर्थन के मामले में, यदि सर्वर ने Cache-Control शीर्षक के साथ एक प्रारंभिक संकेत प्रतिक्रिया लौटा दी है, तो हम बहुत पहले जान लेंगे कि कतार एक अनुरोध में ढह नहीं सकती है, लेकिन इसके बजाय तुरंत कतार से स्रोत तक सभी अनुरोधों को आगे बढ़ाएं।

प्राथमिकता युक्तियों के साथ कम महत्वपूर्ण सामग्री का आदेश दें

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

 <script src="main.js" async importance="high"></script> <script src="non-critical-1.js" async importance="low"></script> 

महत्व की इस नई विशेषता के साथ, डेवलपर्स नेटवर्क के लिए प्रतिस्पर्धा की स्थिति में संसाधनों के लोड क्रम को नियंत्रित कर सकते हैं। प्रोसेसर और नेटवर्क के मुक्त होने तक या डिवाइस के प्रकार के आधार पर शायद कम प्राथमिकता वाले संसाधनों में देरी हो सकती है।

क्या इसका उपयोग किया जा सकता है?

अभी तक न तो प्रारंभिक सुराग और न ही प्राथमिकता के सुराग मानक बन गए हैं। हाल ही में, H2O, HTTP / 2 सर्वर का उपयोग और फास्ट द्वारा समर्थित, ने शुरुआती संकेत (PR 1727 और 1767 देखें ) का उपयोग करना शुरू किया, और क्रोम में प्राथमिकता संकेत को लागू करने का इरादा है , साथ ही साथ 1xx प्रतिक्रियाओं को सक्रिय रूप से ट्रैक करना है। इसी समय, अभी शुरुआती संकेत भेजने में कोई नुकसान नहीं है - और यदि आप प्रवृत्ति से आगे निकलना चाहते हैं, तो जाएं!