👩🏽‍🏭 🤙🏾 👏🏼 BFCache, या वहाँ और वापस। यैंडेक्स रिपोर्ट 🧝🏻 👸🏼 👺

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

- नमस्कार, मेरा नाम विक्टर है। मैं एक काफी बड़ी टीम के हिस्से के रूप में काम करता हूं जो खोज पृष्ठ से संबंधित है।

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

मैं जाने-माने कंपनियों से कई उदाहरण दूंगा। Google ने एक प्रयोग किया। उन्होंने जानबूझकर खोज पृष्ठ पर एक देरी एम्बेडेड और मापा कि यह प्रदर्शन को कैसे प्रभावित करता है। यह पता चला है कि प्रति उपयोगकर्ता औसतन आधे प्रतिशत कम खोज थे। आधा प्रतिशत क्या है? गणना करें: लाखों Google उपयोगकर्ताओं में से आधा प्रतिशत एक बड़ी संख्या है।

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

AliExpress से उदाहरण। उन्होंने अपनी साइट को 36% तक तेज कर दिया और उपयोगकर्ताओं से काफी अधिक ऑर्डर प्राप्त किए। आदेश प्रत्यक्ष धन हैं। सामान्य तौर पर, यह पहले से ही सभी के लिए स्पष्ट है कि गति काफी महत्वपूर्ण है, यह एक निश्चित संख्या में मीट्रिक के माध्यम से, अर्जित धन को प्रभावित करता है।

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

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

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

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

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

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

समाधान स्वयं ही सुझाता है। हम क्या कर रहे हैं? हम, जब उपयोगकर्ता हमारे पृष्ठ को छोड़ता है, तो उसे तुरंत साफ न करें। हम बस इसकी स्थिति को बचाते हैं और इसे नेत्रहीन उपयोगकर्ता से छिपाते हैं ताकि हुड के नीचे यह ब्राउज़र के निपटान में बना रहे।

यदि उपयोगकर्ता वापस लौटने का फैसला करता है तो हम क्या करेंगे? बस उसे वही बचा हुआ पेज दिखाओ। इसे लगभग तुरंत दिखाया जा सकता है।

इस तकनीक को "आगे और पीछे" शब्दों से बैक / फॉरवर्ड कैश कहा जाता है। Bfcache के लिए लघु।

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

GIF दिखाएं

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

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

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

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

एपीआई और ब्राउज़र का समर्थन

विषय के करीब। मान लीजिए कि मैंने आपको पहले ही मना लिया है, आप हैं: "हाँ, एक अच्छा विषय, हमें इसके साथ काम करना चाहिए।" हमारे पास हमारे पास क्या एपीआई हैं, अगर हम खाते में bfcache लेने के लिए सहमत हैं, तो हम क्या काम कर सकते हैं और यह कैसे ब्राउज़रों द्वारा समर्थित है?

जहां bfcache पहले से मौजूद है, मैं इसे कहां देख सकता हूं?

- यह लंबे समय से ब्राउज़र फ़ायरफ़ॉक्स, सफारी (और मैकओएस और आईओएस) में लागू किया गया है, साथ ही साथ इंटरनेट एक्सप्लोरर 11 (!) में भी। आमतौर पर हम Microsoft डेवलपर्स को डांटते हैं, लेकिन यहां उन्होंने सिर्फ कोशिश की।

- यह ब्राउज़र यूसी ब्राउज़र 11/12, एंड्रॉइड के लिए संस्करण में लागू किया गया है।

- अचानक वह क्रोम में नहीं है। और क्रोमियम में यह सुविधा विकसित हो रही है।

इसलिए, जब वे क्रोमियम में ऐसा करते हैं, तो इनमें से लगभग सभी ब्राउज़र (और यह पूरी सूची नहीं है) जल्द ही या बाद में यह कार्यक्षमता प्राप्त करेंगे - बिना एसएमएस और पंजीकरण के।

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

^{_{स्लाइड से लिंक करें}}

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

