10 สิ่งที่ AI ทำผิดพลาดในการพัฒนาเว็บ

Philip Walton

เผยแพร่: 11 พฤศจิกายน 2569

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

ตั้งแต่ที่เราเปิดตัวเวอร์ชันตัวอย่างทดลองใช้ของคำแนะนำในการพัฒนาเว็บที่ทันสมัยเป็นครั้งแรกเมื่อเดือนพฤษภาคมที่ผ่านมา เอเจนต์การเขียนโค้ดก็มีประสิทธิภาพมากขึ้นเรื่อยๆ และมีการเปิดตัว Frontier Model ใหม่ๆ ที่น่าทึ่งมากมาย คำถามหนึ่งที่เราได้ยินบ่อยที่สุดคือ Frontier Model ใหม่เหล่านี้ไม่ได้ทำตามแนวทางปฏิบัติแนะนำในการพัฒนาเว็บอยู่แล้วหรือ

คำตอบคือ "ไม่" และเรารู้ว่าคำตอบคือ "ไม่" เพราะเราได้ทดสอบแล้ว

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

เมื่อเปรียบเทียบอัตราการผ่านแบบมีคำแนะนำและไม่มีคำแนะนำ คุณจะเห็นว่าโมเดล AI แม้แต่ Frontier Model ล่าสุดก็ไม่สามารถปฏิบัติตามแนวทางปฏิบัติแนะนำในการพัฒนาเว็บสมัยใหม่ได้อย่างน่าเชื่อถือด้วยตัวเอง

โดยเฉลี่ยแล้ว Agent การเขียนโค้ดที่ไม่มีคำแนะนำจะผ่านการตรวจสอบในชุดการประเมินของเราเพียงประมาณ 50% เท่านั้น เมื่อเทียบกับประมาณ 90% เมื่อใช้คำแนะนำในการพัฒนาเว็บที่ทันสมัย

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

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

1. การช่วยเหลือพิเศษ: การจัดการโฟกัสของแป้นพิมพ์และ inert

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

การจัดการโฟกัสและ inert เป็นหนึ่งในช่องว่างด้านการช่วยเหลือพิเศษที่ใหญ่ที่สุดในการประเมินของเรา และเป็นหนึ่งในด้านที่ปรับปรุงมากที่สุดด้วยคำแนะนำในการพัฒนาเว็บที่ทันสมัย ข้อผิดพลาดที่พบบ่อยที่สุดมีดังนี้

• ไม่ย้ายโฟกัสไปยังมุมมองที่เปิดใหม่และลืมคืนค่าโฟกัสไปยังองค์ประกอบที่ทริกเกอร์เมื่อย้อนกลับ
• การใช้ JavaScript เพื่อดักจับการกดปุ่ม Tab ด้วยตนเองและ aria-modal="true" ในโมดัลที่กำหนดเอง แทนที่จะใช้โมดัล <dialog> หรือทำเครื่องหมายเนื้อหาพื้นหลังเป็น inert
• แสดงทุกรายการในแถบเครื่องมือหรือตารางกริดแบบกำหนดทิศทางเป็นจุดหยุดแท็บแยกกัน แทนที่จะใช้จุดหยุดแท็บเดียวที่มี tabindex แบบเคลื่อนที่
• การสร้างเส้นขอบ :focus-visible ที่กำหนดเองซึ่งไม่มีอัตราส่วนคอนทราสต์ 3:1 กับพื้นหลังที่อยู่ติดกัน

2. การช่วยเหลือพิเศษ: การรองรับการลดการเคลื่อนไหว

การเคลื่อนไหวของหน้าเว็บที่ไม่คาดคิดและภาพเคลื่อนไหวขนาดใหญ่ไม่เพียงแต่ทำให้เสียสมาธิเท่านั้น แต่สำหรับผู้ใช้ที่มีความผิดปกติของการทรงตัวหรือความไวต่อการเคลื่อนไหว ภาพเคลื่อนไหวเหล่านี้อาจทำให้เกิดอาการวิงเวียน คลื่นไส้ หรือปวดศีรษะได้

