เว็บแอปที่โหลดทันทีด้วยสถาปัตยกรรม Application Shell

เชลล์แอปพลิเคชันคือ HTML, CSS และ JavaScript ขั้นต่ำที่ขับเคลื่อนอินเทอร์เฟซผู้ใช้ เชลล์แอปพลิเคชันควรมีลักษณะดังนี้

• โหลดเร็ว
• แคชไว้
• แสดงเนื้อหาแบบไดนามิก

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

ข้อมูลเบื้องต้น

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

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

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

ตัวอย่างด้านล่างแสดงการโหลดครั้งแรกของแอปที่ใช้สถาปัตยกรรมนี้เพื่อเน้นประเด็น โปรดสังเกตข้อความแจ้ง "แอปพร้อมใช้งานแบบออฟไลน์แล้ว" ที่ด้านล่างของหน้าจอ หากการอัปเดตเชลล์พร้อมใช้งานในภายหลัง เราจะแจ้งให้ผู้ใช้รีเฟรชเพื่อใช้เวอร์ชันใหม่ได้

Service Worker คืออะไร

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

นอกจากนี้ Service Worker ยังมีชุด API ที่จำกัดเมื่อเทียบกับ JavaScript ในบริบทการท่องเว็บปกติ ซึ่งถือเป็นมาตรฐานสำหรับผู้ปฏิบัติงานบนเว็บ ผู้ให้บริการไม่สามารถเข้าถึง DOM แต่สามารถเข้าถึงสิ่งต่างๆ เช่น Cache API และสามารถส่งคำขอเครือข่ายโดยใช้ Fetch API นอกจากนี้ คุณยังใช้ IndexedDB API และ postMessage() เพื่อเก็บข้อมูลไว้ถาวรและรับส่งข้อความระหว่าง Service Worker กับหน้าที่ควบคุมได้ด้วย เหตุการณ์ Push ที่ส่งจากเซิร์ฟเวอร์สามารถเรียกใช้ Notification API เพื่อเพิ่มการมีส่วนร่วมของผู้ใช้

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

หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับ Service Worker อย่างละเอียด โปรดอ่านข้อมูลเบื้องต้นเกี่ยวกับ Service Worker

ประโยชน์ด้านประสิทธิภาพ

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

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

ในการทดสอบสถาปัตยกรรมนี้ในอุปกรณ์จริง เราได้เรียกใช้ตัวอย่างเชลล์แอปพลิเคชันใน WebPageTest.org และแสดงผลลัพธ์ด้านล่าง

การทดสอบที่ 1: การทดสอบผ่านสายกับ Nexus 5 โดยใช้ Chrome Dev

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

การทดสอบที่ 2: การทดสอบใน 3G ด้วย Nexus 5 โดยใช้ Chrome Dev

นอกจากนี้ เรายังทดสอบตัวอย่างด้วยการเชื่อมต่อ 3G ที่ช้ากว่าเล็กน้อยได้ด้วย ครั้งนี้การแสดงผลที่มีความหมายครั้งแรกใช้เวลา 2.5 วินาทีในการเข้าชมครั้งแรก หน้าเว็บใช้เวลาโหลดจนเสร็จสมบูรณ์ 7.1 วินาที เมื่อใช้การแคช Service Worker การกลับมาเข้าชมซ้ำจะแสดงผลลัพธ์ที่สื่อความหมายและโหลดเสร็จสมบูรณ์ใน 0.8 วินาที

มุมมองอื่นๆ เล่าเรื่องราวที่คล้ายกัน เปรียบเทียบกับ 3 วินาทีที่ใช้ในการแสดงผลที่มีความหมายครั้งแรกในแอปพลิเคชันเชลล์

เหลือเพียง 0.9 วินาทีเมื่อโหลดหน้าเดียวกันจากแคช Service Worker ผู้ใช้ปลายทางจึงประหยัดเวลาได้กว่า 2 วินาที

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

Service Worker ทำให้เราต้องคิดใหม่เกี่ยวกับโครงสร้างแอปไหม

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

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