हम यहां "back_forward" नेविगेशन प्रकार में रुचि रखते हैं, यह स्पष्ट रूप से इंगित करता है कि उपयोगकर्ता कहानी के माध्यम से आगे और पीछे चला गया। यह ठीक उसी प्रकार का नेविगेशन है जिससे हमारा bfcache काम कर सकता है।

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

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

^{_{स्लाइड से लिंक करें}}

ईवेंट समर्थन लगभग सभी ब्राउज़रों में उपलब्ध है, यहां तक कि वे जो अभी तक bfcache का समर्थन नहीं करते हैं।

^{_{स्लाइड से लिंक}}

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

जब मैं इस घटना के सामने आया, bfcache, मुझे इसका अध्ययन करना था, सभी पक्षों पर टैप करें, देखें कि यह कैसे काम करता है। मैं तुरंत अपने पृष्ठ पर देखना चाहता था जब मैं खोलता हूं कि मेरे हैंडलर में निरंतर क्षेत्र का मूल्य क्या है।

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

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

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

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

मैंने इस डीबग कोड को बाहरी स्क्रिप्ट में डाल दिया है।

लेकिन नहीं, सफ़ारी में पेजहाइड हैंडलर गिर गए! किसी कारण से, वे बाहरी स्क्रिप्ट से काम नहीं करते हैं।

ठीक है, मेरे पास पहले से ही एक कार्यशील संस्करण है। मुझे इसे ऐसे ही छोड़ना पड़ा।

मैं संक्षेप में बताऊंगा कि मैंने केवल एक दिन में किस चीज को चलाने में सफलता पाई। सबसे पहले, DevTools कैशिंग को अक्षम कर सकते हैं। आपको शायद याद होगा कि क्रोम में नेटवर्क टैब पर DevTools में एक चेकबॉक्स "कैश अक्षम करें" है। यह नेटवर्क कैश को अक्षम करता है, यह bfcache को प्रभावित नहीं कर सकता है, या यह हो सकता है। सादृश्य स्पष्ट है: हमने DevTools खोले, जिसका अर्थ है कि हम विकसित हो रहे हैं और हमें कैशिंग की आवश्यकता नहीं है। शायद यह हमें परेशान करता है।

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

एक बार फिर मैं आपको याद दिलाता हूं कि सफारी में एक बाहरी स्क्रिप्ट से हैंडलर को नहीं बुलाया जा सकता है, यह बहुत अजीब है।

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

कार्यान्वयन सुविधाएँ

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

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

और फिर मैंने एक तालिका में जो कुछ सीखा, उसे संयोजित करना शुरू किया। मुझे निम्नलिखित जैसा कुछ मिला:

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

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

एपीआई जो एक चेकमार्क और हरे रंग के साथ हस्तक्षेप नहीं करते हैं, जो निश्चित रूप से पृष्ठ को bfcache में जाने से रोकेंगे, लाल रंग में चिह्नित हैं। सफेद क्षेत्र ऐसे स्थान हैं जिनका कहीं भी वर्णन नहीं किया गया है।

फ़ायरफ़ॉक्स

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

^{_{स्लाइड से लिंक}}

फ़ायरफ़ॉक्स के स्रोतों से मैंने जो सबसे महत्वपूर्ण बात सीखी, वह यह है कि जब bfcache के साथ काम करते हैं तो यह डिस्क पर टेक्स्ट लॉग को लिख सकता है कि यह पृष्ठ को कैश में क्यों नहीं डाल सकता है।

^{_{स्लाइड से लिंक करें}}

और मैं यह भी पता लगाने में कामयाब रहा कि यह कैसे करना है। दो गुप्त पर्यावरण चर हैं: एक में हम संकेत करते हैं कि क्या लॉग करना है, दूसरे में - लॉग लिखने के लिए किस फ़ाइल में। उसके बाद, हम बाइनरी लॉन्च करते हैं, और वॉयला! हम लगभग यह देखेंगे कि पिछली स्लाइड पर, "ऐसे html को ऐसे कारण के लिए कैश नहीं किया जा सकता है, जैसे कि एक अलग कारण के लिए"। हम इसे तुरंत, बहुत सुविधाजनक तरीके से पढ़ सकते हैं।

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

^{_{स्लाइड से लिंक}}

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

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

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

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

