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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

จะเกิดอะไรขึ้นหากผู้ให้บริการวิเคราะห์หรือ RUM ของฉันยังไม่มีรายงานเป้าหมายพื้นฐาน

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

บทสรุป

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