แล้วการเพิ่มประสิทธิภาพแบบต่อเนื่องล่ะ

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

ด้านล่างนี้คุณจะเห็นเวอร์ชันเต็มที่แสดงผลใน Chrome, Firefox Nightly และ Safari ที่ด้านซ้ายสุด คุณจะเห็นเวอร์ชัน Safari ที่ระบบแสดงผลเนื้อหาบนเซิร์ฟเวอร์โดยไม่มี Service Worker ทางด้านขวาเราจะเห็น Chrome และ Firefox เวอร์ชัน Nightly ที่ทำงานด้วย Service Worker

สถาปัตยกรรมนี้เหมาะสําหรับกรณีใด

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

มีแอปเวอร์ชันที่ใช้งานจริงที่ใช้รูปแบบนี้หรือไม่

สถาปัตยกรรมเชลล์แอปพลิเคชันทำได้ด้วยการเปลี่ยนแปลง UI ของแอปพลิเคชันโดยรวมเพียงไม่กี่อย่าง และใช้งานได้ดีกับเว็บไซต์ขนาดใหญ่ เช่น Progressive Web App ของ I/O 2015 ของ Google และกล่องจดหมายของ Google

เชลล์แอปพลิเคชันแบบออฟไลน์เป็นปัจจัยสำคัญในการเพิ่มประสิทธิภาพ และยังแสดงให้เห็นอย่างชัดเจนในแอป Wikipedia ออฟไลน์ของ Jake Archibald และเว็บแอปแบบโปรเกรสซีฟของ Flipkart Lite

อธิบายสถาปัตยกรรม

ในระหว่างการโหลดครั้งแรก เป้าหมายของคุณคือแสดงเนื้อหาที่มีความหมายบนหน้าจอของผู้ใช้โดยเร็วที่สุด

การโหลดครั้งแรกและการโหลดหน้าอื่นๆ

โดยทั่วไปแล้ว สถาปัตยกรรม App Shell จะมีลักษณะดังนี้

• ให้ความสําคัญกับการโหลดครั้งแรก แต่ให้ Service Worker แคชเชลล์แอปพลิเคชันเพื่อให้ไม่ต้องดึงข้อมูลเชลล์จากเครือข่ายซ้ำเมื่อเข้าชมซ้ำ

• โหลดส่วนที่เหลือแบบ Lazy Load หรือโหลดในเบื้องหลัง ตัวเลือกที่ดีอย่างหนึ่งคือการใช้การแคชแบบอ่านผ่านสำหรับเนื้อหาแบบไดนามิก

• ใช้เครื่องมือ Service Worker เช่น sw-precache เพื่อแคชและอัปเดต Service Worker ที่จัดการเนื้อหาแบบคงที่อย่างน่าเชื่อถือ (ดูข้อมูลเพิ่มเติมเกี่ยวกับ sw-precache ภายหลัง)

วิธีดำเนินการมีดังนี้

• เซิร์ฟเวอร์จะส่งเนื้อหา HTML ที่ไคลเอ็นต์แสดงผลได้ และใช้ส่วนหัวการหมดอายุของแคช HTTP ในอนาคตอันไกลโพ้นเพื่อรองรับเบราว์เซอร์ที่ไม่รองรับ Service Worker โดยจะแสดงชื่อไฟล์โดยใช้แฮชเพื่อให้ทั้ง "การกำหนดเวอร์ชัน" และการอัปเดตได้ง่ายในภายหลังในวงจรของแอปพลิเคชัน

