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

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

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

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

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

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

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

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

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

การมีส่วนร่วมใน Web Framework

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

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

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

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

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

Angular

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

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

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

Next.js

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

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

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

  1. กลยุทธ์การรวมกลุ่มเว็บแพ็กที่ได้รับการปรับปรุงซึ่งจะแสดงแพ็กเกจที่ละเอียดยิ่งขึ้น ซึ่งช่วยลด จำนวนโค้ดที่ซ้ำกันที่ดึงข้อมูลผ่านหลายเส้นทาง (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 และ เว็บแพ็ก)
  • การแสดงผลฝั่งเซิร์ฟเวอร์
  • การดึงข้อมูลแบบอะซิงโครนัสสำหรับทุกหน้า
  • พื้นที่เก็บข้อมูลเริ่มต้น (Vuex)

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

Babel

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

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

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

ค่าที่กำหนดล่วงหน้าใหม่ของ Babel เพื่อการเพิ่มโพลีฟิลล์ที่ดียิ่งขึ้นสำหรับเบราว์เซอร์

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

ขั้นตอนถัดไปคือ

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

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