เรื่องราวของสินค้าที่จัดส่ง วิธีการวัดผลกระทบ และข้อดีข้อเสีย
ที่มา
ค้นหาหัวข้อต่างๆ บน Google แล้วคุณจะเห็นหน้าผลลัพธ์ที่มีความหมายและเกี่ยวข้องในทันที สิ่งที่คุณ อาจไม่ได้ตระหนักคือ หน้าผลการค้นหานี้แสดงโดยเทคโนโลยีเว็บอันทรงพลังที่เรียกว่า 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 ออฟไลน์ที่กำหนดเองและอนุญาตให้ผู้ใช้ป้อนคำค้นหาได้ทันที
ผลการค้นหาจะไม่แสดงจนกว่าจะมีการเชื่อมต่ออินเทอร์เน็ต แต่โปรแกรมทำงานของบริการอนุญาตให้เลื่อนการค้นหาและส่งไปยังเซิร์ฟเวอร์ของ Google ทันทีที่อุปกรณ์กลับมาออนไลน์โดยใช้ API การซิงค์ในเบื้องหลัง
การแคชและแสดงผล JavaScript ที่ชาญฉลาดยิ่งขึ้น
แรงจูงใจอีกอย่างคือการเพิ่มประสิทธิภาพการแคชและการโหลดโค้ด JavaScript แบบแยกส่วนซึ่งขับเคลื่อนฟีเจอร์ต่างๆ ในหน้าผลการค้นหา การรวมกลุ่ม JavaScript มีข้อดีหลายอย่างเมื่อไม่มี Service Worker เข้ามาเกี่ยวข้อง ทีม Search จึงไม่ต้องการที่จะหยุดการรวมกลุ่มไปเลย
การใช้ความสามารถของ Service Worker ในการสร้างเวอร์ชันและแคชส่วน JavaScript แบบละเอียดในระหว่างรันไทม์ทำให้ทีม Search สงสัยว่าสามารถลดปริมาณการเลิกใช้งานแคชได้และช่วยให้แคช JavaScript ที่นำมาใช้ใหม่ในอนาคตได้อย่างมีประสิทธิภาพ ตรรกะภายในโปรแกรมทำงานของบริการสามารถวิเคราะห์คำขอ HTTP ขาออกสำหรับแพ็กเกจที่มีโมดูล JavaScript หลายรายการ ดำเนินการตามตรรกะของโมดูลดังกล่าวโดยการนำโมดูลที่แคชไว้ในเครื่องหลายๆ โมดูลมารวมไว้ใน "การเลิกรวมกลุ่ม" อย่างมีประสิทธิภาพ เมื่อเป็นไปได้ ซึ่งจะช่วยประหยัดแบนด์วิดท์ของผู้ใช้ และปรับปรุงการตอบสนองโดยรวม
นอกจากนี้ ยังมีประโยชน์ด้านประสิทธิภาพในการใช้ JavaScript ที่แคชไว้ซึ่งให้บริการโดยโปรแกรมทำงานด้วย กล่าวคือ ใน Chrome ระบบจะจัดเก็บการแสดงโค้ดไบต์ที่แยกวิเคราะห์และแยกวิเคราะห์ของ JavaScript ดังกล่าวและนำมาใช้ซ้ำ ซึ่งช่วยให้งานที่จำเป็นต้องทำขณะรันไทม์น้อยลงเพื่อให้เรียกใช้ JavaScript ในหน้าเว็บได้
ความท้าทายและวิธีแก้ปัญหา
ต่อไปนี้คืออุปสรรคบางอย่างที่ต้องเอาชนะเพื่อให้บรรลุเป้าหมายของทีม ในขณะที่อุปสรรคบางอย่างมีไว้สำหรับ Google Search โดยเฉพาะ แต่ปัญหาหลายอย่างก็ใช้ได้กับเว็บไซต์ต่างๆ มากมายที่อาจพิจารณาเรื่องการติดตั้งใช้งาน Service Worker
ปัญหา: ค่าใช้จ่ายในการดำเนินงานของ Service Worker
ความท้าทายที่ใหญ่ที่สุดและตัวบล็อกที่แท้จริงในการเปิดตัว Service Worker ใน Google Search คือการดูแลไม่ให้ระบบทำอะไรที่อาจเพิ่มเวลาในการตอบสนองที่ผู้ใช้รับรู้ Google Search ให้ความสำคัญกับประสิทธิภาพอย่างมาก และในอดีตได้บล็อกการเปิดตัวฟังก์ชันใหม่หากมีเวลาในการตอบสนองเพิ่มเติมหลายสิบมิลลิวินาทีสำหรับกลุ่มผู้ใช้หนึ่งๆ
เมื่อทีมเริ่มรวบรวมข้อมูลประสิทธิภาพระหว่างการทดสอบครั้งแรก ก็เห็นได้ชัดว่ามีปัญหาเกิดขึ้น HTML ที่แสดงผลเพื่อตอบสนองต่อคำขอการนำทางของหน้าผลการค้นหาเป็นแบบไดนามิก และแตกต่างกันไปตามตรรกะที่จำเป็นต้องเรียกใช้ในเว็บเซิร์ฟเวอร์ของ Search ขณะนี้ยังไม่มีวิธีให้โปรแกรมทำงานของบริการจำลองตรรกะนี้และแสดงผล HTML ที่แคชไว้ทันที วิธีที่ดีที่สุดคือการส่งคำขอการนำทางไปยังเว็บเซิร์ฟเวอร์แบ็กเอนด์ซึ่งจำเป็นต้องมีคำขอเครือข่าย
หากไม่มี Service Worker คำขอเครือข่ายนี้จะเกิดขึ้นทันทีที่การนำทางของผู้ใช้ เมื่อลงทะเบียน Service Worker แล้ว จะต้องเริ่มต้นใช้งานและมีโอกาสเรียกใช้ตัวแฮนเดิลเหตุการณ์ fetch เสมอ แม้ว่าตัวแฮนเดิลการดึงข้อมูลเหล่านั้นจะไม่ดำเนินการอื่นใดนอกจากไปที่เครือข่ายก็ตาม ระยะเวลาที่ใช้ในการเริ่มต้นและเรียกใช้โค้ดโปรแกรมทำงานของบริการคือการเพิ่มโอเวอร์เฮดทั้งหมดที่ด้านบนของการนำทางทั้งหมด ดังนี้
ซึ่งทำให้การใช้ Service Worker เสียผลประโยชน์จากเวลาในการตอบสนองมากเกินไปเพื่อให้ได้ประโยชน์อื่นๆ นอกจากนี้ ทีมพบว่าจากการวัดเวลาเปิดเครื่องของ Service Worker ในอุปกรณ์ในชีวิตจริง มีการกระจายเวลาเริ่มต้นอย่างทั่วถึง โดยที่อุปกรณ์เคลื่อนที่แบบโลว์เอนด์บางรุ่นใช้เวลาเกือบพอสำหรับการเริ่มต้นโปรแกรมทำงานของบริการ เนื่องจากอาจต้องส่งคำขอเครือข่ายสำหรับ HTML ของหน้าผลการค้นหา
วิธีแก้ไข: ใช้การโหลดการนำทางล่วงหน้า
ฟีเจอร์เดียวที่สำคัญที่สุดซึ่งช่วยให้ทีม Google Search ก้าวหน้าในการเปิดตัว Service Worker ได้ก็คือการโหลดการนำทางล่วงหน้า การใช้การโหลดล่วงหน้าของการนำทางเป็นประโยชน์หลักด้านประสิทธิภาพสำหรับโปรแกรมทำงานของบริการที่จำเป็นต้องใช้การตอบสนองจากเครือข่ายเพื่อตอบสนองคำขอการนำทาง โดยจะให้คำแนะนำให้เบราว์เซอร์เริ่มส่งคำขอการนำทางทันทีในเวลาเดียวกันกับที่โปรแกรมทำงานของบริการเริ่มทำงาน
ตราบใดที่โปรแกรมทำงานของบริการเริ่มต้นทำงานน้อยกว่าเวลาที่ใช้ในการตอบกลับจากเครือข่าย ก็ไม่ควรมีโอเวอร์เฮ็ดเวลาในการตอบสนองที่โปรแกรมทำงานของบริการสร้างขึ้น
นอกจากนี้ทีม Search ยังจำเป็นต้องหลีกเลี่ยงการใช้ Service Worker ในอุปกรณ์เคลื่อนที่ระดับล่างซึ่งเวลาเปิดเครื่องของ Service Worker มากเกินกว่าคำขอการนำทาง เนื่องจากไม่มีกฎแบบเข้มงวดและรวดเร็วสำหรับสิ่งที่ประกอบขึ้นเป็นอุปกรณ์ "ระดับล่าง" จึงได้มีวิธีการเรียนรู้การตรวจสอบ RAM ทั้งหมดที่ติดตั้งในอุปกรณ์ หน่วยความจำที่น้อยกว่า 2 กิกะไบต์จะจัดอยู่ในหมวดหมู่อุปกรณ์ระดับล่าง ซึ่งระบบไม่ยอมรับเวลาเริ่มต้นของโปรแกรมทำงานของบริการ
พื้นที่เก็บข้อมูลที่ใช้ได้เป็นอีกการพิจารณาหนึ่ง เนื่องจากชุดทรัพยากรทั้งหมดที่จะแคชไว้สำหรับการใช้งานในอนาคตอาจมีหลายเมกะไบต์ อินเทอร์เฟซของ navigator.storage ช่วยให้หน้า Google Search ทราบล่วงหน้าว่าการพยายามแคชข้อมูลมีความเสี่ยงที่จะล้มเหลวเนื่องจากความล้มเหลวของโควต้าพื้นที่เก็บข้อมูลหรือไม่
ซึ่งทำให้ทีม Search มีเกณฑ์มากมายที่สามารถใช้พิจารณาว่าจะใช้ Service Worker หรือไม่ นั่นคือหากผู้ใช้เข้ามาที่หน้า Google Search โดยใช้เบราว์เซอร์ที่รองรับการโหลดการนำทางล่วงหน้า และมี RAM อย่างน้อย 2 กิกะไบต์และพื้นที่ว่างเพียงพอ ระบบจึงลงทะเบียนโปรแกรมทำงานของ Service Worker เบราว์เซอร์หรืออุปกรณ์ที่ไม่เป็นไปตามเกณฑ์จะไม่ได้กลายเป็นโปรแกรมที่ทำงานของบริการ แต่เบราว์เซอร์หรืออุปกรณ์ดังกล่าวจะยังคงได้รับประสบการณ์การใช้งาน Google Search เหมือนเดิม
ประโยชน์อย่างหนึ่งของการลงทะเบียนที่เลือกนี้คือความสามารถในการจัดส่ง Service Worker ขนาดเล็กลงแต่มีประสิทธิภาพมากขึ้น การกำหนดเป้าหมายเบราว์เซอร์ที่ทันสมัยค่อนข้างทันสมัยในการเรียกใช้โค้ด Service Worker จะช่วยลดค่าใช้จ่ายในการส่งและ Polyfill สำหรับเบราว์เซอร์รุ่นเก่า วิธีนี้ทำให้โค้ด JavaScript ที่ไม่ได้บีบอัดมีขนาดประมาณ 8 กิโลไบต์จากขนาดรวมของการติดตั้งใช้งานโปรแกรมทำงานของบริการ
ปัญหา: ขอบเขต Service Worker
เมื่อทีม Search ทำการทดสอบเวลาในการตอบสนองมากพอและมั่นใจว่าการใช้การโหลดล่วงหน้าของการนำทางช่วยให้ทีมมีเส้นทางที่ใช้งานได้จริงและปราศจากเวลาในการตอบสนองเมื่อใช้ 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 ที่กำหนดประเภทผลการค้นหาที่เฉพาะเจาะจงที่จะแสดง บางรสชาติใช้โค้ดเบสต่างจากหน้าผลการค้นเว็บแบบเดิมอย่างสิ้นเชิง ตัวอย่างเช่น การค้นหารูปภาพและการค้นหาช็อปปิ้งจะแสดงภายใต้เส้นทาง URL /search ด้วยพารามิเตอร์การค้นหาที่แตกต่างกัน แต่อินเทอร์เฟซทั้ง 2 แบบไม่พร้อมมอบประสบการณ์การใช้งานแบบ Service Worker ของตนเอง (ในขณะนี้)
วิธีแก้ปัญหา: สร้างเฟรมเวิร์กการส่งงานและการกำหนดเส้นทาง
แม้ว่าจะมีข้อเสนอบางอย่างที่ทำให้มีบางสิ่งที่มีประสิทธิภาพมากกว่าคำนำหน้าเส้นทาง URL ในการกำหนดขอบเขตของโปรแกรมทำงานของบริการ แต่ทีม Google Search ต้องติดการทำให้โปรแกรมทำงานของบริการที่ไม่ได้ดำเนินการใดๆ กับหน้าเว็บชุดย่อยที่ควบคุมอยู่
ในการแก้ปัญหานี้ ทีม Google Search จึงสร้างเฟรมเวิร์กการมอบหมายงานและการกำหนดเส้นทางตามความต้องการ ซึ่งสามารถกำหนดค่าเพื่อตรวจสอบเกณฑ์ต่างๆ เช่น พารามิเตอร์การค้นหาของหน้าไคลเอ็นต์ และใช้ในการกำหนดเส้นทางของโค้ดที่เจาะจงที่จะเลื่อนลงไป แทนที่จะใช้กฎฮาร์ดโค้ด ระบบนี้สร้างขึ้นให้มีความยืดหยุ่นและช่วยให้ทีมที่ใช้พื้นที่ของ URL ร่วมกัน เช่น การค้นหารูปภาพและการค้นหา Shopping สามารถนำตรรกะของผู้ปฏิบัติงานบริการของตนมาใช้ได้หลังจากนั้น
ปัญหา: ผลการค้นหาและเมตริกที่ปรับเปลี่ยนในแบบของคุณ
ผู้ใช้สามารถลงชื่อเข้าใช้ Google Search โดยใช้บัญชี Google ได้ และประสบการณ์การใช้งานผลการค้นหาอาจได้รับการปรับแต่งตามข้อมูลบัญชีที่เฉพาะเจาะจง ผู้ใช้ที่เข้าสู่ระบบจะได้รับการระบุโดยคุกกี้ของเบราว์เซอร์ที่เฉพาะเจาะจง ซึ่งเป็นมาตรฐานที่น่าเชื่อถือและได้รับการสนับสนุนอย่างกว้างขวาง
อย่างไรก็ตาม ข้อเสียอย่างหนึ่งของการใช้คุกกี้ของเบราว์เซอร์คือ คุกกี้เหล่านี้จะไม่ถูกเปิดเผยภายใน Service Worker และไม่มีวิธีตรวจสอบค่าโดยอัตโนมัติและมั่นใจได้ว่าค่านั้นไม่เปลี่ยนแปลงเนื่องจากผู้ใช้ออกจากระบบหรือสลับบัญชี (มีความพยายามที่จะทำให้ Service Worker เข้าถึงคุกกี้ แต่ขณะเขียนบทความนี้ แนวทางนี้เป็นขั้นทดลองและไม่ได้รับการรองรับในวงกว้าง)
มุมมองผู้ใช้ที่เข้าสู่ระบบในปัจจุบันของโปรแกรมทำงานของบริการไม่ตรงกับผู้ใช้จริงที่เข้าสู่ระบบอินเทอร์เฟซเว็บของ Google Search อาจนำไปสู่ผลการค้นหาที่ปรับเปลี่ยนในแบบของคุณอย่างไม่ถูกต้อง หรือเมตริกและการบันทึกที่ระบุแหล่งที่มาไม่ถูกต้อง สถานการณ์ที่ล้มเหลวอาจเป็นปัญหาร้ายแรงสำหรับทีม Google Search
วิธีแก้ไข: ส่งคุกกี้โดยใช้ postMessage
แทนที่จะรอให้ API ทดลองเปิดตัวและให้สิทธิ์เข้าถึงคุกกี้ของเบราว์เซอร์ภายใน Service Worker โดยตรง ทีม Google Search ได้ใช้โซลูชันการหยุดทำงาน นั่นคือเมื่อใดก็ตามที่หน้าเว็บที่ควบคุมโดย Service Worker โหลดขึ้นมา หน้านั้นจะอ่านคุกกี้ที่เกี่ยวข้องและใช้ postMessage() เพื่อส่งคุกกี้ไปยัง Service Worker
จากนั้น Service Worker จะตรวจสอบค่าคุกกี้ปัจจุบันเทียบกับค่าที่คาดไว้ และหากไม่ตรงกัน จะมีขั้นตอนการลบข้อมูลเฉพาะผู้ใช้ออกจากพื้นที่เก็บข้อมูลอย่างถาวร และโหลดหน้าผลการค้นหาซ้ำโดยไม่มีการปรับเปลี่ยนในแบบของคุณที่ไม่ถูกต้อง
ขั้นตอนเฉพาะที่โปรแกรมทำงานของบริการทำเพื่อรีเซ็ตสิ่งต่างๆ ให้เป็นไปตามเกณฑ์พื้นฐานนั้นเป็นไปตามข้อกำหนดของ Google Search โดยเฉพาะ แต่แนวทางทั่วไปเดียวกันนี้อาจมีประโยชน์สำหรับนักพัฒนาซอฟต์แวร์รายอื่นๆ ที่จัดการข้อมูลที่ปรับเปลี่ยนในแบบของคุณซึ่งรวบรวมจากคุกกี้ในเบราว์เซอร์
ปัญหา: การทดลองและไดนามิก
อย่างที่ได้กล่าวไปแล้ว ทีม Google Search อาศัยการทดสอบจริงจากการใช้งานจริง และทดสอบผลของโค้ดและฟีเจอร์ใหม่ๆ ในโลกแห่งความเป็นจริงก่อนที่จะเปิดใช้โดยค่าเริ่มต้น นี่อาจเป็นเรื่องท้าทายเล็กน้อยสำหรับโปรแกรมทำงานของบริการแบบคงที่ซึ่งต้องอาศัยข้อมูลที่แคชไว้อย่างมาก เนื่องจากการเลือกผู้ใช้เข้าและออกจากการทดสอบมักต้องมีการสื่อสารกับเซิร์ฟเวอร์แบ็กเอนด์
วิธีแก้ปัญหา: สคริปต์ Service Worker ที่สร้างขึ้นแบบไดนามิก
โซลูชันที่ทีมใช้คือการใช้สคริปต์ Service Worker ที่สร้างขึ้นแบบไดนามิก ที่ปรับแต่งโดยเว็บเซิร์ฟเวอร์สำหรับผู้ใช้แต่ละราย แทนที่จะใช้สคริปต์ Service Worker แบบคงที่เพียงสคริปต์เดียวที่สร้างขึ้นล่วงหน้า ข้อมูลเกี่ยวกับการทดสอบที่อาจส่งผลต่อพฤติกรรมของผู้ปฏิบัติงานบริการหรือคำขอเครือข่ายโดยทั่วไปรวมอยู่ในสคริปต์ของผู้ปฏิบัติงานบริการที่กำหนดเองนี้โดยตรง การเปลี่ยนชุดประสบการณ์การใช้งานของผู้ใช้จะดำเนินการผ่านการใช้เทคนิคดั้งเดิมต่างๆ ร่วมกัน เช่น คุกกี้ของเบราว์เซอร์ ตลอดจนการแสดงโค้ดที่อัปเดตใน URL ของโปรแกรมทำงานของบริการที่ลงทะเบียนไว้
นอกจากนี้ การใช้สคริปต์ Service Worker ที่สร้างขึ้นแบบไดนามิกยังทำให้คุณหาทางแก้ปัญหาได้ง่ายขึ้นในกรณีที่การติดตั้งใช้งาน Service Worker มีข้อบกพร่องร้ายแรงที่ต้องหลีกเลี่ยง การตอบกลับของผู้ปฏิบัติงานเซิร์ฟเวอร์แบบไดนามิกอาจเป็นการใช้งานแบบ Noop ที่ปิดใช้ 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 ไปใช้นั้นดำเนินการต่อเนื่องกัน
หากผู้ใช้คลิกแบ็กเอนด์ที่มีการอัปเดตแล้วเข้าไปยังหน้าอื่นอย่างรวดเร็วซึ่งไปยังแบ็กเอนด์ที่ยังไม่ได้รับโปรแกรมทำงานของบริการที่อัปเดต พวกเขาสุดท้ายจะพลิกไปหลายๆ เวอร์ชัน ดังนั้นการแจ้งเบราว์เซอร์ให้ตรวจสอบสคริปต์ที่อัปเดตเฉพาะเมื่อผ่านไป 25 นาทีแล้วไม่ได้มีข้อเสียที่สำคัญ ข้อดีของการเลือกใช้ลักษณะการทำงานนี้จะลดไปมากในการรับส่งข้อมูลที่ปลายทางได้รับ ซึ่งสร้างสคริปต์ Service Worker แบบไดนามิก
นอกจากนี้ ส่วนหัว ETag จะมีการตั้งค่าในการตอบกลับ HTTP ของสคริปต์โปรแกรมทำงานของบริการ เพื่อให้แน่ใจว่าเมื่อทำการตรวจสอบการอัปเดตหลังผ่านไป 25 นาที เซิร์ฟเวอร์จะตอบสนองได้อย่างมีประสิทธิภาพด้วยการตอบกลับ HTTP 304 หากไม่มีการอัปเดตใดๆ ที่โปรแกรมทำงานของบริการใช้งานได้ในระหว่างนั้น
แม้ว่าการโต้ตอบบางอย่างภายในเว็บแอป Google Search จะใช้การนำทางแบบแอป
แบบหน้าเดียว (เช่น ผ่าน History API)
โดยส่วนมาก Google Search เป็นเว็บแอปแบบดั้งเดิมที่ใช้การนำทาง
แบบ "จริง" สถานการณ์นี้จึงเข้ามามีบทบาทเมื่อทีมตัดสินใจว่าจะใช้ 2 ตัวเลือกที่เร่งวงจรการอัปเดตโปรแกรมทำงานของบริการได้ ซึ่งได้แก่ clients.claim() และ skipWaiting()
โดยทั่วไปแล้ว การคลิกส่วนต่างๆ ของอินเทอร์เฟซ Google Search จะเป็นการไปยังเอกสาร HTML ใหม่ การเรียกใช้ skipWaiting ช่วยให้มั่นใจได้ว่า Service Worker ที่อัปเดตจะมีโอกาสจัดการคำขอการนำทางใหม่เหล่านั้นทันทีหลังการติดตั้ง ในทำนองเดียวกัน การเรียกใช้ clients.claim() หมายความว่าโปรแกรมทำงานของบริการที่อัปเดตจะมีโอกาสเริ่มควบคุมหน้า Google Search ที่เปิดอยู่ซึ่งไม่มีการควบคุม หลังจากเปิดใช้งาน Service Worker
แนวทางที่ Google Search ใช้ไม่จำเป็นต้องเป็นโซลูชันที่เหมาะสำหรับทุกคน แต่เป็นผลที่ได้จากการทดสอบ A/B หลายๆ ชุดตัวเลือกการแสดงผลอย่างรอบคอบ จนกว่าจะพบสิ่งที่เหมาะสำหรับตนเองมากที่สุด
นักพัฒนาซอฟต์แวร์ที่มีโครงสร้างพื้นฐานแบ็กเอนด์อนุญาตให้ติดตั้งใช้งานการอัปเดตได้รวดเร็วยิ่งขึ้นอาจต้องการให้เบราว์เซอร์ตรวจสอบสคริปต์ Service Worker ที่อัปเดตอยู่เสมอโดยเพิกเฉยต่อแคช HTTP เสมอ
หากคุณกำลังสร้างแอปแบบหน้าเดียวที่ผู้ใช้อาจเปิดไว้เป็นเวลานาน การใช้ skipWaiting() อาจไม่ใช่ตัวเลือกที่เหมาะสำหรับคุณ คุณมีความเสี่ยงที่จะพบความไม่สอดคล้องกันของแคชหากอนุญาตให้โปรแกรมทำงานของบริการใหม่เปิดใช้งานในระหว่างที่มีไคลเอ็นต์ที่อยู่มานานแล้ว
สรุปประเด็นสำคัญ
โดยค่าเริ่มต้น โปรแกรมทำงานของบริการจะไม่เป็นกลางด้านประสิทธิภาพ
การเพิ่ม Service Worker ลงในเว็บแอปหมายถึงการแทรก JavaScript ที่ต้องโหลดและเรียกใช้ก่อนที่เว็บแอปจะได้รับการตอบสนองคำขอ หากคำตอบเหล่านั้นมาจากแคชในเครื่องแทนที่จะเป็นจากเครือข่าย ค่าใช้จ่ายในการเรียกใช้ 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 อีกครั้ง