การยกระดับระบบนิเวศของเว็บเฟรมเวิร์ก

Chrome ทำงานร่วมกับเฟรมเวิร์กแบบโอเพนซอร์สเพื่อมุ่งสู่เว็บที่ดีขึ้น

Chrome เป็นผู้มีส่วนร่วมอย่างแข็งขันในระบบนิเวศของเฟรมเวิร์กเว็บ และการพูดคุยของเราที่ Chrome Dev Summit 2019 ครอบคลุมสิ่งที่เราได้ทำไปในปีที่ผ่านมา

อ่านข้อมูลสรุปเพิ่มเติมของการพูดคุยพร้อมรายละเอียดและแหล่งข้อมูลเพิ่มเติม

เราจะทำให้เว็บดีขึ้นได้อย่างไร

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

นักพัฒนาเว็บส่วนใหญ่ ใช้เครื่องมือแบบโอเพนซอร์สทุกครั้งที่ทำได้ และไม่ต้องการสร้าง โครงสร้างพื้นฐานที่กำหนดเองทั้งหมด เฟรมเวิร์ก JavaScript ฝั่งไคลเอ็นต์และไลบรารี UI คิดเป็นสัดส่วนที่เพิ่มขึ้นของการใช้งานแบบโอเพนซอร์ส ข้อมูลเกี่ยวกับเฟรมเวิร์กและไลบรารีฝั่งไคลเอ็นต์ 3 รายการที่ได้รับความนิยมมากที่สุด ได้แก่ React, Angular และ Vue แสดงให้เห็น ดังนี้

  • 72% ของผู้เข้าร่วมการสำรวจนักพัฒนาเว็บและนักออกแบบประจำปีครั้งแรกของ MDN ใช้เฟรมเวิร์กและไลบรารีเหล่านี้อย่างน้อย 1 รายการ
  • เว็บไซต์กว่า 320,000 เว็บไซต์ใน URL 5 ล้านอันดับแรกที่วิเคราะห์โดย HTTP Archive ใช้เฟรมเวิร์กและไลบรารีเหล่านี้อย่างน้อย 1 รายการ
  • เมื่อจัดกลุ่มตามเวลาที่ใช้ URL 30 รายการจาก 100 URL อันดับแรกใช้เฟรมเวิร์กและไลบรารีเหล่านี้อย่างน้อย 1 รายการ (การวิจัยดำเนินการกับข้อมูลภายใน)

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

การมีส่วนร่วมในเฟรมเวิร์กเว็บ

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

  • เฟรมเวิร์ก (หรือไลบรารี) UI เช่น Preact, React หรือ Vue ซึ่งให้การควบคุม เลเยอร์มุมมองของแอปพลิเคชัน (ผ่านโมเดลคอมโพเนนต์ เป็นต้น)
  • เฟรมเวิร์กเว็บ เช่น Next.js, Nuxt.js และ Gatsby ซึ่งมีระบบแบบครบวงจร พร้อมฟีเจอร์เริ่มต้นในตัว เช่น การแสดงผลฝั่งเซิร์ฟเวอร์ เฟรมเวิร์กเหล่านี้มักใช้ประโยชน์จากเฟรมเวิร์กหรือไลบรารี UI สำหรับเลเยอร์มุมมอง

เฟรมเวิร์กและไลบรารี UI ที่หลากหลายเทียบกับเฟรมเวิร์กเว็บ

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

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

Angular

ทีม Angular ได้เปิดตัวการปรับปรุงหลายอย่างในเฟรมเวิร์กเวอร์ชัน 8 ดังนี้

