داستان آنچه ارسال شد، چگونه تاثیر اندازه گیری شد، و مبادلاتی که انجام شد.
زمینه
تقریباً هر موضوعی را در Google جستجو کنید، با یک صفحه قابل تشخیص فوری از نتایج معنادار و مرتبط روبرو خواهید شد. چیزی که احتمالاً متوجه نشده اید این است که این صفحه نتایج جستجو، تحت سناریوهای خاصی، توسط یک بخش قدرتمند از فناوری وب به نام کارگر خدمات ارائه می شود.
ارائه پشتیبانی کارگر خدماتی برای جستجوی Google بدون تأثیر منفی بر عملکرد، به ده‌ها مهندس نیاز داشت که در چندین تیم کار کنند. این داستان این است که چه چیزی ارسال شد، عملکرد چگونه اندازه‌گیری شد و چه مبادلاتی انجام شد.
دلایل کلیدی برای کاوش کارکنان خدمات
اضافه کردن یک سرویس دهنده به یک برنامه وب، درست مانند ایجاد هر تغییر معماری در سایت شما، باید با مجموعه ای واضح از اهداف انجام شود. برای تیم جستجوی Google، چند دلیل کلیدی وجود دارد که چرا افزودن یک سرویس دهنده ارزش کاوش را دارد.
ذخیره محدود نتایج جستجو
تیم جستجوی Google دریافت که معمولاً کاربران در مدت زمان کوتاهی بیش از یک بار عبارات مشابه را جستجو می کنند. تیم جستجو به‌جای اجرای یک درخواست پشتیبان جدید فقط برای دریافت نتایج مشابه، می‌خواست از مزیت ذخیره‌سازی استفاده کند و این درخواست‌های تکراری را به صورت محلی انجام دهد.
اهمیت تازگی را نمی توان نادیده گرفت و گاهی اوقات کاربران به طور مکرر عبارات مشابهی را جستجو می کنند زیرا موضوعی در حال تحول است و انتظار دارند نتایج تازه ای ببینند. استفاده از سرویسکار به تیم جستجو اجازه می‌دهد تا منطق دقیقی را برای کنترل طول عمر نتایج جستجوی ذخیره‌سازی شده محلی پیاده‌سازی کند و به تعادل دقیق سرعت در مقابل تازگی دست یابد که معتقدند بهترین خدمات را به کاربران ارائه می‌دهد.
تجربه آفلاین معنادار
علاوه بر این، تیم جستجوی Google می‌خواست یک تجربه آفلاین معنادار ارائه دهد. وقتی کاربر می خواهد در مورد موضوعی بداند، می خواهد مستقیماً به صفحه جستجوی Google رفته و بدون نگرانی در مورد اتصال فعال اینترنت، جستجو را آغاز کند.
بدون یک سرویس‌دهنده، بازدید از صفحه جستجوی Google در حالت آفلاین فقط به صفحه خطای شبکه استاندارد مرورگر منتهی می‌شود و کاربران باید به خاطر داشته باشند که پس از بازگشت اتصال خود دوباره برگردند و دوباره امتحان کنند. با یک سرویسکار، می‌توان یک پاسخ HTML آفلاین سفارشی ارائه کرد و به کاربران اجازه داد که بلافاصله درخواست جستجوی خود را وارد کنند.
تا زمانی که اتصال اینترنت برقرار نشود، نتایج در دسترس نخواهد بود، اما کارگر سرویس اجازه می‌دهد به محض اینکه دستگاه با استفاده از API همگام‌سازی پس‌زمینه آنلاین شد، جستجو به تعویق افتاد و به سرورهای Google ارسال شود.
ذخیره سازی و سرویس دهی هوشمند جاوا اسکریپت
انگیزه دیگر، بهینه سازی ذخیره و بارگذاری کد جاوا اسکریپت مدولار شده بود که انواع مختلف ویژگی ها را در صفحه نتایج جستجو تقویت می کند. تعدادی از مزایا توسط بسته‌بندی جاوا اسکریپت ارائه می‌شود که زمانی معنا پیدا می‌کنند که درگیر سرویس‌دهی نباشد، بنابراین تیم جستجو نمی‌خواهد صرفاً بسته‌بندی را به طور کامل متوقف کند.
با استفاده از توانایی یک سرویس‌دهنده برای نسخه‌سازی و ذخیره‌سازی تکه‌های ریز جاوا اسکریپت در زمان اجرا، تیم جستجو مشکوک شد که می‌توانند میزان ریزش حافظه پنهان را کاهش دهند و اطمینان حاصل کنند که جاوا اسکریپت مورد استفاده مجدد در آینده می‌تواند به طور موثر در حافظه پنهان ذخیره شود. منطق داخل سرویسکار آنها می‌تواند یک درخواست HTTP خروجی را برای بسته‌ای که حاوی چندین ماژول جاوا اسکریپت است، تجزیه و تحلیل کند و آن را با کنار هم قرار دادن چندین ماژول حافظه پنهان محلی انجام دهد - در صورت امکان به طور موثر «بازسازی» شود. این باعث صرفه جویی در پهنای باند کاربر و بهبود پاسخگویی کلی می شود.
استفاده از جاوا اسکریپت کش که توسط یک سرویسکار ارائه می‌شود، مزایای عملکردی نیز دارد: در کروم، نمایش کد تجزیه‌شده و بایتی آن جاوا اسکریپت ذخیره می‌شود و مجدداً مورد استفاده قرار می‌گیرد، که منجر به کار کمتری می‌شود که در زمان اجرا باید انجام شود تا جاوا اسکریپت در آن اجرا شود. صفحه.
چالش ها و راه حل ها
در اینجا چند مورد از موانعی که برای دستیابی به اهداف تیم باید برطرف شود، آورده شده است. در حالی که برخی از این چالش‌ها مختص جستجوی Google هستند، بسیاری از آنها برای طیف گسترده‌ای از سایت‌هایی که ممکن است به‌کارگیری کارگر خدماتی را در نظر بگیرند، قابل اجرا هستند.
مشکل: سربار کارگر خدمات
بزرگ‌ترین چالش و یکی از مسدودکننده‌های واقعی برای راه‌اندازی یک سرویسکار در جستجوی Google، اطمینان از اینکه کاری انجام نمی‌دهد که ممکن است تأخیر درک شده توسط کاربر را افزایش دهد. جستجوی Google عملکرد را بسیار جدی می‌گیرد، و در گذشته، راه‌اندازی عملکردهای جدید را مسدود کرده است، اگر حتی ده‌ها میلی‌ثانیه تأخیر اضافی برای یک جمعیت کاربر خاص ایجاد کند.
هنگامی که تیم شروع به جمع آوری داده های عملکرد در اولین آزمایشات خود کرد، آشکار شد که مشکلی وجود خواهد داشت. HTML بازگردانده شده در پاسخ به درخواست‌های ناوبری برای صفحه نتیجه جستجو، پویا است و بسته به منطقی که باید در سرورهای وب جستجو اجرا شود، بسیار متفاوت است. در حال حاضر هیچ راهی برای کارگر سرویس وجود ندارد که بتواند این منطق را تکرار کند و HTML حافظه پنهان را فوراً برگرداند - بهترین کاری که می تواند انجام دهد این است که درخواست های ناوبری را به سرورهای وب پشتیبان ارسال کند، که نیاز به درخواست شبکه دارد.
بدون یک سرویس دهنده، این درخواست شبکه بلافاصله پس از ناوبری کاربر انجام می شود. هنگامی که یک سرویسکار ثبت‌نام می‌شود، همیشه باید راه‌اندازی شود و به آن فرصتی داده شود تا کنترل‌کننده‌های رویداد fetch خود را اجرا کند، حتی زمانی که این امکان وجود ندارد که آن کنترل‌کننده‌های واکشی کاری غیر از رفتن به شبکه انجام دهند. مقدار زمانی که برای راه‌اندازی و اجرای کد Service Worker طول می‌کشد، سربار خالصی است که به هر پیمایش اضافه می‌شود:
این امر پیاده‌سازی کارگر سرویس را در مضیقه بسیار با تأخیر قرار می‌دهد تا هرگونه مزیت دیگری را توجیه کند. علاوه بر این، تیم دریافت که بر اساس اندازه‌گیری زمان راه‌اندازی کارگر سرویس در دستگاه‌های واقعی، توزیع گسترده‌ای از زمان‌های راه‌اندازی وجود دارد، به طوری که برخی از دستگاه‌های تلفن همراه پایین‌رده تقریباً به همان اندازه که ممکن است برای راه‌اندازی سرویسکار زمان صرف می‌کنند. درخواست شبکه برای HTML صفحه نتایج را انجام دهید.
راه حل: از پیش بارگذاری ناوبری استفاده کنید
تنها و مهم‌ترین ویژگی که به تیم جستجوی Google اجازه می‌دهد با راه‌اندازی سرویس‌دهنده خود پیش برود، پیش‌بارگذاری ناوبری است. استفاده از پیش بارگذاری ناوبری یک پیروزی کلیدی در عملکرد برای هر سرویس دهنده ای است که نیاز به استفاده از پاسخ شبکه برای برآورده کردن درخواست های ناوبری دارد. این یک اشاره به مرورگر ارائه می دهد که همزمان با راه اندازی سرویس دهنده، درخواست ناوبری را بلافاصله شروع کند:
تا زمانی که مدت زمان راه‌اندازی کارگر سرویس کمتر از مدت زمانی است که برای دریافت پاسخ از شبکه طول می‌کشد، نباید سربار تاخیری توسط سرویسکار معرفی شود.
تیم جستجو همچنین باید از استفاده از یک سرویس‌دهنده در دستگاه‌های تلفن همراه ارزان‌قیمتی که زمان راه‌اندازی کارگر سرویس می‌تواند از درخواست ناوبری بیشتر باشد، اجتناب کند. از آنجایی که هیچ قانون سخت و سریعی برای اینکه چه چیزی یک دستگاه "پایین" را تشکیل می دهد وجود ندارد، آنها به بررسی اکتشافی کل RAM نصب شده روی دستگاه رسیدند. هر چیزی که کمتر از 2 گیگابایت حافظه داشته باشد در دسته دستگاه های رده پایین آنها قرار می گیرد، جایی که زمان راه اندازی سرویس دهنده غیرقابل قبول است.
فضای ذخیره‌سازی موجود یکی دیگر از موارد مورد توجه است، زیرا مجموعه کامل منابعی که باید برای استفاده در آینده ذخیره شوند، می‌توانند تا چندین مگابایت اجرا شوند. رابط navigator.storage به صفحه جستجوی Google این امکان را می‌دهد تا از قبل بفهمد که آیا تلاش‌های آنها برای ذخیره داده‌ها به دلیل شکست سهمیه ذخیره‌سازی خطر شکست را دارد یا خیر.
این باعث شد که تیم جستجو چندین معیار داشته باشد که آنها می توانند برای تعیین اینکه آیا از یک سرویس دهنده استفاده کنند یا نه استفاده کنند: اگر کاربر با استفاده از مرورگری که از پیش بارگذاری ناوبری پشتیبانی می کند و حداقل 2 گیگابایت حافظه رم دارد به صفحه جستجوی Google می آید. ، و فضای ذخیره سازی رایگان کافی، سپس یک سرویس دهنده ثبت نام می شود . مرورگرها یا دستگاه‌هایی که این معیارها را برآورده نمی‌کنند در نهایت به یک سرویس‌دهنده ختم نمی‌شوند، اما همچنان همان تجربه جستجوی Google را خواهند دید که همیشه داشته‌اند.
یکی از مزیت های جانبی این ثبت نام انتخابی، امکان ارسال یک کارگر خدماتی کوچکتر و کارآمدتر است. هدف قرار دادن مرورگرهای نسبتاً مدرن برای اجرای کد سرویسکار، هزینه‌های سربار انتقال و چند پر کردن مرورگرهای قدیمی‌تر را حذف می‌کند. این منجر به حذف حدود 8 کیلوبایت کد جاوا اسکریپت غیرفشرده از کل حجم پیاده‌سازی کارگر سرویس شد.
مشکل: محدوده کارگر خدمات
هنگامی که تیم جستجو آزمایش‌های تأخیر کافی را انجام داد و مطمئن شد که استفاده از پیش‌بارگذاری ناوبری راهی مناسب و بدون تأخیر را برای استفاده از یک سرویس‌دهنده به آنها ارائه می‌دهد، برخی از مسائل عملی شروع به کار کردند. یکی از این مسائل مربوط به قوانین محدوده کاری کارکنان خدمات است. محدوده یک کارگر خدماتی تعیین می کند که به طور بالقوه می تواند کنترل کدام صفحات را در دست بگیرد.
Scoping بر اساس پیشوند مسیر URL کار می کند. برای دامنه‌هایی که میزبان یک برنامه وب واحد هستند، این یک مشکل نیست، زیرا معمولاً فقط از یک سرویسکار با حداکثر دامنه / استفاده می‌کنید، که می‌تواند کنترل هر صفحه را در دامنه را در اختیار بگیرد. اما ساختار URL جستجوی گوگل کمی پیچیده تر است.
اگر حداکثر دامنه / را به کارمند سرویس داده شود، در نهایت می‌تواند کنترل هر صفحه‌ای را که تحت www.google.com میزبانی می‌شود (یا معادل منطقه‌ای) را در دست بگیرد، و نشانی‌های اینترنتی زیر آن دامنه وجود دارند که هیچ ارتباطی ندارند. با جستجوی گوگل یک محدوده معقول تر و محدودتر /search است که حداقل URL های کاملاً نامرتبط با نتایج جستجو را حذف می کند.
متأسفانه، حتی آن مسیر URL /search در میان رنگ‌های مختلف نتایج جستجوی Google به اشتراک گذاشته می‌شود، با پارامترهای جستجوی URL که نوع خاصی از نتیجه جستجو را تعیین می‌کند. برخی از این طعم‌ها از پایگاه‌های کد کاملاً متفاوتی نسبت به صفحه نتایج جستجوی وب سنتی استفاده می‌کنند. به عنوان مثال، جستجوی تصویر و جستجوی خرید هر دو تحت مسیر URL /search با پارامترهای پرس و جو متفاوت ارائه می‌شوند، اما هیچ یک از این رابط‌ها آماده ارسال تجربه کارگر خدمات خود (هنوز) نبودند.
راه حل: ایجاد یک چارچوب اعزام و مسیریابی
در حالی که برخی پیشنهادات وجود دارد که به چیزی قدرتمندتر از پیشوندهای مسیر URL برای تعیین محدوده سرویسکار اجازه می‌دهد، تیم جستجوی Google در استقرار یک سرویسکار که هیچ کاری برای زیرمجموعه‌ای از صفحات تحت کنترل خود انجام نمی‌داد، گیر کرده بود.
برای حل این مشکل، تیم جستجوی Google یک چارچوب سفارشی ارسال و مسیریابی ایجاد کرد که می‌توان آن را پیکربندی کرد تا معیارهایی مانند پارامترهای پرس و جو صفحه مشتری را بررسی کند و از آنها برای تعیین مسیر کد خاصی استفاده کند. به جای قوانین کدگذاری سخت، این سیستم به گونه‌ای ساخته شده است که انعطاف‌پذیر باشد و به تیم‌هایی که فضای URL را به اشتراک می‌گذارند، مانند جستجوی تصویر و جستجوی خرید، اجازه می‌دهد تا در صورت تصمیم به پیاده‌سازی آن، منطق کارگر خدمات خود را پایین بیاورند.
مشکل: نتایج و معیارهای شخصی سازی شده
کاربران می‌توانند با استفاده از حساب‌های Google خود وارد «جستجوی Google» شوند و تجربه نتایج جستجوی آنها ممکن است بر اساس داده‌های حساب خاص آنها سفارشی شود. کاربرانی که وارد سیستم شده‌اند با کوکی‌های خاص مرورگر شناسایی می‌شوند که استانداردی قابل احترام و پشتیبانی گسترده است.
با این حال، یکی از معایب استفاده از کوکی‌های مرورگر این است که در داخل یک سرویس‌دهنده نمایش داده نمی‌شوند و هیچ راهی برای بررسی خودکار مقادیر آنها و اطمینان از عدم تغییر آنها به دلیل خروج کاربر یا تغییر حساب وجود ندارد. (تلاش‌هایی در حال انجام است تا دسترسی به کوکی‌ها را برای کارکنان خدمات فراهم کند ، اما از زمان نگارش این مقاله، این رویکرد آزمایشی است و به طور گسترده پشتیبانی نمی‌شود.)
عدم تطابق بین دیدگاه کارمند خدمات از کاربر وارد شده فعلی و کاربر واقعی وارد شده به رابط وب جستجوی Google می‌تواند منجر به نتایج جستجوی شخصی‌سازی نادرست یا معیارها و گزارش‌های نادرست نسبت داده شود. هر یک از این سناریوهای شکست برای تیم جستجوی گوگل یک مشکل جدی خواهد بود.
راه حل: ارسال کوکی ها با استفاده از postMessage
تیم جستجوی Google به جای اینکه منتظر راه‌اندازی APIهای آزمایشی باشد و دسترسی مستقیم به کوکی‌های مرورگر را در داخل یک سرویسکار فراهم کند، یک راه‌حل توقف را پیش گرفت: هر زمان که صفحه‌ای که توسط سرویسکار کنترل می‌شود، بارگیری می‌شود، صفحه موارد مربوطه را می‌خواند. کوکی‌ها و از postMessage() برای ارسال آنها به سرویسکار استفاده می‌کند.
سپس کارمند سرویس، مقدار کوکی فعلی را در برابر مقدار مورد انتظارش بررسی می‌کند، و در صورت عدم تطابق، اقداماتی را برای پاک کردن داده‌های خاص کاربر از فضای ذخیره‌سازی آن انجام می‌دهد و صفحه نتایج جستجو را بدون هیچ شخصی‌سازی نادرست بارگیری می‌کند.
مراحل خاصی که کارمند خدمات برای بازنشانی چیزها به یک خط پایه انجام می‌دهد، مربوط به الزامات جستجوی Google است، اما همین رویکرد کلی ممکن است برای توسعه‌دهندگان دیگری که با داده‌های شخصی‌سازی‌شده کلید کوکی‌های مرورگرها سروکار دارند، مفید باشد.
مشکل: آزمایش و پویایی
همانطور که گفته شد، تیم جستجوی گوگل به شدت به اجرای آزمایش‌ها در تولید، و آزمایش اثرات کدها و ویژگی‌های جدید در دنیای واقعی قبل از روشن کردن آنها به صورت پیش‌فرض، متکی است. این می‌تواند کمی چالش‌برانگیز با یک سرویسکار ثابت باشد که به شدت به داده‌های ذخیره شده در حافظه پنهان متکی است، زیرا انتخاب کاربران در آزمایش‌ها و خارج کردن آنها اغلب نیاز به ارتباط با سرور پشتیبان دارد.
راه حل: اسکریپت کارگر سرویس به صورت پویا تولید شده است
راه حلی که تیم به دنبال آن بود، استفاده از یک اسکریپت سرویس کارگر تولید شده به صورت پویا بود که توسط وب سرور برای هر کاربر شخصی سفارشی شده بود، به جای یک اسکریپت کارگر خدمات ثابت که زودتر از موعد تولید می شود. اطلاعات مربوط به آزمایش‌هایی که ممکن است بر رفتار کارمند سرویس یا به طور کلی درخواست‌های شبکه تأثیر بگذارد، مستقیماً در این اسکریپت‌های سرویسکار سفارشی گنجانده شده است. تغییر مجموعه‌های تجربیات فعال برای یک کاربر از طریق ترکیبی از تکنیک‌های سنتی، مانند کوکی‌های مرورگر، و همچنین ارائه کد به‌روز شده در URL ثبت‌شده سرویسکار انجام می‌شود.
استفاده از یک اسکریپت سرویس کارگر ایجاد شده به صورت پویا، ارائه یک دریچه فرار را در صورت بعید به وجود می آورد که اجرای یک سرویسکار دارای یک اشکال مرگبار است که باید از آن اجتناب شود. پاسخ کارگر سرور پویا می‌تواند یک پیاده‌سازی بدون عملیات باشد، که به طور موثر سرویسکار را برای برخی یا همه کاربران فعلی غیرفعال می‌کند.
مشکل: هماهنگی به روز رسانی
یکی از سخت‌ترین چالش‌های پیش روی هر استقرار کارگر خدمات در دنیای واقعی، ایجاد یک معاوضه معقول بین اجتناب از شبکه به نفع حافظه پنهان است، و در عین حال، اطمینان از اینکه کاربران فعلی به‌روزرسانی‌ها و تغییرات حیاتی را بلافاصله پس از استقرار دریافت می‌کنند. به تولید. تعادل مناسب به عوامل زیادی بستگی دارد:
- این که آیا برنامه وب شما یک برنامه تک صفحه ای با عمر طولانی است که کاربر آن را بدون پیمایش به صفحات جدید به طور نامحدود باز نگه می دارد.
- سرعت استقرار برای به روز رسانی به سرور وب پشتیبان شما چیست.
- اینکه آیا کاربر معمولی استفاده از یک نسخه کمی قدیمی از برنامه وب شما را تحمل می کند یا اینکه تازه بودن اولویت اصلی است.
در حین آزمایش با کارکنان خدمات، تیم جستجوی Google مطمئن شد که آزمایش‌ها را در تعدادی از به‌روزرسانی‌های برنامه‌ریزی‌شده پشتیبان اجرا می‌کند تا اطمینان حاصل شود که معیارها و تجربه کاربر با آنچه کاربران بازگشتی در دنیای واقعی مشاهده می‌کنند، بیشتر مطابقت دارند.
راه حل: ایجاد تعادل در تازگی و استفاده از حافظه پنهان
پس از آزمایش تعدادی از گزینه‌های پیکربندی مختلف، تیم جستجوی Google دریافت که راه‌اندازی زیر تعادل مناسبی بین تازگی و استفاده از حافظه پنهان فراهم می‌کند.
نشانی وب اسکریپت کارگر سرویس با سربرگ پاسخ Cache-Control: private, max-age=1500 (1500 ثانیه یا 25 دقیقه) ارائه می‌شود و با updateViaCache که روی «all» تنظیم شده است ثبت می‌شود تا اطمینان حاصل شود که سرصفحه مورد احترام قرار می‌گیرد. همانطور که ممکن است تصور کنید، پشتیبان وب جستجوی Google مجموعه ای بزرگ و توزیع شده در سطح جهانی از سرورها است که تا حد امکان به 100٪ آپتایم نیاز دارد. استقرار تغییری که بر محتوای اسکریپت کارمند سرویس تأثیر بگذارد، به صورت متحرک انجام می شود.
اگر کاربر به بک‌ندی که به‌روزرسانی شده است ضربه بزند، و سپس به سرعت به صفحه دیگری بروید که به پشتیبانی که هنوز سرویسکار به‌روزرسانی‌شده را دریافت نکرده است، می‌رود، در نهایت چندین بار بین نسخه‌ها فلیپ فلاپ می‌شود. بنابراین، گفتن به مرورگر که فقط در صورتی که 25 دقیقه از آخرین بررسی گذشته است، برای بررسی یک اسکریپت به‌روز شده زحمت بکشد، منفی قابل توجهی ندارد. نکته مثبت شرکت در این رفتار کاهش قابل توجه ترافیک دریافتی توسط نقطه پایانی است که به صورت پویا اسکریپت Service Worker را تولید می کند.
علاوه بر این، یک هدر ETag بر روی پاسخ HTTP اسکریپت کارگر سرویس تنظیم می‌شود و اطمینان حاصل می‌کند که وقتی بررسی به‌روزرسانی پس از گذشت 25 دقیقه انجام می‌شود، سرور می‌تواند به طور موثر با یک پاسخ HTTP 304 پاسخ دهد اگر به‌روزرسانی‌هایی برای سرویس وجود نداشته باشد. کارگر مستقر در این دوره
در حالی که برخی از تعاملات در برنامه وب جستجوی Google از پیمایش های سبک برنامه تک صفحه ای استفاده می کنند (یعنی از طریق History API )، در بیشتر موارد، جستجوی Google یک برنامه وب سنتی است که از پیمایش های "واقعی" استفاده می کند. وقتی تیم تصمیم گرفت که استفاده از دو گزینه که چرخه عمر به‌روزرسانی کارگر سرویس را تسریع می‌بخشد مؤثر است: clients.claim() و skipWaiting() . با کلیک بر روی رابط جستجوی Google معمولاً به اسناد HTML جدید هدایت می شوید. تماس با skipWaiting تضمین می‌کند که یک سرویسکار به‌روزرسانی شده فرصتی برای رسیدگی به درخواست‌های ناوبری جدید بلافاصله پس از نصب پیدا می‌کند. به طور مشابه، فراخوانی clients.claim() به این معنی است که سرویسکار به‌روزرسانی‌شده این فرصت را پیدا می‌کند که پس از فعال‌سازی سرویسکار، شروع به کنترل هر صفحه جستجوی باز Google که کنترل نشده است، کند.
رویکردی که «جستجوی Google» با آن پیش رفت، لزوماً راه‌حلی نیست که برای همه کارآیی داشته باشد، بلکه نتیجه آزمایش دقیق A/B ترکیب‌های مختلف گزینه‌های ارائه‌شده بود تا زمانی که آنها بهترین کار را برای آنها پیدا کردند. توسعه‌دهندگانی که زیرساخت‌های پشتیبان به آنها اجازه می‌دهد به‌روزرسانی‌ها را سریع‌تر اجرا کنند، ممکن است ترجیح دهند که مرورگر اسکریپت‌های به‌روزرسانی‌شده سرویسکار را تا حد امکان با نادیده گرفتن کش HTTP بررسی کند. اگر در حال ساخت یک برنامه تک صفحه ای هستید که کاربران ممکن است برای مدت طولانی باز نگه دارند، احتمالاً استفاده از skipWaiting() انتخاب مناسبی برای شما نیست - اگر به سرویس دهنده جدید اجازه فعال کردن را بدهید ، در خطر مواجه شدن با ناسازگاری حافظه پنهان قرار خواهید داشت. در حالی که مشتریان با عمر طولانی وجود دارد.
خوراکی های کلیدی
به‌طور پیش‌فرض، کارگران خدماتی عملکرد خنثی ندارند
افزودن یک سرویس دهنده به برنامه وب شما به معنای وارد کردن یک قطعه جاوا اسکریپت اضافی است که باید قبل از اینکه برنامه وب شما به درخواست های خود پاسخ دهد، بارگیری و اجرا شود. اگر این پاسخ‌ها در نهایت از یک حافظه پنهان محلی به جای شبکه دریافت شوند، در آن صورت هزینه سربار اجرای سرویسکار معمولاً در مقایسه با برنده عملکردی که در ابتدا به حافظه پنهان می‌رسد ناچیز است. اما اگر می‌دانید که کارمند خدمات شما همیشه باید هنگام رسیدگی به درخواست‌های ناوبری با شبکه مشورت کند، استفاده از پیش‌بارگذاری ناوبری یک پیروزی مهم در عملکرد است.
کارگران خدمات (هنوز!) یک پیشرفت پیشرونده هستند
داستان پشتیبانی کارکنان خدمات امروز بسیار روشن تر از یک سال پیش است. همه مرورگرهای مدرن در حال حاضر حداقل از برخی از قابلیت‌های سرویس‌دهنده پشتیبانی می‌کنند، اما متأسفانه، برخی از ویژگی‌های سرویسکار پیشرفته - مانند همگام‌سازی پس‌زمینه و پیش‌بارگذاری ناوبری - وجود دارد که به‌طور جهانی عرضه نشده‌اند. بررسی ویژگی‌ها برای زیرمجموعه خاصی از ویژگی‌هایی که می‌دانید به آنها نیاز دارید، و فقط ثبت‌نام یک کارگر خدماتی زمانی که آنها حضور دارند، هنوز یک رویکرد معقول است.
به طور مشابه، اگر آزمایش‌هایی را در طبیعت انجام داده‌اید و می‌دانید که دستگاه‌های ارزان قیمت با سربار اضافی یک کارگر خدمات ضعیف عمل می‌کنند، می‌توانید در آن سناریوها نیز از ثبت نام کارگر خدمات خودداری کنید.
شما باید به کارکنان خدماتی به‌عنوان یک پیشرفت پیشرونده نگاه کنید که زمانی به یک برنامه وب اضافه می‌شود که همه پیش‌نیازها برآورده شوند و کارمند خدمات چیز مثبتی به تجربه کاربر و عملکرد کلی بارگیری اضافه کند.
همه چیز را اندازه گیری کنید
تنها راهی که می توانید بفهمید حمل و نقل یک کارگر خدماتی تأثیر مثبت یا منفی بر تجربیات کاربران شما داشته است، آزمایش و اندازه گیری نتایج است.
ویژگی‌های تنظیم اندازه‌گیری‌های معنی‌دار به ارائه‌دهنده تجزیه و تحلیلی که استفاده می‌کنید و اینکه معمولاً چگونه آزمایش‌ها را در تنظیم استقرار خود انجام می‌دهید بستگی دارد. یکی از رویکردها، استفاده از Google Analytics برای جمع‌آوری معیارها، در این مطالعه موردی بر اساس تجربه استفاده از سرویس‌دهندگان در برنامه وب Google I/O توضیح داده شده است.
بدون گل
در حالی که بسیاری از افراد در جامعه توسعه وب، کارکنان خدمات را با برنامه‌های وب پیشرفته مرتبط می‌کنند، ساختن «Google Search PWA» هدف اولیه تیم نبود. برنامه وب «جستجوی Google» در حال حاضر متادیتا را از طریق مانیفست برنامه وب ارائه نمی‌کند و کاربران را تشویق نمی‌کند که از جریان «افزودن به صفحه اصلی» عبور کنند. تیم جستجو در حال حاضر از ورود کاربران به برنامه وب خود از طریق نقاط ورودی سنتی برای جستجوی Google راضی است.
به جای تلاش برای تبدیل تجربه وب جستجوی Google به چیزی معادل آنچه از یک برنامه نصب شده انتظار دارید، تمرکز بر روی عرضه اولیه بر بهبود تدریجی وب سایت موجود بود.
سپاسگزاریها
از کل تیم توسعه وب جستجوی Google برای کارشان بر روی پیاده‌سازی سرویس‌دهنده، و برای به اشتراک گذاشتن مطالب پیش‌زمینه‌ای که برای نوشتن این مقاله انجام شد، تشکر می‌کنیم. تشکر ویژه از فیلیپ گول، راجش جاگاناتان، آر. ساموئل کلاچکو، اندی مارتونه، لئوناردو پنیا، ریچل شیرر، گرگ ترونو، و کلی وولام.
به‌روزرسانی (اکتبر 2021): از آنجایی که این مقاله در ابتدا منتشر شد، تیم جستجوی Google مزایا و معاوضه‌های معماری فعلی سرویسکار خود را مورد ارزیابی مجدد قرار داده است. کارمند خدماتی که در بالا توضیح داده شد در حال بازنشستگی است. همانطور که زیرساخت وب جستجوی Google در حال تکامل است، تیم ممکن است طراحی سرویس کار خود را دوباره بررسی کند.