โดยปกติแล้ว โมเดล AI จะจำได้ว่าต้องตรวจสอบ prefers-reduced-motion เมื่อเพิ่มการเปลี่ยน CSS มาตรฐานหรือภาพเคลื่อนไหวคีย์เฟรม อย่างไรก็ตาม เมื่อใช้ฟีเจอร์ใหม่ๆ เช่น การเลื่อนอย่างราบรื่น การเปลี่ยนมุมมอง หรือภาพเคลื่อนไหวที่ขับเคลื่อนด้วยการเลื่อน นักพัฒนามักจะลืมเรื่องการลดการเคลื่อนไหวหรือทำผิดพลาดเมื่อนำไปใช้ ดังนี้

• การตั้งค่า scroll-behavior:smooth ทั่วโลกและไม่มีเงื่อนไขในองค์ประกอบรูท
• ใช้ภาพเคลื่อนไหว CSS ที่ขับเคลื่อนด้วยการเลื่อนโดยไม่มีการตรวจสอบการเคลื่อนไหวที่ลดลง
• การนำระยะเวลา transition ออกจากรายการภาพสไลด์เพื่อลดการเคลื่อนไหวระหว่างการเลื่อน แต่ลืมนำพร็อพเพอร์ตี้การเปลี่ยนรูปแบบออกด้วย ทำให้รายการมีขนาดกระโดดไปมาขณะเลื่อน
• การใช้การรีเซ็ตระยะเวลา 0.01ms แบบครอบคลุมใน *, *::before และ *::after เมื่อเปิดใช้การลดการเคลื่อนไหว ซึ่งจะล้างการเปลี่ยนภาพที่ไม่ใช่การเคลื่อนไหวที่จำเป็นทั้งหมดด้วย (จำเป็นสำหรับการสื่อสารการเปลี่ยนแปลงสถานะ UI)
• การเปิดใช้การเปลี่ยนมุมมองข้ามเอกสารโดยไม่มีเงื่อนไขและลบล้างภาพเคลื่อนไหว ::view-transition-* เมื่อเปิดใช้การลดการเคลื่อนไหว แทนที่จะจำกัดกฎ @view-transition ไว้หลังการตรวจสอบการลดการเคลื่อนไหว

3. การช่วยเหลือพิเศษ: การตรวจสอบความถูกต้องของแบบฟอร์ม คำแนะนำเกี่ยวกับรูปแบบ และสถานะการป้อนข้อความอัตโนมัติ

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

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

• การใช้ CSS :user-invalid ซ้ำกับการตรวจสอบ JavaScript blur ที่กำหนดเอง ซึ่งมักจะแจ้งว่าช่อง required ที่ไม่มีการแตะต้องมีข้อผิดพลาดทันทีที่ผู้ใช้กด Tab ผ่านช่องดังกล่าว
• การปล่อยให้ aria-invalid ไม่ซิงค์กับข้อผิดพลาดที่มองเห็นได้ ไม่ว่าจะเป็นการตั้งค่า aria-invalid="true" ก่อนเวลาอันควรใน blur หรือการจัดรูปแบบ :user-invalid ใน CSS โดยไม่ซิงค์ aria-invalid ใน JavaScript
• การใช้ข้อความ placeholder ที่หายไปเพื่อแสดงรูปแบบที่จำเป็น (เช่น MM/YY ในช่องป้อนข้อมูลวันหมดอายุของบัตร) แทนการแสดงคำแนะนำแบบถาวรที่ลิงก์กับ aria-describedby
• การวางคำแนะนำเกี่ยวกับรูปแบบและกฎรหัสผ่านไว้ใต้ <input> (แทนที่จะอยู่ด้านบน) ซึ่งอาจถูกบดบังด้วยแป้นพิมพ์บนอุปกรณ์เคลื่อนที่และป๊อปโอเวอร์การป้อนข้อความอัตโนมัติเมื่อผู้ใช้ต้องการอ่าน
• ไฮไลต์อินพุต :autofill โดยเปลี่ยนสีขอบเพียงอย่างเดียวแทนที่จะจับคู่สีกับสัญญาณที่ไม่ใช่สีซึ่งไม่เปลี่ยนเลย์เอาต์ (เช่น box-shadow ที่แทรก)

