เรื่องราวของสิ่งที่เปิดตัว วิธีวัดผลกระทบ และการแลกเปลี่ยนที่เกิดขึ้น
เผยแพร่: 20 มิถุนายน 2019
ค้นหาหัวข้อใดก็ได้ใน 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 Search ขณะออฟไลน์จะ นำไปสู่หน้าข้อผิดพลาดเกี่ยวกับเครือข่ายมาตรฐานของเบราว์เซอร์เท่านั้น และผู้ใช้จะต้อง จำไว้ว่าต้องกลับมาลองอีกครั้งเมื่อการเชื่อมต่อกลับมาใช้งานได้ Service Worker ช่วยให้แสดงการตอบกลับ HTML แบบออฟไลน์ที่กำหนดเองได้ และอนุญาตให้ ผู้ใช้ป้อนคำค้นหาได้ทันที
ผลการค้นหาจะยังไม่พร้อมใช้งานจนกว่าจะมีการเชื่อมต่ออินเทอร์เน็ต แต่ Service Worker จะช่วยให้เลื่อนการค้นหาและส่งไปยังเซิร์ฟเวอร์ของ Google ได้ ทันทีที่อุปกรณ์กลับมาออนไลน์อีกครั้งโดยใช้ Background Sync API
การแคชและการแสดง JavaScript ที่มีประสิทธิภาพมากขึ้น
อีกเหตุผลหนึ่งคือการเพิ่มประสิทธิภาพการแคชและการโหลดโค้ด JavaScript แบบแยกส่วนที่ขับเคลื่อนฟีเจอร์ประเภทต่างๆ ในหน้าผลการค้นหา การจัดกลุ่ม JavaScript มีประโยชน์หลายอย่างที่สมเหตุสมผลเมื่อไม่มีการใช้ Service Worker ดังนั้นทีม Search จึงไม่ต้องการหยุดการจัดกลุ่มทั้งหมด
ทีม Search สงสัยว่าการใช้ความสามารถของ Service Worker ในการกำหนดเวอร์ชันและแคช JavaScript แบบละเอียดในรันไทม์จะช่วยลดปริมาณการเปลี่ยนแปลงแคชและทำให้มั่นใจได้ว่า JavaScript ที่นำกลับมาใช้ใหม่ในอนาคตจะแคชได้อย่างมีประสิทธิภาพ ตรรกะภายใน Service Worker สามารถ วิเคราะห์คำขอ HTTP ขาออกสำหรับ Bundle ที่มีโมดูล 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ตัวแฮนเดิลเหตุการณ์
แม้ว่าจะไม่มีโอกาสที่ตัวแฮนเดิลการดึงข้อมูลเหล่านั้นจะทำอย่างอื่นนอกเหนือจากการไปที่เครือข่ายก็ตาม ระยะเวลาที่ใช้ในการเริ่มต้นและเรียกใช้โค้ด Service 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 เบราว์เซอร์หรืออุปกรณ์ที่ไม่เป็นไปตามเกณฑ์ดังกล่าวจะไม่มี Service Worker แต่จะยังคงได้รับประสบการณ์การใช้งาน Google Search แบบเดิม
ข้อดีอย่างหนึ่งของการลงทะเบียนแบบเลือกนี้คือความสามารถในการจัดส่ง Service Worker ที่มีขนาดเล็กลงและมีประสิทธิภาพมากขึ้น การกำหนดเป้าหมายเบราว์เซอร์ที่ค่อนข้างใหม่เพื่อเรียกใช้โค้ด Service Worker จะช่วยลดค่าใช้จ่ายในการแปลงโค้ดและ Polyfill สำหรับเบราว์เซอร์รุ่นเก่า ซึ่งช่วยลดขนาดโค้ด JavaScript ที่ไม่ได้บีบอัดประมาณ 8 กิโลไบต์จากขนาดทั้งหมดของการติดตั้งใช้งาน Service Worker
ปัญหา: ขอบเขตของ Service Worker
เมื่อทีม Search ทำการทดลองเรื่องเวลาในการตอบสนองมากพอและมั่นใจว่าการใช้การโหลดล่วงหน้าของการนำทางเป็นเส้นทางที่ใช้ได้จริงและไม่ส่งผลต่อเวลาในการตอบสนองสำหรับการใช้ Service Worker ปัญหาในทางปฏิบัติบางอย่างก็เริ่มเข้ามามีบทบาทมากขึ้น ปัญหาอย่างหนึ่ง เหล่านั้นเกี่ยวข้องกับกฎการกำหนดขอบเขตของ Service Worker ขอบเขตของ Service Worker จะกำหนดหน้าเว็บที่ Service Worker อาจควบคุมได้
การกำหนดขอบเขตจะทำงานตามคำนำหน้าเส้นทาง URL สำหรับโดเมนที่โฮสต์เว็บแอปเดียว นี่ไม่ใช่ปัญหา เนื่องจากโดยปกติคุณจะใช้ Service Worker ที่มีขอบเขตสูงสุดของ / ซึ่งอาจควบคุมหน้าใดก็ได้ภายใต้โดเมน
แต่โครงสร้าง URL ของ Google Search จะซับซ้อนกว่าเล็กน้อย
หาก Service Worker ได้รับขอบเขตสูงสุดของ / ก็จะสามารถควบคุมหน้าเว็บใดก็ได้ที่โฮสต์ภายใต้ www.google.com (หรือเทียบเท่าในภูมิภาค) และมี URL ภายใต้โดเมนนั้นซึ่งไม่มีส่วนเกี่ยวข้องกับ Google Search ขอบเขตที่จำกัดและสมเหตุสมผลมากขึ้นคือ /search ซึ่งอย่างน้อยจะช่วยกำจัด URL ที่ไม่เกี่ยวข้องกับผลการค้นหาโดยสิ้นเชิง
น่าเสียดายที่แม้แต่เส้นทาง URL /search นั้นก็ยังใช้ร่วมกันในผลการค้นหาของ Google Search รูปแบบต่างๆ โดยพารามิเตอร์การค้นหาของ URL จะเป็นตัวกำหนดประเภทผลการค้นหาที่เฉพาะเจาะจงซึ่งจะแสดง ซึ่งบางเวอร์ชันใช้โค้ดเบสที่แตกต่างจากหน้าผลการค้นหาของเว็บแบบดั้งเดิมโดยสิ้นเชิง
ตัวอย่างเช่น การค้นหารูปภาพ
และการค้นหา Shopping จะแสดงภายใต้/searchเส้นทาง URL ที่มีพารามิเตอร์การค้นหา
ที่แตกต่างกัน แต่ไม่มีอินเทอร์เฟซใดพร้อมที่จะเปิดตัวประสบการณ์ Service Worker ของตนเอง (ในขณะนี้)
วิธีแก้ไข: สร้างกรอบการจัดส่งและการกำหนดเส้นทาง
แม้ว่าจะมีข้อเสนอแนะบางอย่าง ที่อนุญาตให้ใช้สิ่งที่มีประสิทธิภาพมากกว่าคำนำหน้าเส้นทาง URL เพื่อกำหนด ขอบเขตของ Service Worker แต่ทีม Google Search ก็ไม่สามารถติดตั้งใช้งาน Service Worker ที่ไม่ได้ทำอะไรเลยสำหรับชุดย่อยของหน้าที่ควบคุม
ทีม Google Search จึงสร้างเฟรมเวิร์กการส่งและการกำหนดเส้นทางที่กำหนดเองซึ่งสามารถกำหนดค่าเพื่อตรวจสอบเกณฑ์ต่างๆ เช่น พารามิเตอร์การค้นหาของหน้าไคลเอ็นต์ และใช้เกณฑ์เหล่านั้นเพื่อกำหนดเส้นทางโค้ดที่เฉพาะเจาะจงที่จะใช้ ระบบนี้สร้างขึ้นเพื่อให้มีความยืดหยุ่นและอนุญาตให้ทีมที่แชร์พื้นที่ URL เช่น Image Search และ Shopping Search สามารถแทรกลอจิกของ Service Worker ของตนเองได้ในอนาคต หากตัดสินใจที่จะใช้
ปัญหา: ผลลัพธ์และเมตริกที่ปรับเปลี่ยนในแบบของคุณ
ผู้ใช้สามารถลงชื่อเข้าใช้ Google Search โดยใช้บัญชี Google และระบบอาจปรับแต่งประสบการณ์การใช้งานผลการค้นหา ตามข้อมูลบัญชีของผู้ใช้ ระบบจะระบุผู้ใช้ที่เข้าสู่ระบบด้วยคุกกี้ของเบราว์เซอร์ที่เฉพาะเจาะจง ซึ่งเป็นมาตรฐานที่ได้รับการยอมรับและรองรับอย่างกว้างขวาง
อย่างไรก็ตาม ข้อเสียอย่างหนึ่งของการใช้คุกกี้ของเบราว์เซอร์คือคุกกี้จะไม่แสดงภายใน Service Worker และไม่มีวิธีตรวจสอบค่าของคุกกี้โดยอัตโนมัติ รวมถึงตรวจสอบว่าค่าของคุกกี้ไม่ได้เปลี่ยนแปลงเนื่องจากผู้ใช้ได้ออกจากระบบหรือเปลี่ยนบัญชี (ขณะนี้เรากำลังพยายามนำสิทธิ์เข้าถึงคุกกี้มายัง Service Worker แต่ ณ เวลาที่เขียนบทความนี้ วิธีการนี้ยังอยู่ในขั้นทดลอง และยังไม่รองรับในวงกว้าง)
มุมมองของผู้ใช้ที่เข้าสู่ระบบปัจจุบันของ Service Worker กับผู้ใช้จริงที่เข้าสู่ระบบอินเทอร์เฟซเว็บของ Google Search อาจไม่ตรงกัน ซึ่งอาจส่งผลให้ผลการค้นหาที่ปรับเปลี่ยนในแบบของคุณไม่ถูกต้อง หรือเมตริกและการบันทึกไม่ถูกต้อง สถานการณ์ที่ล้มเหลวเหล่านี้จะเป็นปัญหาที่ร้ายแรงสำหรับทีม Google Search
วิธีแก้ปัญหา: ส่งคุกกี้โดยใช้ postMessage
ทีม Google Search จึงเลือกใช้โซลูชันชั่วคราวแทนที่จะรอให้ API เวอร์ชันทดลองเปิดตัวและให้สิทธิ์เข้าถึงคุกกี้ของเบราว์เซอร์ภายใน Service Worker โดยตรง นั่นคือ เมื่อใดก็ตามที่มีการโหลดหน้าเว็บที่ควบคุมโดย 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 มีข้อบกพร่องร้ายแรงที่ต้องหลีกเลี่ยง ซึ่งเป็นเหตุการณ์ที่เกิดขึ้นได้ยาก การตอบกลับของเซิร์ฟเวอร์แบบไดนามิก ของ Worker อาจเป็นการติดตั้งใช้งานแบบไม่มีการดำเนินการ ซึ่งเป็นการปิดใช้ Service Worker สำหรับผู้ใช้ปัจจุบันบางรายหรือทั้งหมด
ปัญหา: การประสานงานการอัปเดต
ความท้าทายที่ยากที่สุดอย่างหนึ่งในการติดตั้งใช้งาน Service Worker ในโลกแห่งความเป็นจริง คือการประดิษฐ์การแลกเปลี่ยนที่สมเหตุสมผลระหว่างการหลีกเลี่ยงเครือข่ายเพื่อใช้ แคช ในขณะเดียวกันก็ต้องมั่นใจว่าผู้ใช้ที่มีอยู่จะได้รับการอัปเดตที่สำคัญ และการเปลี่ยนแปลงในไม่ช้าหลังจากที่ติดตั้งใช้งานในเวอร์ชันที่ใช้งานจริง ความสมดุลที่เหมาะสมขึ้นอยู่กับปัจจัยหลายอย่าง ดังนี้
- ไม่ว่าเว็บแอปจะเป็นแอปหน้าเดียวที่ใช้งานได้นาน ซึ่งผู้ใช้จะเปิดไว้เรื่อยๆ โดยไม่ต้องไปยังหน้าใหม่
- ความถี่ในการติดตั้งใช้งานสำหรับการอัปเดตเว็บเซิร์ฟเวอร์แบ็กเอนด์
- ผู้ใช้โดยเฉลี่ยจะยอมรับการใช้เว็บแอปเวอร์ชันที่ล้าสมัยเล็กน้อยหรือไม่ หรือความใหม่เป็นสิ่งสำคัญอันดับแรก
ขณะทดสอบ 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 สดใสกว่าเมื่อปีที่แล้วมาก ปัจจุบันเบราว์เซอร์สมัยใหม่ทั้งหมดมีการรองรับ 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 อีกครั้ง