ความคาดหวังเกี่ยวกับการทำให้ Service Worker ใช้งานได้

การทำให้ Service Worker ใช้งานได้อาจเปลี่ยนแปลงลักษณะการทำงานของเว็บไซต์โดยไม่คาดคิด เนื่องจาก Workbox ทำให้การเขียนและทำให้ Service Worker ใช้งานได้เป็นเรื่องง่าย จึงอาจพลาดผลกระทบบางอย่างที่โปรแกรมทำงานของบริการมีในเว็บไซต์เมื่อทำให้ใช้งานได้แล้ว

ซึ่งไม่ได้หมายความว่าการใช้ Workbox จะส่งผลให้เกิดผลลัพธ์ที่ไม่ดี เพียงแต่ความสะดวกสบายที่มีอาจทำให้พบข้อผิดพลาดได้ง่ายขึ้นถ้าผู้ใช้ไม่ทราบถึงสิ่งที่มาพร้อมกับการทำให้ Service Worker ใช้งานได้

การแคชล่วงหน้า

การแคชล่วงหน้าได้อธิบายไว้ในเอกสารเหล่านี้ก่อนหน้านี้ โดยไม่ได้กล่าวถึงวิธีที่แนวทางปฏิบัตินั้นๆ ทำให้เกิดผลตรงกันข้ามได้ คุณอาจพบปัญหาหากใช้การแคชล่วงหน้ากับเนื้อหามากเกินไป หรือหาก Service Worker ลงทะเบียนไว้ก่อนที่หน้าเว็บจะมีโอกาสโหลดเนื้อหาที่สำคัญเสร็จ

เนื่องจากลักษณะการทำงานเริ่มต้นของ workbox-webpack-plugin คือการสั่งให้ Service Worker แคชเนื้อหาที่สร้างขึ้นล่วงหน้าโดยอัตโนมัติ นี่จึงอาจเป็นปัญหาในลักษณะที่คุณพลาดได้ง่าย เนื่องจากอุปสรรคในการนำไปใช้งานอยู่ในระดับต่ำ

เมื่อ Service Worker แคชเนื้อหาล่วงหน้าระหว่างการติดตั้ง คำขอเครือข่ายอย่างน้อย 1 รายการจะเริ่มต้นพร้อมกัน ซึ่งอาจสร้างปัญหาให้กับประสบการณ์ของผู้ใช้ได้ถ้าไม่ตรงเวลา แม้ว่าช่วงเวลานั้นจะไม่เป็นไปอย่างที่คิด แต่ท้ายที่สุดก็อาจทำให้สูญเสียข้อมูลได้หากเนื้อหาที่จัดเก็บในแคชล่วงหน้าไม่ได้ถูกจำกัด

ทำทุกอย่างได้ทันใจ

หากโปรแกรมทำงานของบริการแคชล่วงหน้าไว้ เวลาที่โปรแกรมทำงานนั้นลงทะเบียนก็จะมีสถานะสำคัญ Service Worker มักลงทะเบียนโดยใช้องค์ประกอบ <script> ในบรรทัด ซึ่งหมายความว่าโปรแกรมแยกวิเคราะห์ HTML อาจพบโค้ดการลงทะเบียน Service Worker ก่อนที่เนื้อหาสำคัญของหน้าเว็บจะโหลดขึ้นมา

ซึ่งถือเป็นปัญหา ในกรณีที่เลวร้ายที่สุด โปรแกรมทำงานของบริการควรทำงานอย่างเป็นกลางและไม่ทำให้ประสิทธิภาพแย่ลง ผู้ใช้ต้องให้ความช่วยเหลือและลงทะเบียน Service Worker เมื่อเหตุการณ์ load ของหน้าเว็บเริ่มทำงาน ซึ่งช่วยลดโอกาสที่การแคชล่วงหน้าจะรบกวนการโหลดเนื้อหาสำคัญของหน้าเว็บ ซึ่งทำให้หน้าเว็บโต้ตอบได้เร็วขึ้นโดยไม่ต้องเผชิญหน้ากับคำขอของเครือข่ายสำหรับเนื้อหาที่อาจไม่จำเป็นแล้วในภายหลัง