4. ประสบการณ์ของผู้ใช้: ท่าทางสัมผัสแบบปัดและแตะ

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

การโต้ตอบเหล่านี้หลายอย่างสามารถนำไปใช้กับ CSS และ API การเลื่อนแบบเนทีฟ ซึ่งช่วยให้เบราว์เซอร์เรียกใช้ฟิสิกส์ของท่าทางสัมผัสนอกเทรดหลักได้ แต่ในการประเมินของเรา โมเดล AI มักจะมองข้ามฟีเจอร์เหล่านี้

• การใช้ท่าทางสัมผัสแบบปัดเพื่อปิดหรือปัดเพื่อแสดงด้วย Listener pointermove หรือ touchmove แทนการใช้ CSS Scroll Snap
• การละเว้น overscroll-behavior-x:none ในอินเทอร์เฟซการปัดแท็บ ซึ่งอาจทริกเกอร์การนำทางย้อนกลับหรือไปข้างหน้าของเบราว์เซอร์โดยไม่ตั้งใจในระหว่างการปัดมากเกินไป
• การขับเคลื่อนเอฟเฟกต์ความคืบหน้าของการปัดบนเทรดหลักใน Callback ของ JavaScript แทนการใช้ภาพเคลื่อนไหวที่ขับเคลื่อนด้วยการเลื่อน
• ไม่รองรับโฟกัสของแป้นพิมพ์ในแผงการดำเนินการปัดตามการเลื่อนอย่างเหมาะสม

5. ประสบการณ์ของผู้ใช้: กล่องโต้ตอบ, ป๊อปโอเวอร์ และการเปลี่ยนเลเยอร์ด้านบน

ในการประเมินของเรา โมเดลมักจะกลับไปใช้วิธีแก้ปัญหาเฉพาะหน้าด้วย JavaScript ที่จำเป็นเมื่อสร้างภาพเคลื่อนไหว ปิด หรือมีแถบเลื่อนรอบๆ กล่องโต้ตอบโมดัลและป๊อปโอเวอร์

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

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

• การสร้างการวางซ้อน position:fixed ที่กำหนดเองด้วยเครื่องมือจัดการการคลิกภายนอกด้วยตนเองสำหรับการปิดแบบเบา แทนที่จะใช้เพียง popover
• การสร้างภาพเคลื่อนไหวขาเข้าและขาออกโดยการสลับคลาสการเปลี่ยน CSS และประสานงานกับ Listener requestAnimationFrame() และ transitionend (โดยมี setTimeout() เป็นทางเลือกสำรอง) แทนที่จะทำใน CSS ล้วนๆ ด้วย @starting-style และ transition-behavior
• การล็อกการเลื่อนหน้าเว็บด้านหลังโมดัลที่เปิดอยู่โดยตั้งค่า overflow:hidden ใน <html> แทนการใช้องค์ประกอบ <dialog> เพื่อจำกัดการเลื่อนเกิน
• การเพิ่ม Listener popstate เพื่อตรวจจับท่าทางสัมผัสเพื่อย้อนกลับของ Android และปิดโมดัลที่เปิดอยู่ แทนที่จะใช้ฟังก์ชันการปิดด้วยปุ่มย้อนกลับแบบเนทีฟขององค์ประกอบ <dialog> ของโมดัล

6. ประสบการณ์ของผู้ใช้: โหมดมืดและการควบคุมที่ปรับเปลี่ยนตามธีม

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

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

• ไม่มี <meta name="color-scheme" content="light dark"> ใน <head> ซึ่งทำให้ผู้ใช้โหมดมืดเห็นภาพพื้นหลังสีขาวกะพริบขณะโหลดสไตล์ชีตภายนอก
• การจัดสไตล์ธีมมืดหรือคอมโพเนนต์ที่มีพื้นหลังสีเข้มด้วยสีที่กำหนดเองโดยไม่ตั้งค่า color-scheme ทำให้แถบเลื่อนและตัวควบคุมแบบฟอร์มในตัวติดอยู่ในโหมดสว่าง
• การมองข้ามฟังก์ชัน CSS light-dark() เมื่อกำหนดโทเค็นสีที่ปรับตามธีมซึ่งจะติดตาม color-scheme ที่ใช้งานอยู่โดยอัตโนมัติ
• การจัดเตรียมปุ่มสลับโหมดสว่างหรือมืดแบบไบนารีเท่านั้น ซึ่งจะตั้งค่าการลบล้างที่ชัดเจนใน localStorage โดยไม่มีตัวเลือกให้กลับไปใช้ค่าเริ่มต้นของระบบปฏิบัติการ
• ลืมเพิ่ม Listener เหตุการณ์ storage ซึ่งทำให้แท็บอื่นๆ ที่เปิดอยู่ไม่ซิงค์กันเมื่อผู้ใช้เปลี่ยนธีม

