Chrome Dev Insider: การเพิ่มประสิทธิภาพด้วยระบบนิเวศของเฟรมเวิร์ก

Paul Kinlan

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

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

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

สำหรับ Chrome Dev Insider ฉบับที่ 3 ฉันได้พูดคุยกับ Addy Osmani, Kara Erickson และ Houssein Djirdeh จากทีม Project Aurora ว่าพวกเขามีการดำเนินงานเกี่ยวกับโครงการนี้อย่างไรและพวกเขารออะไรอยู่

ข่าววงใน: การทำงานร่วมกับเฟรมเวิร์กของบุคคลที่สาม

มาเริ่มกันที่ที่มาของโปรเจ็กต์นี้ เหตุใดจึงเป็นเช่นนั้น

Addy: Aurora เริ่มต้นด้วยแนวคิดง่ายๆ นั่นก็คือ มาพบกับนักพัฒนาซอฟต์แวร์ที่พวกเขาอยู่และช่วยให้พวกเขาไปยังที่ที่พวกเขาต้องการ ตัวอย่างเช่น ช่วยเหลือชุดซอฟต์แวร์โครงสร้างพื้นฐานยอดนิยมที่เขาเลือกที่จะปรับปรุงประสิทธิภาพ นักพัฒนาแอปจำนวนมากกำลังสร้างโดยใช้ React, Vue หรือ Angular ในทุกวันนี้ หรือจะใช้เมตา-frameworks* เช่น Next.js และ Nuxt (และแน่นอน แอปอื่นๆ อีกมากมาย... Svelte, Lit, Preact, Astro รายการจะดำเนินต่อไป) แทนที่จะคาดหวังให้นักพัฒนาซอฟต์แวร์เหล่านี้กลายเป็นผู้เชี่ยวชาญเชิงลึก (เช่น ในเรื่องประสิทธิภาพ) เราดูแลให้นักพัฒนาแอปเหล่านี้ตกอยู่ในห้วงแห่งความสำเร็จได้ ด้วยการทำตามแนวทางปฏิบัติแนะนำเพิ่มเติมโดยค่าเริ่มต้น วิธีนี้จะทำให้เว็บไซต์มีคุณภาพดีขึ้นเป็นผลข้างเคียงจากการสร้างเว็บเพียงอย่างเดียว

Aurora เลือกเฟรมเวิร์กและเมตา-เฟรมเวิร์คที่ใช้กันอย่างแพร่หลาย 2-3 รายการที่ต้องการร่วมทำงานด้วย โดยบันทึกสิ่งที่ได้เรียนรู้ของเรา (เช่น วิธีสร้างองค์ประกอบรูปภาพที่ดี) เพื่อให้ผู้อื่นทำตามได้อย่างรวดเร็วและพยายามปรับขนาดผ่านเฟรมเวิร์กและเครื่องมืออื่นๆ ผ่านกองทุน Chrome Frameworks Fund แม้ว่าจะสามารถปรับปรุงคุณภาพประสบการณ์การใช้งานเว็บผ่านเบราว์เซอร์ได้ แต่เราเชื่อว่าเป้าหมายนี้ก็สามารถบรรลุได้ด้วย (ในบางกรณี) ผ่านเฟรมเวิร์กด้วยเช่นกัน เราหวังว่าสิ่งนี้จะช่วยเราบรรลุเป้าหมายในการสร้างเว็บที่มีคุณภาพสูงขึ้นสำหรับทุกคน

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

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

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

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

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

ตัวอย่างเช่น เว็บเฟรมเวิร์ก (Next.js, Nuxt.js และในขอบเขต Angular) จะพยายามนำเสนอความคิดเห็นและค่าเริ่มต้นมากกว่าโซลูชันที่ผู้ใช้ต้องดำเนินการเอง นี่เป็นเหตุผลหนึ่งที่เราชอบทำงานร่วมกัน การใช้ค่าเริ่มต้นที่รัดกุมยิ่งขึ้นสำหรับวิธีโหลดรูปภาพ แบบอักษร และสคริปต์เพื่อให้ Core Web Vitals ที่ดียิ่งขึ้นเหมาะสำหรับโมเดลเหล่านี้

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

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