คำนึงถึงปริมาณการใช้อินเทอร์เน็ต

ไม่ว่าจะเป็นช่วงเวลาใด การแคชล่วงหน้าเกี่ยวข้องกับการส่งคำขอเครือข่าย หากไม่มีการดูแลจัดการไฟล์ Manifest ของชิ้นงานที่จะแคชล่วงหน้าอย่างรอบคอบ ก็อาจทำให้ขยะเกิดขึ้นได้

ข้อมูลที่สูญเปล่านี้อาจมีข้อดีข้อเสียจากการแคชล่วงหน้า แต่ไม่ใช่ทุกคนที่จะเข้าถึงอินเทอร์เน็ตที่เร็วหรือแม้แต่แผนบริการข้อมูลแบบไม่จำกัด! เมื่อทำการแคชล่วงหน้า ให้ลองตัดเนื้อหาขนาดใหญ่ออกโดยเฉพาะและอาศัยการแคชรันไทม์เพื่อบันทึกเนื้อหาเหล่านั้นแทนการคิดว่าจะมีค่าใช้จ่ายสูง

การเริ่มต้นโปรแกรมทำงานของบริการอาจทำให้คำขอเครือข่ายล่าช้า

โปรแกรมทำงานของบริการจะทำงานในกระบวนการที่แยกจากโค้ดอื่นๆ ของเว็บไซต์ กระบวนการนี้จะเริ่มต้นและหยุดกลางคันบ่อยๆ เมื่อโปรแกรมทำงานของบริการต้องจัดการเหตุการณ์การดึงข้อมูลหลังจากไม่มีการใช้งาน เบราว์เซอร์จะต้องใช้เวลาในการเริ่มต้นโปรแกรมทำงานของบริการก่อน ค่าใช้จ่ายเพิ่มเติมนี้ก่อนจะดำเนินการจัดการคำขอนั้นน้อยเมื่อเทียบกับประโยชน์ของการแสดงการตอบกลับจากแคชแทนเครือข่าย

เมื่อใช้กลยุทธ์ที่ไม่สามารถแสดงจากแคชและต้องไปที่เครือข่าย โดยเฉพาะเมื่อต้องจัดการคำขอการนำทาง เวลาเปิดเครื่องจะเพิ่มการหน่วงเวลาเสมอ คำขอการนำทางอาจล่าช้าอย่างเห็นได้ชัดเนื่องจากมีการเปิดเครื่องทำงานช้า ทั้งนี้ขึ้นอยู่กับความสามารถของอุปกรณ์และ/หรือแรงกดของ CPU การทำให้ Service Worker ใช้งานได้โดยไม่ทราบความล่าช้านี้จะทำให้ผู้ใช้พบ Hit ประสิทธิภาพโดยไม่ตั้งใจ

ปัญหานี้ได้รับการแก้ไขแล้วด้วยการโหลดการนำทางล่วงหน้า แต่ยังไม่มีการรองรับในบางเบราว์เซอร์ แต่ทั้งนี้ก็คุ้มค่าที่จะลองพิจารณา ซึ่งจะมีข้อมูลต่อไปในเอกสารประกอบนี้

กลยุทธ์ที่ใช้แคชเป็นหลักอาจเริ่มทำงานเดิมได้

กลยุทธ์การแคชที่จะคำนึงถึงแคชก่อน หรือดูเฉพาะแคชจะเหมาะสำหรับทั้งการเข้าถึงและประสิทธิภาพแบบออฟไลน์ อย่างไรก็ตาม อาจทำให้เกิดปัญหาในบางกรณี

การแคชรันไทม์ของเนื้อหาแบบคงที่ที่ไม่มีเวอร์ชัน

Bundler มักสร้างเวอร์ชันเนื้อหาแบบคงที่โดยใช้แฮชตามเนื้อหาในชื่อไฟล์ (เช่น styles.a4edf38c.css) สำหรับโปรแกรมทำงานที่ใช้กลยุทธ์การแคชซึ่งจะคำนึงถึงแคชก่อนสำหรับเนื้อหาคงที่ และใช้กลยุทธ์ที่มุ่งเน้นเครือข่ายสำหรับมาร์กอัปหน้าเว็บ คุณไม่ควรพบปัญหาในการแคชเนื่องจากมีการอ้างอิงเนื้อหาที่อัปเดตในมาร์กอัปซึ่งจะดึงมาจากเครือข่ายเสมอ