^{_{स्लाइड से लिंक}}

मान लीजिए कि आपका पृष्ठ HTTPS के माध्यम से खुलता है, लेकिन आप अभी भी HTTP, विशेषकर स्क्रिप्ट के माध्यम से कुछ संसाधनों को लोड करते हैं। यानी आपके पास एक गैर-सुरक्षा स्क्रिप्ट है, इसे किसी के द्वारा भी संशोधित किया जा सकता है।

^{_{स्लाइड से लिंक}}

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

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

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

^{_{स्लाइड से लिंक करें}}

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

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

सफारी

सबसे क्रूर बात सफारी तब करती है जब कोई पृष्ठ bfcache मारता है: यदि आपके पास AJAX के अनुरोध लंबित हैं, तो सफारी सिर्फ उन्हें मारती है।

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

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

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

एक और दिलचस्प बात। जैसा कि आप जानते हैं, आप window.open () के माध्यम से कई विंडो खोल सकते हैं। और एक ही समय में, इन खिड़कियों के एक-दूसरे से लिंक होते हैं। यही है, वे एक साथ एक-दूसरे की खिड़की पर चढ़ सकते हैं, विभिन्न गुणों को पढ़ / लिख सकते हैं। बाल खिड़कियों का यह उद्घाटन bfcache में हस्तक्षेप नहीं करता है। और यहां, सबसे अधिक संभावना है, सफारी सिर्फ उतना ही क्रूर है जितना एजेक्स अनुरोधों के साथ है, अर्थात, सब कुछ मुश्किल से फाड़ रहा है, और अलविदा। Apple डेवलपर्स इसे बहुत पसंद करते हैं।

फिर एक मिनट C ++! वेबकिट स्रोत भी गुप्त नहीं हैं, उन्हें खोला, पढ़ा और अध्ययन भी किया जा सकता है।

^{_{स्लाइड से लिंक}}

वे GitHub पर हैं, वहां मैंने दो महत्वपूर्ण कार्यों पर प्रकाश डाला:

- canCacheFrame () - जांचें कि क्या यह फ्रेम कैश किया जा सकता है।
- पृष्ठ पर विभिन्न वस्तुओं, जैसे कि HTML तत्व या फ़ॉन्ट में, canSuspendForDocumentSuspension () विधियाँ हैं। यह ऑब्जेक्ट कैश है, फ्रीज है या नहीं, इसके लिए जिम्मेदार है।

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

वहाँ से मुझे पता चला कि सफारी भी टेक्स्ट लॉग में bfcache, सभी सुविधाओं के बारे में अपना सारा ज्ञान लिखती है। लेकिन, दुर्भाग्य से, मुझे कभी यह पता नहीं चला कि इस लॉगिंग को कैसे सक्षम किया जाए या, यदि यह सक्षम है, तो डिस्क पर इस फ़ाइल को कहां ढूंढें। अगर किसी को पता है, तो मुझे बताओ, मैं बहुत आभारी रहूंगा।

क्रोमियम।

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

दिलचस्प से - मैंने पहले से ही window.open () के माध्यम से एक पृष्ठ खोलने के बारे में बात की थी। क्रोमियम में, ऐसे पृष्ठों को अब तक कैश नहीं किया गया है। उन्होंने यह पता लगाने के लिए कि यह कैसे सही ढंग से हल किया है, और बेशर्मी से इसे काट दिया, जैसा कि सफारी में, उनका विवेक उन्हें अनुमति नहीं देता है।

यदि DOMContentLoaded नहीं होती है, तो पृष्ठ भी कैश नहीं किया जाएगा।

कई नए एपीआई हैं जो "वेब" से शुरू होते हैं - यह उनके साथ भी मुश्किल और समझ से बाहर है, और अब तक वे सभी डिफ़ॉल्ट रूप से bfcache को बंद कर देते हैं। यही है, अगर कुछ ट्रेंडी, नए का उपयोग पृष्ठ पर किया जाता है, जैसे कि WebGL, WebVR, WebUSB, WebBluaxy, आदि, तो ऐसा पेज bfcache में नहीं आएगा।

