در سپتامبر 2017، تغییراتی را در نحوه مدیریت صدا با خط‌مشی رفتار پخش خودکار در Chrome اعلام کردیم. این تغییر خط‌مشی با Chrome 66 Stable در می ۲۰۱۸ منتشر شد.
پس از بازخورد انجمن توسعه صوتی وب، انتشار بخش صوتی وب از خط‌مشی پخش خودکار را به تاخیر انداختیم تا به توسعه‌دهندگان زمان بیشتری برای به‌روزرسانی وب‌سایت‌هایشان بدهیم. ما همچنین تغییراتی را در اجرای خط‌مشی Web Audio ایجاد کرده‌ایم که باعث کاهش تعداد وب‌سایت‌هایی می‌شود که نیاز به تنظیم کد خود دارند - به ویژه بازی‌های وب - و بنابراین تجربه بهتری را برای کاربران خود فراهم می‌کنند.
این تغییر خط مشی اکنون قرار است در دسامبر 2018 با Chrome 71 عرضه شود.
تغییر سیاست دقیقا چه کاری انجام می دهد؟
پخش خودکار نامی است که به محتوایی داده می شود که بلافاصله پس از بارگذاری یک صفحه وب پخش می شود. برای وب‌سایت‌هایی که انتظار می‌رود بتوانند محتوای خود را به صورت خودکار پخش کنند، این تغییر به‌طور پیش‌فرض از پخش جلوگیری می‌کند. در بیشتر موارد، پخش از سر گرفته می‌شود، اما در موارد دیگر، یک تنظیم کوچک در کد مورد نیاز است. به طور خاص، توسعه دهندگان باید کدی را اضافه کنند که در صورت تعامل کاربر با صفحه وب، محتوای آنها از سر گرفته شود.
با این حال، اگر کاربر به صفحه‌ای با محتوای پخش خودکار وارد شود و از صفحه‌ای با همان مبدا به آن صفحه رفته باشد، آن محتوا هرگز مسدود نخواهد شد. برای مثال های دقیق تر، پست وبلاگ قبلی ما را در مورد خط مشی پخش خودکار بخوانید.
علاوه بر این، یک اکتشافی برای یادگیری از رفتار گذشته کاربران در رابطه با وب‌سایت‌هایی که صدا را به صورت خودکار پخش می‌کنند، اضافه کردیم. زمانی را تشخیص می‌دهیم که کاربران به طور منظم در بیشتر بازدیدهایشان از یک وب‌سایت، بیش از ۷ ثانیه اجازه پخش صدا را می‌دهند و پخش خودکار آن وب‌سایت را فعال می‌کنیم.
ما این کار را با نمایه‌ای انجام می‌دهیم که به‌صورت محلی در نمایه Chrome در یک دستگاه ذخیره می‌شود - بین دستگاه‌ها همگام‌سازی نمی‌شود و فقط به عنوان بخشی از آمار کاربران ناشناس به اشتراک گذاشته می‌شود. ما این فهرست را نمایه تعامل رسانه (MEI) می نامیم و می توانید آن را از طریق chrome://media-engagement مشاهده کنید.
MEI تعداد بازدید از یک سایت شامل پخش صوتی بیش از 7 ثانیه را پیگیری می کند. بر اساس MEI کاربر، ما معتقدیم که می‌توانیم بفهمیم که آیا کاربر از یک وب‌سایت خاص انتظار صدا دارد یا نه - و هدف کاربر را در آینده پیش‌بینی کنیم.
اگر کاربر اغلب به دامنه وب سایت اجازه پخش صدا را برای بیش از 7 ثانیه می دهد، در آینده فرض می کنیم که کاربر انتظار دارد این وب سایت حق پخش خودکار صدا را داشته باشد. بنابراین، ما به آن وب سایت حق پخش خودکار صدا را بدون نیاز به تعامل کاربر با یک برگه از آن دامنه می دهیم.
با این حال، این حق به طور نامحدود تضمین نمی شود. اگر رفتار کاربر تغییر کند - به عنوان مثال توقف پخش صدا یا بستن برگه در آستانه 7 ثانیه در طول چندین بازدید - آنگاه حق وب سایت برای پخش خودکار را حذف می کنیم.
هر دو استفاده از عناصر HTML رسانه (ویدئو و صدا) و صدای وب (اشیاء AudioContext نمونه سازی شده جاوا اسکریپ) به MEI کمک خواهند کرد. در آماده‌سازی برای عرضه این خط‌مشی، رفتار کاربر در رابطه با Web Audio از Chrome 70 به بعد شروع به کمک به MEI خواهد کرد. این تضمین می‌کند که ما می‌توانیم قصد مورد نظر کاربر را در مورد پخش خودکار و وب‌سایت‌هایی که معمولاً بازدید می‌کنند، پیش‌بینی کنیم.
لازم به ذکر است که iframe ها تنها در صورتی می توانند حق پخش خودکار را بدون تعامل کاربر به دست آورند که صفحه وب اصلی که iframe را تعبیه کرده است ، این حق را به iframe داده شده گسترش دهد .
به تعویق انداختن تغییر برای حمایت از جامعه
هنگامی که این تغییر در کانال Chrome Stable ظاهر شد، جامعه توسعه دهندگان Web Audio - به ویژه توسعه‌دهنده بازی‌های وب و بخش‌های توسعه‌دهنده WebRTC از این انجمن، متوجه شدند.
بازخورد جامعه این بود که بسیاری از بازی‌های وب و تجربیات صوتی وب تحت تأثیر منفی این تغییر قرار می‌گیرند – به‌ویژه، بسیاری از سایت‌هایی که به‌روزرسانی نشده‌اند دیگر صدا را برای کاربران پخش نمی‌کنند. در نتیجه، تیم ما به این نتیجه رسید که ارزش این را دارد که این تغییر را به تأخیر بیندازیم تا به توسعه دهندگان صوتی وب زمان بیشتری برای به‌روزرسانی وب‌سایت‌هایشان بدهیم.
علاوه بر این، ما این زمان را به این موارد اختصاص دادیم:
- به طور جدی در نظر بگیرید که آیا این تغییر سیاست بهترین اقدام بود یا خیر.
- روش‌هایی را که می‌توانیم به کاهش تعداد وب‌سایت‌های صوتی که تحت تأثیر قرار می‌گیرند کمک کنیم، کاوش کنید.
در مورد اولی، ما در نهایت تصمیم گرفتیم که تغییر خط مشی در واقع برای بهبود تجربه کاربر برای اکثر کاربران ما ضروری است. جزئیات بیشتر در مورد مشکلی که تغییر خط مشی حل می کند را می توانید در بخش بعدی این مقاله بخوانید.
برای دومی، ما تنظیماتی را در پیاده سازی خود برای Web Audio انجام داده ایم که تعداد وب سایت هایی را که در ابتدا تحت تأثیر قرار گرفته اند کاهش می دهد. از میان سایت‌هایی که می‌دانستیم با این تغییر شکسته شده‌اند - که بسیاری از آنها به عنوان نمونه توسط جامعه توسعه بازی‌های وب ارائه شده‌اند - این تنظیم به این معنی است که بیش از 80٪ از آنها به طور خودکار کار می‌کنند. تجزیه و تحلیل و آزمایش ما از این سایت های نمونه را می توان در اینجا مشاهده کرد . این تنظیم جدید با جزئیات بیشتر در زیر توضیح داده شده است.
ما همچنین تغییری برای پشتیبانی از برنامه های WebRTC ایجاد کردیم. در حالی که یک جلسه ضبط فعال وجود دارد، پخش خودکار مجاز خواهد بود.
این تغییر رفتار با هدف حل چه مشکلی است؟
مرورگرها از لحاظ تاریخی در کمک به کاربر در مدیریت صدا ضعیف بوده اند. وقتی کاربران یک صفحه وب را باز می کنند و صدایی را دریافت می کنند که انتظار یا نمی خواستند، تجربه کاربری ضعیفی دارند. این تجربه کاربری ضعیف مشکلی است که ما سعی در حل آن داریم. نویز ناخواسته دلیل اصلی این است که کاربران نمی خواهند مرورگر آنها محتوا را به صورت خودکار پخش کند.
با این حال، گاهی اوقات کاربران می خواهند محتوا به صورت خودکار پخش شود و تعداد قابل توجهی از پخش خودکار مسدود شده در Chrome متعاقبا توسط کاربر پخش می شود.
بنابراین، ما بر این باوریم که با یادگیری از کاربر – و پیش‌بینی قصد آنها در هر وب‌سایت – می‌توانیم بهترین تجربه کاربری را ایجاد کنیم. اگر کاربران تمایل به پخش محتوای یک وب سایت داشته باشند، در آینده محتوای آن سایت را به صورت خودکار پخش خواهیم کرد. برعکس، اگر کاربران تمایل به توقف پخش خودکار محتوای یک وب سایت خاص داشته باشند، به طور پیش فرض از پخش خودکار آن محتوا جلوگیری می کنیم.
یکی از پیشنهادات ارائه شده توسط انجمن، بی صدا کردن صدای یک برگه به جای توقف پخش خودکار بوده است. با این حال، ما معتقدیم که بهتر است تجربه پخش خودکار را متوقف کنیم تا وب‌سایت از مسدود شدن پخش خودکار آگاه شود و به توسعه‌دهنده وب‌سایت اجازه دهد تا به این موضوع واکنش نشان دهد. برای مثال، در حالی که برخی از توسعه دهندگان ممکن است بخواهند به سادگی صدا را بی صدا کنند، سایر توسعه دهندگان ممکن است ترجیح دهند محتوای صوتی آنها تا زمانی که کاربر فعالانه با محتوا درگیر شود، متوقف شود - در غیر این صورت کاربر ممکن است بخشی از تجربه صوتی را از دست بدهد.
تنظیمات جدید برای کمک به توسعه دهندگان بازی های وب
رایج ترین روشی که توسعه دهندگان از Web Audio API استفاده می کنند، ایجاد دو نوع شی برای پخش صدا است:
- یک متن صوتی
- و AudioNodes که به یک زمینه متصل هستند
توسعه دهندگان صوتی وب یک AudioContext برای پخش صدا ایجاد می کنند. برای از سرگیری صدای خود پس از اینکه خط مشی پخش خودکار به طور خودکار AudioContext خود را به حالت تعلیق درآورد، آنها باید تابع resume() را در این شیء پس از تعامل کاربر با برگه فراخوانی کنند:
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 است. AudioNode هایی که رابط AudioScheduledSourceNode را پیاده سازی می کنند معمولاً به عنوان گره های منبع (مانند AudioBufferSourceNode، ConstantSourceNode و OscillatorNode) نامیده می شوند. گره های منبع یک متد start() را پیاده سازی می کنند.
گره‌های منبع معمولاً قطعه‌های صوتی جداگانه‌ای را نشان می‌دهند که بازی‌ها پخش می‌کنند، برای مثال: صدایی که هنگام جمع‌آوری سکه توسط بازیکن پخش می‌شود یا موسیقی پس‌زمینه‌ای که در مرحله فعلی پخش می‌شود. توسعه دهندگان بازی به احتمال زیاد هر زمان که هر یک از این صداها برای بازی ضروری باشد، تابع start() را روی گره های منبع فراخوانی می کنند.
هنگامی که این الگوی رایج در بازی های وب را شناختیم، تصمیم گرفتیم پیاده سازی خود را به موارد زیر تنظیم کنیم:
یک AudioContext به صورت خودکار از سر گرفته می شود که دو شرط برآورده شود:
- کاربر با یک صفحه تعامل داشته است.
- متد start() یک گره منبع فراخوانی می شود.
با توجه به این تغییر، اکثر بازی های وب اکنون زمانی که کاربر بازی را شروع می کند، صدای خود را از سر می گیرند.
حرکت وب به جلو
برای پیشبرد پلتفرم وب گاهی اوقات لازم است تغییراتی ایجاد شود که می تواند سازگاری را از بین ببرد. متاسفانه پخش خودکار صدا پیچیده است و در این دسته از تغییرات قرار می گیرد. اما ایجاد این تغییر برای اطمینان از اینکه وب راکد نمی شود یا مزیت نوآورانه خود را از دست نمی دهد بسیار مهم است.
با این وجود، ما می دانیم که اعمال اصلاحات برای وب سایت ها به دلایل مختلف همیشه در کوتاه مدت امکان پذیر نیست:
- توسعه دهندگان وب ممکن است بر روی یک پروژه جدید متمرکز شوند و نگهداری از یک وب سایت قدیمی بلافاصله امکان پذیر نیست.
- پورتال های بازی های وب ممکن است کنترلی بر اجرای بازی ها در کاتالوگ خود نداشته باشند و به روز رسانی صدها - اگر نه هزاران - بازی ممکن است برای ناشران وقت گیر و گران باشد.
- برخی از وب‌سایت‌ها ممکن است به سادگی بسیار قدیمی باشند و – به دلایلی – دیگر نگهداری نمی‌شوند اما همچنان برای اهداف تاریخی میزبانی می‌شوند.
در اینجا یک قطعه کد کوتاه جاوا اسکریپت است که ایجاد اشیاء 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);
});
})();
لازم به ذکر است که این قطعه کد به از سرگیری AudioContext هایی که در یک iframe نمونه سازی شده اند کمکی نمی کند، مگر اینکه این قطعه کد در محدوده محتوای خود iframe گنجانده شود.
ارائه خدمات بهتر به کاربران
برای همراهی با تغییر خط‌مشی، ما همچنین مکانیزمی را برای کاربران معرفی می‌کنیم تا خط‌مشی پخش خودکار را غیرفعال کنند تا مواردی را پوشش دهد که یادگیری خودکار طبق انتظار کار نمی‌کند یا برای وب‌سایت‌هایی که با این تغییر غیرقابل استفاده می‌شوند. این تغییر با خط‌مشی جدید در Chrome 71 اعمال می‌شود و می‌توانید آن را در تنظیمات صدا پیدا کنید. سایت هایی که کاربر می خواهد به پخش خودکار اجازه دهد می توانند به لیست مجاز اضافه شوند.
چگونه MEI برای کاربران جدید ساخته شده است؟
همانطور که قبلا ذکر شد، ما MEI را به طور خودکار در طول زمان بر اساس رفتار کاربر ایجاد می کنیم تا هدف مورد نظر آنها را در رابطه با یک وب سایت خاص با محتوای پخش خودکار پیش بینی کنیم. هر وب سایت در این شاخص امتیازی بین صفر تا یک دارد. نمرات بالاتر نشان می دهد که کاربر انتظار دارد محتوا از آن وب سایت پخش شود.
با این حال، برای نمایه‌های کاربر جدید یا اگر کاربر داده‌های مرور خود را پاک کند، به‌جای مسدود کردن پخش خودکار در همه جا، از یک فهرست پیش‌فرض بر اساس امتیازات MEI جمع‌آوری‌شده کاربر ناشناس استفاده می‌شود تا مشخص شود کدام وب‌سایت‌ها می‌توانند به طور خودکار پخش شوند. این داده تنها وضعیت اولیه MEI را در هنگام ایجاد نمایه کاربر تعیین می کند. همانطور که کاربر وب را مرور می کند و با وب سایت هایی با محتوای پخش خودکار تعامل می کند MEI شخصی او پیکربندی پیش فرض را لغو می کند.
فهرست سایت از پیش تعیین شده به‌جای تنظیم دستی، به‌صورت الگوریتمی ایجاد می‌شود، و هر وب‌سایتی واجد شرایط گنجاندن است. اگر تعداد زیادی از کاربرانی که از آن سایت بازدید می کنند اجازه پخش خودکار در آن سایت را داشته باشند، سایت ها به لیست اضافه می شوند. این آستانه بر اساس درصد است تا به سایت های بزرگتر علاقه نداشته باشد.
یافتن تعادل
ما اسناد جدیدی را ارسال کرده‌ایم تا بینش بیشتری در مورد فرآیند تصمیم‌گیری و منطق طراحی پشت این سیاست ارائه دهیم. و همچنین مستندات جدید در مورد نحوه عملکرد فهرست سایت از پیش تعیین شده .
ما همیشه کاربران خود را در اولویت قرار می دهیم، اما همچنین نمی خواهیم جامعه توسعه وب را ناامید کنیم. گاهی اوقات مرورگر بودن به این معنی است که این دو هدف باید به دقت متعادل شوند. ما معتقدیم که با تنظیماتی که در اجرای این خط‌مشی انجام داده‌ایم و زمان اضافی که برای توسعه‌دهندگان صوتی وب برای به‌روزرسانی کدشان در نظر گرفته‌ایم، با Chrome 71 به این تعادل دست خواهیم یافت.