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

Addy Osmani

Matt Gaunt

Application Shell คือ HTML, CSS และ JavaScript ที่ขับเคลื่อนอินเทอร์เฟซผู้ใช้ Application Shell ควร

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

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

ที่มา

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

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

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

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

Service Worker คืออะไรนะ

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

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

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

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

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

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

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

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

การทดสอบ 1: การทดสอบสายเคเบิลกับ Nexus 5 โดยใช้ Chrome Dev

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

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

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

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

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

ประสิทธิภาพการทำงานที่คล้ายคลึงกันและเชื่อถือได้สำหรับแอปพลิเคชันของคุณเองนั้นเป็นไปได้ด้วยสถาปัตยกรรม Application Shell

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

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

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

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

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

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

เมื่อใดที่ควรใช้สถาปัตยกรรมนี้

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

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

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

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

อธิบายเกี่ยวกับสถาปัตยกรรม

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

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

โดยทั่วไป สถาปัตยกรรม Application Shell จะมีคุณสมบัติดังนี้

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

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

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

เพื่อให้บรรลุเป้าหมายนี้

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

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

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

การนำไปใช้งานจริง

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

วงจรชีวิตของโปรแกรมทำงานของบริการ

สำหรับโปรเจ็กต์ Application Shell เราใช้ sw-precache ซึ่งมีวงจรชีวิตของโปรแกรมทำงานของบริการต่อไปนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หมายเหตุ: ตัวอย่าง Application Shell ไม่ได้ใช้ (ในขณะที่เขียน) ใช้การกำหนดเวอร์ชันไฟล์สำหรับเนื้อหาที่อ้างอิงในการแสดงผลแบบคงที่ ซึ่งมักจะใช้สำหรับการไม่ใช้แคช เราหวังว่าจะเพิ่มฟีเจอร์นี้ในอนาคตอันใกล้นี้ ส่วน Service Worker จะมีเวอร์ชันเป็น sw-precache (ครอบคลุมในส่วนเครื่องมือ)

เครื่องมือ

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

ใช้ sw-precache สำหรับ Application Shell ของคุณ

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

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

ใช้กล่องเครื่องมือ Sw-tool สำหรับการแคชรันไทม์

ใช้ sw-toolbox สำหรับการแคชรันไทม์ที่มีกลยุทธ์ต่างๆ โดยขึ้นอยู่กับทรัพยากร ดังนี้

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

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

บทสรุป

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

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

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

ขอขอบคุณผู้รีวิวของเรา ได้แก่ Jeff Posnick, Paul Lewis, Alex Russell, Seth Thompson, Rob Dodson, Taylor Savage และ Joe Medley