เรื่องราวเกี่ยวกับสิ่งที่เผยแพร่ วิธีวัดผลลัพธ์ และข้อเสียที่เกิดขึ้น
ข้อมูลเบื้องต้น
ค้นหาหัวข้อใดก็ได้ใน Google แล้วคุณจะเห็นหน้าผลการค้นหาที่เกี่ยวข้องและมีความหมายซึ่งจดจำได้ทันที สิ่งที่คุณอาจไม่ทราบคือหน้าผลการค้นหานี้แสดงโดยเทคโนโลยีเว็บที่มีประสิทธิภาพที่เรียกว่าService Worker ในบางสถานการณ์
การเปิดตัวการรองรับ Service Worker สําหรับ Google Search โดยไม่ส่งผลเสียต่อประสิทธิภาพนั้นต้องใช้วิศวกรหลายสิบคนทํางานในหลายทีม นี่เป็นเรื่องราวเกี่ยวกับสิ่งที่เผยแพร่ วิธีวัดประสิทธิภาพ และสิ่งที่เสียสละ
เหตุผลสําคัญในการสํารวจ Service Worker
การเพิ่ม Service Worker ลงในเว็บแอปควรทำโดยมีเป้าหมายที่ชัดเจนเช่นเดียวกับการเปลี่ยนแปลงโครงสร้างเว็บไซต์ ทีม Google Search พบว่ามีเหตุผลสำคัญ 2-3 ข้อที่ควรลองใช้ Service Worker
การแคชผลการค้นหาแบบจำกัด
ทีม Google Search พบว่าผู้ใช้มักค้นหาคำเดียวกันมากกว่า 1 ครั้งภายในระยะเวลาสั้นๆ ทีม Search ต้องการใช้ประโยชน์จากการแคชและดำเนินการตามคำขอซ้ำเหล่านั้นในเครื่องแทนที่จะทริกเกอร์คำขอแบ็กเอนด์ใหม่เพื่อรับสิ่งที่มีแนวโน้มจะเป็นผลลัพธ์เดียวกัน
ความสำคัญของความใหม่นั้นไม่ควรมองข้าม และบางครั้งผู้ใช้ก็ค้นหาคำเดียวกันซ้ำๆ เนื่องจากเป็นหัวข้อที่มีการเปลี่ยนแปลงอยู่เสมอ และผู้ใช้คาดหวังว่าจะเห็นผลการค้นหาใหม่ การใช้ Service Worker ช่วยให้ทีม Search สามารถใช้ตรรกะแบบละเอียดเพื่อควบคุมอายุของผลการค้นหาที่แคชไว้ในพื้นที่ และรักษาสมดุลระหว่างความเร็วกับความใหม่อย่างแม่นยำ ซึ่งทีมเชื่อว่าจะเป็นประโยชน์ต่อผู้ใช้มากที่สุด
ประสบการณ์การใช้งานแบบออฟไลน์ที่มีประโยชน์
นอกจากนี้ ทีม Google Search ยังต้องการมอบประสบการณ์การใช้งานแบบออฟไลน์ที่มีประโยชน์ เมื่อต้องการค้นหาข้อมูลเกี่ยวกับหัวข้อหนึ่งๆ ผู้ใช้ต้องการไปที่หน้า Google Search โดยตรงและเริ่มค้นหาโดยไม่ต้องกังวลเกี่ยวกับการเชื่อมต่ออินเทอร์เน็ต
หากไม่มี Service Worker การไปที่หน้าค้นหาของ Google ขณะออฟไลน์จะนําไปยังหน้าข้อผิดพลาดเกี่ยวกับเครือข่ายมาตรฐานของเบราว์เซอร์ และผู้ใช้จะต้องจดจําไว้ว่าต้องกลับมาลองอีกครั้งเมื่อการเชื่อมต่อกลับมาทำงานอีกครั้ง Service Worker ช่วยให้คุณแสดงการตอบกลับ HTML ออฟไลน์ที่กําหนดเองได้ และอนุญาตให้ผู้ใช้ป้อนข้อความค้นหาได้ทันที
ผลลัพธ์จะยังไม่พร้อมใช้งานจนกว่าจะมีการเชื่อมต่ออินเทอร์เน็ต แต่ Service Worker จะช่วยให้เลื่อนการค้นหาและส่งไปยังเซิร์ฟเวอร์ของ Google ได้ทันทีที่อุปกรณ์กลับมาออนไลน์โดยใช้ Background Sync API
การแคชและการแสดง JavaScript ที่ชาญฉลาดยิ่งขึ้น
อีกเหตุผลหนึ่งคือการเพิ่มประสิทธิภาพการแคชและโหลดโค้ด JavaScript แบบโมดูลที่ขับเคลื่อนฟีเจอร์ประเภทต่างๆ ในหน้าผลการค้นหา การรวม JavaScript มีประโยชน์หลายอย่างเมื่อไม่มี Service Worker เข้ามาเกี่ยวข้อง ทีม Search จึงไม่ได้ต้องการหยุดการรวมทั้งหมด
ทีม Search คาดหวังว่าการใช้ความสามารถของ Service Worker ในการจัดเวอร์ชันและแคช JavaScript ในส่วนเล็กๆ ที่ละเอียดในรันไทม์จะช่วยลดความผันผวนของแคชและทำให้แคช JavaScript ที่นํามาใช้ซ้ำในอนาคตได้อย่างมีประสิทธิภาพ ตรรกะภายใน Service Worker สามารถวิเคราะห์คําขอ HTTP ที่ส่งออกสําหรับกลุ่มที่มีโมดูล JavaScript หลายรายการ และดําเนินการตามคําขอโดยการรวบรวมโมดูลที่แคชไว้ในพื้นที่หลายรายการเข้าด้วยกัน ซึ่งจะทําให้ "การแยกกลุ่ม" เป็นไปอย่างมีประสิทธิภาพเมื่อเป็นไปได้ ซึ่งจะช่วยประหยัดแบนด์วิดท์ของผู้ใช้และปรับปรุงการตอบสนองโดยรวม
นอกจากนี้ การใช้ JavaScript ที่แคชไว้ซึ่งให้บริการโดย Service Worker ยังให้ประโยชน์ด้านประสิทธิภาพด้วย ใน Chrome ระบบจะจัดเก็บและนำการนําเสนอโค้ดไบต์ที่แยกวิเคราะห์แล้วของ JavaScript นั้นมาใช้ซ้ำ ซึ่งทำให้ต้องทํางานน้อยลงเมื่อรันไทม์เพื่อเรียกใช้ JavaScript ในหน้าเว็บ
ปัญหาและวิธีแก้ปัญหา
ต่อไปนี้คืออุปสรรคบางส่วนที่ต้องเอาชนะเพื่อให้บรรลุเป้าหมายที่ทีมได้ระบุไว้ แม้ว่าความท้าทายบางอย่างเหล่านี้จะเกี่ยวข้องกับ Google Search โดยเฉพาะ แต่ก็มีอีกหลายอย่างที่ใช้ได้กับเว็บไซต์หลากหลายประเภทที่อาจพิจารณาการใช้ Service Worker
ปัญหา: ค่าใช้จ่ายเพิ่มเติมของ Service Worker
ปัญหาที่ใหญ่ที่สุดและอุปสรรคสำคัญในการเปิดใช้งาน Service Worker ใน Google Search คือต้องตรวจสอบว่า Service Worker ไม่ได้ทําสิ่งใดที่อาจเพิ่มเวลาในการตอบสนองที่ผู้ใช้รับรู้ Google Search ให้ความสำคัญกับประสิทธิภาพอย่างยิ่ง และที่ผ่านมาได้บล็อกการเปิดตัวฟังก์ชันการทำงานใหม่หากทำให้เวลาในการตอบสนองเพิ่มขึ้นเพียงไม่กี่สิบมิลลิวินาทีสำหรับผู้ใช้กลุ่มหนึ่งๆ
เมื่อทีมเริ่มรวบรวมข้อมูลประสิทธิภาพระหว่างการทดสอบครั้งแรกๆ ก็เห็นได้ชัดว่าจะเกิดปัญหา HTML ที่แสดงผลเพื่อตอบสนองคำขอการไปยังส่วนต่างๆของหน้าผลการค้นหาเป็นแบบไดนามิกและแตกต่างกันอย่างมากโดยขึ้นอยู่กับตรรกะที่จำเป็นต้องทำงานในเว็บเซิร์ฟเวอร์ของ Search ปัจจุบัน Service Worker ไม่สามารถจำลองตรรกะนี้และแสดง HTML ที่แคชไว้ได้ทันที สิ่งที่ทำได้ดีที่สุดคือส่งต่อคำขอไปยังเว็บเซิร์ฟเวอร์แบ็กเอนด์ ซึ่งจำเป็นต้องมีการส่งคำขอผ่านเครือข่าย
หากไม่มี Service Worker คำขอเครือข่ายนี้จะเกิดขึ้นทันทีเมื่อผู้ใช้ไปยังส่วนต่างๆ เมื่อลงทะเบียน Service Worker แล้ว จะต้องเริ่มต้นใช้งานเสมอและเปิดโอกาสให้ดำเนินการfetch ตัวแฮนเดิลเหตุการณ์ แม้ว่าจะไม่มีโอกาสที่ตัวแฮนเดิลการดึงข้อมูลเหล่านั้นจะทำสิ่งใดนอกเหนือจากการไปที่เครือข่าย ระยะเวลาที่ใช้ในการเริ่มต้นและเรียกใช้โค้ดบริการ worker คือเวลาในการดำเนินการเพิ่มเติมทั้งหมดที่เพิ่มไว้ด้านบนของการนำทางแต่ละครั้ง
การดำเนินการนี้ทำให้การใช้งาน Service Worker เสียเปรียบมากจนไม่คุ้มค่ากับประโยชน์อื่นๆ นอกจากนี้ ทีมยังพบว่าเวลาเริ่มต้นของ Service Worker นั้นแตกต่างกันไปมาก โดยอุปกรณ์เคลื่อนที่ระดับล่างบางรุ่นใช้เวลาในการเริ่มต้น Service Worker เกือบเท่ากับเวลาที่ใช้ในการส่งคำขอเครือข่ายสำหรับ HTML ของหน้าผลการค้นหา
โซลูชัน: ใช้การโหลดการนำทางล่วงหน้า
ฟีเจอร์เดียวที่สำคัญที่สุดซึ่งช่วยให้ทีม Google Search เปิดตัว Service Worker ได้คือการโหลดหน้าเว็บล่วงหน้า การใช้การโหลดล่วงหน้าสำหรับการนําทางเป็นปัจจัยสําคัญที่ช่วยให้ประสิทธิภาพดีขึ้นสําหรับ Service Worker ที่ต้องใช้การตอบกลับจากเครือข่ายเพื่อตอบสนองคําขอการนําทาง ซึ่งจะบอกใบ้ให้เบราว์เซอร์เริ่มส่งคำขอไปยังส่วนต่างๆ ทันที ในเวลาเดียวกับที่ Service Worker เริ่มทำงาน
ตราบใดที่เวลาเริ่มต้นการทำงานของ Service Worker น้อยกว่าเวลาที่ใช้ในการรับการตอบกลับจากเครือข่าย Service Worker ไม่ควรทำให้เกิดเวลาในการตอบสนองที่เพิ่มขึ้น
ทีม Search ยังต้องหลีกเลี่ยงการใช้ Service Worker ในอุปกรณ์เคลื่อนที่ระดับล่างที่เวลาบูต Service Worker อาจนานกว่าคำขอไปยังส่วนต่างๆ เนื่องจากไม่มีกฎตายตัวว่าอุปกรณ์ "ระดับล่าง" คืออะไร ทีมจึงใช้วิธีการเฮิวริสติกในการตรวจสอบ RAM ทั้งหมดที่ติดตั้งในอุปกรณ์ หน่วยความจำที่น้อยกว่า 2 กิกะไบต์จะจัดอยู่ในหมวดหมู่อุปกรณ์ระดับล่าง ซึ่งเวลาเริ่มต้นของ Service Worker จะยอมรับไม่ได้
พื้นที่เก็บข้อมูลที่มีอยู่ก็เป็นอีกสิ่งหนึ่งที่ต้องพิจารณา เนื่องจากชุดทรัพยากรทั้งหมดที่จะแคชไว้ใช้ในอนาคตอาจมีขนาดหลายเมกะไบต์ อินเทอร์เฟซ navigator.storage ช่วยให้หน้า Google Search ทราบล่วงหน้าว่าความพยายามในการแคชข้อมูลมีความเสี่ยงที่จะล้มเหลวเนื่องจากโควต้าพื้นที่เก็บข้อมูลไม่เพียงพอหรือไม่
ด้วยเหตุนี้ ทีม Search จึงมีเกณฑ์หลายรายการที่สามารถใช้เพื่อพิจารณาว่าจะใช้งาน Service Worker หรือไม่ โดยหากผู้ใช้มาที่หน้า Google Search โดยใช้เบราว์เซอร์ที่รองรับการโหลดนำทางล่วงหน้า และมี RAM อย่างน้อย 2 กิกะไบต์ รวมถึงมีพื้นที่เก็บข้อมูลว่างเพียงพอ ระบบจะลงทะเบียน Service Worker เบราว์เซอร์หรืออุปกรณ์ที่ไม่เป็นไปตามเกณฑ์ดังกล่าวจะไม่แสดงผลลัพธ์จากบริการดังกล่าว แต่ผู้ใช้จะยังคงเห็นประสบการณ์การใช้งาน Google Search เหมือนเดิม
ประโยชน์อย่างหนึ่งของการลงทะเบียนแบบเลือกนี้คือความสามารถในการจัดส่ง Service Worker ที่เล็กลงและมีประสิทธิภาพมากขึ้น การกําหนดเป้าหมายเบราว์เซอร์ที่ค่อนข้างทันสมัยเพื่อเรียกใช้โค้ด Service Worker จะช่วยประหยัดค่าใช้จ่ายในการแปลงโค้ดและ Polyfill สําหรับเบราว์เซอร์รุ่นเก่า การดำเนินการนี้ทำให้โค้ด JavaScript ที่ไม่ผ่านการบีบอัดประมาณ 8 KB หายไปจากขนาดรวมของการใช้งาน Service Worker
ปัญหา: ขอบเขต Service Worker
เมื่อทีม Search ทำการทดสอบเวลาในการตอบสนองมากพอและมั่นใจว่าการใช้การโหลดหน้าเว็บล่วงหน้าเป็นเส้นทางที่ใช้งานได้จริงและไม่มีเวลาในการตอบสนองสำหรับการใช้ Service Worker แล้ว ปัญหาในทางปฏิบัติบางอย่างก็เริ่มปรากฏขึ้น ปัญหาหนึ่งเกี่ยวข้องกับกฎการกําหนดขอบเขตของ Service Worker ขอบเขตของ Service Worker จะกําหนดหน้าเว็บที่อาจควบคุมได้
การกําหนดขอบเขตจะทํางานตามคํานําหน้าเส้นทาง URL สําหรับโดเมนที่โฮสต์เว็บแอปเดียว ปัญหานี้จะไม่เกิดขึ้น เนื่องจากปกติแล้วคุณจะใช้ Service Worker ที่มีขอบเขตสูงสุดของ / ซึ่งสามารถควบคุมหน้าเว็บใดก็ได้ในโดเมน
แต่โครงสร้าง URL ของ Google Search มีความซับซ้อนกว่าเล็กน้อย
หาก Service Worker ได้รับขอบเขตสูงสุดของ / สุดท้ายแล้ว Service Worker จะควบคุมหน้าเว็บที่โฮสต์ภายใต้ www.google.com (หรือโดเมนเทียบเท่าระดับภูมิภาค) ได้ และจะมี URL ภายใต้โดเมนนั้นซึ่งไม่เกี่ยวข้องกับ Google Search ขอบเขตที่จำกัดและสมเหตุสมผลมากกว่าคือ /search ซึ่งอย่างน้อยก็จะนำ URL ที่ไม่เกี่ยวข้องกับผลการค้นหาโดยสิ้นเชิงออก
ขออภัย แม้แต่เส้นทาง URL /search ดังกล่าวก็มีการแชร์กันระหว่างผลการค้นหาของ Google Search รูปแบบต่างๆ โดยมีพารามิเตอร์การค้นหาของ URL เป็นตัวกำหนดประเภทผลการค้นหาที่เฉพาะเจาะจงที่จะแสดง เวอร์ชันย่อยบางเวอร์ชันใช้ฐานโค้ดที่แตกต่างจากหน้าผลการค้นหาบนเว็บแบบดั้งเดิมอย่างสิ้นเชิง ตัวอย่างเช่น ทั้งการค้นหารูปภาพและการค้นหา Shopping แสดงภายใต้เส้นทาง URL /search ที่มีพารามิเตอร์การค้นหาที่แตกต่างกัน แต่อินเทอร์เฟซทั้ง 2 รายการยังไม่พร้อมให้บริการประสบการณ์การใช้งาน Service Worker ของตนเอง (ในตอนนี้)
โซลูชัน: สร้างเฟรมเวิร์กการส่งและการกำหนดเส้นทาง
แม้ว่าจะมีข้อเสนอบางอย่างที่อนุญาตให้ใช้สิ่งที่มีประสิทธิภาพมากกว่าคำนำหน้าเส้นทาง URL เพื่อกำหนดขอบเขต Service Worker แต่ทีม Google Search ก็ติดขัดในการติดตั้งใช้งาน Service Worker ที่ไม่ได้ทําอะไรกับหน้าเว็บชุดย่อยที่ควบคุม
ทีม Google Search จึงสร้างเฟรมเวิร์กการส่งและการกำหนดเส้นทางที่ออกแบบมาโดยเฉพาะ ซึ่งสามารถกําหนดค่าให้ตรวจสอบเกณฑ์ต่างๆ เช่น พารามิเตอร์การค้นหาของหน้าไคลเอ็นต์ และใช้เกณฑ์เหล่านั้นเพื่อกําหนดเส้นทางโค้ดที่เฉพาะเจาะจง ระบบสร้างขึ้นให้มีความยืดหยุ่นและอนุญาตให้ทีมที่แชร์พื้นที่ URL เช่น ค้นรูปและ Shopping Search ใส่ตรรกะ Service Worker ของตนเองได้ในอนาคต หากตัดสินใจที่จะใช้งาน
ปัญหา: ผลการค้นหาและเมตริกที่ปรับเปลี่ยนในแบบของคุณ
ผู้ใช้สามารถลงชื่อเข้าใช้ Google Search โดยใช้บัญชี Google และระบบอาจปรับแต่งประสบการณ์ผลการค้นหาตามข้อมูลบัญชีของผู้ใช้ ระบบจะระบุผู้ใช้ที่เข้าสู่ระบบด้วยคุกกี้เบราว์เซอร์ที่เฉพาะเจาะจง ซึ่งเป็นมาตรฐานที่เก่าแก่และได้รับการรองรับอย่างกว้างขวาง
ข้อเสียอย่างหนึ่งของการใช้คุกกี้เบราว์เซอร์คือคุกกี้จะไม่แสดงใน Service Worker และไม่มีวิธีตรวจสอบค่าโดยอัตโนมัติและตรวจสอบว่าค่าเหล่านั้นไม่เปลี่ยนแปลงเนื่องจากผู้ใช้ออกจากระบบหรือเปลี่ยนบัญชี (เรากําลังพยายามเพิ่มสิทธิ์เข้าถึงคุกกี้ให้กับ Service Worker แต่ ณ เวลาที่เขียนนี้ แนวทางดังกล่าวยังอยู่ในขั้นทดลองและยังไม่ได้รับการรองรับอย่างกว้างขวาง)
ความไม่ตรงกันระหว่างมุมมองของ Service Worker เกี่ยวกับผู้ใช้ที่เข้าสู่ระบบอยู่ในปัจจุบันกับผู้ใช้จริงที่เข้าสู่ระบบเว็บอินเทอร์เฟซของ Google Search อาจส่งผลให้ผลการค้นหาที่ปรับเปลี่ยนในแบบของคุณไม่ถูกต้อง หรือเมตริกและการบันทึกที่ระบุแหล่งที่มาไม่ถูกต้อง สถานการณ์ที่เกิดความล้มเหลวเหล่านี้จะเป็นปัญหาร้ายแรงสำหรับทีม Google Search
โซลูชัน: ส่งคุกกี้โดยใช้ postMessage
แทนที่จะรอให้ API เวอร์ชันทดลองเปิดตัวและให้การเข้าถึงคุกกี้ของเบราว์เซอร์โดยตรงภายใน Service Worker ทีม Google Search จึงเลือกใช้วิธีแก้ปัญหาชั่วคราว ซึ่งก็คือเมื่อโหลดหน้าเว็บที่ Service Worker ควบคุม หน้าเว็บจะอ่านคุกกี้ที่เกี่ยวข้องและใช้ postMessage() เพื่อส่งไปยัง Service Worker
จากนั้น Service Worker จะตรวจสอบค่าคุกกี้ปัจจุบันกับค่าที่คาดไว้ และหากไม่ตรงกัน ก็จะดำเนินการตามขั้นตอนเพื่อล้างข้อมูลเฉพาะผู้ใช้ออกจากพื้นที่เก็บข้อมูล และโหลดหน้าผลการค้นหาอีกครั้งโดยไม่มีการปรับโฆษณาตามโปรไฟล์ของผู้ใช้ที่ไม่ถูกต้อง
ขั้นตอนที่เฉพาะเจาะจงที่ Service Worker ใช้เพื่อรีเซ็ตทุกอย่างเป็นค่าเริ่มต้นนั้นขึ้นอยู่กับข้อกําหนดของ Google Search แต่แนวทางทั่วไปเดียวกันนี้อาจเป็นประโยชน์สําหรับนักพัฒนาซอฟต์แวร์รายอื่นๆ ที่จัดการกับข้อมูลที่ปรับเปลี่ยนในแบบของคุณซึ่งอิงตามคีย์ของคุกกี้เบราว์เซอร์
ปัญหา: การทดสอบและการเปลี่ยนแปลง
ดังที่ได้กล่าวไว้ก่อนหน้านี้ ทีม Google Search อาศัยการทดสอบในเวอร์ชันที่ใช้งานจริงเป็นอย่างมาก รวมถึงทดสอบผลของโค้ดและฟีเจอร์ใหม่ในชีวิตจริงก่อนที่จะเปิดใช้โดยค่าเริ่มต้น การดำเนินการนี้อาจเป็นเรื่องยากสำหรับ Service Worker แบบคงที่ซึ่งอาศัยข้อมูลที่แคชไว้เป็นอย่างมาก เนื่องจากการเลือกให้ผู้ใช้เข้าร่วมหรือออกจากการทดสอบมักต้องมีการสื่อสารกับเซิร์ฟเวอร์แบ็กเอนด์
โซลูชัน: สคริปต์ Service Worker ที่สร้างขึ้นแบบไดนามิก
โซลูชันที่ทีมเลือกใช้คือการใช้สคริปต์ Service Worker ที่สร้างขึ้นแบบไดนามิก ซึ่งเว็บเซิร์ฟเวอร์จะปรับแต่งให้ผู้ใช้แต่ละรายแทนที่จะใช้สคริปต์ Service Worker แบบคงที่รายการเดียวที่สร้างไว้ล่วงหน้า ข้อมูลเกี่ยวกับการทดสอบที่อาจส่งผลต่อลักษณะการทํางานของ Service Worker หรือคําขอเครือข่ายโดยทั่วไปจะรวมอยู่ในสคริปต์ Service Worker ที่กําหนดค่าเองนี้โดยตรง การเปลี่ยนชุดประสบการณ์การใช้งานที่ใช้งานอยู่สําหรับผู้ใช้ทําได้โดยใช้เทคนิคแบบดั้งเดิมหลายอย่าง เช่น คุกกี้เบราว์เซอร์ รวมถึงการแสดงโค้ดที่อัปเดตแล้วใน URL ของ Service Worker ที่ลงทะเบียน
การใช้สคริปต์ Service Worker ที่สร้างขึ้นแบบไดนามิกยังช่วยให้ระบุทางออกได้ง่ายขึ้นในกรณีที่การใช้งาน Service Worker พบข้อบกพร่องร้ายแรงที่ควรหลีกเลี่ยง การตอบสนองของเซิร์ฟเวอร์แบบไดนามิกสำหรับ Service Worker อาจไม่มีการใช้งาน ซึ่งจะปิดใช้ Service Worker สำหรับผู้ใช้ปัจจุบันบางส่วนหรือทั้งหมดอย่างมีประสิทธิภาพ
ปัญหา: การประสานงานการอัปเดต
หนึ่งในความท้าทายที่ยากที่สุดซึ่งต้องเผชิญกับการใช้งาน Service Worker ในชีวิตจริงคือการหาจุดสมดุลที่เหมาะสมระหว่างการหลีกเลี่ยงเครือข่ายเพื่อใช้แคช และขณะเดียวกันก็ช่วยให้ผู้ใช้ปัจจุบันได้รับอัปเดตและการเปลี่ยนแปลงที่สำคัญไม่นานหลังจากที่มีการนำไปใช้งานจริง ความสมดุลที่เหมาะสมขึ้นอยู่กับปัจจัยหลายประการ ดังนี้
- เว็บแอปของคุณเป็น Single Page App ที่ใช้ได้นานซึ่งผู้ใช้เปิดไว้อย่างไม่มีกำหนดโดยไม่มีการไปยังหน้าใหม่หรือไม่
- ความถี่ในการติดตั้งใช้งานสำหรับการอัปเดตเว็บเซิร์ฟเวอร์แบ็กเอนด์
- ผู้ใช้ทั่วไปจะทนใช้เว็บแอปเวอร์ชันที่ล้าสมัยไปเล็กน้อยหรือไม่ หรือความใหม่เป็นสิ่งสำคัญที่สุด
ขณะทดสอบ Service Worker ทีม Google Search ได้ตรวจสอบว่าการทดสอบทำงานอยู่เสมอในการอัปเดตแบ็กเอนด์ตามกำหนดการหลายรายการ เพื่อให้มั่นใจว่าเมตริกและประสบการณ์ของผู้ใช้จะตรงกับสิ่งที่ผู้ใช้จะเห็นในชีวิตจริงมากขึ้น
โซลูชัน: รักษาสมดุลระหว่างความใหม่กับการใช้แคช
หลังจากทดสอบตัวเลือกการกําหนดค่าต่างๆ หลายรายการแล้ว ทีม Google Search พบว่าการตั้งค่าต่อไปนี้ให้ความสมดุลที่เหมาะสมระหว่างความใหม่กับการใช้แคช
URL สคริปต์ Service Worker จะแสดงพร้อมกับส่วนหัวการตอบกลับ Cache-Control: private, max-age=1500 (1,500 วินาทีหรือ 25 นาที) และลงทะเบียนโดยตั้งค่า updateViaCache เป็น "all" เพื่อให้แน่ใจว่าระบบจะใช้ส่วนหัวดังกล่าว แบ็กเอนด์ของเว็บ Google Search เป็นชุดเซิร์ฟเวอร์ขนาดใหญ่ที่กระจายอยู่ทั่วโลก ซึ่งจำเป็นต้องมีเวลาทำงานใกล้เคียงกับ 100% มากที่สุด การนำการเปลี่ยนแปลงที่จะส่งผลต่อเนื้อหาของสคริปต์ Service Worker มาใช้จะทยอยดำเนินการ
หากผู้ใช้เข้าถึงแบ็กเอนด์ที่อัปเดตแล้ว จากนั้นไปยังหน้าอื่นอย่างรวดเร็วซึ่งเข้าถึงแบ็กเอนด์ที่ยังไม่ได้ Service Worker ที่อัปเดต ผู้ใช้จะสลับไปมาระหว่างเวอร์ชันต่างๆ หลายครั้ง ดังนั้น การบอกให้เบราว์เซอร์ตรวจสอบสคริปต์ที่อัปเดตแล้วเฉพาะในกรณีที่ผ่านไป 25 นาทีนับจากการตรวจสอบครั้งล่าสุดจึงไม่มีผลกระทบที่ร้ายแรง ข้อดีของการเลือกใช้ลักษณะการทำงานนี้คือช่วยลดปริมาณการเข้าชมที่ได้รับโดยปลายทางที่สร้างสคริปต์ Service Worker แบบไดนามิกได้อย่างมาก
นอกจากนี้ ระบบจะตั้งค่าส่วนหัว ETag ในการตอบกลับ HTTP ของสคริปต์ Service Worker เพื่อให้มั่นใจว่าเมื่อทำการตรวจสอบการอัปเดตหลังจากผ่านไป 25 นาที เซิร์ฟเวอร์จะตอบกลับได้อย่างมีประสิทธิภาพด้วยการตอบกลับ HTTP 304 หากไม่มีอัปเดต Service Worker ที่ติดตั้งใช้งานในระหว่างนี้
แม้ว่าการโต้ตอบบางอย่างภายในเว็บแอป Google Search จะใช้การนําทางแบบแอปหน้าเดียว (เช่น ผ่าน History API) แต่ Google Search ส่วนใหญ่เป็นเว็บแอปแบบดั้งเดิมที่ใช้การนําทาง "จริง" ตัวเลือกนี้มีผลเมื่อทีมตัดสินใจว่าการใช้ 2 ตัวเลือกต่อไปนี้จะมีประสิทธิภาพในการเร่งวงจรการอัปเดต Service Worker
clients.claim()
และ
skipWaiting()
โดยทั่วไปแล้ว การคลิกไปรอบๆ อินเทอร์เฟซของ Google Search จะไปยังเอกสาร HTML ใหม่ การเรียกใช้ skipWaiting ช่วยให้มั่นใจว่า Service Worker ที่อัปเดตแล้วจะได้รับโอกาสจัดการคำขอไปยังส่วนต่างๆ ใหม่เหล่านั้นทันทีหลังจากการติดตั้ง ในทํานองเดียวกัน การเรียก clients.claim() หมายความว่า Service Worker ที่อัปเดตแล้วมีโอกาสเริ่มควบคุมหน้า Google Search ที่เปิดอยู่ซึ่งไม่มีการควบคุม หลังจากการเรียกใช้งาน Service Worker
แนวทางที่ Google Search เลือกใช้อาจไม่ใช่โซลูชันที่เหมาะกับทุกคน แต่เป็นผลมาจากการทดสอบ A/B อย่างละเอียดของชุดค่าผสมต่างๆ ของตัวเลือกการแสดงผลจนกว่าจะพบตัวเลือกที่ได้ผลดีที่สุด
นักพัฒนาแอปที่มีโครงสร้างพื้นฐานแบ็กเอนด์ช่วยให้สามารถทําให้อัปเดตได้เร็วขึ้นอาจต้องการให้เบราว์เซอร์ตรวจสอบสคริปต์ Service Worker ที่อัปเดตแล้วบ่อยที่สุดเท่าที่จะทำได้ โดยไม่สนใจแคช HTTP เสมอ
หากคุณกำลังสร้างแอปแบบหน้าเดียวที่ผู้ใช้อาจเปิดทิ้งไว้เป็นเวลานาน การใช้ skipWaiting() อาจไม่ใช่ตัวเลือกที่เหมาะสมสำหรับคุณ เนื่องจากคุณเสี่ยงที่จะพบปัญหาความไม่สอดคล้องของแคช หากอนุญาตให้ Service Worker ใหม่เปิดใช้งานขณะที่มีไคลเอ็นต์ที่ทำงานอยู่เป็นเวลานาน
สิ่งสำคัญที่เรียนรู้
โดยค่าเริ่มต้น Service Worker ไม่ได้เป็นบริการที่มีประสิทธิภาพกลางๆ
การเพิ่ม Service Worker ลงในเว็บแอปหมายความว่าคุณจะต้องแทรก JavaScript เพิ่มเติมที่จำเป็นต้องโหลดและดำเนินการก่อนที่เว็บแอปจะได้รับคำตอบสำหรับคำขอ หากการตอบสนองเหล่านั้นมาจากแคชในเครื่องแทนที่มาจากเครือข่าย ค่าใช้จ่ายเพิ่มเติมในการใช้งาน Service Worker มักจะไม่มีนัยสำคัญเมื่อเทียบกับประสิทธิภาพที่เพิ่มขึ้นจากการใช้แคชก่อน แต่หากคุณทราบว่า Service Worker จะต้องปรึกษาเครือข่ายเสมอเมื่อจัดการคำขอการนําทาง การใช้การโหลดการนําทางล่วงหน้าเป็นวิธีเพิ่มประสิทธิภาพที่สำคัญ
Service Worker (ยังคง) เป็นการเพิ่มประสิทธิภาพแบบค่อยเป็นค่อยไป
การสนับสนุน Service Worker ในปัจจุบันดีกว่าเมื่อ 1 ปีก่อนมาก ขณะนี้เบราว์เซอร์สมัยใหม่ทั้งหมดมีการรองรับ Service Worker อย่างน้อยบางส่วน แต่น่าเสียดายที่ฟีเจอร์ Service Worker ขั้นสูงบางรายการ เช่น การซิงค์ในเบื้องหลังและการโหลดการนําทางล่วงหน้า ยังไม่พร้อมให้บริการในวงกว้าง การตรวจสอบฟีเจอร์สำหรับชุดย่อยของฟีเจอร์ที่คุณรู้ว่าต้องใช้ และการลงทะเบียน Service Worker เฉพาะเมื่อมีฟีเจอร์เหล่านั้นยังคงเป็นแนวทางที่สมเหตุสมผล
ในทํานองเดียวกัน หากคุณได้ทำการทดสอบในสถานการณ์จริงและทราบว่าอุปกรณ์ระดับล่างมีประสิทธิภาพต่ำเมื่อมีภาระเพิ่มเติมของ Service Worker คุณก็เลือกที่จะไม่ลงทะเบียน Service Worker ในสถานการณ์เหล่านั้นได้เช่นกัน
คุณควรใช้ Service Worker เป็นการเพิ่มประสิทธิภาพแบบเป็นขั้นเป็นตอนต่อไป ซึ่งจะเพิ่มลงในเว็บแอปเมื่อมีคุณสมบัติตรงตามข้อกําหนดเบื้องต้นทั้งหมด และ Service Worker เพิ่มสิ่งที่ดีต่อประสบการณ์ของผู้ใช้และประสิทธิภาพการโหลดโดยรวม
วัดผลทุกอย่าง
วิธีเดียวที่จะทราบได้ว่าการนำ Service Worker ไปใช้ส่งผลดีหรือแย่ต่อประสบการณ์ของผู้ใช้คือการทดสอบและวัดผลลัพธ์
รายละเอียดการตั้งค่าการวัดผลที่สื่อความหมายจะขึ้นอยู่กับผู้ให้บริการข้อมูลวิเคราะห์ที่คุณใช้ และวิธีที่คุณทําการทดสอบตามปกติในการตั้งค่าการติดตั้งใช้งาน แนวทางหนึ่งคือการใช้ Google Analytics เพื่อรวบรวมเมตริก ซึ่งมีรายละเอียดอยู่ในกรณีศึกษานี้ ซึ่งอิงตามประสบการณ์การใช้ Service Worker ในเว็บแอป Google I/O
เหตุการณ์ที่ไม่ใช่เป้าหมาย
แม้ว่าคนในชุมชนการพัฒนาเว็บจำนวนมากจะเชื่อมโยง Service Worker กับ Progressive Web App แต่การสร้าง "PWA ของ Google Search" นั้นไม่ใช่เป้าหมายแรกเริ่มของทีม ปัจจุบันเว็บแอป Google Search ไม่ได้ระบุข้อมูลเมตาผ่านไฟล์ Manifest ของเว็บแอป และไม่ได้ส่งเสริมให้ผู้ใช้ทำตามขั้นตอนการเพิ่มลงในหน้าจอหลัก ปัจจุบันทีม Search พอใจกับผู้ใช้ที่เข้ามายังเว็บแอปผ่านจุดแรกเข้าแบบดั้งเดิมของ Google Search
แทนที่จะพยายามเปลี่ยนประสบการณ์การใช้งาน Google Search บนเว็บให้เทียบเท่ากับสิ่งที่คุณคาดหวังจากแอปพลิเคชันที่ติดตั้งไว้ เป้าหมายในการเปิดตัวครั้งแรกคือการปรับปรุงเว็บไซต์ที่มีอยู่อย่างต่อเนื่อง
ขอขอบคุณ
ขอขอบคุณทีมพัฒนาเว็บของ Google Search ทุกคนที่ทํางานเกี่ยวกับการติดตั้งใช้งาน Service Worker และแชร์ข้อมูลเบื้องต้นที่ใช้ในการเขียนบทความนี้ ขอขอบคุณเป็นพิเศษ Philippe Golle, Rajesh Jagannathan, R. Samuel Klatchko, Andy Martone, Leonardo Peña, Rachel Shearer, Greg Terrono และ Clay Woolam
ข้อมูลอัปเดต (ต. ค. 2021): นับตั้งแต่เผยแพร่บทความนี้ครั้งแรก ทีม Google Search ได้ประเมินประโยชน์และข้อเสียของสถาปัตยกรรม Service Worker ปัจจุบันอีกครั้ง เราจะเลิกใช้งาน Service Worker ที่อธิบายไว้ข้างต้น เมื่อโครงสร้างพื้นฐานเว็บของ Google Search พัฒนาขึ้น ทีมอาจกลับมาดูการออกแบบ Service Worker อีกครั้ง