กราฟแสดงการลดขนาดแพ็กเกจของ angular.io ที่มีและไม่มีบิลด์ที่แตกต่าง
การลดขนาดแพ็กเกจสำหรับ angular.io ด้วยการสร้างแบบแยกส่วน (จาก Angular เวอร์ชัน 8)
  • การรองรับไวยากรณ์การนำเข้าแบบไดนามิกมาตรฐานสำหรับการโหลดเส้นทางแบบ Lazy
  • การรองรับ Web Worker เพื่อเรียกใช้การดำเนินการในเทรดเบื้องหลังที่แยกจากเทรดหลัก
  • Ivy ซึ่งเป็นเครื่องมือแสดงผลใหม่ของ Angular ที่ให้ประสิทธิภาพการคอมไพล์ใหม่ที่ดีขึ้นและลดขนาดแพ็กเกจ พร้อมให้ใช้งานใน โหมดพรีวิว สำหรับโปรเจ็กต์ที่มีอยู่

ดูข้อมูลเพิ่มเติมเกี่ยวกับการปรับปรุงเหล่านี้ได้ใน "Angular เวอร์ชัน 8" และทีม Chrome หวังว่าจะได้ทำงานร่วมกับทีม Angular อย่างใกล้ชิดในปีหน้าเมื่อมีการเปิดตัวฟีเจอร์เพิ่มเติม

Next.js

Next.js เป็นเฟรมเวิร์กเว็บที่ใช้ React เป็นเลเยอร์มุมมอง นอกเหนือจากโมเดลคอมโพเนนต์ UI ที่นักพัฒนาซอฟต์แวร์หลายคนคาดหวังจากเฟรมเวิร์กฝั่งไคลเอ็นต์แล้ว Next.js ยังมีฟีเจอร์เริ่มต้นในตัวหลายอย่าง ดังนี้

  • การกำหนดเส้นทางด้วยการแยกโค้ดเริ่มต้น
  • การคอมไพล์และการรวม (ใช้ Babel และ Webpack)
  • การแสดงผลฝั่งเซิร์ฟเวอร์
  • กลไกในการดึงข้อมูลในระดับต่อหน้า
  • การจัดรูปแบบที่ห่อหุ้ม (ด้วย styled-jsx)

Next.js ได้รับการปรับให้เหมาะสมเพื่อลดขนาดแพ็กเกจ และทีม Chrome ได้ช่วยระบุส่วนที่เราสามารถช่วยปรับปรุงประสิทธิภาพเพิ่มเติมได้ คุณดูข้อมูลเพิ่มเติมเกี่ยวกับแต่ละส่วนได้โดยดูคำขอความคิดเห็น (RFC) และคำขอผสาน (PR) ดังนี้

  1. กลยุทธ์การแบ่งส่วน Webpack ที่ปรับปรุงแล้วซึ่งจะสร้างแพ็กเกจที่ละเอียดขึ้น ลดปริมาณโค้ดที่ซ้ำกันซึ่งดึงข้อมูลผ่านหลายเส้นทาง (RFC, PR)
  2. การโหลดแบบแยกส่วนด้วยรูปแบบ โมดูล/โนโมดูล ซึ่งสามารถลดปริมาณ JavaScript ทั้งหมดในแอป Next.js ได้สูงสุด 20% โดยไม่ต้องเปลี่ยนแปลงโค้ด (RFC, PR)
  3. การติดตามเมตริกประสิทธิภาพที่ปรับปรุงแล้วซึ่งใช้ User Timing API (PR)
หน้าแรกของ Barnebys.com
Barnebys.com ซึ่งเป็นเครื่องมือค้นหาขนาดใหญ่สำหรับของเก่าและของสะสม มี JavaScript ทั้งหมดลดลง 23% หลังจากเปิดใช้การแบ่งส่วนแบบละเอียด

