Progressive Web App (PWA) สร้างขึ้นและปรับปรุงด้วย API สมัยใหม่เพื่อให้ความสามารถ ความสามารถในการทำงาน และความสามารถในการติดตั้งที่ดีขึ้น พร้อมทั้งเข้าถึงทุกคน ทุกที่ และทุกอุปกรณ์ด้วยโค้ดฐานเดียว ใช้รายการตรวจสอบและคำแนะนำหลักและเหมาะสมเพื่อช่วยให้คุณสร้างประสบการณ์การใช้งานที่ดีที่สุด
รายการตรวจสอบ Progressive Web App หลัก
รายการตรวจสอบเว็บแอปแบบ Progressive จะอธิบายสิ่งที่ทําให้ผู้ใช้ทุกคนติดตั้งและใช้แอปได้ ไม่ว่าอุปกรณ์จะมีขนาดหรือประเภทอินพุตใดก็ตาม
ประสิทธิภาพมีบทบาทสําคัญต่อความสําเร็จของประสบการณ์การใช้งานออนไลน์ เนื่องจากเว็บไซต์ที่มีประสิทธิภาพสูงจะดึงดูดและรักษาผู้ใช้ไว้ได้ดีกว่าเว็บไซต์ที่มีประสิทธิภาพต่ำ มุ่งเน้นการเพิ่มประสิทธิภาพสำหรับเมตริกประสิทธิภาพที่เน้นผู้ใช้เป็นศูนย์กลาง
ทำไม
ความเร็วเป็นสิ่งสําคัญในการทําให้ผู้ใช้ใช้แอปของคุณ อันที่จริงแล้ว เมื่อเวลาในการโหลดหน้าเว็บเพิ่มขึ้นจาก 1 วินาทีเป็น 10 วินาที ความน่าจะเป็นในการตีกลับของผู้ใช้จะเพิ่มขึ้น 123% ประสิทธิภาพไม่ได้หยุดลงที่เหตุการณ์ load
เช่นกัน ผู้ใช้ไม่ควรสงสัยว่าการโต้ตอบของตน เช่น การคลิกปุ่ม ได้รับการบันทึกหรือไม่ การเลื่อนและภาพเคลื่อนไหวควรลื่นไหล
ประสิทธิภาพส่งผลต่อประสบการณ์การใช้งานทั้งหมด ทั้งในแง่ลักษณะการทํางานของแอปและวิธีที่ผู้ใช้รับรู้
แม้ว่าแอปพลิเคชันทั้งหมดจะมีความต้องการที่แตกต่างกัน แต่การตรวจสอบประสิทธิภาพใน Lighthouse จะอิงตาม Core Web Vitals และคะแนนการตรวจสอบที่สูงจะทำให้ผู้ใช้มีโอกาสได้รับประสบการณ์การใช้งานที่น่าพึงพอใจมากขึ้น นอกจากนี้ คุณยังใช้ PageSpeed Insights หรือรายงานประสบการณ์ของผู้ใช้ Chrome เพื่อดูข้อมูลประสิทธิภาพการใช้งานจริงของเว็บแอปได้ด้วย
อย่างไร
ทำตามคู่มือเกี่ยวกับเวลาในการโหลดที่รวดเร็วเพื่อดูวิธีทำให้ PWA เริ่มต้นอย่างรวดเร็วและทำงานได้อย่างรวดเร็วอยู่เสมอ
ผู้ใช้สามารถใช้เบราว์เซอร์ใดก็ได้ที่เลือกเพื่อเข้าถึงเว็บแอปก่อนที่จะติดตั้ง
ทำไม
Progressive Web App เป็นเว็บแอปก่อน ซึ่งหมายความว่าต้องทำงานได้กับเบราว์เซอร์ต่างๆ
วิธีหนึ่งที่มีประสิทธิภาพในการดำเนินการดังกล่าวคือ ระบุฟีเจอร์หลัก ให้บริการฟีเจอร์เหล่านั้นโดยใช้เทคโนโลยีที่ง่ายที่สุด จากนั้นจึงปรับปรุงประสบการณ์การใช้งานเมื่อเป็นไปได้ ตามที่ Jeremy Keith กล่าวไว้ในการออกแบบเว็บที่ยืดหยุ่น ในหลายกรณี การทำเช่นนี้หมายความว่าคุณควรเริ่มต้นด้วย HTML เพียงอย่างเดียวเพื่อสร้างฟีเจอร์หลัก และปรับปรุงประสบการณ์ของผู้ใช้ด้วย CSS และ JavaScript เพื่อสร้างประสบการณ์ที่ดึงดูดใจยิ่งขึ้น
ยกตัวอย่างเช่น การส่งแบบฟอร์ม วิธีที่ง่ายที่สุดในการใช้งานคือใช้แบบฟอร์ม HTML ที่ส่งคําขอ POST
หลังจากสร้างแล้ว คุณสามารถปรับปรุงประสบการณ์การใช้งานด้วย JavaScript เพื่อตรวจสอบความถูกต้องของแบบฟอร์มและส่งแบบฟอร์มผ่าน AJAX ซึ่งจะปรับปรุงประสบการณ์การใช้งานสำหรับผู้ใช้ที่รองรับ
ผู้ใช้เข้าชมเว็บไซต์ของคุณผ่านอุปกรณ์และเบราว์เซอร์ที่หลากหลาย คุณไม่สามารถกําหนดเป้าหมายเฉพาะกลุ่มที่ร่ำรวยที่สุดได้ ใช้การตรวจหาฟีเจอร์เพื่อมอบประสบการณ์การใช้งานที่ใช้งานได้แก่ผู้มีโอกาสเป็นผู้ใช้ในวงกว้างที่สุด ซึ่งรวมถึงผู้ใช้เบราว์เซอร์และอุปกรณ์ที่ยังไม่มีอยู่
อย่างไร
การออกแบบเว็บที่ยืดหยุ่นของ Jeremy Keith เป็นแหล่งข้อมูลที่ยอดเยี่ยมซึ่งอธิบายวิธีคิดเกี่ยวกับการออกแบบเว็บในแนวทางแบบ Progressive ที่ใช้งานได้กับทุกเบราว์เซอร์
อ่านเพิ่มเติม
- บทความ การศึกษาการเพิ่มประสิทธิภาพแบบต่อเนื่องของ 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, ชุดแนวคิดสําคัญที่เกี่ยวข้องกับการออกแบบนี้ ตลอดจนหนังสือและการบรรยายมากมาย หากต้องการจำกัดการพูดคุยนี้ให้แคบลงเฉพาะแง่มุมเนื้อหาของการออกแบบที่ตอบสนองตามอุปกรณ์ โปรดดู การออกแบบที่เน้นเนื้อหาเป็นหลักและ เลย์เอาต์ที่ตอบสนองตามอุปกรณ์ซึ่งเน้นเนื้อหาเป็นหลัก สุดท้ายนี้ แม้ว่าบทความเจ็ดตำนานร้ายแรงเกี่ยวกับอุปกรณ์เคลื่อนที่ของ 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 เข้าถึงได้จะทำให้ทุกคนใช้งานได้
อย่างไร
ข้อมูลเบื้องต้นเกี่ยวกับการช่วยเหลือพิเศษบนเว็บของ W3C เป็นจุดเริ่มต้นที่ดี การทดสอบการช่วยเหลือพิเศษส่วนใหญ่ต้องดำเนินการด้วยตนเอง เครื่องมือต่างๆ เช่น การตรวจสอบการช่วยเหลือพิเศษใน Lighthouse, axe และ Accessibility Insights ช่วยให้คุณทำการทดสอบการช่วยเหลือพิเศษบางอย่างได้โดยอัตโนมัติ นอกจากนี้ คุณยังต้องใช้องค์ประกอบที่ถูกต้องตามความหมายแทนการสร้างองค์ประกอบเหล่านั้นขึ้นมาใหม่ด้วยตนเอง เช่น องค์ประกอบ a
และ button
วิธีนี้ช่วยให้มั่นใจว่าเมื่อคุณจำเป็นต้องสร้างฟีเจอร์ขั้นสูงมากขึ้น ก็จะเป็นไปตามความคาดหวังด้านการช่วยเหลือพิเศษ (เช่น กรณีที่ควรใช้ปุ่มลูกศรแทนแท็บ)
การ์ดข้อมูลโภชนาการ A11Y มีคำแนะนำที่ยอดเยี่ยมเกี่ยวกับเรื่องนี้สำหรับคอมโพเนนต์ทั่วไปบางรายการ
PWA ของคุณจะค้นพบได้ผ่านการค้นหา
ทำไม
ข้อได้เปรียบที่ใหญ่ที่สุดอย่างหนึ่งของเว็บคือการค้นพบเว็บไซต์และแอปผ่านการค้นหา อันที่จริงแล้วการเข้าชมเว็บไซต์ทั้งหมดมากกว่าครึ่งมาจากผลการค้นหาทั่วไป การตรวจสอบว่ามี Canonical URL สำหรับเนื้อหาและเครื่องมือค้นหาสามารถจัดทำดัชนีเว็บไซต์ของคุณได้นั้นสำคัญอย่างยิ่งต่อผู้มีโอกาสเป็นผู้ใช้ที่อาจพบ 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()
หรือมี Listener เหตุการณ์การเลื่อนที่ไม่ใช่แบบพาสซีฟ) - คุณยังเขียนโค้ดเพื่อการป้องกันเพื่อให้ PWA ไม่ขัดข้องได้หากการวิเคราะห์หรือไลบรารีอื่นๆ ของบุคคลที่สามโหลดไม่สำเร็จ
- พิจารณากำหนดให้ต้องวิเคราะห์โค้ดแบบคงที่ เช่น การตรวจหาข้อบกพร่องในโค้ด รวมถึงการทดสอบอัตโนมัติในเบราว์เซอร์และช่องทางการเผยแพร่หลายช่องทาง เทคนิคเหล่านี้จะช่วยตรวจจับข้อผิดพลาดได้ก่อนที่จะนำไปใช้งานจริง