सेवा कार्यकर्ता। साथ ही, हम इस तरह के पेज को अभी तक कैश नहीं करते हैं, लेकिन हम इसे सही तरीके से संसाधित करने की योजना बनाते हैं, इसे सेवा कार्यकर्ता की सतर्क आंखों से छिपाते हैं।

यदि जियोलोकेशन सक्षम है, तो हम इसे अभी तक कैश नहीं करते हैं। अब के लिए इतना आसान है।

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

^{_{स्लाइड से लिंक करें}}

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

^{_{स्लाइड से लिंक करें}}

सूत्रों का कहना है। जैसा कि आप जानते हैं, क्रोमियम स्रोत भी उपलब्ध हैं। यह सब BackForwardCacheImpl नामक एक वर्ग में निहित है - बहुत अच्छा नामकरण, लगभग देखने के लिए नहीं था। मुख्य विधि जो यह जांचती है कि क्या किसी दस्तावेज़ को बचाया जा सकता है, उसे CanStoreDocument () कहा जाता है। एक GetDisallowedFeatures () विधि भी है, जो बस उन सभी नई सुविधाओं और एपीआई को सूचीबद्ध करती है जो bfcache में समर्थित नहीं हैं। बहुत सुविधाजनक: एक ही स्थान पर केंद्रित, पढ़ा और महसूस किया कि वर्तमान में क्या संभव है और क्या उपयोग नहीं किया जा सकता है।

इंटरनेट एक्सप्लोरर 11

उन लोगों के लिए इतिहास में एक भ्रमण जो अभी भी IE 11 है। उन लोगों के लिए जिनके पास सब कुछ बुरा है।

वहां bfcache है, और यह मुख्य समस्या है, क्योंकि आपको इससे निपटना होगा। प्रलेखन का कहना है कि bfcache माना जाता है कि केवल HTTP पर काम करता है। वास्तव में, उत्पादन में, यह किसी कारण से HTTPS पर भी काम करता है। नैतिक: यदि आप एक डेवलपर हैं, तो कृपया अपने प्रलेखन पर ध्यान दें। फिर आपको उसकी वजह से भुगतना पड़ता है।

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

यदि पृष्ठ लोड नहीं हुआ है, तो यह भी कैश नहीं किया गया है। यदि कोई ActiveX घटकों का उपयोग करता है, तो हम कैश भी नहीं करते हैं। और अगर DevTools वहाँ खुला है, भी। यह एक महत्वपूर्ण मुद्दा है।

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

हमारे पास सुंदर कोड था जो निर्धारित करता है कि क्या हम कैश से लौटे हैं या सर्वर से पुनः लोड किए गए हैं।

अब इसे IE के लिए एक बैसाखी के साथ पूरक किया जाना था। हम निर्धारित करते हैं कि हमारे पास IE है, और कुछ वर्कअराउंड में हम समझते हैं कि पेज अभी भी कैश से निकाला गया था और एक ही समय में, हमारे पास एक इतिहास नेविगेशन (back_forward) था।

इसके अलावा, आपको कैसे पता चलेगा कि कोई पेज कैश है? हम उसका लोड समय लेते हैं। यदि यह सर्वर से 50 मिलीसेकंड या उससे अधिक तेज़ी से लोड होता है, तो यह मूल रूप से IE में नहीं हो सकता है - इसका मतलब है कि यह कैश से है! :)

मैंने इतिहास के माध्यम से पहले ही नेविगेशन का उल्लेख किया है। यदि हमारे पास back_forward नेविगेशन प्रकार है, तो हम इतिहास के माध्यम से चले गए, और यदि पृष्ठ कैश से है, तो इसका मतलब है bfcache, IE में कोई अन्य विकल्प नहीं हैं।

आगे क्या होगा?

इस ज्ञान के साथ आगे क्या करना है? मैं नहीं चाहूंगा कि तुम एक बुरे सपने की तरह यह सब भूल जाओ।

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

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

जीआईएफ खोलें

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

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

जैसा कि वादा किया गया है, सामग्री का एक लिंक ।

BFCache, या वहाँ और वापस। यैंडेक्स रिपोर्ट