हमने सितंबर 2017 में, Chrome में ऑडियो के अपने-आप चलने की नीति के तहत, आने वाले समय में होने वाले बदलाव का एलान किया था. नीति में किए गए इस बदलाव को मई 2018 में, Chrome 66 स्टेबल वर्शन के साथ रिलीज़ किया गया था.
वेब ऑडियो डेवलपमेंट कम्यूनिटी से सुझाव मिलने के बाद, हमने डेवलपर को उनकी वेबसाइट अपडेट करने के लिए ज़्यादा समय देने के लिए, अपने-आप चलने वाली नीति का वेब ऑडियो वाला हिस्सा रिलीज़ करने में देरी की. हमने वेब ऑडियो से जुड़ी नीति को लागू करने के तरीके में भी कुछ बदलाव किए हैं. इससे उन वेबसाइटों की संख्या कम हो जाएगी जिन्हें अपना कोड बदलने की ज़रूरत पड़ती है, खास तौर पर वेब गेम. इस वजह से, वे हमारे उपयोगकर्ताओं को बेहतर अनुभव दे पाएंगे.
अब यह नीति बदलाव दिसंबर 2018 में Chrome 71 के साथ रोल आउट करने के लिए शेड्यूल किया गया है.
नीति में हुए बदलाव का क्या असर होता है?
वीडियो के अपने-आप चलने की सुविधा वह नाम होता है जो वेबपेज के लोड होने पर तुरंत चलता है. जिन वेबसाइटों के अपने-आप वीडियो चलने की उम्मीद होती है उनके लिए, इस बदलाव से वीडियो डिफ़ॉल्ट रूप से रुक जाएगा. ज़्यादातर मामलों में, वीडियो चलना फिर से शुरू होगा, लेकिन बाकी मामलों में, कोड में थोड़ा बदलाव करने की ज़रूरत होगी. खास तौर पर, डेवलपर को ऐसा कोड जोड़ना होगा जो उपयोगकर्ता के वेबपेज से इंटरैक्ट करने पर अपने कॉन्टेंट को फिर से शुरू कर दे.
हालांकि, अगर उपयोगकर्ता किसी ऐसे पेज पर आता है जहां अपने-आप चलने वाला कॉन्टेंट है और वह उसी ऑरिजिन के किसी पेज से उस पेज पर जाता है, तो उस कॉन्टेंट को कभी भी ब्लॉक नहीं किया जाएगा. ज़्यादा जानकारी वाले उदाहरणों के लिए, वीडियो अपने-आप चलने की नीति के बारे में हमारी पुरानी ब्लॉग पोस्ट पढ़ें.
इसके अलावा, हमने ऑडियो अपने-आप चलने वाली वेबसाइटों को लेकर, उपयोगकर्ताओं के पिछले व्यवहार के बारे में जानने के लिए अनुमान लगाया. हम यह पता लगाते हैं कि उपयोगकर्ता जब किसी वेबसाइट पर आते हैं, तो ज़्यादातर मामलों में वे सात सेकंड से ज़्यादा समय तक ऑडियो चलाते हैं. इसके बाद, हम उस वेबसाइट के लिए, वीडियो अपने-आप चलने की सुविधा चालू करते हैं.
हम यह काम ऐसे इंडेक्स के साथ करते हैं जो किसी डिवाइस पर, हर Chrome प्रोफ़ाइल के हिसाब से सेव किया जाता है. इसे सभी डिवाइसों पर सिंक नहीं किया जाता और सिर्फ़ पहचान छिपाने वाले उपयोगकर्ता के आंकड़ों के हिस्से के तौर पर शेयर किया जाता है. हम इस इंडेक्स को मीडिया एंगेजमेंट इंडेक्स (एमईआई) कहते हैं और आप इसे chrome://media-engagement के ज़रिए देख सकते हैं.
एमईआई, इस बात का ट्रैक रखता है कि किसी साइट पर कितनी बार आने वाले लोगों की संख्या में सात सेकंड से ज़्यादा का ऑडियो चलाया गया है. उपयोगकर्ता के एमईआई के आधार पर, हम यह समझ सकते हैं कि कोई व्यक्ति किसी खास वेबसाइट से ऑडियो की उम्मीद करता है या नहीं. साथ ही, हम आने वाले समय में उपयोगकर्ता के मकसद का अनुमान भी लगा सकते हैं.
अगर उपयोगकर्ता अक्सर किसी वेबसाइट के डोमेन को 7 सेकंड से ज़्यादा समय के लिए ऑडियो चलाने की अनुमति देता है, तो हम आने वाले समय में यह मानकर चलते हैं कि उपयोगकर्ता इस वेबसाइट पर अपने-आप ऑडियो चलाने की सुविधा का इस्तेमाल कर सकता है. इसलिए, हम उस वेबसाइट को यह अधिकार देते हैं कि वह अपने-आप ऑडियो चलने की सुविधा का इस्तेमाल कर सके. इसके लिए, उपयोगकर्ता को डोमेन के किसी टैब से इंटरैक्ट करने की ज़रूरत नहीं होती.
हालांकि, इस अधिकार की गारंटी हमेशा के लिए नहीं होती. अगर उपयोगकर्ता का व्यवहार बदलता रहता है – उदाहरण के लिए, कई बार विज़िट करने के दौरान ऑडियो प्लेबैक को रोकना या टैब को सात सेकंड के अंदर बंद करना – तो हम वेबसाइट के अपने-आप चलने की सुविधा को हटा देते हैं.
मीडिया एचटीएमएल एलिमेंट (वीडियो और ऑडियो) और वेब ऑडियो (JavaScript इंस्टैंशिएट किए गए ऑडियोकॉन्टेक्स्ट ऑब्जेक्ट) के इस्तेमाल से, एमईआई बेहतर होगा. वेब ऑडियो के लिए उपयोगकर्ता के इस नीति को रोल आउट करने पर, Chrome 70 और उसके बाद के वर्शन से MEI पर योगदान मिलना शुरू हो जाएगा. इससे यह पक्का होगा कि हम अपने-आप वीडियो चलने की सुविधा और आम तौर पर विज़िट की जाने वाली वेबसाइटों को लेकर, उपयोगकर्ता की दिलचस्पी का अनुमान लगा सकें.
ध्यान रखें कि iframe को उपयोगकर्ता के इंटरैक्शन के बिना अपने-आप चलने का अधिकार सिर्फ़ तब मिल सकता है, जब iframe को एम्बेड करने वाला पैरंट वेबपेज उस अधिकार को दिए गए iframe पर बढ़ा देता हो.
समुदाय की सहायता करने के लिए बदलाव में देरी
Chrome स्टेबल चैनल में यह बदलाव दिखने पर, वेब ऑडियो डेवलपर समुदाय – खास तौर पर, वेब गेम डेवलपर और इस समुदाय के WebRTC डेवलपर समुदाय ने इस पर ध्यान दिया.
कम्यूनिटी के लोगों का सुझाव था कि इस बदलाव से कई वेब गेम और वेब ऑडियो सुविधाओं पर बुरा असर पड़ेगा. खास तौर पर, अपडेट नहीं की गई कई साइटों पर अब उपयोगकर्ताओं के लिए ऑडियो नहीं चलेगा. इसलिए, हमारी टीम ने यह तय किया कि इस बदलाव में देरी होनी चाहिए, ताकि वेब ऑडियो डेवलपर को अपनी वेबसाइट अपडेट करने के लिए ज़्यादा समय मिल सके.
इसके अलावा, हमने इन कामों के लिए भी समय लिया:
- इस बात पर गंभीरता से विचार करें कि नीति में किया गया यह बदलाव, कार्रवाई का सबसे अच्छा तरीका था या नहीं.
- उन तरीकों के बारे में जानें जिनसे हम ऑडियो वाली वेबसाइटों की संख्या को कम कर सकते हैं.
पहले के मामले में, हमने आखिरकार यह तय किया कि हमारे ज़्यादातर उपयोगकर्ताओं के उपयोगकर्ता अनुभव को बेहतर बनाने के लिए नीति में बदलाव करना वाकई ज़रूरी है. नीति में बदलाव से किस समस्या का समाधान हो रहा है, इसके बारे में ज़्यादा जानकारी इस लेख के अगले सेक्शन में पढ़ी जा सकती है.
हमने वेब ऑडियो की सुविधा को लागू करने के तरीके में बदलाव किया है. इससे उन वेबसाइटों की संख्या कम हो जाएगी जिन पर मूल रूप से असर हुआ था. हमें पता था कि बदलाव की वजह से कई साइटें टूट गई थीं – इनमें से कई साइटें, वेब गेम डेवलपमेंट कम्यूनिटी ने उदाहरण के तौर पर दी थीं – इस बदलाव का मतलब था कि इनमें से 80% से ज़्यादा साइटें अपने-आप काम करेंगी. हमारा विश्लेषण और जांच करने के लिए, उदाहरण के तौर पर दी गई इन साइटों को यहां देखा जा सकता है. इस नए अडजस्टमेंट के बारे में यहां ज़्यादा जानकारी दी गई है.
हमने WebRTC ऐप्लिकेशन के साथ काम करने के लिए भी एक बदलाव किया है. कैप्चर की सुविधा चालू रहने पर, वीडियो अपने-आप चलने की सुविधा चालू रहेगी.
इस बदलाव को किस समस्या को हल करना है?
ब्राउज़र, आवाज़ को मैनेज करने में लोगों की मदद करने के लिए हमेशा खराब रहे हैं. जब उपयोगकर्ताओं को कोई ऐसा वेबपेज मिलता है जिसकी उन्हें उम्मीद नहीं थी या कोई ऐसी आवाज़ मिलती है जिसकी उन्हें उम्मीद नहीं थी, तब उनका उपयोगकर्ता अनुभव खराब होता है. इस खराब उपयोगकर्ता अनुभव की वजह से हम समस्या को हल करने की कोशिश कर रहे हैं. अनचाहा शोर, उपयोगकर्ताओं के ब्राउज़र में कॉन्टेंट अपने-आप न चलने की मुख्य वजह है.
हालांकि, कभी-कभी उपयोगकर्ता चाहते हैं कि कॉन्टेंट अपने-आप चले, और Chrome में ब्लॉक किए गए अपने-आप चलने वाले विज्ञापनों को उपयोगकर्ता बाद में चलाता है.
इसलिए, हमारा मानना है कि उपयोगकर्ता से सीखकर और हर वेबसाइट के आधार पर उनके इरादे का अनुमान लगाकर, हम सबसे अच्छा उपयोगकर्ता अनुभव दे सकते हैं. अगर उपयोगकर्ता किसी वेबसाइट से कॉन्टेंट चलाना चाहते हैं, तो हम आने वाले समय में उस साइट से अपने-आप कॉन्टेंट चलने लगेंगे. वहीं, अगर लोग किसी वेबसाइट पर अपने-आप चलने वाला कॉन्टेंट बंद करते हैं, तो हम उस वेबसाइट पर मौजूद कॉन्टेंट को अपने-आप चलने की सुविधा को डिफ़ॉल्ट रूप से रोक देंगे.
कम्यूनिटी ने एक प्रस्ताव यह बताया कि वीडियो के अपने-आप चलने की सुविधा को रोकने के बजाय, किसी टैब का ऑडियो म्यूट कर दिया जाए. हालांकि, हमारा मानना है कि वीडियो के अपने-आप चलने की सुविधा को रोकना बेहतर होगा, ताकि वेबसाइट को यह पता चल सके कि वीडियो अपने-आप चलने की सुविधा ब्लॉक है. इसके बाद, वेबसाइट डेवलपर को इस पर प्रतिक्रिया देने की अनुमति दें. उदाहरण के लिए, हो सकता है कि कुछ डेवलपर सिर्फ़ ऑडियो म्यूट करना चाहें, लेकिन अन्य डेवलपर चाहें तो उनका ऑडियो कॉन्टेंट तब तक के लिए रोक देना चाहिए, जब तक उपयोगकर्ता खुद उस कॉन्टेंट पर कार्रवाई नहीं करता. ऐसा न करने पर हो सकता है कि उपयोगकर्ता को ऑडियो सुनने का कुछ हिस्सा मिल न जाए.
वेब गेम डेवलपर की मदद के लिए नए बदलाव
डेवलपर, Web Audio API का सबसे सामान्य तरीके से इस्तेमाल करते हैं. वे ऑडियो चलाने के लिए दो तरह के ऑब्जेक्ट बनाते हैं:
- AudioContext
- साथ ही, किसी कॉन्टेक्स्ट से जुड़े AudioNodes.
वेब ऑडियो डेवलपर, ऑडियो चलाने के लिए एक Audioकॉन्टेक्स्ट बनाएंगे. अपने-आप चलने वाली नीति के ऑडियोकॉन्टेक्स्ट को अपने-आप निलंबित करने के बाद, ऑडियो को फिर से शुरू करने के लिए, उपयोगकर्ता के टैब से इंटरैक्ट करने के बाद, उसे इस ऑब्जेक्ट पर रेज़्यूमे() फ़ंक्शन को कॉल करना होगा:
const context = new AudioContext();
// Setup an audio graph with AudioNodes and schedule playback.
...
// Resume AudioContext playback when user clicks a button on the page.
document.querySelector('button').addEventListener('click', function() {
context.resume().then(() => {
console.log('AudioContext playback resumed successfully');
});
});
ऐसे कई इंटरफ़ेस हैं जिन्हें AudioNode से इनहेरिट किया जाता है. इनमें से एक AudioScheduledSourceNode इंटरफ़ेस है. AudioScheduledSourceNode इंटरफ़ेस को लागू करने वाले AudioNodes को आम तौर पर, सोर्स नोड कहा जाता है. जैसे, AudioBufferSourceNode, konstSourceNode, और OscillatorNode. सोर्स नोड, start() तरीके को लागू करते हैं.
आम तौर पर, सोर्स नोड गेम में चलने वाले अलग-अलग ऑडियो स्निपेट को दिखाते हैं. उदाहरण के लिए: वह आवाज़ जो तब बजती है, जब कोई खिलाड़ी कोई सिक्का इकट्ठा करता है या मौजूदा स्टेज में चलने वाला बैकग्राउंड संगीत. जब भी गेम के लिए इनमें से किसी भी आवाज़ की ज़रूरत हो, तो गेम डेवलपर के सोर्स नोड पर start() फ़ंक्शन को कॉल करने की काफ़ी संभावना होती है.
वेब गेम में इस सामान्य पैटर्न को पहचानने के बाद, हमने इन्हें लागू करने का फ़ैसला लिया है:
दो शर्तें पूरी होने पर, ऑडियो कॉन्टेक्स्ट अपने-आप फिर से शुरू हो जाएगा:
- उपयोगकर्ता ने एक पेज से इंटरैक्ट किया है.
- सोर्स नोड के start() तरीके को कॉल किया जाता है.
इस बदलाव की वजह से, अब जब उपयोगकर्ता गेम खेलना शुरू करेगा, तब ज़्यादातर वेब गेम में ऑडियो चलने लगेगा.
वेब को बेहतर बनाना
वेब प्लैटफ़ॉर्म को आगे बढ़ाने के लिए, कभी-कभी ऐसे बदलाव करना ज़रूरी होता है जिनसे काम करने की सुविधा पर असर पड़ सकता है. माफ़ करें, ऑडियो अपने-आप चलने की सुविधा जटिल है और इसमें इसी तरह का बदलाव किया जा सकता है. हालांकि, इस बदलाव को लागू करना बहुत ज़रूरी है. इससे यह पक्का किया जा सकेगा कि वेब में कोई रुकावट न आए और न ही वेब की नई खासियत खत्म हो जाए.
इसके बावजूद, हम मानते हैं कि वेबसाइटों के लिए सुधार लागू करना कम समय में हमेशा संभव नहीं होता और इसके कई वजहें होती हैं:
- शायद वेब डेवलपर किसी नए प्रोजेक्ट पर फ़ोकस कर रहे हों और किसी पुरानी वेबसाइट का रखरखाव तुरंत संभव न हो.
- ऐसा हो सकता है कि वेब गेम पोर्टल के पास अपने कैटलॉग में गेम लागू करने की सुविधा पर कंट्रोल न हो. साथ ही, हज़ारों गेम को अपडेट करने में पब्लिशर का समय लग सकता है. इसलिए, पब्लिशर के लिए यह काम काफ़ी महंगा हो सकता है.
- कुछ वेबसाइटें बहुत पुरानी हो सकती हैं और – किसी न किसी वजह से – उनका रखरखाव अब नहीं किया जाता है, लेकिन फिर भी उन्हें ऐतिहासिक मकसद से होस्ट किया जाता है.
यहां एक छोटा JavaScript कोड स्निपेट दिया गया है, जो नए AudioContext ऑब्जेक्ट बनाने में रुकावट डालता है. साथ ही, जब उपयोगकर्ता अलग-अलग तरह के उपयोगकर्ता इंटरैक्शन करता है, तब इन ऑब्जेक्ट के रेज़्यूमे फ़ंक्शन को अपने-आप ट्रिगर कर देता है. आपके वेबपेज पर कोई भी AudioContext ऑब्जेक्ट बनाने से पहले, यह कोड इस्तेमाल किया जाना चाहिए – उदाहरण के लिए, इस कोड को अपने वेबपेज के टैग में जोड़ा जा सकता है:
(function () {
// An array of all contexts to resume on the page
const audioContextList = [];
// An array of various user interaction events we should listen for
const userInputEventNames = [
'click',
'contextmenu',
'auxclick',
'dblclick',
'mousedown',
'mouseup',
'pointerup',
'touchend',
'keydown',
'keyup',
];
// A proxy object to intercept AudioContexts and
// add them to the array for tracking and resuming later
self.AudioContext = new Proxy(self.AudioContext, {
construct(target, args) {
const result = new target(...args);
audioContextList.push(result);
return result;
},
});
// To resume all AudioContexts being tracked
function resumeAllContexts(event) {
let count = 0;
audioContextList.forEach(context => {
if (context.state !== 'running') {
context.resume();
} else {
count++;
}
});
// If all the AudioContexts have now resumed then we
// unbind all the event listeners from the page to prevent
// unnecessary resume attempts
if (count == audioContextList.length) {
userInputEventNames.forEach(eventName => {
document.removeEventListener(eventName, resumeAllContexts);
});
}
}
// We bind the resume function for each user interaction
// event on the page
userInputEventNames.forEach(eventName => {
document.addEventListener(eventName, resumeAllContexts);
});
})();
ध्यान रखें कि यह कोड स्निपेट iframe में इंस्टैंशिएट किए गए AudioContexts को फिर से शुरू करने में तब तक मदद नहीं करेगा, जब तक कि यह कोड स्निपेट iframe के कॉन्टेंट के दायरे में शामिल न हो.
हमारे उपयोगकर्ताओं को बेहतर सेवा देना
नीति में इस बदलाव के साथ-साथ, हम उपयोगकर्ताओं के लिए एक तरीका भी पेश कर रहे हैं. इसकी मदद से, वे अपने-आप चलने की सुविधा से जुड़ी नीति को बंद कर सकेंगे. ऐसा उन मामलों में होगा जहां अपने-आप सीखने की सुविधा उम्मीद के मुताबिक काम नहीं कर रही है. इसके अलावा, ये बदलाव उन वेबसाइटों के लिए भी हैं जो बदलाव की वजह से काम का नहीं हैं. यह बदलाव Chrome 71 में नई नीति के साथ रोल आउट किया जाएगा और इसे साउंड सेटिंग में देखा जा सकता है. जिन साइटों के लिए उपयोगकर्ता अपने-आप वीडियो चलने की अनुमति देना चाहता है उन्हें अनुमति वाली सूची में जोड़ा जा सकता है.
नए उपयोगकर्ताओं के लिए एमईआई कैसे बनाया जाता है?
जैसा कि पहले बताया गया है, हम उपयोगकर्ता के व्यवहार के आधार पर, समय के साथ अपने-आप एमईआई बनाते हैं. इससे, उपयोगकर्ता अपने-आप कॉन्टेंट वाली किसी वेबसाइट पर, उपयोगकर्ता की पसंद का अनुमान लगा पाता है. इस इंडेक्स में हर वेबसाइट का स्कोर शून्य और एक के बीच होता है. ज़्यादा स्कोर का मतलब है कि उपयोगकर्ता उस वेबसाइट से कॉन्टेंट चलाना चाहता है.
हालांकि, नए उपयोगकर्ताओं की प्रोफ़ाइलों या अपना ब्राउज़िंग डेटा मिटाने के मामले में, हर जगह अपने-आप वीडियो चलने की सुविधा को ब्लॉक करने के बजाय, उपयोगकर्ता के एग्रीगेट किए गए MEI स्कोर के आधार पर, पहले से चुनी गई सूची का इस्तेमाल किया जाता है. इसकी मदद से, यह तय किया जाता है कि कौनसी वेबसाइटें अपने-आप चल सकती हैं. इस डेटा से, उपयोगकर्ता की प्रोफ़ाइल बनाते समय ही एमईआई की शुरुआती स्थिति तय की जाती है. जब उपयोगकर्ता, वेब ब्राउज़ करता है और अपने-आप कॉन्टेंट दिखाने वाली वेबसाइटों से इंटरैक्ट करता है, तब उसका निजी एमईआई डिफ़ॉल्ट कॉन्फ़िगरेशन को बदल देता है.
पहले से चुनी गई साइट की सूची, मैन्युअल तरीके से चुनने के बजाय, एल्गोरिदम के हिसाब से जनरेट की जाती है. इसमें कोई भी वेबसाइट शामिल की जा सकती है. साइटों को सूची में तब जोड़ा जाता है, जब उस साइट पर आने वाले उपयोगकर्ताओं की संख्या, अपने-आप चलने की अनुमति देती हो. यह सीमा प्रतिशत पर आधारित होती है, ताकि बड़ी साइटों को पसंद न किया जाए.
बैलेंस ढूंढा जा रहा है
हमने फ़ैसला लेने की प्रोसेस और इस नीति के पीछे की वजह के बारे में ज़्यादा जानकारी देने के लिए, नया दस्तावेज़ पोस्ट किया है. साथ ही, पहले से चुनी गई साइट की सूची के काम करने के तरीके के बारे में नए दस्तावेज़ पढ़ें.
हम हमेशा अपने उपयोगकर्ताओं को प्राथमिकता देते हैं, लेकिन साथ ही वेब डेवलपमेंट कम्यूनिटी को अनदेखा नहीं करना चाहते. कभी-कभी ब्राउज़र होने का मतलब है कि इन दोनों लक्ष्यों को सावधानी से संतुलित करना होगा. हमारा मानना है कि नीति को लागू करने के लिए किए गए हमारे अडजस्टमेंट और वेब ऑडियो डेवलपर को अपना कोड अपडेट करने में जो अतिरिक्त समय लगा है उससे हम Chrome 71 का इस्तेमाल करके इस संतुलन को हासिल कर लेंगे.