วิธีเลือกเป้าหมายพื้นฐาน

เผยแพร่เมื่อวันที่ 20 พฤษภาคม 2025

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

เป้าหมายพื้นฐานคืออะไร

เป้าหมายพื้นฐานคือการจัดกลุ่มฟีเจอร์ของเว็บที่นักพัฒนาแอปเลือกที่จะรองรับได้ โดยอิงตามสถานะพื้นฐาน เป้าหมายพื้นฐานมี 2 ประเภท ได้แก่ เป้าหมายแบบเคลื่อนที่และเป้าหมายแบบคงที่

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

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

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

เหตุผลที่ควรเลือกเป้าหมาย

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

ใช้ข้อมูลเพื่อเลือกเป้าหมายพื้นฐาน

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

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

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

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

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

ข้อมูลพื้นฐานของ RUMvision จะแสดงข้อมูลการสนับสนุนสําหรับเป้าหมายพื้นฐานแต่ละรายการ รวมถึงรายละเอียดข้อมูลการสนับสนุนระดับฟีเจอร์

ฉันควรทำอย่างไรหากไม่มีข้อมูลการสนับสนุนจากผู้ใช้จริง

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

  • เป้าหมายพื้นฐานใหม่ เช่น ปีปัจจุบันหรือปีก่อน มีแนวโน้มที่จะได้รับการรองรับจากผู้ใช้น้อยที่สุด อย่างไรก็ตาม เป้าหมายเหล่านี้จะได้รับการรองรับที่ดียิ่งขึ้นเมื่อเวลาผ่านไป เช่นเดียวกับเป้าหมายพื้นฐานอื่นๆ
  • เป้าหมายพื้นฐานเดิมๆ โดยเฉพาะเป้าหมายพื้นฐานที่พร้อมให้บริการในวงกว้างจะได้รับการรองรับอย่างดี หากไม่แน่ใจ ให้เลือก "พร้อมให้บริการอย่างแพร่หลาย" ซึ่งเป็นเป้าหมายที่ยอดเยี่ยมซึ่งจะพัฒนาไปเรื่อยๆ ตามช่วงเวลา 30 เดือน
  • แม้แต่เป้าหมายพื้นฐานที่เก่ากว่าซึ่งอยู่นอกกรอบเวลา "พร้อมให้บริการในวงกว้าง" 30 เดือนก็ยังได้รับการสนับสนุนที่ดีที่สุด แม้ว่า "พร้อมให้บริการอย่างแพร่หลาย" จะเป็นเป้าหมายเริ่มต้นที่ดี แต่ก็มี Use Case พิเศษที่ต้องใช้ SLA ที่เข้มงวด

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

ฉันจะบังคับใช้เป้าหมายพื้นฐานที่เลือกในโปรเจ็กต์ได้อย่างไร

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

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

ฟีเจอร์ที่ไม่เป็นไปตามเป้าหมายพื้นฐานจะเป็นอย่างไร

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

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

  • การเพิ่มประสิทธิภาพ: หากใช้ฟีเจอร์ในเบราว์เซอร์ที่ไม่รองรับ ประสบการณ์การใช้งานจะไม่หยุดชะงัก ประสบการณ์การใช้งานอาจลดลง แต่ผู้ใช้อาจไม่สังเกตเห็น ตัวอย่างเช่น loading="lazy"
  • เสริม: ฟีเจอร์ให้ประโยชน์เพิ่มเติมที่อาจสังเกตได้ เช่น การเปลี่ยนแปลงการจัดรูปแบบหน้าเว็บหรือฟังก์ชันบางอย่าง ผู้ใช้อาจไม่สังเกตเห็นความแตกต่างหากเบราว์เซอร์ไม่รองรับฟีเจอร์นี้ ยกเว้นในกรณีที่เปรียบเทียบกับเบราว์เซอร์ที่รองรับ ตัวอย่าง: ตารางย่อย
  • สำคัญ: หากระบบไม่รองรับฟีเจอร์ ผู้ใช้จะได้รับประสบการณ์การใช้งานที่ไม่ดี และอาจใช้งานไม่ได้เลย ตัวอย่างเช่น File System Access API ที่ใช้เป็นฟีเจอร์หลักและจำเป็น

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

วิธีนี้จะช่วยให้คุณใช้เป้าหมายพื้นฐานเพื่อลดจํานวนฟีเจอร์ที่ต้องพิจารณาอย่างรอบคอบได้ คุณไม่ต้องกังวลกับทุกสิ่งที่อยู่ภายในเป้าหมาย หากมีฟีเจอร์ 1-2 รายการนอกกลุ่มเป้าหมายที่มีประโยชน์อย่างยิ่ง คุณมีเครื่องมือในการสำรวจเพิ่มเติมและตัดสินใจว่าจะใช้ Polyfill หรือใช้เป็น Progressive Enhancement

บทสรุป

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