7. ประสิทธิภาพ: การตอบสนองและความราบรื่นของรันไทม์

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

ในการประเมินของเรา โดยทั่วไปแล้วโมเดลจะทำตามแนวทางปฏิบัติแนะนำเกี่ยวกับเวลาในการโหลดแบบคลาสสิกที่ได้รับการโปรโมตในเครื่องมืออย่าง Lighthouse มาหลายปี และมักจะรู้วิธีถ่ายโอนลูปที่หนักหน่วงอย่างเห็นได้ชัดไปยัง Web Worker สิ่งที่นักพัฒนาแอปมักประสบปัญหาอยู่เสมอคือการตอบสนองของเทรดหลัก ซึ่งจำเป็นต่อการเพิ่มประสิทธิภาพ INP ได้แก่ การแยกงานเลย์เอาต์ การจัดกำหนดการงานตามลำดับความสำคัญ และการใช้ประโยชน์จากฟีเจอร์ HTML และ CSS ใหม่ๆ ที่แสดงผลนอกเทรดหลัก

ตัวอย่างเช่น เรามักเห็นตัวแทนทำสิ่งต่อไปนี้

• การใช้คิว setTimeout() ที่กำหนดเองสำหรับงานเบื้องหลังหรือที่มีลำดับความสำคัญต่ำ แทนที่จะจัดลำดับความสำคัญของงานที่ผู้ใช้มองเห็นด้วย scheduler.postTask() หรือใช้ประโยชน์จากการทำงานต่อเนื่องด้วย scheduler.yield() เมื่อเบราว์เซอร์รองรับ
• การสร้างเลย์เอาต์ที่ซับซ้อน (เช่น ตารางกริดข้อมูลที่หนาแน่น) โดยไม่ใช้ content-visibility:auto และ contain-intrinsic-size ซึ่งหมายความว่าการอัปเดตหลังจากการโต้ตอบของผู้ใช้จะทริกเกอร์การจัดเรียงใหม่ทั้งหน้า
• การซ่อนมุมมอง SPA ที่ไม่ได้ใช้งานด้วย display:none (หรือการทำลายมุมมอง) แทนการใช้ content-visibility:hidden (จับคู่กับ inert) วิธีแรกจะทำลายสถานะการแสดงผลที่แคชไว้ ดังนั้นการเปลี่ยนกลับจะทริกเกอร์เลย์เอาต์และการวาดภาพแบบเต็ม
• การหยุดภาพเคลื่อนไหว <canvas> ที่อยู่นอกหน้าจอและลูปพื้นหลังชั่วคราวด้วย Callback ของ Intersection Observer แทนที่จะจับคู่ content-visibility:auto กับเหตุการณ์ contentvisibilityautostatechange (หากมี) ทำให้พลาดระยะขอบก่อนแสดงผลของเบราว์เซอร์ก่อนที่องค์ประกอบจะเลื่อนเข้ามาในมุมมอง
• การสร้างคำแนะนำ UI สำหรับการเลื่อนโดยใช้ Listener เหตุการณ์ scroll ที่บังคับให้คำนวณเลย์เอาต์อย่างต่อเนื่อง แทนที่จะใช้การค้นหาสถานะการเลื่อน CSS เมื่อพร้อมใช้งาน (พร้อมการสำรองข้อมูล Intersection Observer)

8. ประสิทธิภาพ: การเปลี่ยนเลย์เอาต์และการกะพริบของภาพ

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

