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 หรือเมตาเฟรมเวิร์ก* เช่น Next.js และ Nuxt (และอื่นๆ อีกมากมาย Svelte, Lit, Preact, Astro รายการนี้ยังยาวกว่านี้อีก) แทนที่จะคาดหวังให้นักพัฒนาซอฟต์แวร์เหล่านี้เป็นผู้เชี่ยวชาญด้านประสิทธิภาพ (เช่น ในด้านประสิทธิภาพ) เราช่วยให้นักพัฒนาซอฟต์แวร์เหล่านี้ประสบความสำเร็จได้ด้วยการฝังแนวทางปฏิบัติแนะนำเพิ่มเติมไว้ในแพ็กเกจเหล่านี้โดยค่าเริ่มต้น วิธีนี้จะทำให้เว็บไซต์มีคุณภาพดีขึ้นโดยเป็นผลพลอยได้จากการสร้างเว็บไซต์

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

แทนที่นักพัฒนาซอฟต์แวร์จะต้องหาวิธีแก้ปัญหาด้วยตนเอง

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

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

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

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

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

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

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

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

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

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

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

แล้วกระบวนการนี้จะมีลักษณะอย่างไรในทางปฏิบัติ คุณแก้ปัญหานี้อย่างไร

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

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

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

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

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

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

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

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

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

ด้วยเหตุนี้ เราจึงได้ดำเนินการต่อไปนี้

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

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

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

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

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

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

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

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

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

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

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

ข่าวสาร

ก่อนจะจากกัน เราขอแชร์ข้อมูลอัปเดตที่น่าสนใจ 2-3 รายการจากโลกเฟรมเวิร์กที่เกิดขึ้นภายใน Google

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

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

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

แล้วพบกันใหม่ใน Insider ครั้งถัดไป

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