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

เผยแพร่เมื่อ: 20 พฤษภาคม 2025

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

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

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

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

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

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

เหตุใดจึงควรเลือกเป้าหมาย

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

ใช้ข้อมูลเพื่อเลือกฟีเจอร์ที่พร้อมใช้งานเป็นเป้าหมาย

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

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

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

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

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

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

ฉันควรทำอย่างไรหากผู้ให้บริการ Analytics หรือ RUM ยังไม่มีรายงานฟีเจอร์ที่พร้อมใช้งานเป็นเป้าหมาย

หากคุณใช้เครื่องมือ Analytics หรือ RUM ที่ยังไม่มีรายงานฟีเจอร์ที่พร้อมใช้งานเป็นเป้าหมาย แต่มีข้อมูลเกี่ยวกับเบราว์เซอร์เวอร์ชันต่างๆ คุณสามารถรวมข้อมูลจริงกับข้อมูลการจับคู่เบราว์เซอร์เวอร์ชันต่างๆ จากโมดูล baseline-browser-mapping ได้ โมดูลนี้มีฟังก์ชัน JavaScript - getAllVersions() - ที่จับคู่เบราว์เซอร์ตามชื่อและเวอร์ชันกับปีที่ฟีเจอร์พร้อมใช้งานและสถานะการรองรับสำหรับฟีเจอร์ที่พร้อมใช้งานอย่างแพร่หลาย การจับคู่เหล่านี้สามารถแสดงเป็นอาร์เรย์ ออบเจ็กต์ที่มีคีย์ หรือเป็นไฟล์ CSV เช่น เครื่องมือตรวจสอบฟีเจอร์ที่พร้อมใช้งานของ Google Analytics ใช้โมดูลนี้เพื่อรวมข้อมูล Analytics กับฟีเจอร์ที่พร้อมใช้งานเป็นเป้าหมาย

เอาต์พุตของฟังก์ชันนี้ยังพร้อมใช้งานเป็นไฟล์ JSON หรือ CSV ที่โฮสต์ไว้ ซึ่งจะอัปเดตทุกวัน ไฟล์ all_versions_with_supports.csv มีข้อมูลที่คุณสามารถจับคู่กับข้อมูลเบราว์เซอร์เวอร์ชันต่างๆ ของผู้ให้บริการ Analytics ได้โดยใช้ช่องต่อไปนี้

  • browser: ชื่อเบราว์เซอร์ตามที่ใช้ใน baseline-browser-mapping
  • version: เวอร์ชันของเบราว์เซอร์ เบราว์เซอร์บางตัวใช้เฉพาะหมายเลขเวอร์ชันหลัก ส่วนเบราว์เซอร์อื่นๆ ใช้หมายเลขเวอร์ชัน major.minor
  • year: ชุดฟีเจอร์ของปีที่ฟีเจอร์พร้อมใช้งานที่เบราว์เซอร์เวอร์ชันนี้รองรับ หากเบราว์เซอร์เวอร์ชันหนึ่งเผยแพร่ก่อนที่จะกำหนดการรองรับฟีเจอร์ที่พร้อมใช้งานได้ในเดือนกรกฎาคม 2015 ช่องนี้จะมีค่าเป็น pre_baseline
  • supports: ช่องนี้จะมีค่าเป็น widely หรือ newly สำหรับเบราว์เซอร์เวอร์ชันที่รองรับชุดฟีเจอร์เหล่านั้น และจะเป็นค่าว่างสำหรับเวอร์ชันที่ไม่รองรับชุดฟีเจอร์ใดๆ เบราว์เซอร์เวอร์ชันทั้งหมดที่รองรับฟีเจอร์ที่พร้อมใช้งานใหม่จะรองรับฟีเจอร์ที่พร้อมใช้งานอย่างแพร่หลายด้วย
  • release_date: วันที่เผยแพร่เบราว์เซอร์เวอร์ชันนี้ (หากมี)
  • engine: ชื่อเอนจินสำหรับเบราว์เซอร์ที่อยู่ปลายทางของเบราว์เซอร์ Baseline หลัก ระบบจะรวมเฉพาะเบราว์เซอร์ที่ใช้ Blink แต่เอนจินเบราว์เซอร์อื่นๆ อาจแสดงในอนาคต
  • engine_version: เวอร์ชัน Chromium ที่เบราว์เซอร์เวอร์ชันนี้ใช้ ซึ่งใช้เพื่อกำหนดชุดฟีเจอร์ Baseline ที่เวอร์ชันปลายทางรองรับ

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

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

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

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

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

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

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

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

ฉันควรทำอย่างไรกับฟีเจอร์ที่ไม่ตรงกับฟีเจอร์ที่พร้อมใช้งานเป็นเป้าหมาย

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

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

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

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

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

บทสรุป

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