ตัวอย่างเช่น หากเราดูความนิยมเพียงอย่างเดียว React, Vue และ Angular คือ "3 องค์ประกอบหลัก" ที่ต้องพิจารณา แต่เราทำงานกับ Next.js, Nuxt และ Angular ได้มากที่สุด เนื่องจากไลบรารีการแสดงผล เช่น React และ Vue จะเน้นการแสดงภาพเป็นหลัก จึงเป็นไปไม่ได้ที่จะสร้างฟีเจอร์ทั้งหมดที่เราต้องการรวมไว้ในไฟล์โดยตรง ดังนั้น เราจึงทำงานอย่างใกล้ชิดกับเฟรมเวิร์กเมตาที่ได้รับความเห็นซึ่งสร้างจาก Next.js และ Nuxt สำหรับ Abstraction ระดับนี้ เราจะสร้างคอมโพเนนต์ในตัวได้ ทั้งยังมีเซิร์ฟเวอร์ในตัวเพื่อให้เราสามารถรวมการเพิ่มประสิทธิภาพฝั่งเซิร์ฟเวอร์ได้

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

และน่าสังเกตว่าเรามีความสัมพันธ์อย่างต่อเนื่องกับโครงการอื่นๆ อย่างเช่น Gatsby ซึ่งเราจะซิงค์การออกแบบบ้างแต่ไม่ค่อยได้มีส่วนร่วมในการออกแบบโค้ด

แล้วโซลูชันนี้มีลักษณะอย่างไรในทางปฏิบัติ และวิธีแก้ปัญหานี้ของคุณคืออะไร

Kara: ในทางปฏิบัติ เรามีเฟรมเวิร์ก 2-3 อย่างที่เราทำงานร่วมกันอย่างใกล้ชิด เราจะใช้เวลาสักระยะหนึ่งในโปรไฟล์แอปโดยใช้เฟรมเวิร์กนั้นและค้นหาจุดบกพร่องที่พบบ่อยเกี่ยวกับประสิทธิภาพ จากนั้นเราจะทำงานร่วมกับทีมเฟรมเวิร์กเพื่อออกแบบฟีเจอร์ทดลองเพื่อแก้ไขประเด็นปัญหาเหล่านั้น และเขียนโค้ดไปยังที่เก็บ OSS โดยตรงเพื่อติดตั้งใช้งาน

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

ทั้งหมดนี้ไม่สามารถทำได้ง่ายๆ เหมือนกับการแสดงความคิดเห็น ความท้าทายหรือการเรียนรู้ต่างๆ ที่คุณได้รับจนถึงตอนนี้มีอะไรบ้าง

Houssein: สิ่งสำคัญอย่างหนึ่งที่เราพยายามทำอย่างสุดความสามารถคือการมีส่วนร่วมกับที่เก็บข้อมูลโอเพนซอร์สยอดนิยมซึ่งมีความสำคัญพอๆ กันหลายประการ การที่เราเป็นทีม Google ไม่ได้หมายความว่าฟีเจอร์ของเราจะได้รับการจัดลำดับความสำคัญสูงเสมอไป เราจึงพยายามอย่างดีที่สุดเพื่อให้สอดคล้องกับขั้นตอนทั่วไปในการเสนอและจัดส่งฟีเจอร์ใหม่ๆ โดยไม่เป็นการรบกวนผู้อื่น เราโชคดีมากที่ได้ร่วมงานกับผู้ดูแลจัดการที่เปิดรับในระบบนิเวศ Next.js, Nuxt และ Angular เรารู้สึกซาบซึ้งที่ทีมดังกล่าวเปิดใจรับฟังข้อกังวลของเราเกี่ยวกับระบบนิเวศของเว็บ และยินดีที่จะทำงานร่วมกับเราด้วยวิธีการต่างๆ มากกว่า 1 วิธี

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

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

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

ถัดไป คุณมุ่งเน้นที่การเพิ่มประสิทธิภาพประเภทใด

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

จากความคิดนี้ เราได้จัดส่ง:

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

ช่วยแชร์ผลลัพธ์เชิงบวกจากผลงานของคุณกับผู้เล่นบางคนได้ไหม

Houssein: เว็บไซต์จำนวนมากพบว่าประสิทธิภาพดีขึ้นเนื่องจากการเพิ่มประสิทธิภาพที่เรามอบให้ ตัวอย่างหนึ่งที่ผมชอบคือ Leboncoin ที่ลด LCP จาก 2.4 วินาทีเป็น 1.7 วินาทีหลังจากที่เปลี่ยนไปใช้คอมโพเนนต์รูปภาพ Next.js ในระยะการทดสอบและการทดสอบยังอยู่ในช่วงอื่นๆ อีกมาก เราจะแชร์สิ่งที่ได้เรียนรู้และความสำเร็จจากการทดสอบเหล่านั้นต่อไปที่นี่

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

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

เราได้เห็นความสำเร็จบางอย่างจากการนำสิ่งที่ได้เรียนรู้จากระบบนิเวศหนึ่ง (เช่น React และ Next.js) มามอบให้กับคนอื่นๆ ตัวอย่างเช่น คำสั่งว่าด้วยภาพ Angular ใหม่ (สร้างขึ้นจากการเรียนรู้ของเราเกี่ยวกับการสร้างคอมโพเนนต์รูปภาพ Next.js) หรือ Gatsby เพื่อจัดส่งวิธีการของเราในการแบ่งส่วน JavaScript แบบละเอียด

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

