การทำให้ Service Worker ใช้งานได้อาจเปลี่ยนแปลงลักษณะการทำงานของเว็บไซต์โดยไม่คาดคิด เนื่องจาก Workbox ทำให้การเขียนและทำให้ Service Worker ใช้งานได้เป็นเรื่องง่าย จึงอาจพลาดผลกระทบบางอย่างที่โปรแกรมทำงานของบริการมีในเว็บไซต์เมื่อทำให้ใช้งานได้แล้ว
ซึ่งไม่ได้หมายความว่าการใช้ Workbox จะส่งผลให้เกิดผลลัพธ์ที่ไม่ดี เพียงแต่ความสะดวกสบายที่มีอาจทำให้พบข้อผิดพลาดได้ง่ายขึ้นถ้าผู้ใช้ไม่ทราบถึงสิ่งที่มาพร้อมกับการทำให้ Service Worker ใช้งานได้
การแคชล่วงหน้า
การแคชล่วงหน้าได้อธิบายไว้ในเอกสารเหล่านี้ก่อนหน้านี้ โดยไม่ได้กล่าวถึงวิธีที่แนวทางปฏิบัตินั้นๆ ทำให้เกิดผลตรงกันข้ามได้ คุณอาจพบปัญหาหากใช้การแคชล่วงหน้ากับเนื้อหามากเกินไป หรือหาก Service Worker ลงทะเบียนไว้ก่อนที่หน้าเว็บจะมีโอกาสโหลดเนื้อหาที่สำคัญเสร็จ
เนื่องจากลักษณะการทำงานเริ่มต้นของ workbox-webpack-plugin
คือการสั่งให้ Service Worker แคชเนื้อหาที่สร้างขึ้นล่วงหน้าโดยอัตโนมัติ นี่จึงอาจเป็นปัญหาในลักษณะที่คุณพลาดได้ง่าย เนื่องจากอุปสรรคในการนำไปใช้งานอยู่ในระดับต่ำ
![เอาต์พุตของเทอร์มินัล](https://developer.chrome.google.cn/static/docs/workbox/service-worker-deployment/image/terminal-output-6714930555301.png?authuser=6&hl=th)
workbox-webpack-plugin.
ในตัวอย่างนี้ แคชล่วงหน้าให้ชิ้นงาน 14 รายการในโปรเจ็กต์ปัจจุบันรวมเป็น 352 กิโลไบต์โดยค่าเริ่มต้นเมื่อ 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 ขณะที่คุณดำเนินการต่อ เอกสารนี้จะช่วยคุณในการจัดการกับข้อกังวลเหล่านี้ด้วยความระมัดระวังและความมั่นใจ