โมเดลจะเพิ่มแอตทริบิวต์ width และ height ลงในองค์ประกอบ <img> มาตรฐานได้อย่างน่าเชื่อถือเพื่อป้องกันการเปลี่ยนแปลงเลย์เอาต์ แต่โมเดลจะพลาดแหล่งที่มาอื่นๆ ที่พบบ่อยของการเปลี่ยนแปลงเลย์เอาต์และแฟลชก่อนการแสดงผลจากองค์ประกอบ <video>, การสลับแบบอักษรบนเว็บ, แถบเครื่องมือของเบราว์เซอร์บนมือถือ และการทดสอบฝั่งไคลเอ็นต์ ซึ่งทั้งหมดนี้อาจส่งผลต่อ CLS

• การละเว้นแอตทริบิวต์ width และ height ที่ชัดเจนในองค์ประกอบ <video> (เพื่อให้โปรแกรมเล่นที่ไม่ได้โหลดมีค่าเริ่มต้นเป็น 300×150 และเปลี่ยนเลย์เอาต์เมื่อโหลดข้อมูลเมตา) หรือการจัดรูปแบบองค์ประกอบ Wrapper ของสื่อแทนการตั้งค่า aspect-ratio และ object-fit โดยตรงในองค์ประกอบสื่อ
• การจับคู่แบบอักษรบนเว็บกับแบบอักษรสำรองของระบบโดยไม่มี font-size-adjust ทำให้ย่อหน้าและส่วนหัวจัดเรียงใหม่ได้อย่างชัดเจนเมื่อสลับแบบอักษรบนเว็บ
• การปรับขนาดส่วนหลักและเลย์เอาต์แบบเต็มหน้าจอด้วยหน่วย vh แบบคงที่แทนหน่วยวิวพอร์ตแบบไดนามิกหรือขนาดเล็ก (dvh, svh) ทำให้เนื้อหากระโดดเมื่อแถบเครื่องมือของเบราว์เซอร์บนมือถือขยายและหด
• การซ่อนเนื้อหาด้วยข้อมูลโค้ดป้องกันหน้าเว็บสั่น opacity:0 หรือ visibility:hidden เดิม และการหมดเวลาหลายวินาทีสำหรับการทดสอบ A/B ฝั่งไคลเอ็นต์ (ทำให้ LCP ล่าช้าและปล่อยให้องค์ประกอบที่มองไม่เห็นคลิกได้) แทนที่จะใช้สคริปต์ที่มี blocking="render" เมื่อพร้อมใช้งาน
• การทริกเกอร์การเปลี่ยนมุมมองข้ามเอกสารก่อนที่มาร์กอัปครึ่งหน้าบนที่สำคัญจะแยกวิเคราะห์แทนที่จะคงการแสดงผลครั้งแรกไว้ด้วย rel="expect" และ blocking="render" ทำให้องค์ประกอบที่แยกวิเคราะห์ครึ่งหนึ่งปรากฏขึ้นระหว่างการเปลี่ยน

9. ความปลอดภัย: การป้องกัน DOM XSS และการทำความสะอาด HTML

ข้อบกพร่องของ Cross-site Scripting (XSS) เพียงจุดเดียวช่วยให้ผู้โจมตีเรียกใช้โค้ดที่กำหนดเองในเบราว์เซอร์ของผู้ใช้ ขโมยข้อมูลเซสชัน หรือดำเนินการในนามของผู้ใช้ได้ นี่คือเหตุผลที่การป้องกันที่บังคับใช้โดยเบราว์เซอร์ เช่น การทำความสะอาด HTML ที่ปลอดภัย, Trusted Types และ CSP ที่เข้มงวดจึงมีความสำคัญอย่างยิ่ง

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

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