ปัญหาเกิดขึ้นเมื่อระบบแคชเนื้อหาคงที่ที่ไม่กำหนดเวอร์ชันไว้ขณะรันไทม์โดยใช้กลยุทธ์เหล่านี้ หาก app.js เป็นผู้กำหนดฟังก์ชันการทำงานของเว็บไซต์และใช้กลยุทธ์รันไทม์แบบเน้นแคชเป็นหลัก ระบบจะอัปเดต app.js ในภายหลังโดยไม่เปลี่ยนชื่อไฟล์ เวอร์ชันที่แคชไว้ในตอนแรกจะยังแสดงจากแคชแทนการอัปเดต

วิธีแก้ปัญหาคือการใช้กลยุทธ์ที่ปรึกษากับเครือข่ายเพื่ออัปเดตข้อมูล เช่น ให้ความสำคัญกับเครือข่ายเป็นอันดับแรก หรือไม่มีการอัปเดตขณะตรวจสอบความถูกต้องใหม่ อีกทางเลือกหนึ่งคือ เครื่องมือสร้างไฟล์ Manifest สำหรับ Precache สำหรับเนื้อหาเหล่านั้น เนื่องจากตรรกะการแคชล่วงหน้าของ Workbox จะทำให้เนื้อหาเป็นปัจจุบันเสมอ

และควรพิจารณาการกำหนดเวอร์ชันของเนื้อหาแบบคงที่โดยใช้แฮชในชื่อเนื้อหาหรือในสตริงคำค้นหา วิธีนี้จะช่วยป้องกันปัญหาเนื้อหาที่ไม่มีอัปเดตในโปรแกรมทำงานของบริการที่ใช้กลยุทธ์รันไทม์แบบเน้นแคชเป็นหลักสำหรับเนื้อหาแบบคงที่

โควต้าพื้นที่เก็บข้อมูลความคิด

เป็นเรื่องปกติที่จะเปิดตัวการอัปเดต Service Worker เป็นครั้งคราว และเมื่อมีการเปิดตัวการอัปเดต แคชเก่าที่มีชื่อที่หมดอายุแล้วโดยปกติจะถูกตัดออกระหว่างการเปิดใช้ Service Worker ใหม่

อย่างไรก็ตาม การทำซ้ำ Service Worker บางรายการจะมีอายุการทำงานที่ยาวนาน หรือชื่อแคชอาจไม่ได้รับการอัปเดตในการอัปเดตใหม่ๆ เมื่อเกิดกรณีนี้ขึ้น เนื้อหาคงที่เก่าๆ อาจสะสมอยู่ในแคชเมื่อมีการเปิดตัวการอัปเดต เบราว์เซอร์จะกำหนดโควต้าพื้นที่เก็บข้อมูล และขีดจำกัดอาจแตกต่างกันไป นั่นเป็นเหตุผลที่คุณควรคำนึงถึงพวกเขา

Workbox บรรเทาปัญหาเหล่านี้ได้เป็นอย่างดี แต่คุณก็ยังเกินโควต้าพื้นที่เก็บข้อมูลได้ คุณควบคุมแคชได้ละเอียดยิ่งขึ้นด้วยโมดูลการหมดอายุของ Workbox

อย่าหวาดกลัว

การทำให้ Service Worker ใช้งานได้ไม่ใช่เรื่องเล็กๆ ถึงกระนั้น คุณไม่ควรต้องหวาดกลัวมากเพราะต้องมีการวางแผนและตระหนักถึงความสำคัญของการทำ Service Worker ให้กับ Workbox ขณะที่คุณดำเนินการต่อ เอกสารนี้จะช่วยคุณในการจัดการกับข้อกังวลเหล่านี้ด้วยความระมัดระวังและความมั่นใจ