นอกจากนี้ เรายังสำรวจฟีเจอร์อื่นๆ เพื่อปรับปรุงประสบการณ์ของผู้ใช้และนักพัฒนาซอฟต์แวร์ในการใช้ Next.js เช่น

  • การเปิดใช้โหมดพร้อมกันเพื่อปลดล็อกการเติมน้ำให้คอมโพเนนต์แบบค่อยๆ หรือบางส่วน
  • ระบบการปฏิบัติตามข้อกำหนดที่อิงตาม Webpack ซึ่งจะวิเคราะห์ไฟล์ต้นฉบับและชิ้นงานที่สร้างขึ้นทั้งหมดเพื่อ แสดงข้อผิดพลาดและคำเตือนที่ดีขึ้น (RFC)
ตัวอย่างข้อผิดพลาดในการสร้างตามข้อกำหนดใน Next.js
ตัวอย่างข้อผิดพลาดในการสร้างการปฏิบัติตามข้อกำหนดใน Next.js (ต้นแบบ)

Nuxt.js

Nuxt.js เป็นเฟรมเวิร์กเว็บที่รวม Vue.js กับไลบรารีต่างๆ เพื่อ ให้การตั้งค่าเป็นไปตามความคิดเห็นที่ชัดเจน ซึ่งคล้ายกับ Next.js ที่มีฟีเจอร์มากมายพร้อมใช้งานทันที ดังนี้

  • การกำหนดเส้นทางด้วยการแยกโค้ดเริ่มต้น
  • การคอมไพล์และการรวม (ใช้ Babel และ Webpack)
  • การแสดงผลฝั่งเซิร์ฟเวอร์
  • การดึงข้อมูลแบบไม่พร้อมกันสำหรับทุกหน้า
  • ที่เก็บข้อมูลเริ่มต้น (Vuex)

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

Babel

นอกจากนี้ เรายังมีความคืบหน้าในการปรับปรุงประสิทธิภาพของเครื่องมือพื้นฐานที่สำคัญในเฟรมเวิร์กเกือบทั้งหมด ที่กล่าวถึง นั่นคือBabel

Babel จะคอมไพล์โค้ดที่มีไวยากรณ์ใหม่กว่าเป็นโค้ดที่เบราว์เซอร์ต่างๆ เข้าใจได้ การใช้ @babel/preset-env เพื่อกำหนดเป้าหมาย เบราว์เซอร์สมัยใหม่กลายเป็นเรื่องปกติ โดยคุณสามารถระบุเป้าหมายเบราว์เซอร์ต่างๆ เพื่อให้มี Polyfill เพียงพอสำหรับสภาพแวดล้อมที่เลือกทั้งหมด วิธีหนึ่งในการระบุเป้าหมายคือการใช้ <script type="module"> เพื่อกำหนดเป้าหมายเบราว์เซอร์ทั้งหมดที่ รองรับโมดูล ES

เราได้เปิดตัวค่าที่ตั้งไว้ล่วงหน้าใหม่ล่าสุด นั่นคือ @babel/preset-modules เพื่อเพิ่มประสิทธิภาพในกรณีนี้ preset-modules จะแก้ไขข้อบกพร่องแต่ละรายการโดยเฉพาะด้วยการแปลงเป็นไวยากรณ์สมัยใหม่ที่ไม่เสียหายที่ใกล้เคียงที่สุดแทนการแปลงไวยากรณ์สมัยใหม่เป็นไวยากรณ์เก่าเพื่อหลีกเลี่ยงข้อบกพร่องของเบราว์เซอร์ ซึ่งจะส่งผลให้โค้ดสมัยใหม่สามารถส่งไปยังเบราว์เซอร์ส่วนใหญ่ได้ โดยไม่ต้องแก้ไขเกือบทั้งหมด

Babel Preset ใหม่เพื่อมอบการ Polyfill ที่ดีขึ้นสำหรับเบราว์เซอร์

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

ขั้นตอนต่อไปคืออะไร

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

หากคุณทำงานกับเฟรมเวิร์กเว็บ ไลบรารี UI หรือเครื่องมือเว็บรูปแบบใดก็ตาม (ตัวรวม, คอมไพเลอร์, Linter) ให้สมัครกองทุนเฟรมเวิร์ก!