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

แอดดี ออสมานี

Twitter GitHub

Matt Gaunt

Twitter หน้าแรก

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

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

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

ที่มา

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

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

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

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

Service Worker คืออะไร

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

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

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

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

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

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

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

หากต้องการทดสอบสถาปัตยกรรมนี้ในอุปกรณ์จริง เราได้เรียกใช้ตัวอย่าง Application Shell ใน 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 วินาทีที่ใช้ในการทำให้ได้การแสดงผลที่มีความหมายครั้งแรกใน Application Shell

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

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

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

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

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

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

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

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

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

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

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

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

Shell แอปพลิเคชันแบบออฟไลน์เป็นชัยชนะที่สำคัญและยังแสดงให้เห็นในแอป Wikipedia แบบออฟไลน์ของ Jake Archibald และ Progressive Web App ของ Flipkart Lite

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

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

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

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

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

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

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

หากต้องการทำสิ่งต่อไปนี้

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

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

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

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

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

วงจรการทำงานของ Service Worker

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

การใช้เครื่องมือ

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

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

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

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

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

ใช้ 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