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 เป็นแหล่งข้อมูลที่ยอดเยี่ยมในการอธิบายวิธีคำนึงถึงการออกแบบเว็บโดยใช้วิธีการแบบโพรเกรสซีฟแบบข้ามเบราว์เซอร์นี้
อ่านเพิ่มเติม
- การทำความเข้าใจการเพิ่มประสิทธิภาพแบบโพรเกรสซีฟของรายการนอกเหนือจากรายการเป็นการแนะนำหัวข้อได้เป็นอย่างดี
- การเพิ่มประสิทธิภาพแบบก้าวหน้า: คืออะไรและมีประโยชน์อย่างไรของ Smashing Magazine จะให้ข้อมูลเบื้องต้นที่นำไปปฏิบัติได้จริงและลิงก์ไปยังหัวข้อที่ซับซ้อนขึ้น
- บทความเกี่ยวกับ การใช้การตรวจหาฟีเจอร์ของ MDN พูดถึงวิธีตรวจหาฟีเจอร์ด้วยการค้นหาฟีเจอร์นั้นโดยตรง
ผู้ใช้สามารถใช้ PWA ในหน้าจอทุกขนาดและเนื้อหาทั้งหมดก็พร้อมใช้งานในวิวพอร์ตขนาดใดก็ได้
ทำไม
อุปกรณ์มีหลายขนาด และผู้ใช้อาจใช้แอปพลิเคชันของคุณได้หลากหลายขนาดแม้ในอุปกรณ์เดียวกัน ดังนั้นจึงต้องตรวจสอบว่าไม่เพียงแต่เนื้อหาของคุณพอดีกับวิวพอร์ตเท่านั้น แต่ยังต้องใช้ฟีเจอร์และเนื้อหาทั้งหมดของเว็บไซต์ในวิวพอร์ตทุกขนาดด้วย
งานที่ผู้ใช้ต้องการดำเนินการและเนื้อหาที่ผู้ใช้ต้องการเข้าถึงจะไม่เปลี่ยนแปลงตามขนาดวิวพอร์ต คุณจัดเรียงเนื้อหาใหม่ตามขนาดวิวพอร์ตที่ต่างกันได้ ซึ่งทั้งหมดควรอยู่ที่นั่น ไม่ว่าจะในลักษณะใดลักษณะหนึ่ง อันที่จริงแล้ว Luke Wroblewski ได้เขียนอธิบายไว้ในหนังสือ Mobile First ว่า การเริ่มจากสิ่งเล็กๆ และปรับเปลี่ยนการออกแบบสำหรับหน้าจอขนาดใหญ่จะช่วยพัฒนาการออกแบบเว็บไซต์ได้ ดังนี้
อุปกรณ์เคลื่อนที่กำหนดให้ทีมพัฒนาซอฟต์แวร์ต้องเน้นเฉพาะข้อมูลและการดำเนินการที่สำคัญที่สุดในแอปพลิเคชันเท่านั้น หน้าจอขนาด 320 x 480 พิกเซลไม่มีพื้นที่เพียงพอสำหรับองค์ประกอบที่ไม่จำเป็นและไม่จำเป็น คุณต้องจัดลำดับความสำคัญ
อย่างไร
มีแหล่งข้อมูลมากมายเกี่ยวกับการออกแบบที่ปรับเปลี่ยนตามอุปกรณ์ ซึ่งรวมถึงบทความต้นฉบับโดย Ethan Marcotte คอลเล็กชันแนวคิดสำคัญที่เกี่ยวข้อง ตลอดจนหนังสือและการบรรยายมากมาย หากต้องการจำกัดขอบเขตการพูดคุยนี้ให้แคบลงถึงแง่มุมเนื้อหาของการออกแบบที่ปรับเปลี่ยนตามอุปกรณ์ โปรดดู การออกแบบที่เน้นเนื้อหาเป็นหลักและ เลย์เอาต์ที่ปรับเปลี่ยนตามอุปกรณ์ สุดท้ายนี้ แม้ว่าจะมุ่งเน้นที่อุปกรณ์เคลื่อนที่ แต่บทเรียนใน Seven Deadly Mobile Myths ของ Josh Clark จะเกี่ยวข้องกับมุมมองขนาดเล็กของเว็บไซต์ที่ปรับเปลี่ยนตามอุปกรณ์มากพอๆ กับบนอุปกรณ์เคลื่อนที่โดยทั่วไป
เมื่อผู้ใช้ออฟไลน์อยู่ การเก็บผู้ใช้ไว้ใน PWA จะให้ประสบการณ์การใช้งานที่ราบรื่นมากกว่าการกลับไปใช้หน้าออฟไลน์ของเบราว์เซอร์เริ่มต้น
ทำไม
ผู้ใช้คาดหวังให้แอปที่ติดตั้งทำงานได้ไม่ว่าสถานะการเชื่อมต่อจะเป็นอย่างไรก็ตาม แอปเฉพาะแพลตฟอร์มจะไม่แสดงหน้าว่างเมื่อออฟไลน์ และ PWA ไม่ควรแสดงหน้าออฟไลน์เริ่มต้นของเบราว์เซอร์ การมอบประสบการณ์การใช้งานแบบออฟไลน์ที่กำหนดเอง ทั้งเมื่อผู้ใช้ไปยัง URL ที่ไม่ได้แคชและเมื่อผู้ใช้พยายามใช้ฟีเจอร์ที่ต้องเชื่อมต่อ จะช่วยให้ประสบการณ์การใช้งานเว็บของคุณรู้สึกเหมือนเป็นส่วนหนึ่งของอุปกรณ์ที่กำลังใช้งาน
อย่างไร
ระหว่างเหตุการณ์ install
ของโปรแกรมทำงานของบริการ คุณจะแคชหน้าออฟไลน์ที่กำหนดเองไว้ล่วงหน้าได้สำหรับการใช้งานในภายหลัง หากผู้ใช้ออฟไลน์ คุณสามารถตอบกลับด้วยหน้าออฟไลน์ที่กำหนดเองซึ่งแคชไว้ล่วงหน้า คุณติดตามตัวอย่างหน้าเว็บออฟไลน์ที่กำหนดเองได้เพื่อดูตัวอย่างการใช้งานจริงและดูวิธีใช้ด้วยตนเอง
ผู้ใช้ที่ติดตั้งหรือเพิ่มแอปลงในอุปกรณ์มีแนวโน้มที่จะมีส่วนร่วมกับแอปเหล่านั้นมากกว่า
ทำไม
การติดตั้ง 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 และข้อมูลเชิงลึกเกี่ยวกับการช่วยเหลือพิเศษจะช่วยให้การทดสอบการช่วยเหลือพิเศษบางรายการเป็นแบบอัตโนมัติได้ นอกจากนี้ คุณยังต้องใช้องค์ประกอบที่ถูกต้องเชิงความหมายแทนที่จะสร้างองค์ประกอบเหล่านั้นใหม่ด้วยตัวเอง เช่น องค์ประกอบ 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 จะไม่เสียหายหากข้อมูลวิเคราะห์หรือไลบรารีของบุคคลที่สามอื่นๆ โหลดไม่สำเร็จ
- พิจารณากำหนดให้ต้องมีการวิเคราะห์โค้ดแบบคงที่ เช่น การวิเคราะห์ซอร์สโค้ด ตลอดจนการทดสอบอัตโนมัติในเบราว์เซอร์ต่างๆ และเวอร์ชันการเผยแพร่ เทคนิคเหล่านี้จะช่วยตรวจจับข้อผิดพลาดก่อนนำไปใช้งานจริง