Progressive Web App ที่ดีเป็นอย่างไร

Pete LePage
Sam Richard

Progressive Web App (PWA) สร้างและเพิ่มประสิทธิภาพด้วย API ที่ทันสมัยเพื่อมอบความสามารถ ความน่าเชื่อถือ และการติดตั้งที่ดียิ่งขึ้นในขณะที่เข้าถึงทุกคน ทุกที่ และทุกอุปกรณ์ได้ด้วยโค้ดเบสเดียว ใช้รายการตรวจสอบและคําแนะนําหลักและเหมาะสมที่สุด เพื่อเป็นแนวทางในการสร้างประสบการณ์ที่ดีที่สุด

รายการตรวจสอบหลักของ Progressive Web App

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

เริ่มต้นเร็ว ประสิทธิภาพแรงไม่มีตก

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

ทำไม

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

แม้ว่าแอปพลิเคชันทั้งหมดจะมีข้อกำหนดที่แตกต่างกัน แต่การตรวจสอบประสิทธิภาพใน Lighthouse จะอิงตาม Core Web Vitals และการได้คะแนน สูงในการตรวจสอบเหล่านั้นจะทำให้ผู้ใช้มีแนวโน้มที่จะได้รับประสบการณ์ที่น่าพึงพอใจมากขึ้น นอกจากนี้ คุณยังใช้ PageSpeed Insights หรือรายงานประสบการณ์ของผู้ใช้ Chrome เพื่อรับข้อมูลประสิทธิภาพการใช้งานจริงสำหรับเว็บแอปได้ด้วย

อย่างไร

โปรดอ่านคำแนะนำเกี่ยวกับเวลาในการโหลดที่รวดเร็วเพื่อดูวิธีทำให้ PWA เริ่มทำงานได้อย่างรวดเร็วและทำงานเร็วอย่างต่อเนื่อง

ใช้งานได้ในทุกเบราว์เซอร์

ผู้ใช้สามารถใช้เบราว์เซอร์ใดก็ได้ที่ต้องการเพื่อเข้าถึงเว็บแอปก่อนที่จะติดตั้ง

ทำไม

Progressive Web App เป็นเว็บแอปก่อน ซึ่งหมายความว่าต้องทำงานได้ในเบราว์เซอร์ต่างๆ

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

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

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

อย่างไร

Resilient Web Design ของ Jeremy Keith เป็นแหล่งข้อมูลที่ยอดเยี่ยมซึ่งอธิบายวิธีคิดเกี่ยวกับการออกแบบเว็บในวิธีการแบบค่อยเป็นค่อยไปที่ใช้ได้กับทุกเบราว์เซอร์

อ่านเพิ่มเติม

ปรับตามขนาดหน้าจอ

ผู้ใช้สามารถใช้ PWA ของคุณได้ในทุกขนาดหน้าจอ และเนื้อหาทั้งหมดจะพร้อมใช้งาน ในทุกขนาด Viewport

ทำไม

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

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

"อุปกรณ์เคลื่อนที่กำหนดให้ทีมพัฒนาซอฟต์แวร์มุ่งเน้นเฉพาะข้อมูลและการดำเนินการที่สำคัญที่สุดในแอปพลิเคชัน หน้าจอขนาด 320 x 480 พิกเซลไม่มีพื้นที่สำหรับองค์ประกอบที่ไม่จำเป็น คุณต้องจัดลำดับความสำคัญ"

อย่างไร

มีแหล่งข้อมูลมากมายเกี่ยวกับการออกแบบที่ปรับเปลี่ยนตามพื้นที่โฆษณา ซึ่งรวมถึง บทความต้นฉบับของ Ethan Marcotte และชุดแนวคิดที่สำคัญ ที่เกี่ยวข้อง รวมถึงหนังสือและการพูดคุยมากมาย

หากต้องการจำกัดการสนทนานี้ให้เหลือเฉพาะด้านเนื้อหาของการออกแบบที่ตอบสนองตามอุปกรณ์ โปรดดูที่

แสดงหน้าเว็บแบบออฟไลน์ที่กำหนดเอง

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

ทำไม

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

อย่างไร

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

ติดตั้งได้

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

ทำไม

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

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

อย่างไร

ทำตามคำแนะนำในการติดตั้ง

เช็กลิสต์ Progressive Web App ที่ดีที่สุด

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

มอบประสบการณ์การใช้งานแบบออฟไลน์

ในกรณีที่ไม่จำเป็นต้องมีการเชื่อมต่ออย่างเคร่งครัด แอปจะทำงานในโหมดออฟไลน์เหมือนกับในโหมดออนไลน์

ทำไม

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