• หน้าเว็บจะมีสไตล์ CSS แบบอินไลน์ในแท็ก <style> ภายในเอกสาร <head> เพื่อให้ Shell ของแอปพลิเคชันแสดงผลครั้งแรกอย่างรวดเร็ว แต่ละหน้าจะโหลด JavaScript ที่จําเป็นสําหรับมุมมองปัจจุบันแบบไม่สอดคล้องกัน เนื่องจาก CSS ไม่สามารถโหลดแบบไม่พร้อมกันได้ เราจึงขอสไตล์โดยใช้ JavaScript ได้ เนื่องจากเป็นการดำเนินการแบบไม่พร้อมกัน ไม่ใช่แบบขับเคลื่อนโดยโปรแกรมแยกวิเคราะห์และแบบพร้อมกัน นอกจากนี้ เรายังใช้ประโยชน์จาก requestAnimationFrame() เพื่อหลีกเลี่ยงกรณีที่อาจมีการตีกลับจากแคชอย่างรวดเร็วและทำให้สไตล์กลายเป็นส่วนหนึ่งของเส้นทางการแสดงผลที่สำคัญโดยไม่ตั้งใจ requestAnimationFrame() จะบังคับให้แสดงเฟรมแรกก่อนที่จะโหลดสไตล์ อีกทางเลือกหนึ่งคือการใช้โปรเจ็กต์อย่าง loadCSS ของ Filament Group เพื่อขอ CSS แบบไม่พร้อมกันโดยใช้ JavaScript

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

การใช้งานจริง

เราได้เขียนตัวอย่างที่ใช้งานได้อย่างสมบูรณ์โดยใช้สถาปัตยกรรมเชลล์แอปพลิเคชัน, JavaScript เวอร์ชัน ES2015 พื้นฐานสําหรับไคลเอ็นต์ และ Express.js สําหรับเซิร์ฟเวอร์ แน่นอนว่าคุณใช้แพ็กเกจของตัวเองสำหรับส่วนไคลเอ็นต์หรือเซิร์ฟเวอร์ (เช่น PHP, Ruby, Python) ก็ได้

วงจรของ Service Worker

สําหรับโปรเจ็กต์เชลล์แอปพลิเคชัน เราใช้ sw-precache ซึ่งให้บริการวงจรของ Service Worker ดังนี้

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

บิตเซิร์ฟเวอร์

ในสถาปัตยกรรมนี้ คอมโพเนนต์ฝั่งเซิร์ฟเวอร์ (ในกรณีของเราเขียนด้วย Express) ควรจัดการเนื้อหาและการแสดงผลแยกกัน เนื้อหาอาจเพิ่มลงในเลย์เอาต์ HTML ซึ่งส่งผลให้หน้าเว็บแสดงผลแบบคงที่ หรืออาจแสดงแยกต่างหากและโหลดแบบไดนามิกก็ได้

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

• ระบบจะกำหนดปลายทางสำหรับ 3 ส่วนของแอปพลิเคชัน ได้แก่ URL ที่แสดงต่อผู้ใช้ (ดัชนี/ไวลด์การ์ด) เชลล์แอปพลิเคชัน (Service Worker) และ HTML บางส่วน

• ปลายทางแต่ละรายการจะมีตัวควบคุมที่ดึงเลย์เอาต์ handlebar ซึ่งจะดึงข้อมูลบางส่วนและมุมมองของ handlebar ได้ พูดง่ายๆ คือ ข้อมูลบางส่วนคือมุมมองที่เป็นกลุ่มของ HTML ที่คัดลอกไปยังหน้าสุดท้าย หมายเหตุ: เฟรมเวิร์ก JavaScript ที่มีการซิงค์ข้อมูลขั้นสูงขึ้นมักจะพอร์ตไปยังสถาปัตยกรรม Application Shell ได้ง่ายกว่ามาก โดยมักจะใช้การเชื่อมโยงข้อมูลและการซิงค์แทนการใช้ส่วนย่อย

• ผู้ใช้จะเห็นหน้าเว็บแบบคงที่ที่มีเนื้อหาในตอนแรก หน้านี้จะลงทะเบียน Service Worker (หากรองรับ) ซึ่งจะแคชเชลล์แอปพลิเคชันและทุกอย่างที่เชลล์นั้นใช้ (CSS, JS ฯลฯ)

