นักพัฒนาซอฟต์แวร์มักแจ้งให้เราทราบว่าการติดตามการเปลี่ยนแปลงบนเว็บและเข้าใจสาเหตุที่เกิดการเปลี่ยนแปลงเหล่านี้นั้นเป็นเรื่องยาก วันนี้เราจะเปิดตัวซีรีส์ใหม่เรื่อง Chrome Dev Insider ซึ่งจะมาแชร์ (1) สิ่งที่น่าสนใจและน่าสนใจในเชิงข่าวสาร (2) ข้อมูลเชิงลึกเกี่ยวกับวิธีที่เราตัดสินใจเกี่ยวกับหัวข้อสำคัญๆ (เช่น การเปลี่ยน FLOC) หรือแนวทางการทำงานของเรากับระบบนิเวศ (เช่น Interop 2022) และ (3) เรื่องสำคัญที่คุณจำเป็นต้องทราบ (เช่น เรื่องที่ตัวแทนจำเป็นต้องทราบ)
แชร์สิ่งที่เรากำลังทำอยู่ตอนนี้ในบริบทของสิ่งสำคัญ 4 ประการสำหรับปี 2022 ดังนี้
- การสร้างประสบการณ์ที่น่าพึงพอใจให้กับผู้ใช้: ทำให้ผู้ใช้ใช้งานสิ่งต่างๆ ได้ง่าย ไม่ว่าจะเป็นประสิทธิภาพ ธุรกรรม ตัวตน หรือการเปลี่ยนแปลง
- การยกระดับความสามารถของเว็บ: รองรับบทบาทที่เปลี่ยนแปลงไปของเว็บจากการเป็นแพลตฟอร์มการบริโภคเนื้อหา ไปจนถึงแพลตฟอร์มสำหรับประสบการณ์ที่หลากหลาย รวมถึงความต้องการในการผสานรวมระบบปฏิบัติการในระดับฮาร์ดแวร์ในระดับลึก
- ลดความซับซ้อนของการพัฒนาเว็บ: ตัดสินใจได้ง่ายขึ้นและปรับปรุงประสิทธิภาพการทำงานของนักพัฒนาซอฟต์แวร์
- การปรับปรุงความเป็นส่วนตัวของเว็บ: ให้บริการผู้ใช้เว็บ ความคาดหวังในการคุ้มครองความเป็นส่วนตัวของข้อมูลที่ดีขึ้นเมื่อต้องเผชิญกับความซับซ้อนของนักพัฒนาซอฟต์แวร์ที่เพิ่มขึ้นเรื่อยๆ ในด้านการติดตามและการกำหนดเป้าหมาย
ข่าวสาร: การทำงานร่วมกัน 2022
เมื่อวางแผนโรดแมป เราจะพิจารณาความคิดเห็นของนักพัฒนาแอปเพื่อทำความเข้าใจปัญหาและความต้องการอันดับต้นๆ ของนักพัฒนาเว็บ รวมถึงปัจจัยอื่นๆ ธีมหลักที่ปรากฏซ้ำๆ คือความเข้ากันได้กับเบราว์เซอร์ ซึ่งทำให้ประสบการณ์การใช้งานทำงานเหมือนกันในเบราว์เซอร์ต่างๆ ตลอดปีที่ผ่านมา เราทำงานกับระบบนิเวศเพื่อจัดการกับธีมนี้ ซึ่งถือเป็นส่วนหนึ่งของภารกิจสำคัญที่เราจะต้อง "ทำให้การพัฒนาเว็บง่ายขึ้น"
เมื่อปีที่แล้ว Microsoft, Chrome และผู้เล่นในระบบนิเวศได้ประกาศเปิดตัว Compat 2021 ซึ่งส่งผลให้เครื่องมือเบราว์เซอร์ยอดนิยมทั้งหมด (Chromium, Gecko และ Webkit) ได้คะแนนมากกว่า 90% ในด้านสำคัญ 5 ด้านที่ระบุไว้สำหรับปีนี้ เมื่อเทียบกับปัจจัยอื่นๆ แล้ว Compat 2021 นำไปสู่การสร้างรากฐานที่มั่นคงสำหรับฟีเจอร์ที่มีประสิทธิภาพ เช่น CSS Grid (มีปริมาณการใช้งานเพิ่มขึ้น 12% และเพิ่มขึ้นอย่างต่อเนื่อง) และ CSS Flexbox (การใช้งาน 77%)
และเมื่อเดือนที่แล้ว Apple, Bocoup, Google, Igalia, Microsoft และ Mozilla ได้รวมตัวกันเป็นผู้สนับสนุนเพื่อแก้ไขปัญหาด้านความเข้ากันได้ของเบราว์เซอร์ยอดนิยมที่นักพัฒนาเว็บระบุ และยอมรับการเปรียบเทียบร่วมกัน ผลที่ได้ก็คือ Interop 2022 ซึ่งเป็นโครงการที่มีเป้าหมายที่จะช่วยเพิ่มความเป็นเอกภาพให้กับแพลตฟอร์ม การเปรียบเทียบนี้มุ่งเน้นไปที่ด้านที่สำคัญ 15 ด้านซึ่งนักพัฒนาซอฟต์แวร์ระบุไว้ว่าเป็นหัวใจสำคัญในการเพิ่มประสิทธิภาพการทำงาน
ข่าววงใน: การทำงานร่วมกับเบราว์เซอร์
ด้วยความตระหนักรู้ถึงการทำงานร่วมกันในปี 2022 ฉันจึงได้มานั่งพูดคุยกับ Robert Nyman และ Philip Jägenstedt ผู้ที่มีส่วนร่วมในบทสนทนาเหล่านี้เพื่อฟังเรื่องราวภายใน นี่คือภาพที่ตัดต่อโดยบรรณาธิการให้แสดงที่มาด้วยกัน
ที่มาของโครงการริเริ่มนี้คืออะไร
Robert: ทุกอย่างเริ่มต้นขึ้นในปี 2019 ตอนที่เราทำการสำรวจ MDN DNA 2019 ปัญหาความเข้ากันได้นั้นเห็นได้ชัดเจนว่าเป็นปัญหาหลักสำหรับนักพัฒนาแอปที่สร้างสำหรับเว็บ และเราได้ติดตามรายละเอียดเพิ่มเติมมากมายในรายงานความเข้ากันได้ของเบราว์เซอร์ MDN 2020 ข้อมูลนี้ทำให้เรามีข้อมูลและข้อมูลที่นำไปปฏิบัติได้มากเพียงพอสำหรับเริ่มความพยายามปฏิบัติตามข้อกำหนดในปี 2021 ส่งผลให้การดำเนินงานนั้นดำเนินต่อไปและขยายขอบเขตดังกล่าวด้วยการทำงานร่วมกันในปี 2022
Philip: ฉันอยากพูดถึง web-platform-tests และ State of CSS 2021 ด้วย เราได้ทำงานร่วมกันอย่างหนักกับผู้ให้บริการเบราว์เซอร์รายอื่นๆ ในการทดสอบโดยใช้ WPT ในช่วงหลายปีที่ผ่านมา เราจึงอยากนำเรื่องนี้มาใช้ประโยชน์ การทดสอบสำหรับฟีเจอร์เหล่านี้ส่วนใหญ่เขียนไว้อยู่แล้ว เราจึงจําเป็นต้องทบทวนการทดสอบและเพิ่มการครอบคลุมบางส่วนที่ขาดหายไป Google ลงทุนไปอย่างมากกับ wpt.fyi แต่เรายังมี Mozilla ต้องขอบคุณที่ทำให้ WPT ประสบความสำเร็จอย่างทุกวันนี้ แน่นอนว่า Mozilla มีส่วนสำคัญอย่างมากในการสำรวจดีเอ็นเอ MDN นอกเหนือจากนั้น ยังมีสถานะของ CSS 2021 อีกด้วย เพื่อร่วมกันทำงานอย่างการทำงานร่วมกัน 2022 เราต้องขอความคิดเห็นใหม่ๆ เกี่ยวกับความต้องการของนักพัฒนาเว็บ จึงร่วมมือกับผู้บำรุงรักษาแบบสำรวจอย่าง Sacha เพื่อใส่คำถามใหม่ๆ เกี่ยวกับปัญหาความเข้ากันได้ของเบราว์เซอร์ สิ่งนี้ช่วยเราอย่างมากในขั้นตอนการวางแผนการทำงานร่วมกันในปี 2022
มีข้อคิดเห็นหรือความคิดเห็นอะไรจาก Compat 2021 ไหม
Robert: การวัดค่าและมีคะแนนและข้อมูลเชิงลึกเกี่ยวกับประสิทธิภาพของแต่ละเครื่องมือของเบราว์เซอร์นั้นมีประโยชน์มาก เพื่อให้เราติดตามความคืบหน้า รวมถึงหารือและแก้ไขปัญหาที่ไม่ชัดเจนหรือต้องได้รับการจัดลำดับความสำคัญได้ และเรายังตระหนักได้อย่างรวดเร็วว่า "การทำงานร่วมกัน" เป็นชื่อที่ดียิ่งขึ้นสำหรับโครงการริเริ่ม โดยทั่วไปแล้ว คำว่าความเข้ากันได้และความสามารถในการทำงานร่วมกันจะแยกความแตกต่างตามผู้ให้บริการเบราว์เซอร์ ส่วนการทำงานร่วมกันหมายถึงการทำงานร่วมกันของเว็บไซต์ ส่วนการทำงานร่วมกันหมายถึงเบราว์เซอร์ตั้งแต่ 2 เบราว์เซอร์ขึ้นไปที่ทำงานเหมือนกัน ในคำศัพท์ดังกล่าว ความพยายามนี้เกี่ยวข้องกับความสามารถในการทำงานร่วมกัน และเพื่อให้โปรเจ็กต์สอดคล้องกับชื่อดังกล่าว
วิสัยทัศน์ของเราในที่นี้
Robert: หากต้องการทำให้เว็บเปิดกว้างอยู่เสมอ ความหลากหลายของเบราว์เซอร์และการแสดงผลเครื่องมือมีความสำคัญอย่างยิ่ง น่าเสียดายที่ปัจจุบันฟีเจอร์นี้มีราคาสูงสำหรับนักพัฒนาซอฟต์แวร์ที่ต้องตามให้ทันระดับการสนับสนุนฟีเจอร์ในแต่ละเครื่องมือที่แตกต่างกัน วิสัยทัศน์ของเราคือให้นักพัฒนาซอฟต์แวร์มองว่าแพลตฟอร์มเว็บเป็นตัวเลือกที่มีประสิทธิภาพมากที่สุดและเป็นตัวเลือกที่น่าดึงดูดใจมากที่สุดตามความต้องการของตน และพวกเขาสามารถมุ่งเน้นการสร้างประสบการณ์ที่ดีที่สุดเท่าที่จะเป็นไปได้ แทนที่จะเสียเวลามากมายไปกับการแก้ปัญหาการทำงานร่วมกัน และเห็นได้ชัดเจนมากว่า การจะบรรลุเป้าหมายนั้น จะต้องมีคุณลักษณะที่เป็นที่ต้องการมากที่สุดในเครื่องมือค้นหาเบราว์เซอร์หลักๆ ทั้งหมด เพื่อให้นักพัฒนาซอฟต์แวร์ประสบความสำเร็จบนแพลตฟอร์มเว็บได้อย่างแท้จริง
เราจะร่วมกันขับเคลื่อนสิ่งต่างๆ ไปข้างหน้าอย่างไรเมื่อเบราว์เซอร์ที่มีเป้าหมายที่ต่างกัน (บางครั้ง) ทำงานร่วมกัน
Philip: แนวทางของเราคือมองหาส่วนของความสนใจร่วมกันเพื่อหาการทำงานร่วมกันที่ได้รับประโยชน์ทั้ง 2 ฝ่าย โดยที่เป้าหมายต่างๆ สอดคล้องกันอยู่แล้ว และด้วยการจัดลำดับความสำคัญให้กับการทำงานในจำนวนที่จำกัดในเวลาเดียวกัน เราจึงให้ความสำคัญกับส่วนเหล่านั้น รวมถึงก้าวไปข้างหน้าอย่างรวดเร็วและได้รับคุณภาพที่ดีกว่าเดิมหากเพียงแค่ทำงานแยกกัน นี่คือแนวคิดหนึ่ง
ผมคิดว่าเป็นเรื่องสำคัญที่จะต้องตระหนักว่ามีขีดจำกัดสำหรับวิธีการตามความเห็นพ้องนี้ โดยที่เป้าหมายยังไม่เพียงพอที่เราจะต้องดำเนินการต่อในอีกทางหนึ่ง บางครั้งการแสดงหลักฐานเพิ่มเติมเกี่ยวกับความต้องการของนักพัฒนาเว็บหรือความต้องการของผู้ใช้อาจช่วยได้ แต่ท้ายที่สุดแล้ว ผู้ให้บริการเบราว์เซอร์สามารถส่งมอบสิ่งต่างๆ ที่ไม่มีข้อตกลงกว้างๆ ได้ ในกรณีที่ดีที่สุด นักพัฒนาเว็บจะแสดงให้เห็นประโยชน์ของฟีเจอร์นั้นๆ โดยพบว่าสามารถตอบสนองความต้องการ และถามถึงการใช้ฟีเจอร์เดียวกันในทุกเบราว์เซอร์
เมื่อย้อนกลับไปที่การทำงานร่วมกันในปี 2022 เราจะเห็นว่ามีฟีเจอร์ใหม่ที่ไม่ใช่การออกแบบหรือเลย์เอาต์พร้อมใช้งานไหม
ฟิลิป: แน่นอน การทำงานร่วมกันในปี 2022 ไม่ได้จำกัดอยู่แค่ฟีเจอร์ด้านสไตล์และเลย์เอาต์ แต่สุดท้ายแล้วก็เอนเอียงไปทาง CSS อย่างมาก ส่วนหนึ่งเป็นเพราะสถานะของ CSS 2021 มีความสดใหม่ แต่ก็เป็นเพราะนักพัฒนาเว็บได้แจ้งให้เราทราบว่าจุดนี้เป็นจุดที่ผู้ใช้พบปัญหาเรื่องความแตกต่างระหว่างเบราว์เซอร์มากที่สุด จุดมุ่งเน้นหลายด้าน เช่น องค์ประกอบแบบฟอร์มและกล่องโต้ตอบ จะทำงานมากกว่า CSS และเรายังมีความพยายามในการตรวจสอบเกี่ยวกับการแก้ไข API และเหตุการณ์เกี่ยวกับตัวชี้และเมาส์ เราหวังว่าสำหรับการทำงานร่วมกันในปี 2023 เราจะมีข้อมูลใหม่ๆ เกี่ยวกับความต้องการของนักพัฒนาซอฟต์แวร์ทั่วทั้งอินเทอร์เน็ต และจะได้รวมฟีเจอร์ต่างๆ ดังกล่าวเพิ่มเติมด้วย
การเปลี่ยนแปลงสำคัญที่จะเกิดขึ้น
หนึ่งในจุดประสงค์ของซีรีส์นี้คือเพื่อให้นักพัฒนาแอปได้ทราบล่วงหน้าเกี่ยวกับการเปลี่ยนแปลงสำคัญที่จะเกิดขึ้น ซึ่งสำคัญต่อการปรับปรุงประสบการณ์ของผู้ใช้และความสามารถของแพลตฟอร์ม
ลำดับเวลาที่ระบุไว้ด้านล่างคือเวลาที่เราคาดว่าการเปลี่ยนแปลงเหล่านี้จะเกิดขึ้น แต่เวอร์ชันที่เผยแพร่สำหรับฟีเจอร์ต่างๆ อาจมีการเปลี่ยนแปลง
การลด User Agent
ส่วนหัว User-Agent และอินเทอร์เฟซ JS ที่เกี่ยวข้องไม่เพียงส่งข้อมูลเบราว์เซอร์และอุปกรณ์ที่เป็นประโยชน์ แต่ยังรวมถึงข้อมูลเชื้อสายและข้อมูลที่ไม่ถูกต้องเอาไว้ด้วย ปัญหามากกว่าการมีข้อบกพร่องในการแยกวิเคราะห์สตริง UA ที่แทบไม่มีที่สิ้นสุดก็คือ การที่ข้อบกพร่องในการแยกวิเคราะห์สตริง UA จะส่งแบบพาสซีฟไปยังเซิร์ฟเวอร์สำหรับคำขอการนำทางและทรัพยากรย่อยทั้งหมด ซึ่งแสดงถึงเอนโทรปีประมาณ 10 บิตที่เซิร์ฟเวอร์สามารถใช้สร้างตัวระบุการติดตามที่เสถียรขณะที่ผู้ใช้ท่องเว็บ
แผนปัจจุบันของเราคือการลดสตริง UA ที่มีอยู่โดยการจัดส่งเวอร์ชันหลักของเบราว์เซอร์ที่มีเอนโทรปีต่ำ ชื่อแพลตฟอร์ม และความเหมาะกับอุปกรณ์เคลื่อนที่ ซึ่งจะช่วยทำให้ข้อมูลเอนโทรปีสูงคงอยู่ต่อไป สำหรับกรณีการใช้งานที่ต้องการข้อมูลเพิ่มเติมมากกว่าที่มีอยู่ในส่วนหัว เราได้จัดส่ง API User-Agent Client Hints API มาตั้งแต่ Chrome 89
เราทำการทดสอบจากต้นทางเป็นเวลา 6 เดือนเพื่อทำการทดสอบและแสดงความคิดเห็น และยินดีที่ได้รับความคิดเห็นเกี่ยวกับการหยุดทำงานแม้จะมีผู้เข้าร่วมมากกว่า 200 คน
- ไทม์ไลน์: ใน Chrome 101 เราจะกําลังดำเนินการกับสิ่งที่เราเรียกว่า ระยะที่ 4 นั่นคือการลดข้อมูล
MINOR.BUILD.PATCHในสตริง UA เป็น0.0.0และเราจะแจ้งให้เว็บไซต์ต่างๆ ทราบล่วงหน้าและจะเตรียมพร้อมสำหรับระยะที่ 5 เป็นต้นไปต่อไป นอกจากนี้เรายังสร้างนโยบายองค์กรเพื่อเลือกไม่ใช้การเปลี่ยนแปลงเหล่านี้อีกด้วย และจะทำการทดลองใช้การเลิกใช้งานจนถึง Chrome 113 เพื่อให้เว็บไซต์มีเวลามากขึ้นในการเตรียมพร้อมสำหรับการเปลี่ยนแปลงเหล่านี้ - คำกระตุ้นการตัดสินใจ: ย้ายข้อมูลเว็บไซต์ไปยังคำแนะนำไคลเอ็นต์ UA หรือเข้าร่วมการทดลองใช้การเลิกใช้งาน
API การเข้าถึงแบบอักษรในเครื่อง
Chrome กำลังจะเปิดตัว Local Font Access API แม้ว่าเว็บไซต์จะใช้แบบอักษรในเครื่องมานานแล้ว แต่ API นี้จะแจกแจงรายการแบบอักษรในเครื่องและให้การเข้าถึงข้อมูลแบบอักษรนั้นๆ ฟังก์ชันนี้ช่วยให้ผู้ใช้สามารถใช้แบบอักษรทั้งหมดของตนกับการออกแบบบนเว็บและแอปพลิเคชันอื่นๆ
แบบอักษรในเครื่องเป็นที่รู้จักกันมาอย่างยาวนานว่าเป็นเวกเตอร์การเก็บลายนิ้วมือ แม้ว่า API ใหม่นี้จะไม่เพิ่มความสามารถในการใช้แบบอักษรสำหรับการเก็บลายนิ้วมือ แต่ Chrome กำหนดให้ผู้ใช้ต้องให้สิทธิ์ "local-fonts" ใหม่สำหรับเว็บไซต์ก่อนจึงจะใช้ Local Font Access API ใหม่ได้
ในอนาคต เราวางแผนที่จะกำหนดให้ใช้ "local-fonts" เดียวกัน ได้รับสิทธิ์ก่อนใช้ API อื่นๆ ที่ให้สิทธิ์เข้าถึงแบบอักษรในเครื่อง
- ไทม์ไลน์: การกำหนดเป้าหมาย Chrome 103 (มิถุนายน 2022)
- คำกระตุ้นให้ดำเนินการ (Call-To-Action:) ดูข้อมูลเพิ่มเติมเกี่ยวกับ API และวิธีใช้งานเพื่อเริ่มติดตั้งใช้งาน
การทำให้ BFCache ใช้งานได้กับ Cache-control: no-store
เราพบโอกาสสำคัญในการปรับปรุงความถี่ที่แคชย้อนหลังสามารถแสดงการนำทางกลับ/ไปข้างหน้าแบบทันทีได้ การดำเนินการนี้จำเป็นต้องเปลี่ยนลักษณะการทำงานของ BFCache ในหน้าที่แสดงด้วยส่วนหัว Cache-control: no-store HTTP เรามีข้อเสนอสาธารณะที่ออกแบบมาเพื่อป้องกันไม่ให้เกิดความตกใจมากด้วยการตรวจสอบสัญญาณต่างๆ (เช่น นำหน้าออกจาก BFCache ทุกครั้งที่มีการเปลี่ยนแปลงคุกกี้แบบ HTTP-เท่านั้น) และดูรายละเอียด (เช่น นโยบายกลุ่มสำหรับลูกค้า Enterprise/Edu) สำหรับบริบทเฉพาะต่างๆ นี่เป็นโอกาสที่ซับซ้อนแต่ก็น่าตื่นเต้น เราจึงอยากได้การตรวจสอบและความคิดเห็นเพิ่มเติม
- ลำดับเวลา: กำหนดเป้าหมายไปยัง Chrome 104 (กรกฎาคม 2022) โดยไม่ทำให้เกิดอะไรที่น่าประหลาดใจครั้งใหญ่
- คำกระตุ้นให้ดำเนินการ (Call-To-Action): ดูรายละเอียดเพิ่มเติมในข้อเสนอ รวมถึงวิธีเปิดใช้การติดตั้งใช้งานที่อยู่ระหว่างดำเนินการ และวิธีแชร์ความคิดเห็น เช่น สถานการณ์จริงที่แนวทางของเราสร้างอุปสรรคใหม่ๆ
ในซีรีส์นี้ เราหวังว่าจะสามารถทำให้ชุมชนนักพัฒนาซอฟต์แวร์ของเราโฟกัสและความสัมพันธ์กันได้โดยทำให้พวกเขาใกล้ชิดกับทีมและการทำงานของพวกเขามากขึ้น โปรดคอยติดตามและคอยติดตามข้อมูลอัปเดตเพิ่มเติมในพื้นที่นี้
ในระหว่างนี้ ขอให้สนุกกับ Webbing
คุณคิดอย่างไรกับ The Chrome Dev Insider ฉบับแรก แชร์ความคิดเห็น