แล้วแผนกลยุทธ์ในอนาคตสำหรับทีมของคุณมีอะไรบ้าง

Kara: เรามีโปรเจ็กต์ที่น่าตื่นเต้นมากมายกำลังจะมาถึง! ตัวอย่างคุณลักษณะสำคัญบางประการ:

  • การลด CLS เกี่ยวกับแบบอักษร: เป็นเรื่องปกติที่จะเห็นการเปลี่ยนเลย์เอาต์เมื่อโหลดแบบอักษรเว็บแล้วแทนที่แบบอักษรสำรอง เรากำลังทดลองการใช้การลบล้างเมตริกแบบอักษรและพร็อพเพอร์ตี้ "ปรับขนาด" เพื่อลด CLS ที่เกี่ยวข้องกับแบบอักษรโดยค่าเริ่มต้นใน Next.js นอกจากนี้เรายังได้ปรึกษากับทีม Nuxt เกี่ยวกับเรื่องนี้และวางแผนที่จะขยายแนวคิดนี้ไปยังเฟรมเวิร์กอื่นๆ ในปีหน้า
  • การแก้ไขข้อบกพร่อง INP: ตอนนี้เราเปิดตัวเมตริก Interaction to Next Paint (INP) แล้ว เรากำลังทำงานร่วมกับเฟรมเวิร์กเพื่อตรวจสอบสาเหตุหลักของปัญหา INP ที่เกิดขึ้นในชุมชนและแนะนำการแก้ไข เราร่วมงานกับ Angular อย่างใกล้ชิดในเรื่องนี้ และหวังว่าจะได้แชร์ผลลัพธ์ในเร็วๆ นี้
  • การเพิ่มประสิทธิภาพสคริปต์ 3P ทั่วไป: การโหลดสคริปต์ของบุคคลที่สามในเวลาที่ไม่เหมาะสมอาจส่งผลเสียต่อประสิทธิภาพได้อย่างมาก เนื่องจากมี 3P ที่ใช้กันทั่วไปอยู่บ้าง เราจึงพิจารณาว่าจะเสนอ Wrapper สำหรับ Wrapper เหล่านี้ได้หรือไม่ เพื่อให้แน่ใจว่ามี 3P ที่โหลดอย่างเหมาะสมด้วยเฟรมเวิร์กและไม่บล็อกเทรดหลัก เราใช้คอมโพเนนต์สคริปต์ Next.js ที่สร้างขึ้นเป็นจุดเริ่มต้นสำหรับการตรวจสอบนี้

นักพัฒนาแอปติดตามความคืบหน้าของเราได้ในเว็บไซต์นี้

ข่าวสาร

ก่อนจากกันไป ผมอยากจะฝากข้อมูลอัปเดตที่น่าสนใจไว้สัก 2-3 ข้อจากโลกแห่งกรอบงานที่เกิดขึ้นภายใน Google

เมื่อเดือนกรกฎาคม ทีม Chrome ได้ประกาศเงินสนับสนุนรอบล่าสุดจำนวน $500,000 สำหรับกองทุน Frameworks and Tools ซึ่งมุ่งเน้นโครงการเงินทุนที่มุ่งช่วยปรับปรุงประสิทธิภาพ ประสบการณ์ของผู้ใช้ และประสบการณ์ของนักพัฒนาซอฟต์แวร์บนเว็บ เงินสนับสนุนในอนาคตจะพิจารณาโครงการใหม่ๆ ดังนั้น อย่าลืมส่งคำขอของคุณ

แถมยังมีเรื่องที่น่าตื่นตาตื่นใจเกิดขึ้นในชุมชนด้วย ระบบนิเวศนี้เต็มไปด้วยเฟรมเวิร์กใหม่ เช่น Fresh จาก Deno และประสบการณ์การใช้งานที่ยอดเยี่ยม เช่น บทแนะนำการเริ่มต้นใช้งานของ Svelte ที่ไม่เพียงเป็นการสาธิตในเบราว์เซอร์เท่านั้น แต่ยังใช้ Web Container API เพื่อเรียกใช้ Node.js ตามปกติในเบราว์เซอร์ด้วย มีสิ่งดีๆ มากมาย!

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

จนกว่าจะถึงคนวงในคนถัดไป Hwyl fawr

คุณคิดอย่างไรกับ The Chrome Dev Insider ฉบับนี้ แชร์ความคิดเห็น