क्या आपने हाल ही में अपने Developer Console में नीचे दी गई जैसी कोई चेतावनी देखी है Chrome ने सोचा कि यह क्या था?
(index):34 A Parser-blocking, cross-origin script,
https://paul.kinlan.me/ad-inject.js, is invoked via document.write().
This may be blocked by the browser if the device has poor network connectivity.
कंपोज़ेबिलिटी, वेब की मुख्य ताकतों में से एक है. इसकी मदद से, हम नए बेहतरीन प्रॉडक्ट बनाने के लिए तीसरे पक्ष की सेवाओं के साथ इंटिग्रेट करें! एक किसी एक पक्ष के साथ समझौते की कमियां हैं, तो यह भी है कि इसमें एक जैसी ज़िम्मेदारी आती है उपयोगकर्ता अनुभव पर असर डाल सकते हैं. अगर इंटिग्रेशन से कोई नतीजा नहीं मिलता, तो उपयोगकर्ता अनुभव पर बुरा असर पड़ेगा.
खराब परफ़ॉर्मेंस की एक वजह, पेजों के अंदर document.write()
का इस्तेमाल करना है,
जो स्क्रिप्ट इंजेक्ट करते हैं. यह गेम जितना दिखने वाला है, यह उतना खतरनाक है
उपयोगकर्ताओं को गंभीर समस्याएं हो सकती हैं.
document.write('<script src="https://example.com/ad-inject.js"></script>');
ब्राउज़र किसी पेज को रेंडर कर सके, उससे पहले उसे एचटीएमएल मार्कअप को पार्स करके डीओएम ट्री बनाना होगा. जब भी पार्सर को कोई स्क्रिप्ट मिलती है, तो उसे जारी रखने से पहले उसे रोकना और एक्ज़ीक्यूट करना पड़ता है एचटीएमएल को पार्स करना. अगर स्क्रिप्ट डाइनैमिक तौर पर कोई दूसरी स्क्रिप्ट इंजेक्ट करती है, तो पार्सर को इंतज़ार करना पड़ता है संसाधन को डाउनलोड करने में और भी ज़्यादा समय लगाता है, जिससे एक या ज़्यादा नेटवर्क राउंडट्रिप हो सकती हैं और पेज को पहली बार रेंडर करने में लगने वाले समय को रोकें
धीमे कनेक्शन वाले उपयोगकर्ताओं के लिए, जैसे कि 2G. बाहरी स्क्रिप्ट डाइनैमिक रूप से काम करती हैं
document.write()
के ज़रिए डालने पर, मुख्य पेज का कॉन्टेंट दिखने में देरी हो सकती है
या पेज लोड नहीं हो पाते हैं या पेज लोड होने में इतना समय लगता है कि
उपयोगकर्ता बस छोड़ देता है. Chrome के इंस्ट्रुमेंटेशन के आधार पर, हमने पाया है कि
document.write()
के ज़रिए डाली गई तीसरे पक्ष की स्क्रिप्ट दिखाने वाले पेज
आम तौर पर, 2G पर अन्य पेजों के मुकाबले दोगुना धीमा होता है.
हमने 1% Chrome पर 28 दिनों के फ़ील्ड ट्रायल से डेटा इकट्ठा किया
स्थिर उपयोगकर्ता, 2G कनेक्शन का इस्तेमाल करने वाले उपयोगकर्ताओं तक ही सीमित है. हमने देखा कि कुल पेज का 7.6% लोड हुआ
2G नेटवर्क में कम से कम एक क्रॉस-साइट, पार्सर ब्लॉक करने वाली स्क्रिप्ट शामिल थी, जो
शीर्ष स्तर के दस्तावेज़ में document.write()
के ज़रिए सम्मिलित किया गया. ब्लॉक करने की वजह से
इन स्क्रिप्ट के लोड होते ही, हमें उन लोड में निम्न सुधार दिखाई दिए:
- पेज लोड होने में 10% बढ़ोतरी हुई फ़र्स्ट कॉन्टेंटफ़ुल पेंट (उपयोगकर्ता को विज़ुअल तौर पर पुष्टि करने के लिए कि पेज असरदार तरीके से लोड हो रहा है), 25% ज़्यादा पेज लोड, पूरी तरह से पार्स किए गए स्टेटस तक पहुंचते हैं और 10% कम बार फिर से लोड होता है उपयोगकर्ता की निराशा कम होने का सुझाव दे रहा है.
- औसत समय में 21% की कमी (एक सेकंड से ज़्यादा), जब तक फ़र्स्ट कॉन्टेंटफ़ुल पेंट
- किसी पेज को पार्स करने में लगने वाले औसत समय से 38% की कमी. इसका मतलब है कि करीब छह सेकंड का सुधार हुआ है, जिससे समय बहुत तेज़ी से कम हुआ है उपयोगकर्ता को ज़रूरी चीज़ें दिखाई जाती हैं.
इस डेटा को ध्यान में रखते हुए, Chrome के वर्शन 55 से,
सभी लोगों की ओर से मध्यवर्ती
जब हम document.write()
के तरीके को बदलकर इस ज्ञात-खराब पैटर्न का पता लगाते हैं, तो उपयोगकर्ताओं को
Chrome में मैनेज की जाती है (Chrome की स्थिति देखें).
खास तौर पर, Chrome इसके ज़रिए इंजेक्ट किए गए <script>
एलिमेंट को एक्ज़ीक्यूट नहीं करेगा
नीचे दी गई सभी शर्तें पूरी होने पर document.write()
:
- उपयोगकर्ता का इंटरनेट कनेक्शन धीमा है. खास तौर पर तब, जब उपयोगकर्ता 2G का इस्तेमाल कर रहा हो. ( आने वाले समय में, यह बदलाव धीमा कनेक्शन वाले दूसरे उपयोगकर्ताओं के लिए भी लागू होगा, जैसे कि धीमा 3G या धीमा वाई-फ़ाई.)
document.write()
, टॉप लेवल दस्तावेज़ में मौजूद है. इंटरवेंशन से कोई दस्तावेज़ को iframe में दस्तावेज़.लिखाई जाने वाली स्क्रिप्ट पर लागू करें, क्योंकि वे मुख्य पेज को रेंडर करना.document.write()
में मौजूद स्क्रिप्ट, पार्सर को ब्लॉक कर रही है. इस विषय से जुड़ी स्क्रिप्ट 'async
' या 'defer
' एट्रिब्यूट अब भी काम करेंगे.- यह स्क्रिप्ट उसी साइट पर होस्ट नहीं की गई है. दूसरे शब्दों में, Chrome eTLD+1 वाली स्क्रिप्ट के लिए दखल नहीं देता है (उदाहरण के लिए, किसी स्क्रिप्ट पर होस्ट किया जाता है) js.example.org को www.example.org पर डाला गया).
- स्क्रिप्ट, ब्राउज़र के एचटीटीपी कैश में पहले से नहीं है. कैश मेमोरी में मौजूद स्क्रिप्ट नेटवर्क में कोई देरी नहीं होगी और यह अब भी लागू होगा.
- पेज को फिर से लोड करने का अनुरोध नहीं किया जाता. Chrome हस्तक्षेप नहीं करेगा, अगर उपयोगकर्ता ने फिर से लोड किया है और वह पेज को सामान्य तरीके से लागू करेगा.
तीसरे पक्ष के स्निपेट, स्क्रिप्ट लोड करने के लिए कभी-कभी document.write()
का इस्तेमाल करते हैं.
अच्छी बात यह है कि ज़्यादातर तीसरे पक्ष
एसिंक्रोनस लोडिंग के विकल्प, जो
बाकी के डिसप्ले ब्लॉक किए बिना तीसरे पक्ष की स्क्रिप्ट को लोड होने की अनुमति देते हैं
कॉन्टेंट मौजूद रहता है.
मैं इस समस्या को कैसे ठीक करूं?
इसका आसान जवाब है कि document.write()
का इस्तेमाल करके स्क्रिप्ट इंजेक्ट न करें. बुध
एसिंक्रोनस लोडर सपोर्ट के लिए जानी-पहचानी सेवाओं का सेट बनाए रखता है
.
अगर सूची में सेवा देने वाली कंपनी का नाम नहीं है और वह एसिंक्रोनस स्क्रिप्ट लोड करने की सुविधा देता है तो कृपया हमें बताएं और हम इस पेज को अपडेट कर सकते हैं. इससे सभी उपयोगकर्ताओं को मदद मिलेगी.
अगर सेवा देने वाली कंपनी, स्क्रिप्ट को एसिंक्रोनस रूप से लोड करने की सुविधा नहीं देती है तो अपने लेख में उनसे संपर्क करें और हमें और उन्हें बताएं उन पर क्या असर पड़ेगा.
अगर सेवा देने वाली कंपनी आपको कोई ऐसा स्निपेट देती है जिसमें document.write()
शामिल है, तो
हो सकता है कि आप स्क्रिप्ट एलिमेंट में async
एट्रिब्यूट जोड़ पाएं या
में जोड़ा जा सकता है, ताकि आप DOM API के साथ document.appendChild()
जैसे स्क्रिप्ट एलिमेंट जोड़ सकें
या parentNode.insertBefore()
.
यह पता लगाने का तरीका कि आपकी साइट पर कब असर पड़ा है
ऐसे कई मानदंड हैं जो यह तय करते हैं कि पाबंदी लागू की गई है या नहीं, आपको कैसे पता चलेगा कि आप पर इसका असर पड़ा है?
किसी उपयोगकर्ता के 2G नेटवर्क का पता लगाया जा रहा है
इस बदलाव के संभावित असर को समझने के लिए, पहले आपको यह समझना होगा कि कि कितने लोग 2G का इस्तेमाल कर रहे होंगे. उपयोगकर्ता के मौजूदा नेटवर्क टाइप का पता लगाया जा सकता है Network Information API का इस्तेमाल करके, तेज़ी से आगे बढ़ सकते हैं. Chrome में उपलब्ध हो और उसके बाद अपने ऐनलिटिक्स या असली उपयोगकर्ता मेट्रिक पर चेतावनी भेजें (आरयूएम) सिस्टम.
if(navigator.connection &&
navigator.connection.type === 'cellular' &&
navigator.connection.downlinkMax <= 0.115) {
// Notify your service to indicate that you might be affected by this restriction.
}
Chrome DevTools में चेतावनियां पाना
Chrome 53 के बाद से, DevTools में गड़बड़ी वाले document.write()
के लिए चेतावनियां जारी की गई हैं
स्टेटमेंट. खास तौर पर, अगर document.write()
का अनुरोध, दो से पांच की शर्त को पूरा करता है
(Chrome इस चेतावनी को भेजते समय, कनेक्शन से जुड़ी शर्तों को अनदेखा कर देता है), चेतावनी
कुछ ऐसा दिखेगा:
Chrome DevTools में चेतावनियां दिखना बहुत अच्छी बात है. हालांकि, इससे पता कैसे चलता है कि यहां स्केल? आप उन एचटीटीपी हेडर की जांच कर सकते हैं जिन्हें आपके सर्वर पर भेजा जाता है. ऐसा तब होता है, जब हस्तक्षेप होता है.
स्क्रिप्ट संसाधन पर अपने एचटीटीपी हेडर की जांच करें
जब document.write
से डाली गई स्क्रिप्ट ब्लॉक हो जाती है, तो Chrome
हेडर को फिर से अनुरोध किए गए संसाधन पर ले जाएं:
Intervention: <https://shorturl/relevant/spec>;
जब document.write
से डाली गई स्क्रिप्ट मिलती है और उसे ब्लॉक किया जा सकता है
अलग-अलग स्थितियों में, Chrome ये ईमेल भेज सकता है:
Intervention: <https://shorturl/relevant/spec>; level="warning"
इंटरवेंशन हेडर को स्क्रिप्ट के लिए जीईटी अनुरोध के हिस्से के तौर पर भेजा जाएगा (असल में रुकावट आने पर, एसिंक्रोनस तरीके से)
भविष्य में क्या है?
शुरुआती प्लान यह है कि जब हमें ज़रूरी शर्तों का पता चल जाए, तब इस इंटरवेंशन को लागू किया जाए मिलना बंद हो गया है. हमने Chrome 53 में Developer Console में सिर्फ़ एक चेतावनी दिखाकर शुरुआत की. (बीटा वर्शन जुलाई 2016 में शुरू हुआ था. हमें उम्मीद है कि स्टेबल चैनल, इन देशों/इलाकों में रहने वाले सभी लोगों के लिए उपलब्ध होगा सितंबर 2016.)
हम 2G उपयोगकर्ताओं के लिए, इंजेक्ट की गई स्क्रिप्ट को ब्लॉक करेंगे Chrome 54, जिसके बारे में अनुमान है कि यह दुनिया भर में मौजूद सभी उपयोगकर्ताओं के लिए ठीक से काम कर सकता है अक्टूबर 2016 के मध्य में. ज़्यादा जानकारी के लिए Chrome की स्थिति से जुड़ी एंट्री ज़्यादा अपडेट के लिए.
हम समय के साथ, इंटरनेट की स्पीड कम होने पर उसे रोकने की कोशिश करते हैं (जैसे, धीमा 3G या वाई-फ़ाई). Chrome की स्थिति की जानकारी का पालन करें.
क्या आपको ज़्यादा जानकारी चाहिए?
ज़्यादा जानकारी के लिए, ये अन्य संसाधन देखें: