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 ซึ่งจะปรับปรุงประสบการณ์การใช้งานสำหรับผู้ใช้ที่รองรับ

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

อย่างไร

การออกแบบเว็บที่ยืดหยุ่นของ 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 ชุดแนวคิดสําคัญต่างๆ ที่เกี่ยวข้อง รวมถึงหนังสือและการพูดคุยต่างๆ หากต้องการจำกัดการพูดคุยนี้ให้แคบลงเฉพาะแง่มุมเนื้อหาของการออกแบบที่ตอบสนองตามอุปกรณ์ โปรดดูการออกแบบที่เน้นเนื้อหาเป็นหลักและเลย์เอาต์ที่ตอบสนองตามอุปกรณ์ซึ่งเน้นเนื้อหาเป็นหลัก สุดท้ายนี้ เมื่อเน้นที่อุปกรณ์เคลื่อนที่ แต่บทเรียนใน Seven Deadly Mobile Myths ของ Josh Clark มีความเกี่ยวข้องกับการแสดงผล ขนาดย่อมของการตอบสนอง ไม่ต่างจากเวอร์ชันอื่นๆ ในอุปกรณ์เคลื่อนที่

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

ทำไม

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

อย่างไร

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

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

ทำไม

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

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

อย่างไร

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

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

ทำไม

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

อย่างไร

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

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

ทำไม

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

อย่างไร

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

คุณสามารถค้นพบ PWA ของคุณได้แล้ว ผ่านการค้นหา

ทำไม

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

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

ทำไม

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

อย่างไร

มีการตรวจสอบที่มีลําดับความสําคัญสูงหลายรายการ เพื่อให้มั่นใจว่า codebase:

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