• จากนั้นเชลล์แอปจะทําหน้าที่เป็นเว็บแอปแบบหน้าเดียว โดยใช้ JavaScript เพื่อ XHR ในเนื้อหาสําหรับ URL ที่เฉพาะเจาะจง การเรียก XHR จะทำกับปลายทาง /partials* ซึ่งจะแสดงผล HTML, CSS และ JS บางส่วนที่จําเป็นในการแสดงเนื้อหานั้น หมายเหตุ: การดําเนินการนี้ทำได้หลายวิธี โดย XHR เป็นเพียงวิธีหนึ่งเท่านั้น แอปพลิเคชันบางรายการจะแทรกข้อมูล (อาจใช้ JSON) ไว้ในบรรทัดแรกสำหรับการแสดงผลครั้งแรก จึงไม่ใช่ "แบบคงที่" ในความหมายของ HTML แบบแบน

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

การกำหนดเวอร์ชันของไฟล์

คำถามหนึ่งที่อาจเกิดขึ้นคือวิธีจัดการกับเวอร์ชันและการอัปเดตไฟล์ ตัวเลือกนี้จะแตกต่างกันไปตามแอปพลิเคชัน โดยมีตัวเลือกดังนี้

• เครือข่ายก่อนและใช้เวอร์ชันที่แคชไว้หากไม่

• เครือข่ายเท่านั้นและใช้งานไม่ได้หากออฟไลน์

• แคชเวอร์ชันเก่าไว้แล้วอัปเดตในภายหลัง

สําหรับเชลล์แอปพลิเคชันเอง คุณควรใช้แนวทางแคชก่อนสําหรับการตั้งค่า Service Worker หากคุณไม่ได้แคชเชลล์แอปพลิเคชัน แสดงว่าคุณไม่ได้ใช้สถาปัตยกรรมอย่างถูกต้อง

เครื่องมือ

เราดูแลไลบรารีตัวช่วยของ Service Worker หลายรายการที่ทําให้กระบวนการแคชเชลล์ของแอปพลิเคชันล่วงหน้าหรือจัดการรูปแบบการแคชทั่วไปได้ง่ายขึ้น

ใช้ sw-precache สำหรับเชลล์แอปพลิเคชัน

การใช้ sw-precache เพื่อแคชเชลล์แอปพลิเคชันควรจัดการข้อกังวลเกี่ยวกับการแก้ไขไฟล์ คำถามเกี่ยวกับการติดตั้ง/การเปิดใช้งาน และสถานการณ์การดึงข้อมูลสําหรับเชลล์แอป วาง sw-precache ลงในกระบวนการบิลด์ของแอปพลิเคชัน และใช้ไวลด์การ์ดที่กำหนดค่าได้เพื่อรับทรัพยากรแบบคงที่ แทนที่จะเขียนสคริปต์ Service Worker ด้วยตนเอง ให้ sw-precache สร้างสคริปต์ที่จัดการแคชอย่างปลอดภัยและมีประสิทธิภาพโดยใช้ตัวแฮนเดิลการดึงข้อมูลแบบแคชก่อน

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

ใช้ sw-toolbox สำหรับการแคชรันไทม์

ใช้ sw-toolbox สำหรับการแคชรันไทม์ด้วยกลยุทธ์ที่แตกต่างกันไปตามทรัพยากร

• cacheFirst สําหรับรูปภาพ พร้อมด้วยแคชที่มีชื่อเฉพาะซึ่งมีนโยบายการหมดอายุที่กําหนดเองเป็น N maxEntries

• networkFirst หรือเร็วที่สุดสำหรับคำขอ API ทั้งนี้ขึ้นอยู่กับความใหม่ของเนื้อหาที่ต้องการ คุณอาจใช้ "เร็วที่สุด" ได้ แต่หากมีฟีด API ที่อัปเดตบ่อย ให้ใช้ networkFirst

บทสรุป

สถาปัตยกรรมเชลล์แอปพลิเคชันมีประโยชน์หลายประการ แต่เหมาะกับแอปพลิเคชันบางคลาสเท่านั้น รูปแบบนี้ยังใหม่อยู่และควรประเมินความพยายามและประโยชน์ด้านประสิทธิภาพโดยรวมของสถาปัตยกรรมนี้

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

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

ขอขอบคุณผู้ตรวจสอบของเรา Jeff Posnick, Paul Lewis, Alex Russell, Seth Thompson, Rob Dodson, Taylor Savage และ Joe Medley