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 หรือไลบรารีสำหรับเลเยอร์การแสดงผล
นักพัฒนาซอฟต์แวร์สามารถเลือกไม่ใช้เฟรมเวิร์ก แต่นำไลบรารีเลเยอร์การแสดงผล เราเตอร์ และ ระบบการจัดรูปแบบ ตัวแสดงผลเซิร์ฟเวอร์ และอื่นๆ พวกเขามักจะสร้างประเภท แม้ว่าจะเป็นความคิดเห็น แต่เฟรมเวิร์กเว็บยังดูแลข้อกังวลต่างๆ เหล่านี้โดยค่าเริ่มต้น
ส่วนที่เหลือของโพสต์นี้เน้นที่การปรับปรุงมากมายที่เกิดขึ้นในเฟรมเวิร์กต่างๆ เมื่อเร็วๆ นี้ และเครื่องมือที่หลากหลาย ซึ่งรวมถึงการสนับสนุนจากทีม Chrome
Angular
ทีม Angular ได้ดำเนินการปรับปรุงเฟรมเวิร์กเวอร์ชัน 8 ดังต่อไปนี้
- การโหลดส่วนต่างตาม ตั้งค่าเริ่มต้นให้ลดจำนวน polyfill ที่ไม่จำเป็นสำหรับเบราว์เซอร์รุ่นใหม่
![กราฟแสดงการลดขนาดกลุ่มของ angular.io ที่มีและไม่มีการสร้าง Differential](https://web.dev/static/articles/advancing-framework-ecosystem-cds-2019/image/graph-showing-bundle-size-2c352e9114973.png?authuser=6&hl=th)
- การรองรับไวยากรณ์การนำเข้าแบบไดนามิกมาตรฐานสำหรับเส้นทางการโหลดแบบ Lazy Loading
- การรองรับผู้ปฏิบัติงานบนเว็บเพื่อเรียกใช้การดำเนินการในเทรดเบื้องหลังโดยแยกจากเทรดหลัก
- Ivy ฟีเจอร์ใหม่จาก Angular เครื่องมือแสดงภาพซึ่งช่วยให้ การคอมไพล์ซ้ำมีประสิทธิภาพดีกว่าเดิมและลดกลุ่ม ขนาดต่างๆ ใช้ได้ในโหมดแสดงตัวอย่างสำหรับ ที่มีอยู่
คุณดูข้อมูลเพิ่มเติมเกี่ยวกับการปรับปรุงเหล่านี้ได้ใน "Angular เวอร์ชัน 8" และทีม Chrome ตั้งตารอที่จะร่วมงานอย่างใกล้ชิดในปีหน้าเนื่องจากจะมีฟีเจอร์เพิ่มเติม land
Next.js
Next.js เป็นเว็บเฟรมเวิร์กที่ใช้ React เป็นเลเยอร์มุมมอง นอกจาก รูปแบบคอมโพเนนต์ UI ที่นักพัฒนาซอฟต์แวร์จำนวนมากคาดหวังว่าจะได้รับจากเฟรมเวิร์กฝั่งไคลเอ็นต์ Next.js จะมอบ จำนวนของคุณลักษณะเริ่มต้นในตัว:
- การกำหนดเส้นทางด้วยการแบ่งรหัสเริ่มต้น
- การคอมไพล์และการรวมกลุ่ม (โดยใช้ Babel และ เว็บแพ็ก)
- การแสดงผลฝั่งเซิร์ฟเวอร์
- กลไกในการดึงข้อมูลที่ระดับต่อหน้า
- การจัดรูปแบบห่อหุ้ม (ที่มี styled-jsx)
Next.js จะเพิ่มประสิทธิภาพแพ็กเกจที่ลดขนาดลง และทีม Chrome ได้ช่วยระบุส่วนที่เราทำได้ เพื่อช่วยปรับปรุงประสิทธิภาพให้ดียิ่งขึ้น คุณดูข้อมูลเพิ่มเติมเกี่ยวกับแต่ละรูปแบบได้โดยดูคำขอของบุคคลเหล่านั้น สำหรับความคิดเห็น (RFCs) และดึงคำขอ (PRs)
- กลยุทธ์การรวมกลุ่มเว็บแพ็กที่ได้รับการปรับปรุงซึ่งจะแสดงแพ็กเกจที่ละเอียดยิ่งขึ้น ซึ่งช่วยลด จำนวนโค้ดที่ซ้ำกันที่ดึงข้อมูลผ่านหลายเส้นทาง (RFC PR)
- การโหลดส่วนต่างด้วยฟังก์ชัน รูปแบบของโมดูล/ไม่มีโมดูล ซึ่งจะช่วยลดจำนวนรวมของ JavaScript ในแอป Next.js ลงได้ถึง 20% โดยไม่ต้องเขียนโค้ด การเปลี่ยนแปลง (RFC, PR)
- การติดตามเมตริกประสิทธิภาพที่ปรับปรุงแล้วโดยใช้ User Timing API (PR)
![หน้าแรกของ Barnebys.com](https://web.dev/static/articles/advancing-framework-ecosystem-cds-2019/image/homepage-barnebyscom-234db657bb205.png?authuser=6&hl=th)
นอกจากนี้เรายังสำรวจฟีเจอร์อื่นๆ เพื่อปรับปรุงประสบการณ์การใช้งานทั้งของผู้ใช้และนักพัฒนาซอฟต์แวร์ Next.js เช่น
- การเปิดใช้โหมดพร้อมกันเพื่อปลดล็อกองค์ประกอบแบบโพรเกรสซีฟหรือปริมาณน้ำบางส่วน
- ระบบการปฏิบัติตามข้อกำหนดแบบ Webpack ซึ่งจะวิเคราะห์ไฟล์ต้นฉบับและเนื้อหาที่สร้างขึ้นทั้งหมดเพื่อวัตถุประสงค์ต่อไปนี้ แสดงข้อผิดพลาดและคำเตือนที่ดีขึ้น (RFC)
![ตัวอย่างข้อผิดพลาดในการสร้างความสอดคล้องใน Next.js](https://web.dev/static/articles/advancing-framework-ecosystem-cds-2019/image/example-a-conformance-bu-4ae834ef6b96b.png?authuser=6&hl=th)
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
ได้แก้ไขข้อบกพร่องที่เจาะจงแต่ละรายการโดยเปลี่ยนเป็น
ไวยากรณ์สมัยใหม่ที่ไม่เสียหายและใกล้เคียงที่สุด ซึ่งทำให้โค้ดสมัยใหม่ที่ส่งได้เกือบ
ไม่มีการแก้ไขกับเบราว์เซอร์ส่วนใหญ่
นักพัฒนาแอปที่ใช้ preset-env
อยู่แล้วจะได้รับประโยชน์จากการเพิ่มประสิทธิภาพเหล่านี้ด้วยโดยไม่ต้อง
ดำเนินการทุกอย่าง เนื่องจากในเร็วๆ นี้จะรวมอยู่ใน preset-env
ด้วย
ขั้นตอนถัดไปคือ
การทำงานอย่างใกล้ชิดกับเฟรมเวิร์กและไลบรารีโอเพนซอร์สเพื่อมอบประสบการณ์การใช้งานที่ดียิ่งขึ้นช่วยให้ ทีม Chrome ตระหนักถึงสิ่งที่สำคัญโดยพื้นฐานต่อผู้ใช้และนักพัฒนาซอฟต์แวร์
หากคุณทำงานบนเฟรมเวิร์กเว็บ ไลบรารี UI หรือเครื่องมือเว็บรูปแบบใดๆ (bundler, compiler, linter) สมัครรับเงินสนับสนุนเฟรมเวิร์กได้เลย