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 เป็นแหล่งข้อมูลที่ยอดเยี่ยมในการอธิบายวิธีคำนึงถึงการออกแบบเว็บโดยใช้วิธีการแบบโพรเกรสซีฟแบบข้ามเบราว์เซอร์นี้
อ่านเพิ่มเติม
- การศึกษาการเพิ่มประสิทธิภาพแบบต่อเนื่องของ A List Apart เป็นบทความแนะนำหัวข้อนี้ที่ดี
- บทความ "Progressive Enhancement: What It Is, And How To Use It?" ของ Smashing Magazine จะให้ข้อมูลเบื้องต้นที่นำไปปฏิบัติได้จริงและลิงก์ไปยังหัวข้อที่ซับซ้อนขึ้น
- บทความเกี่ยวกับ การใช้การตรวจหาฟีเจอร์ของ MDN พูดถึงวิธีตรวจหาฟีเจอร์ด้วยการค้นหาฟีเจอร์นั้นโดยตรง
ผู้ใช้สามารถใช้ PWA ในหน้าจอทุกขนาดและเนื้อหาทั้งหมดก็พร้อมใช้งานในวิวพอร์ตขนาดใดก็ได้
ทำไม
อุปกรณ์มีหลากหลายขนาด และผู้ใช้อาจใช้แอปพลิเคชันของคุณในขนาดที่หลากหลาย แม้ในอุปกรณ์เครื่องเดียวกันก็ตาม ดังนั้นจึงต้องตรวจสอบว่าไม่เพียงแต่เนื้อหาของคุณพอดีกับวิวพอร์ตเท่านั้น แต่ยังต้องใช้ฟีเจอร์และเนื้อหาทั้งหมดของเว็บไซต์ในวิวพอร์ตทุกขนาดด้วย
งานที่ผู้ใช้ต้องการทำและเนื้อหาที่ผู้ใช้ต้องการเข้าถึงจะไม่เปลี่ยนแปลงตามขนาดวิวพอร์ต คุณจัดเรียงเนื้อหาใหม่ตามขนาดวิวพอร์ตที่ต่างกันได้ ซึ่งทั้งหมดควรอยู่ที่นั่น ไม่ทางใดก็ทางหนึ่ง อันที่จริงแล้ว Luke Wroblewski ได้เขียนอธิบายไว้ในหนังสือ Mobile First ว่า การเริ่มจากสิ่งเล็กๆ และปรับเปลี่ยนการออกแบบสำหรับหน้าจอขนาดใหญ่จะช่วยพัฒนาการออกแบบเว็บไซต์ได้ ดังนี้
อุปกรณ์เคลื่อนที่กำหนดให้ทีมพัฒนาซอฟต์แวร์ต้องเน้นเฉพาะข้อมูลและการดำเนินการที่สำคัญที่สุดในแอปพลิเคชันเท่านั้น หน้าจอขนาด 320 x 480 พิกเซลไม่มีพื้นที่เพียงพอสำหรับองค์ประกอบที่ไม่จำเป็นและไม่จำเป็น คุณต้องจัดลำดับความสำคัญ
อย่างไร
การออกแบบที่ตอบสนองได้นั้นมีแหล่งข้อมูลมากมาย ซึ่งรวมถึงบทความต้นฉบับของ Ethan Marcotte, ชุดแนวคิดสําคัญที่เกี่ยวข้องกับการออกแบบนี้ รวมถึงหนังสือและการบรรยายมากมาย หากต้องการจำกัดการพูดคุยนี้ให้แคบลงเฉพาะแง่มุมเนื้อหาของการออกแบบที่ตอบสนองตามอุปกรณ์ โปรดดูการออกแบบที่เน้นเนื้อหาเป็นหลักและเลย์เอาต์ที่ตอบสนองตามอุปกรณ์ซึ่งเน้นเนื้อหาเป็นหลัก สุดท้ายนี้ แม้ว่าบทความจะมุ่งเน้นที่อุปกรณ์เคลื่อนที่ แต่บทเรียนในตำนานร้ายแรง 7 ข้อเกี่ยวกับอุปกรณ์เคลื่อนที่โดย Josh Clark นั้นเกี่ยวข้องกับการแสดงผลขนาดย่อของเว็บไซต์ที่ปรับเปลี่ยนได้เช่นเดียวกับอุปกรณ์เคลื่อนที่โดยทั่วไป
เมื่อผู้ใช้ออฟไลน์ การที่ผู้ใช้อยู่ใน PWA จะให้ประสบการณ์การใช้งานที่ราบรื่นกว่าการกลับไปที่หน้าออฟไลน์ของเบราว์เซอร์เริ่มต้น
ทำไม
ผู้ใช้คาดหวังให้แอปที่ติดตั้งไว้ทํางานได้ไม่ว่าจะมีสถานะการเชื่อมต่ออย่างไร แอปเฉพาะแพลตฟอร์มจะไม่แสดงหน้าว่างเมื่อออฟไลน์ และ PWA ไม่ควรแสดงหน้าออฟไลน์เริ่มต้นของเบราว์เซอร์ การมอบประสบการณ์การใช้งานแบบออฟไลน์ที่กำหนดเอง ทั้งเมื่อผู้ใช้ไปยัง URL ที่ไม่ได้แคชและเมื่อผู้ใช้พยายามใช้ฟีเจอร์ที่ต้องเชื่อมต่อ จะช่วยให้ประสบการณ์การใช้งานเว็บของคุณรู้สึกเหมือนเป็นส่วนหนึ่งของอุปกรณ์ที่กำลังใช้งาน
อย่างไร
ในระหว่างเหตุการณ์ install ของ Service Worker คุณสามารถแคชหน้าเว็บออฟไลน์ที่กำหนดเองไว้ล่วงหน้าเพื่อแสดงเมื่อผู้ใช้ออฟไลน์ โปรดดูหัวข้อสร้างหน้าสำรองสำหรับใช้เมื่อออฟไลน์เพื่อดูวิธีติดตั้งใช้งานด้วยตนเอง โปรดทราบว่า Chrome จะแสดงหน้าออฟไลน์พื้นฐานหากไม่มีการระบุไว้
ผู้ใช้ที่ติดตั้งหรือเพิ่มแอปลงในอุปกรณ์มีแนวโน้มที่จะมีส่วนร่วมกับแอปเหล่านั้นมากกว่า
ทำไม
การติดตั้ง Progressive Web App ช่วยให้แอปมีรูปลักษณ์ ให้ความรู้สึก และทำงานเหมือนกับแอปอื่นๆ ที่ติดตั้งไว้ โดยจะเปิดจากตําแหน่งเดียวกับที่ผู้ใช้เปิดแอปอื่นๆ โดยแอปจะทำงานในหน้าต่างแอปของตัวเองแยกจากเบราว์เซอร์ และจะปรากฏในรายการงานเช่นเดียวกับแอปอื่นๆ
เช่นเดียวกับแอปเฉพาะอุปกรณ์ ผู้ใช้ที่ติดตั้งแอปของคุณคือกลุ่มเป้าหมายที่มีส่วนร่วมมากที่สุด และมักจะมีเมตริกการมีส่วนร่วมที่เทียบเท่ากับผู้ใช้แอปในอุปกรณ์เคลื่อนที่ เมตริกเหล่านี้รวมการเข้าชมซ้ำมากกว่า เวลาบนไซต์นานกว่า และอัตรา Conversion ที่สูงกว่าผู้เข้าชมทั่วไป
อย่างไร
ทำตามคู่มือการติดตั้งได้เพื่อดูวิธีทำให้ PWA ติดตั้งได้
เช็กลิสต์ Progressive Web App ที่ดีที่สุด
หากต้องการสร้าง PWA ที่ยอดเยี่ยมจริงๆ แอปที่ให้ความรู้สึกเหมือนแอปที่ดีที่สุดในวงการ คุณต้องมีมากกว่ารายการตรวจสอบหลัก รายการตรวจสอบ PWA ที่ดีที่สุดมีไว้เพื่อให้ PWA ของคุณรู้สึกเหมือนเป็นส่วนหนึ่งของอุปกรณ์ที่ใช้อยู่ ในขณะเดียวกันก็ใช้ประโยชน์จากสิ่งที่ทำให้เว็บมีประสิทธิภาพ
ในกรณีที่ไม่จำเป็นต้องมีการเชื่อมต่อ แอปจะทำงานแบบออฟไลน์เหมือนกับการทำงานออนไลน์
ทำไม
นอกเหนือจากการสร้างหน้าออฟไลน์ที่กำหนดเองแล้ว ผู้ใช้ยังคาดหวังให้ PWA พร้อมใช้งานแบบออฟไลน์ได้ด้วย ตัวอย่างเช่น แอปการเดินทางและสายการบินควรมีรายละเอียดการเดินทางและบอร์ดดิ้งพาสที่พร้อมใช้งานเมื่อออฟไลน์ แอปเพลง วิดีโอ และครีเอเตอร์พอดแคสต์ควรอนุญาตให้เล่นแบบออฟไลน์ได้ แอปโซเชียลและแอปข่าวควรแคชเนื้อหาล่าสุดเพื่อให้ผู้ใช้อ่านได้แบบออฟไลน์ ผู้ใช้คาดหวังว่าจะยังคงมีการตรวจสอบสิทธิ์เมื่อออฟไลน์ ดังนั้นคุณควรออกแบบการตรวจสอบสิทธิ์แบบออฟไลน์ PWA ออฟไลน์มอบประสบการณ์การใช้งานที่เหมือนกับแอปจริงๆ ให้แก่ผู้ใช้
อย่างไร
หลังจากพิจารณาว่าฟีเจอร์ใดที่ผู้ใช้คาดหวังว่าจะใช้งานได้แบบออฟไลน์ คุณจะต้องทำให้เนื้อหาพร้อมใช้งานและปรับให้เข้ากับบริบทแบบออฟไลน์ คุณสามารถใช้ IndexedDB ซึ่งเป็นระบบพื้นที่เก็บข้อมูล NoSQL ในเบราว์เซอร์เพื่อจัดเก็บและเรียกข้อมูล และใช้การซิงค์ในเบื้องหลังเพื่อให้ผู้ใช้ดำเนินการต่างๆ ขณะออฟไลน์และเลื่อนการสื่อสารระหว่างเซิร์ฟเวอร์ออกไปจนกว่าผู้ใช้จะมีการเชื่อมต่อที่เสถียรอีกครั้ง นอกจากนี้ คุณยังใช้ Service Worker เพื่อจัดเก็บเนื้อหาประเภทอื่นๆ เช่น รูปภาพ ไฟล์วิดีโอ และไฟล์เสียง เพื่อใช้งานแบบออฟไลน์ รวมถึงเพื่อติดตั้งใช้งานเซสชันที่ปลอดภัยและใช้งานได้นานเพื่อตรวจสอบสิทธิ์ผู้ใช้ต่อไป จากมุมมองประสบการณ์ของผู้ใช้ คุณอาจใช้ หน้าจอแบบโครง เพื่อให้ผู้ใช้ทราบถึงความเร็วและเนื้อหาในขณะที่โหลด ซึ่งจะ กลับไปใช้เนื้อหาที่แคชไว้หรือตัวบ่งชี้แบบออฟไลน์ได้ตามต้องการ
การโต้ตอบทั้งหมดของผู้ใช้ผ่านข้อกำหนดการช่วยเหลือพิเศษ WCAG 2.0
ทำไม
ผู้ใช้ส่วนใหญ่อยากใช้ PWA ของคุณในช่วงใดเวลาหนึ่งในลักษณะที่ครอบคลุมตามข้อกำหนดการช่วยเหลือพิเศษ WCAG 2.0 ความสามารถของมนุษย์ในการโต้ตอบและทำความเข้าใจ PWA นั้นมีอยู่หลายระดับ และความต้องการอาจเกิดขึ้นชั่วคราวหรือถาวรก็ได้ การทำให้ PWA เข้าถึงได้หมายความว่าคุณทำให้ทุกคนใช้งาน PWA ได้
อย่างไร
คุณควรเริ่มจาก
ข้อมูลเบื้องต้นเกี่ยวกับการช่วยเหลือพิเศษบนเว็บของ W3C การทดสอบการช่วยเหลือพิเศษส่วนใหญ่ต้องดำเนินการด้วยตนเอง เครื่องมือต่างๆ เช่น การตรวจสอบการช่วยเหลือพิเศษใน Lighthouse, axe และ Accessibility Insights ช่วยให้คุณทำการทดสอบการช่วยเหลือพิเศษบางอย่างได้โดยอัตโนมัติ นอกจากนี้ คุณยังต้องใช้องค์ประกอบที่ถูกต้องเชิงความหมายแทนการสร้างองค์ประกอบเหล่านั้นใหม่ด้วยตัวเอง เช่น องค์ประกอบ a และ button วิธีนี้ช่วยให้มั่นใจว่าเมื่อคุณจำเป็นต้องสร้างฟีเจอร์ขั้นสูงมากขึ้น ก็จะเป็นไปตามความคาดหวังด้านการช่วยเหลือพิเศษ (เช่น กรณีที่ควรใช้ปุ่มลูกศรแทนแท็บ)
การ์ดโภชนาการของ A11Y มีคำแนะนำที่ยอดเยี่ยมเกี่ยวกับส่วนประกอบทั่วไปบางอย่าง
คุณสามารถค้นพบ PWA ผ่านการค้นหาได้ทันที
ทำไม
ข้อได้เปรียบที่ใหญ่ที่สุดอย่างหนึ่งของเว็บคือการค้นพบเว็บไซต์และแอปผ่านการค้นหา อันที่จริงแล้ว มากกว่าครึ่งของการเข้าชมเว็บไซต์ทั้งหมดมาจากการค้นหาทั่วไป การตรวจสอบว่ามี Canonical URL สำหรับเนื้อหาและเครื่องมือค้นหาสามารถจัดทำดัชนีเว็บไซต์ของคุณได้นั้นสำคัญอย่างยิ่งต่อผู้มีโอกาสเป็นผู้ใช้ที่อาจพบ PWA ของคุณ โดยเฉพาะอย่างยิ่งเมื่อใช้การแสดงผลฝั่งไคลเอ็นต์
อย่างไร
เริ่มต้นด้วยการตรวจสอบว่า URL แต่ละรายการมีชื่อที่สื่อความหมายและคำอธิบายเมตาที่ไม่ซ้ำกัน จากนั้นจึงใช้ Google Search Console และการตรวจสอบการปรับแต่งเว็บไซต์ให้ติดอันดับบนเครื่องมือค้นหาใน Lighthouse เพื่อแก้ไขข้อบกพร่องและแก้ไขปัญหาเกี่ยวกับการค้นพบได้ของ PWA นอกจากนี้ คุณยังสามารถใช้เครื่องมือสำหรับเจ้าของเว็บไซต์ของ Bing หรือ Yandex และพิจารณารวมข้อมูลที่มีโครงสร้างโดยใช้สคีมาจาก Schema.org ใน PWA
โดย PWA จะใช้ได้กับเมาส์ แป้นพิมพ์ สไตลัส หรือการแตะเท่านั้น
ทำไม
อุปกรณ์มีวิธีการป้อนข้อมูลที่หลากหลาย และผู้ใช้ควรสลับไปมาได้อย่างราบรื่นขณะใช้แอปพลิเคชัน อีกสิ่งสําคัญที่ควรทราบคือวิธีการป้อนข้อมูลไม่ควรขึ้นอยู่กับขนาดหน้าจอ ซึ่งหมายความว่าวิวพอร์ตขนาดใหญ่ต้องรองรับการสัมผัส และวิวพอร์ตขนาดเล็กต้องรองรับแป้นพิมพ์และเมาส์ โปรดตรวจสอบว่าแอปพลิเคชันและฟีเจอร์ทั้งหมดรองรับการใช้งานวิธีการป้อนข้อมูลที่ผู้ใช้อาจเลือกให้มากที่สุดเท่าที่จะทำได้ ปรับปรุงประสบการณ์การใช้งานเพื่อให้ควบคุมเฉพาะอินพุตได้ด้วย (เช่น การปัดเพื่อรีเฟรช) ตามความเหมาะสม
อย่างไร
Pointer Events API มีอินเทอร์เฟซแบบรวมสำหรับการทำงานกับตัวเลือกการป้อนข้อมูลต่างๆ และเหมาะอย่างยิ่งสำหรับการเพิ่มการรองรับสไตลัส หากต้องการรองรับทั้งการแตะ และแป้นพิมพ์ ให้ตรวจสอบว่าคุณกำลังใช้องค์ประกอบเชิงความหมายที่ถูกต้อง (จุดยึด ปุ่ม ตัวควบคุมฟอร์ม ฯลฯ) และไม่ได้สร้างใหม่ด้วย HTML ที่ไม่มีความหมาย เมื่อมีการรวมการโต้ตอบที่เปิดใช้งานเมื่อวางเมาส์เหนือรายการ ให้ตรวจสอบว่าการโต้ตอบนั้นเปิดใช้งานเมื่อคลิกหรือแตะได้ด้วย
เมื่อขอสิทธิ์ในการใช้ API ที่มีประสิทธิภาพ ให้ระบุบริบทและขอสิทธิ์ก็ต่อเมื่อจำเป็นต้องใช้ API เท่านั้น
ทำไม
API ที่ทริกเกอร์ข้อความแจ้งสิทธิ์ เช่น การแจ้งเตือน ตำแหน่งทางภูมิศาสตร์ และข้อมูลเข้าสู่ระบบ ล้วนออกแบบมาเพื่อรบกวนผู้ใช้ เนื่องจากมักจะเกี่ยวข้องกับฟีเจอร์ที่มีประสิทธิภาพซึ่งจำเป็นต้องมีการเลือกใช้ การแสดงข้อความแจ้งเหล่านี้โดยไม่มีบริบทเพิ่มเติม เช่น เมื่อโหลดหน้าเว็บ จะทำให้ผู้ใช้มีแนวโน้มที่จะไม่ยอมรับสิทธิ์เหล่านั้นและอาจไม่ไว้วางใจแอปในอนาคต แต่ให้ทริกเกอร์ข้อความแจ้งเหล่านั้นหลังจากให้เหตุผลในบริบทแก่ผู้ใช้ว่าทำไมคุณจึงต้องมีสิทธิ์ดังกล่าว
อย่างไร
บทความสิทธิ์ UX และ วิธีที่เหมาะสมในการขอสิทธิ์จากผู้ใช้ของ UX Planet เป็นแหล่งข้อมูลที่ดีในการทำความเข้าใจวิธีออกแบบข้อความแจ้งสิทธิ์ ซึ่งแม้ว่าจะมุ่งเน้นที่อุปกรณ์เคลื่อนที่ แต่ก็จะมีผลกับ PWA ทั้งหมด
การดูแลรักษาโค้ดให้อยู่ในสถานะดีอยู่เสมอจะช่วยให้คุณบรรลุเป้าหมายและให้บริการฟีเจอร์ใหม่ๆ ได้ง่ายขึ้น
ทำไม
การสร้างเว็บแอปพลิเคชันที่ทันสมัยนั้นอาศัยปัจจัยหลายอย่าง การอัปเดตแอปพลิเคชันและฐานของโค้ดให้มีประสิทธิภาพอยู่เสมอจะช่วยให้คุณมอบฟีเจอร์ใหม่ๆ ที่บรรลุเป้าหมายอื่นๆ ที่ระบุไว้ในรายการตรวจสอบนี้ได้ง่ายขึ้น
อย่างไร
มีการตรวจสอบที่มีลําดับความสําคัญสูงหลายรายการเพื่อให้มั่นใจว่าฐานโค้ดมีประสิทธิภาพดี ดังนี้
- หลีกเลี่ยงการใช้ไลบรารีที่มีช่องโหว่ที่ทราบ
- ตรวจสอบว่าคุณไม่ได้ใช้ API ที่เลิกใช้งานแล้ว
- นำแนวทางการเขียนโค้ดที่ไม่ปลอดภัยออกจากโค้ดเบส (เช่น การใช้
document.write()หรือมี Listener เหตุการณ์การเลื่อนที่ไม่ใช่แบบพาสซีฟ) - คุณสามารถเขียนโค้ดเพื่อป้องกันข้อผิดพลาดเพื่อให้แน่ใจว่า PWA จะไม่เสียหายหากข้อมูลวิเคราะห์หรือไลบรารีของบุคคลที่สามอื่นๆ โหลดไม่สำเร็จ
- พิจารณากำหนดให้ต้องวิเคราะห์โค้ดแบบคงที่ เช่น การตรวจหาข้อบกพร่องในโค้ด รวมถึงการทดสอบอัตโนมัติในเบราว์เซอร์และช่องทางการเผยแพร่หลายช่องทาง เทคนิคเหล่านี้จะช่วยตรวจจับข้อผิดพลาดได้ก่อนที่จะนำไปใช้งานจริง