داستان اینکه چه چیزی ارسال شده، چگونه تأثیر آن سنجیده شده و چه بدهبستانهایی صورت گرفته است.
منتشر شده: ۲۰ ژوئن ۲۰۱۹
تقریباً هر موضوعی را در گوگل جستجو کنید، و با صفحهای فوراً قابل تشخیص از نتایج معنادار و مرتبط مواجه خواهید شد. چیزی که احتمالاً متوجه نشدهاید این است که این صفحه نتایج جستجو، تحت سناریوهای خاص، توسط یک فناوری وب قدرتمند به نام service worker ارائه میشود.
ارائه پشتیبانی از سرویس ورکرها برای جستجوی گوگل بدون تأثیر منفی بر عملکرد، نیازمند دهها مهندس بود که در چندین تیم کار میکردند. این داستانِ آنچه ارسال شد، نحوه اندازهگیری عملکرد و چه بدهبستانهایی انجام شد، است.
دلایل کلیدی برای بررسی سرویس ورکرها
اضافه کردن یک سرویس ورکر به یک برنامه وب، درست مانند ایجاد هر تغییر معماری در سایت شما، باید با مجموعهای از اهداف مشخص در ذهن انجام شود. برای تیم جستجوی گوگل، چند دلیل کلیدی وجود داشت که چرا اضافه کردن یک سرویس ورکر ارزش بررسی دارد.
ذخیره سازی محدود نتایج جستجو
تیم جستجوی گوگل متوجه شد که کاربران معمولاً در یک بازه زمانی کوتاه، بیش از یک بار عبارات مشابه را جستجو میکنند. تیم جستجو به جای اینکه یک درخواست backend جدید را فقط برای دریافت نتایج مشابه ایجاد کند، میخواست از قابلیت ذخیرهسازی (caching) استفاده کند و آن درخواستهای تکراری را به صورت محلی انجام دهد.
اهمیت تازگی را نمیتوان نادیده گرفت، و گاهی اوقات کاربران به دلیل اینکه موضوع در حال تغییر است، بارها و بارها عبارات یکسانی را جستجو میکنند و انتظار دارند نتایج جدیدی ببینند. استفاده از یک سرویس ورکر به تیم جستجو اجازه میدهد تا منطق دقیقی را برای کنترل طول عمر نتایج جستجوی ذخیره شده محلی پیادهسازی کند و به تعادل دقیقی بین سرعت و تازگی که به نظر آنها به بهترین شکل در خدمت کاربران است، دست یابد.
تجربه آفلاین معنادار
علاوه بر این، تیم جستجوی گوگل میخواست یک تجربه آفلاین معنادار ارائه دهد. وقتی کاربری میخواهد در مورد موضوعی اطلاعات کسب کند، میخواهد مستقیماً به صفحه جستجوی گوگل برود و جستجو را شروع کند، بدون اینکه نگران اتصال فعال اینترنت باشد.
بدون یک سرویس ورکر، بازدید از صفحه جستجوی گوگل در حالت آفلاین فقط به صفحه خطای شبکه استاندارد مرورگر منتهی میشد و کاربران باید به خاطر داشته باشند که پس از برقراری اتصال، دوباره برگردند و امتحان کنند. با یک سرویس ورکر، میتوان یک پاسخ HTML آفلاین سفارشی ارائه داد و به کاربران اجازه داد تا بلافاصله عبارت جستجوی خود را وارد کنند.
نتایج تا زمانی که اتصال اینترنت برقرار نباشد، در دسترس نخواهند بود، اما سرویس ورکر به محض اینکه دستگاه با استفاده از API همگامسازی پسزمینه دوباره آنلاین شود، امکان به تعویق انداختن جستجو و ارسال آن به سرورهای گوگل را فراهم میکند.
ذخیرهسازی و سرویسدهی هوشمندانهتر جاوا اسکریپت
انگیزه دیگر، بهینهسازی ذخیرهسازی و بارگذاری کد جاوا اسکریپت ماژولار بود که انواع مختلف ویژگیهای صفحه نتایج جستجو را پشتیبانی میکند. بستهبندی جاوا اسکریپت مزایای متعددی دارد که وقتی هیچ سرویس ورکری درگیر نباشد، منطقی به نظر میرسد، بنابراین تیم جستجو نمیخواست بستهبندی را به طور کامل متوقف کند.
تیم جستجو با استفاده از توانایی یک سرویس ورکر برای نسخهبندی و ذخیرهسازی بخشهای ریز جاوا اسکریپت در زمان اجرا، گمان کرد که میتواند میزان ریزش حافظه پنهان را کاهش دهد و اطمینان حاصل کند که جاوا اسکریپت مورد استفاده مجدد در آینده میتواند به طور کارآمد ذخیرهسازی شود. منطق درون سرویس ورکر آنها میتواند یک درخواست HTTP خروجی برای یک بسته که شامل چندین ماژول جاوا اسکریپت است را تجزیه و تحلیل کند و آن را با کنار هم قرار دادن چندین ماژول ذخیره شده محلی - که در صورت امکان به طور مؤثر "جداسازی" میشود - انجام دهد. این امر باعث صرفهجویی در پهنای باند کاربر و بهبود پاسخگویی کلی میشود.
همچنین مزایای عملکردی استفاده از جاوا اسکریپت ذخیره شده توسط یک سرویس ورکر وجود دارد: در کروم، یک نمایش کد بایت تجزیه شده از آن جاوا اسکریپت ذخیره و دوباره استفاده میشود که منجر به کار کمتری میشود که باید در زمان اجرا برای اجرای جاوا اسکریپت در صفحه انجام شود.
چالشها و راهکارها
در اینجا به چند مورد از موانعی که برای دستیابی به اهداف تعیینشدهی تیم باید بر آنها غلبه میشد، اشاره میکنیم. در حالی که برخی از این چالشها مختص جستجوی گوگل هستند، بسیاری از آنها در طیف وسیعی از سایتهایی که ممکن است استقرار سرویس ورکر را در نظر داشته باشند، قابل اجرا هستند.
مشکل: سربار سرویس ورکر
بزرگترین چالش و تنها مانع واقعی برای راهاندازی یک سرویس ورکر در جستجوی گوگل، اطمینان از این بود که هیچ کاری انجام ندهد که ممکن است تأخیر ادراکشده توسط کاربر را افزایش دهد. جستجوی گوگل عملکرد را بسیار جدی میگیرد و در گذشته، راهاندازی قابلیتهای جدید را در صورتی که حتی دهها میلیثانیه تأخیر اضافی برای یک جمعیت کاربری مشخص ایجاد میکردند، مسدود میکرد.
وقتی تیم در طول اولین آزمایشهای خود شروع به جمعآوری دادههای عملکرد کرد، مشخص شد که مشکلی وجود خواهد داشت. HTML برگردانده شده در پاسخ به درخواستهای ناوبری برای صفحه نتیجه جستجو پویا است و بسته به منطقی که باید روی سرورهای وب جستجو اجرا شود، بسیار متفاوت است. در حال حاضر هیچ راهی برای سرویس ورکر وجود ندارد که این منطق را تکرار کند و بلافاصله HTML ذخیره شده را برگرداند - بهترین کاری که میتواند انجام دهد این است که درخواستهای ناوبری را به سرورهای وب backend ارسال کند، که مستلزم درخواست شبکه است.
بدون یک سرویس ورکر، این درخواست شبکه بلافاصله پس از پیمایش کاربر اتفاق میافتد. وقتی یک سرویس ورکر ثبت میشود، همیشه باید راهاندازی شود و فرصتی برای اجرای کنترلکنندههای رویداد fetch خود داشته باشد، حتی زمانی که هیچ شانسی برای انجام کاری غیر از رفتن به شبکه توسط آن کنترلکنندههای واکشی وجود ندارد. مدت زمانی که برای راهاندازی و اجرای کد سرویس ورکر طول میکشد، سربار خالصی است که به هر پیمایش اضافه میشود:
این امر پیادهسازی سرویس ورکر را در معرض ضرر تأخیر بیش از حد قرار میدهد تا هرگونه مزیت دیگری را توجیه کند. علاوه بر این، تیم متوجه شد که بر اساس اندازهگیری زمان بوت سرویس ورکر در دستگاههای دنیای واقعی، توزیع گستردهای از زمانهای راهاندازی وجود دارد، به طوری که برخی از دستگاههای تلفن همراه رده پایین تقریباً به همان اندازه که برای درخواست شبکه برای HTML صفحه نتایج لازم است، برای راهاندازی سرویس ورکر زمان صرف میکنند.
راه حل: از پیش بارگذاری ناوبری استفاده کنید
تنها و مهمترین ویژگی که به تیم جستجوی گوگل اجازه داد تا با راهاندازی سرویس ورکر خود پیش بروند، پیشبارگذاری ناوبری است. استفاده از پیشبارگذاری ناوبری یک مزیت کلیدی برای هر سرویس ورکر است که برای پاسخگویی به درخواستهای ناوبری نیاز به استفاده از پاسخی از شبکه دارد. این به مرورگر اشاره میکند تا بلافاصله، همزمان با راهاندازی سرویس ورکر، درخواست ناوبری را آغاز کند:
تا زمانی که مدت زمان لازم برای راهاندازی سرویس ورکر کمتر از مدت زمان لازم برای دریافت پاسخ از شبکه باشد، نباید هیچ سربار تأخیری توسط سرویس ورکر ایجاد شود.
تیم جستجو همچنین باید از استفاده از یک سرویس ورکر در دستگاههای تلفن همراه رده پایین که زمان بوت شدن سرویس ورکر میتواند از درخواست ناوبری بیشتر شود، خودداری میکرد. از آنجایی که هیچ قانون قطعی و مشخصی برای اینکه چه چیزی یک دستگاه "رده پایین" را تشکیل میدهد، وجود ندارد، آنها به روش اکتشافی بررسی کل رم نصب شده روی دستگاه رسیدند. هر چیزی کمتر از ۲ گیگابایت حافظه در دسته دستگاههای رده پایین آنها قرار میگرفت، جایی که زمان راهاندازی سرویس ورکر غیرقابل قبول بود.
فضای ذخیرهسازی موجود نیز نکتهی قابل توجهی است، زیرا مجموعهی کامل منابعی که قرار است برای استفادههای بعدی ذخیره شوند، میتوانند به چندین مگابایت برسند. رابط کاربری navigator.storage به صفحهی جستجوی گوگل اجازه میدهد تا از قبل تشخیص دهد که آیا تلاشهای آنها برای ذخیرهی دادهها به دلیل نقص در سهمیهبندی ذخیرهسازی، خطر شکست را به همراه دارد یا خیر.
این امر باعث شد تیم جستجو با معیارهای متعددی روبرو شود که میتوانستند برای تعیین استفاده یا عدم استفاده از یک سرویس ورکر از آنها استفاده کنند: اگر کاربری با استفاده از مرورگری که از پیشبارگذاری ناوبری پشتیبانی میکند و حداقل ۲ گیگابایت رم و فضای ذخیرهسازی خالی کافی دارد، به صفحه جستجوی گوگل بیاید، یک سرویس ورکر ثبت میشود . مرورگرها یا دستگاههایی که این معیارها را نداشته باشند، در نهایت یک سرویس ورکر دریافت نخواهند کرد، اما همچنان همان تجربه جستجوی گوگل را مانند همیشه مشاهده خواهند کرد.
یکی از مزایای جانبی این ثبت انتخابی، امکان ارسال یک سرویس ورکر کوچکتر و کارآمدتر است. هدف قرار دادن مرورگرهای نسبتاً مدرن برای اجرای کد سرویس ورکر، سربار transpilation و polyfills را برای مرورگرهای قدیمیتر از بین میبرد. این امر در نهایت منجر به کاهش حدود ۸ کیلوبایت کد جاوا اسکریپت فشرده نشده از کل حجم پیادهسازی سرویس ورکر شد.
مشکل: محدودههای سرویس ورکرها
وقتی تیم جستجو آزمایشهای مربوط به تأخیر را به اندازه کافی انجام داد و مطمئن شد که استفاده از پیشبارگذاری ناوبری، مسیری عملی و بدون تأخیر را برای استفاده از یک سرویس ورکر در اختیار آنها قرار میدهد، برخی از مسائل عملی شروع به مطرح شدن کردند. یکی از این مسائل مربوط به قوانین تعیین محدوده سرویس ورکر است. محدوده یک سرویس ورکر تعیین میکند که کدام صفحات را میتواند به طور بالقوه کنترل کند.
محدودهبندی بر اساس پیشوند مسیر URL کار میکند. برای دامنههایی که میزبان یک برنامه وب واحد هستند، این مسئله مشکلی ایجاد نمیکند، زیرا معمولاً فقط از یک سرویس ورکر با حداکثر محدوده / استفاده میکنید که میتواند کنترل هر صفحهای را تحت دامنه به دست بگیرد. اما ساختار URL جستجوی گوگل کمی پیچیدهتر است.
اگر به این سرویس ورکر حداکثر دامنهی / داده شود، در نهایت میتواند کنترل هر صفحهای که تحت www.google.com (یا معادل منطقهای آن) میزبانی میشود را در دست بگیرد، و URLهایی تحت آن دامنه وجود دارند که هیچ ارتباطی با جستجوی گوگل ندارند. یک دامنهی منطقیتر و محدودتر، /search خواهد بود که حداقل URLهایی را که کاملاً به نتایج جستجو بیربط هستند، حذف میکند.
متأسفانه، حتی مسیر URL /search نیز بین انواع مختلف نتایج جستجوی گوگل به اشتراک گذاشته شده است، و پارامترهای کوئری URL تعیین میکنند که کدام نوع خاص از نتیجه جستجو نشان داده شود. برخی از این انواع از پایگاههای کد کاملاً متفاوتی نسبت به صفحه نتایج جستجوی وب سنتی استفاده میکنند. به عنوان مثال، جستجوی تصویر و جستجوی خرید هر دو تحت مسیر URL /search با پارامترهای کوئری مختلف ارائه میشوند، اما هیچ یک از این رابطها (هنوز) آماده ارائه تجربه کارگر سرویس خود نبودند.
راه حل: ایجاد یک چارچوب اعزام و مسیریابی
در حالی که برخی پیشنهادها وجود دارد که امکان استفاده از چیزی قدرتمندتر از پیشوندهای مسیر URL را برای تعیین محدودههای سرویس ورکرها فراهم میکند، تیم جستجوی گوگل در استقرار یک سرویس ورکرها که هیچ کاری برای زیرمجموعهای از صفحاتی که کنترل میکرد انجام نمیداد، گیر افتاده بود.
برای حل این مشکل، تیم جستجوی گوگل یک چارچوب ارسال و مسیریابی سفارشی ایجاد کرد که میتوانست برای بررسی معیارهایی مانند پارامترهای پرسوجوی صفحه کلاینت پیکربندی شود و از آنها برای تعیین مسیر کد خاص استفاده کند. این سیستم به جای قوانین کدگذاری ثابت، انعطافپذیر ساخته شده بود و به تیمهایی که فضای URL را به اشتراک میگذارند، مانند جستجوی تصویر و جستجوی خرید، اجازه میداد در صورت تصمیم به پیادهسازی، منطق سرویس ورکر خود را در ادامه کار اعمال کنند.
مشکل: نتایج و معیارهای شخصیسازیشده
کاربران میتوانند با استفاده از حسابهای گوگل خود وارد جستجوی گوگل شوند و تجربه نتایج جستجوی آنها ممکن است بر اساس دادههای حساب کاربری خاصشان سفارشیسازی شود. کاربران وارد شده توسط کوکیهای مرورگر خاص شناسایی میشوند که یک استاندارد معتبر و مورد حمایت گسترده است.
با این حال، یکی از معایب استفاده از کوکیهای مرورگر این است که آنها در داخل یک سرویس ورکر نمایش داده نمیشوند و هیچ راهی برای بررسی خودکار مقادیر آنها و اطمینان از عدم تغییر آنها به دلیل خروج کاربر یا تغییر حساب کاربری وجود ندارد. (تلاشهایی برای دسترسی کوکیها به سرویس ورکرها در حال انجام است، اما تا زمان نگارش این مطلب، این رویکرد آزمایشی است و به طور گسترده پشتیبانی نمیشود.)
عدم تطابق بین دیدگاه کاربر فعلی وارد شده توسط سرویس ورکر و کاربر واقعی وارد شده به رابط وب جستجوی گوگل میتواند منجر به شخصیسازی نادرست نتایج جستجو یا تخصیص نادرست معیارها و گزارشگیری شود. هر یک از این سناریوهای خرابی، یک مشکل جدی برای تیم جستجوی گوگل خواهد بود.
راه حل: ارسال کوکیها با استفاده از postMessage
تیم جستجوی گوگل به جای اینکه منتظر بماند تا APIهای آزمایشی راهاندازی شوند و دسترسی مستقیم به کوکیهای مرورگر را درون یک سرویس ورکر فراهم کنند، یک راهحل موقت ارائه داد: هر زمان که صفحهای که توسط سرویس ورکر کنترل میشود بارگذاری میشود، صفحه کوکیهای مربوطه را میخواند و postMessage() برای ارسال آنها به سرویس ورکر استفاده میکند.
سپس سرویس ورکر مقدار کوکی فعلی را با مقداری که انتظار دارد بررسی میکند و در صورت عدم تطابق، اقداماتی را برای پاک کردن هرگونه داده خاص کاربر از حافظه خود انجام میدهد و صفحه نتایج جستجو را بدون هیچ گونه شخصیسازی نادرستی مجدداً بارگذاری میکند.
مراحل خاصی که سرویس ورکر برای تنظیم مجدد موارد به حالت اولیه انجام میدهد، مختص الزامات جستجوی گوگل است، اما همین رویکرد کلی ممکن است برای سایر توسعهدهندگانی که با دادههای شخصیسازیشدهی کوکیهای مرورگر سروکار دارند، مفید باشد.
مشکل: آزمایشها و پویایی
همانطور که گفته شد، تیم جستجوی گوگل به شدت به اجرای آزمایشها در محیط عملیاتی و آزمایش اثرات کدها و ویژگیهای جدید در دنیای واقعی قبل از فعال کردن آنها به صورت پیشفرض متکی است. این امر میتواند با یک سرویس ورکر استاتیک که به شدت به دادههای ذخیره شده متکی است، کمی چالش برانگیز باشد، زیرا انتخاب کاربران برای ورود و خروج از آزمایشها اغلب نیاز به ارتباط با سرور backend دارد.
راه حل: اسکریپت سرویس ورکر که به صورت پویا تولید میشود
راه حلی که تیم انتخاب کرد، استفاده از یک اسکریپت سرویس ورکر پویا بود که توسط وب سرور برای هر کاربر شخصیسازی میشد، به جای یک اسکریپت سرویس ورکر ایستا و واحد که از قبل تولید میشد. اطلاعات مربوط به آزمایشهایی که ممکن است بر رفتار سرویس ورکر یا درخواستهای شبکه به طور کلی تأثیر بگذارند، مستقیماً در این اسکریپتهای سرویس ورکر سفارشی گنجانده شدهاند. تغییر مجموعه تجربیات فعال برای یک کاربر از طریق ترکیبی از تکنیکهای سنتی، مانند کوکیهای مرورگر، و همچنین ارائه کد بهروزرسانی شده در URL سرویس ورکر ثبت شده انجام میشود.
استفاده از یک اسکریپت سرویس ورکر که به صورت پویا تولید میشود، همچنین فراهم کردن یک راه فرار را در مواقع بعیدی که پیادهسازی سرویس ورکر دارای یک باگ مهلک است که باید از آن اجتناب شود، آسانتر میکند. پاسخ پویای سرویس ورکر سرور میتواند یک پیادهسازی بدون عملیات باشد و عملاً سرویس ورکر را برای برخی یا همه کاربران فعلی غیرفعال کند.
مشکل: هماهنگسازی بهروزرسانیها
یکی از سختترین چالشهای پیش روی هر استقرار سرویس ورکری در دنیای واقعی، ایجاد یک موازنه منطقی بین اجتناب از شبکه به نفع حافظه پنهان است، در حالی که در عین حال، اطمینان حاصل شود که کاربران فعلی، بهروزرسانیها و تغییرات حیاتی را بلافاصله پس از استقرار در محیط عملیاتی دریافت میکنند. تعادل مناسب به عوامل زیادی بستگی دارد:
- اینکه آیا برنامه وب شما یک برنامه تک صفحهای با عمر طولانی است که کاربر آن را به طور نامحدود باز نگه میدارد، بدون اینکه به صفحات جدید برود یا خیر.
- سرعت استقرار بهروزرسانیها در وب سرور بکاند شما چگونه است؟
- اینکه آیا کاربر عادی استفاده از نسخه کمی قدیمی برنامه وب شما را تحمل میکند یا اینکه تازگی اولویت اصلی است.
تیم جستجوی گوگل در حین آزمایش با سرویس ورکرها، اطمینان حاصل کرد که آزمایشها در تعدادی از بهروزرسانیهای برنامهریزیشدهی بکاند اجرا شوند تا اطمینان حاصل شود که معیارها و تجربهی کاربری با آنچه کاربران در دنیای واقعی مشاهده میکنند، مطابقت بیشتری داشته باشد.
راه حل: تعادل بین تازگی و استفاده از حافظه پنهان (cache)
پس از آزمایش تعدادی از گزینههای پیکربندی مختلف، تیم جستجوی گوگل دریافت که تنظیمات زیر تعادل مناسبی بین تازگی و استفاده از حافظه پنهان (cache) ایجاد میکند.
آدرس اینترنتی اسکریپت سرویس ورکر با هدر پاسخ Cache-Control: private, max-age=1500 (1500 ثانیه یا 25 دقیقه) ارائه میشود و با updateViaCache که روی 'all' تنظیم شده است، ثبت میشود تا از رعایت هدر اطمینان حاصل شود. همانطور که ممکن است تصور کنید، بکاند وب جستجوی گوگل مجموعهای بزرگ و توزیعشده در سطح جهانی از سرورها است که به حداکثر زمان روشن بودن (آپتایم) ممکن نیاز دارد. اعمال تغییری که بر محتوای اسکریپت سرویس ورکر تأثیر میگذارد، به صورت چرخشی انجام میشود.
اگر کاربری به یک بکاند که بهروزرسانی شده است، مراجعه کند و سپس به سرعت به صفحه دیگری برود که به بکاندی برخورد کند که هنوز سرویس ورکر بهروزرسانیشده را دریافت نکرده است، در نهایت چندین بار بین نسخهها جابهجا میشود. بنابراین، اینکه به مرورگر بگوییم فقط در صورتی که ۲۵ دقیقه از آخرین بررسی گذشته باشد، اسکریپت بهروزرسانیشده را بررسی کند، نکته منفی قابل توجهی ندارد. نکته مثبت انتخاب این رفتار، کاهش قابل توجه ترافیک دریافتی توسط نقطه پایانی است که به صورت پویا اسکریپت سرویس ورکر را تولید میکند.
علاوه بر این، یک هدر ETag روی پاسخ HTTP اسکریپت سرویس ورکر تنظیم شده است، که تضمین میکند وقتی بررسی بهروزرسانی پس از گذشت ۲۵ دقیقه انجام میشود، اگر هیچ بهروزرسانی برای سرویس ورکر مستقر شده در این فاصله انجام نشده باشد، سرور میتواند به طور موثر با یک پاسخ HTTP 304 پاسخ دهد.
در حالی که برخی از تعاملات درون برنامه وب جستجوی گوگل از ناوبریهای تک صفحهای به سبک برنامه استفاده میکنند (یعنی از طریق API History )، جستجوی گوگل در بیشتر موارد یک برنامه وب سنتی است که از ناوبریهای "واقعی" استفاده میکند. این موضوع زمانی مطرح میشود که تیم تصمیم گرفت استفاده از دو گزینه که چرخه عمر بهروزرسانی سرویس ورکر را تسریع میکنند، مؤثر خواهد بود: clients.claim() و skipWaiting() . کلیک کردن در رابط جستجوی گوگل معمولاً به پیمایش به اسناد HTML جدید منجر میشود. فراخوانی skipWaiting تضمین میکند که یک سرویس ورکر بهروزرسانیشده، فرصتی برای مدیریت درخواستهای ناوبری جدید بلافاصله پس از نصب پیدا میکند. به طور مشابه، فراخوانی clients.claim() به این معنی است که سرویس ورکر بهروزرسانیشده، فرصتی برای شروع کنترل هر صفحه جستجوی گوگل باز که کنترل نشده است، پس از فعالسازی سرویس ورکر، پیدا میکند.
رویکردی که گوگل سرچ در پیش گرفت لزوماً راهحلی نیست که برای همه کارساز باشد - این نتیجهی آزمایش دقیق A/B ترکیبات مختلف گزینههای ارائه خدمات بود تا زمانی که بهترین گزینه را برای خود پیدا کردند. توسعهدهندگانی که زیرساخت بکاند آنها به آنها اجازه میدهد بهروزرسانیها را سریعتر مستقر کنند، ممکن است ترجیح دهند که مرورگر تا حد امکان، با نادیده گرفتن همیشگی حافظه پنهان HTTP، اسکریپت بهروزرسانیشدهی سرویس ورکر را بررسی کند. اگر در حال ساخت یک برنامهی تکصفحهای هستید که کاربران ممکن است آن را برای مدت طولانی باز نگه دارند، استفاده از skipWaiting() احتمالاً انتخاب مناسبی برای شما نیست - اگر به سرویس ورکر جدید اجازه دهید در حالی که کلاینتهای با عمر طولانی وجود دارند، فعال شود ، با خطر ناسازگاری در حافظه پنهان مواجه خواهید شد.
نکات کلیدی
به طور پیشفرض، سرویس ورکرها از نظر عملکرد بیطرف نیستند.
اضافه کردن یک سرویس ورکر به برنامه وب شما به معنای وارد کردن یک قطعه کد جاوا اسکریپت اضافی است که باید قبل از دریافت پاسخ به درخواستهای برنامه وب شما، بارگیری و اجرا شود. اگر این پاسخها به جای شبکه از یک حافظه پنهان محلی دریافت شوند، سربار اجرای سرویس ورکر معمولاً در مقایسه با مزیت عملکرد حاصل از اولویتبندی حافظه پنهان، ناچیز است. اما اگر میدانید که سرویس ورکر شما همیشه هنگام مدیریت درخواستهای ناوبری باید با شبکه مشورت کند، استفاده از پیشبارگذاری ناوبری یک مزیت عملکرد حیاتی است.
سرویس ورکرها (هنوز!) یک پیشرفت تدریجی هستند
داستان پشتیبانی از سرویس ورکرها امروزه بسیار روشنتر از حتی یک سال پیش است. اکنون همه مرورگرهای مدرن حداقل از برخی از سرویس ورکرها پشتیبانی میکنند ، اما متأسفانه، برخی از ویژگیهای پیشرفته سرویس ورکرها - مانند همگامسازی پسزمینه و پیشبارگذاری ناوبری - وجود دارند که به طور جهانی ارائه نشدهاند. بررسی ویژگی برای زیرمجموعه خاصی از ویژگیهایی که میدانید به آنها نیاز دارید، و ثبت یک سرویس ورکرها فقط در صورت وجود آنها، هنوز یک رویکرد منطقی است.
به همین ترتیب، اگر آزمایشهایی را در شرایط واقعی انجام دادهاید و میدانید که دستگاههای رده پایین با سربار اضافی یک سرویس ورکر، عملکرد ضعیفی دارند، میتوانید در آن سناریوها نیز از ثبت یک سرویس ورکر خودداری کنید.
شما باید همچنان با سرویس ورکرها به عنوان یک پیشرفت تدریجی رفتار کنید که وقتی همه پیشنیازها برآورده شوند و سرویس ورکرها چیز مثبتی به تجربه کاربری و عملکرد کلی بارگذاری اضافه کنند، به برنامه وب اضافه میشوند.
همه چیز را اندازه بگیرید
تنها راهی که میتوانید بفهمید ارسال یک کارگر خدماتی تأثیر مثبت یا منفی بر تجربیات کاربران شما داشته است، آزمایش و اندازهگیری نتایج است.
جزئیات تنظیم اندازهگیریهای معنادار به این بستگی دارد که از چه ارائهدهنده تحلیلی استفاده میکنید و چگونه معمولاً آزمایشها را در تنظیمات استقرار خود انجام میدهید. یک رویکرد، استفاده از گوگل آنالیتیکس برای جمعآوری معیارها، در این مطالعه موردی بر اساس تجربه استفاده از سرویس ورکرها در برنامه وب Google I/O به تفصیل شرح داده شده است.
اهداف غیر
در حالی که بسیاری از اعضای جامعه توسعه وب، سرویس ورکرها را با برنامههای وب پیشرونده مرتبط میدانند، ساخت یک «Google Search PWA» هدف اولیه این تیم نبود. برنامه وب Google Search نه متادیتا را در مانیفست برنامه وب ارائه میدهد و نه کاربران را به انجام فرآیند «افزودن به صفحه اصلی» تشویق میکند. تیم جستجو از اینکه کاربران با نقاط ورود کلاسیک برای جستجوی گوگل به برنامه وب آنها مراجعه میکنند، راضی است.
به جای تلاش برای تبدیل تجربه وب جستجوی گوگل به معادل آنچه از یک برنامه نصب شده انتظار دارید، تمرکز در نسخه اولیه بر بهبود تدریجی وبسایت موجود بود.
تقدیرنامهها
با تشکر از کل تیم توسعه وب جستجوی گوگل برای کارشان در پیادهسازی سرویس ورکر و به اشتراک گذاشتن مطالب پیشزمینهای که در نوشتن این مطلب به کار رفته است. تشکر ویژه از فیلیپ گول، راجش جاگاناتان، آر. ساموئل کلاچکو، اندی مارتون، لئوناردو پنیا، ریچل شیرر، گرگ ترونو و کلی وولام.
بهروزرسانی (اکتبر ۲۰۲۱): از زمان انتشار اولیه این مقاله، تیم جستجوی گوگل مزایا و معایب معماری فعلی سرویس ورکرها را دوباره ارزیابی کرده است. سرویس ورکرهایی که در بالا توضیح داده شد، در حال بازنشسته شدن هستند. با تکامل زیرساخت وب جستجوی گوگل، تیم ممکن است طراحی سرویس ورکرها را دوباره بررسی کند.