PWA ที่ทำงานแบบออฟไลน์จะมอบประสบการณ์การใช้งานที่เหมือนแอปจริงๆ ให้แก่ผู้ใช้

อย่างไร

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

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

เข้าถึงได้อย่างเต็มที่

การโต้ตอบของผู้ใช้ทั้งหมดเป็นไปตามมาตรฐานสากลของหลักเกณฑ์การช่วยเหลือพิเศษสำหรับเนื้อหาเว็บไซต์ (WCAG) ฉบับล่าสุด

ทำไม

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

อย่างไร

ข้อมูลเบื้องต้นเกี่ยวกับการช่วยเหลือพิเศษบนเว็บของ W3C เป็นจุดเริ่มต้นที่ดี การทดสอบการช่วยเหลือพิเศษส่วนใหญ่ต้องดำเนินการด้วยตนเอง การตรวจสอบการช่วยเหลือพิเศษใน Lighthouse, axe และ Accessibility Insights จะช่วยให้คุณ ทำการทดสอบการช่วยเหลือพิเศษบางอย่างโดยอัตโนมัติได้ นอกจากนี้ การใช้องค์ประกอบที่ถูกต้องตามความหมายแทนการสร้างองค์ประกอบเหล่านั้นขึ้นมาเองก็สำคัญเช่นกัน เช่น องค์ประกอบ <a> และ <button> ซึ่งจะช่วยให้มั่นใจได้ว่าเมื่อคุณต้องการสร้างฟีเจอร์ขั้นสูง เพิ่มเติม ระบบจะตอบสนองความคาดหวังด้านการช่วยเหลือพิเศษ เช่น เมื่อใดควรใช้ ลูกศรเทียบกับแท็บ

การ์ดโภชนาการ A11Y มีคำแนะนำที่ยอดเยี่ยม เกี่ยวกับเรื่องนี้สำหรับคอมโพเนนต์ทั่วไปบางอย่าง

ผู้ใช้ค้นพบ PWA ของคุณได้ง่ายๆ ผ่านการค้นหา

ทำไม

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

อย่างไร

เริ่มต้นด้วยการตรวจสอบว่า URL แต่ละรายการมีชื่อและคำอธิบายเมตา ที่สื่อความหมายและไม่ซ้ำกัน จากนั้นคุณสามารถใช้ Google Search Console และการตรวจสอบการเพิ่มประสิทธิภาพเครื่องมือค้นหา ใน Lighthouse เพื่อแก้ไขข้อบกพร่องและปัญหาเกี่ยวกับการค้นพบ PWA ของคุณ

นอกจากนี้ คุณยังใช้เครื่องมือสำหรับเจ้าของเว็บไซต์ของ Bing หรือ Yandex และพิจารณารวม Structured Data โดยใช้สคีมาจาก Schema.org ใน PWA ได้ด้วย

ใช้ได้กับอินพุตทุกประเภท

ผู้ใช้สามารถใช้ PWA ของคุณได้ทั้งกับเมาส์ แป้นพิมพ์ สไตลัส หรือการสัมผัส

ทำไม

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

อย่างไร

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

ให้บริบทสำหรับคำขอสิทธิ์

เมื่อขอสิทธิ์ใช้ API ที่มีประสิทธิภาพ ให้ระบุบริบทและขอเฉพาะเมื่อจำเป็นต้องใช้ API เท่านั้น

ทำไม

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

แต่ให้ทริกเกอร์ข้อความแจ้งเหล่านั้นหลังจากให้เหตุผลในบริบทแก่ผู้ใช้ว่าทำไมคุณจึงต้องการสิทธิ์นั้น

อย่างไร

บทความUX สิทธิ์และวิธีที่ถูกต้องในการขอสิทธิ์จากผู้ใช้ของ UX Planet เป็นแหล่งข้อมูลที่ดีในการทำความเข้าใจวิธีออกแบบข้อความแจ้งขอสิทธิ์ที่ใช้ได้กับ PWA ทั้งหมด แม้ว่าจะเน้นที่อุปกรณ์เคลื่อนที่ก็ตาม

ปฏิบัติตามแนวทางปฏิบัติแนะนำสำหรับโค้ดที่สมบูรณ์

การดูแลโค้ดเบสให้มีคุณภาพจะช่วยให้คุณบรรลุเป้าหมายและส่งมอบ ฟีเจอร์ใหม่ๆ ได้ง่ายขึ้น

ทำไม

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

อย่างไร

เรามีการตรวจสอบที่มีลำดับความสำคัญสูงหลายอย่างเพื่อให้มั่นใจว่าโค้ดเบสมีคุณภาพดี

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