• การเขียนเครื่องมือทำความสะอาดรายการที่อนุญาต DOMParser ที่สร้างขึ้นเอง ไม่ว่าจะเป็นการใช้ setHTML() เป็นทางเลือกสำรองหรือภายในนโยบายประเภทที่เชื่อถือได้ แทนการใช้ไลบรารีที่ผ่านการตรวจสอบแล้วอย่าง DOMPurify เมื่อไม่มีการทำความสะอาดแบบเนทีฟ
• การรวม DOMPurify อย่างกระตือรือร้นในการโหลดหน้าเว็บทุกครั้งแทนที่จะใช้ setHTML() แบบเนทีฟเมื่อรองรับ และการโหลด DOMPurify แบบ Lazy Loading เป็นทางเลือกสำรองเท่านั้น
• การลงทะเบียนนโยบาย Trusted Types แบบส่งผ่าน (input) => input ที่อนุญาตซึ่งบั่นทอนการบังคับใช้ซิงก์
• การจับคู่ Trusted Types ในหน้าเว็บแบบคงที่กับ CSP script-src 'self' ของรายการที่อนุญาตของโฮสต์ แทนที่จะล็อกสคริปต์ในบรรทัดด้วยแฮช SHA-256
• การละเว้น 'strict-dynamic' และ 'report-sample' เมื่อกำหนดค่านโยบายรักษาความปลอดภัยเนื้อหา script-src ที่อิงตาม Nonce

10. ความปลอดภัย: การลงชื่อเข้าใช้ด้วยพาสคีย์ การตรวจสอบสิทธิ์ซ้ำ และวงจรของข้อมูลเข้าสู่ระบบ

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

WebAuthn มี API การจัดเรียงข้อมูล การตรวจจับความสามารถ และการส่งสัญญาณที่เฉพาะเจาะจง ซึ่งโมเดลที่ไม่มีคำแนะนำมักจะพลาดไปเกือบทั้งหมดในการประเมินของเรา หากคุณขอให้โมเดล AI เพิ่มการลงชื่อเข้าใช้ด้วยพาสคีย์ การจัดการ หรือการตรวจสอบสิทธิ์ซ้ำแบบ Step-Up โมเดลมักจะเขียนตัวช่วยการเข้ารหัสไบต์ด้วยตนเอง ข้ามการตรวจสอบความสามารถใน UI การจัดการ หรือทำให้ข้อมูลเข้าสู่ระบบไม่ซิงค์กับเครื่องมือจัดการรหัสผ่าน ดังนี้

• การสร้างตัวช่วยแปลง atob() และ btoa() Base64URL ด้วยตนเอง ไม่ว่าจะเป็นเส้นทางหลักหรือเป็นโค้ดสำเร็จรูปสำรองที่ซ้ำซ้อน แทนที่จะใช้เมธอดการแปลงเป็นอนุกรมในตัว เช่น parseCreationOptionsFromJSON(), parseRequestOptionsFromJSON() และ credential.toJSON()
• การละเว้น PublicKeyCredential.signalUnknownCredential() ระหว่างการลงชื่อเข้าใช้เมื่อเซิร์ฟเวอร์รายงานรหัสข้อมูลเข้าสู่ระบบที่ไม่รู้จัก ซึ่งทำให้พาสคีย์ที่ลบหรือเพิกถอนแล้วยังคงอยู่ในเครื่องมือจัดการรหัสผ่านของผู้ใช้
• ข้าม PublicKeyCredential.getClientCapabilities() ก่อนแสดงผล UI การสร้างและการจัดการพาสคีย์
• การละเว้น AbortController และ AbortSignal เมื่อเริ่มคำขอการตรวจสอบสิทธิ์อีกครั้งด้วยพาสคีย์แบบยกระดับ
• การส่งตัวเลือก mediation:"immediate" ของช่วงทดลองใช้จากต้นทางแทน uiMode:"immediate" สำหรับข้อความแจ้งให้ลงชื่อเข้าใช้ที่มีประสิทธิภาพมากขึ้น

ปิดช่องว่างเหล่านี้

ทั้ง 10 ด้านนี้เป็นเพียงส่วนหนึ่งเท่านั้น และเราคาดว่าช่องว่างด้านความรู้ที่เฉพาะเจาะจงจะเปลี่ยนแปลงไปตามกาลเวลา โมเดลจะตามทันและแพลตฟอร์มเว็บจะพัฒนาต่อไป

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

หากต้องการเริ่มต้นใช้งานคำแนะนำในการพัฒนาเว็บที่ทันสมัย ให้เรียกใช้คำสั่งต่อไปนี้ หรือค้นหาในมาร์เก็ตเพลสปลั๊กอินของ Agent

npx modern-web-guidance@latest install

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