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

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 ในการออกแบบเว็บที่มีความยืดหยุ่น เพื่อระบุฟังก์ชันหลัก ทำให้ฟังก์ชันดังกล่าวพร้อมใช้งานโดยใช้เทคโนโลยีที่เรียบง่ายที่สุดเท่าที่จะเป็นไปได้ แล้วปรับปรุงประสบการณ์การใช้งานหากทำได้ ในหลายกรณี การเริ่มจาก HTML เพื่อสร้างฟังก์ชันหลัก และการปรับปรุงประสบการณ์ของผู้ใช้ด้วย CSS และ JavaScript เพื่อสร้างประสบการณ์ที่น่าสนใจยิ่งขึ้น

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

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

อย่างไร

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

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

ตอบสนองต่อหน้าจอทุกขนาด

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

ทำไมจึงควร

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

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

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

อย่างไร

มีแหล่งข้อมูลมากมายเกี่ยวกับการออกแบบที่ปรับเปลี่ยนตามอุปกรณ์ ซึ่งรวมถึงบทความต้นฉบับของ Ethan Marcotte ซึ่งเป็นคอลเล็กชันแนวคิดสำคัญที่เกี่ยวข้องกับการออกแบบนี้ ตลอดจนหนังสือและการบรรยายมากมาย หากต้องการจำกัดการสนทนานี้ให้เหลือเพียงแง่มุมเนื้อหาของการออกแบบที่ปรับเปลี่ยนตามอุปกรณ์ คุณสามารถดูการออกแบบที่มุ่งเน้นเนื้อหาและเลย์เอาต์ที่ปรับเปลี่ยนตามอุปกรณ์สำหรับคอนเทนต์ และสุดท้าย แม้ว่าจะมุ่งเน้นที่อุปกรณ์เคลื่อนที่ แต่บทเรียนใน Seven Deadly Mobile Myths โดย Josh Clark จะมีความเกี่ยวข้องกับมุมมองขนาดเล็กของเว็บไซต์ที่ปรับเปลี่ยนตามอุปกรณ์เช่นเดียวกับการดูในอุปกรณ์เคลื่อนที่

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

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

ทำไมจึงควร

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

อย่างไร

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

ติดตั้งได้

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

ทำไมจึงควร

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

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

อย่างไร

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

เช็กลิสต์สำหรับ Progressive Web App ที่เหมาะสมที่สุด

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

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

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

ทำไมจึงควร

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

อย่างไร

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

เข้าถึงได้อย่างเต็มรูปแบบ

การโต้ตอบทั้งหมดของผู้ใช้ผ่านข้อกำหนดด้านการช่วยเหลือพิเศษของ WCAG 2.0

ทำไมจึงควร

ผู้คนส่วนใหญ่ในช่วงเวลาหนึ่งๆ ของชีวิตต้องการใช้ประโยชน์จาก PWA ในลักษณะที่เป็นไปตามข้อกำหนดด้านการช่วยเหลือพิเศษของ WCAG 2.0 ความสามารถของมนุษย์ในการโต้ตอบและทําความเข้าใจ 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 ที่ทริกเกอร์ข้อความแจ้งสิทธิ์ เช่น การแจ้งเตือน ตำแหน่งทางภูมิศาสตร์ และข้อมูลเข้าสู่ระบบ ได้รับการออกแบบมาโดยตั้งใจให้รบกวนผู้ใช้ เนื่องจากมีแนวโน้มที่จะเกี่ยวข้องกับฟังก์ชันที่มีประสิทธิภาพซึ่งจำเป็นต้องเลือกใช้ การทริกเกอร์ข้อความแจ้งเหล่านี้โดยไม่มีบริบทเพิ่มเติม เช่น เมื่อโหลดหน้าเว็บ จะทำให้ผู้ใช้มีแนวโน้มที่จะยอมรับสิทธิ์เหล่านั้นน้อยลงและมีแนวโน้มที่จะไม่เชื่อถือสิทธิ์ดังกล่าวในอนาคต แต่ให้เรียกใช้พรอมต์ดังกล่าวก็ต่อเมื่อให้เหตุผลในบริบทแก่ผู้ใช้ถึงเหตุผลที่คุณต้องมีสิทธิ์ดังกล่าวเท่านั้น

อย่างไร

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

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

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

ทำไมจึงควร

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

อย่างไร

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