ไม่มีวิธีใดที่จะทำให้เว็บไซต์ช้าลง (ตั้งใจเล่นสำนวน) ได้เร็วไปกว่าการใช้โค้ด JavaScript จำนวนมากบนเว็บไซต์ เมื่อใช้ JavaScript คุณต้องจ่ายสำหรับประสิทธิภาพของโครงการไม่น้อยกว่าสี่เท่า นี่คือวิธีที่โค้ด JavaScript ของไซต์โหลดระบบของผู้ใช้:
- การดาวน์โหลดไฟล์ผ่านเครือข่าย
- แยกวิเคราะห์และคอมไพล์ซอร์สโค้ดที่คลายแพ็กหลังจากดาวน์โหลด
- การดำเนินการของรหัส JavaScript
- การใช้หน่วยความจำ
การรวมกันนี้จะปรากฎ .
และเราได้รวมโค้ด JS ในโครงการของเรามากขึ้นเรื่อยๆ เมื่อองค์กรต่าง ๆ เปลี่ยนไปใช้ไซต์ที่ขับเคลื่อนโดยเฟรมเวิร์กและไลบรารี เช่น React, Vue และอื่น ๆ เรากำลังทำให้การทำงานหลักของไซต์ขึ้นอยู่กับจาวาสคริปต์เป็นอย่างมาก
ฉันเคยเห็นเว็บไซต์จำนวนมากที่ใช้เฟรมเวิร์ก JavaScript แต่วิสัยทัศน์ของฉันเกี่ยวกับปัญหานี้มีอคติมาก ความจริงก็คือ บริษัท ที่ฉันทำงานด้วยหันมาหาฉันเพราะพวกเขาประสบปัญหาที่ซับซ้อนในด้านประสิทธิภาพของไซต์ เป็นผลให้ฉันเริ่มสงสัยว่าปัญหานี้เกิดขึ้นบ่อยเพียงใด และเราต้องจ่าย "บทลงโทษ" ประเภทใดเมื่อเราเลือกกรอบงานหนึ่งหรือกรอบอื่นเป็นพื้นฐานสำหรับไซต์ใดไซต์หนึ่ง
โครงการช่วยให้ฉันคิดออก .
ข้อมูล
โครงการ HTTP Archive ติดตามลิงก์ทั้งหมด 4308655 ลิงก์ไปยังไซต์เดสก์ท็อปปกติ และ 5484239 ลิงก์ไปยังไซต์มือถือ ในบรรดาเมตริกต่างๆ ที่เกี่ยวข้องกับลิงก์เหล่านี้คือรายการของเทคโนโลยีที่พบในไซต์นั้นๆ ซึ่งหมายความว่าเราสามารถสุ่มตัวอย่างไซต์นับพันที่ใช้เฟรมเวิร์กและไลบรารีต่างๆ และเรียนรู้เกี่ยวกับจำนวนโค้ดที่ส่งไปยังไคลเอนต์ และจำนวนโหลดโค้ดที่สร้างบนระบบของผู้ใช้
ฉันรวบรวมข้อมูลเดือนมีนาคม 2020 ซึ่งเป็นข้อมูลล่าสุดที่ฉันเข้าถึงได้
ฉันตัดสินใจเปรียบเทียบข้อมูลรวม HTTP Archive ในทุกไซต์กับข้อมูลจากไซต์ที่พบโดยใช้ React, Vue และ Angular แม้ว่าฉันจะพิจารณาใช้แหล่งข้อมูลอื่นเช่นกัน
เพื่อให้น่าสนใจยิ่งขึ้น ฉันยังได้เพิ่มไซต์ที่ใช้ jQuery ในชุดข้อมูลต้นทาง ห้องสมุดแห่งนี้ยังคงได้รับความนิยมอย่างมาก นอกจากนี้ยังแนะนำแนวทางการพัฒนาเว็บที่แตกต่างจากรูปแบบ Single Page Application (SPA) ที่นำเสนอโดย React, Vue และ Angular
ลิงก์ใน HTTP Archive ซึ่งแสดงถึงไซต์ที่พบว่าใช้เทคโนโลยีที่น่าสนใจ
กรอบงานหรือไลบรารี
ลิงก์ไปยังไซต์บนมือถือ
ลิงก์ไปยังไซต์ปกติ
jQuery
4615474
3714643
เกิดปฏิกิริยา
489827
241023
ดู
85649
43691
เชิงมุม
19423
18088
หวังและฝัน
ก่อนที่เราจะไปวิเคราะห์ข้อมูล ฉันอยากจะพูดถึงสิ่งที่ฉันหวังไว้
ฉันเชื่อว่าในโลกอุดมคติ กรอบงานควรเป็นมากกว่าการตอบสนองความต้องการของนักพัฒนาและให้ประโยชน์เฉพาะแก่ผู้ใช้ทั่วไปที่ทำงานกับไซต์ของเรา ประสิทธิภาพเป็นเพียงหนึ่งในผลประโยชน์เหล่านั้น นี่คือจุดที่การเข้าถึงและความปลอดภัยเข้ามามีบทบาท แต่นี่เป็นเพียงสิ่งที่สำคัญที่สุดเท่านั้น
ดังนั้น ในโลกอุดมคติ กรอบงานบางประเภทควรทำให้การสร้างไซต์ประสิทธิภาพสูงเป็นเรื่องง่าย สิ่งนี้ควรทำเนื่องจากเฟรมเวิร์กให้ฐานที่ดีแก่นักพัฒนาในการสร้างโครงการหรือเนื่องจากความจริงที่ว่ามันกำหนดข้อ จำกัด ในการพัฒนาทำให้ข้อกำหนดล่วงหน้าสำหรับการพัฒนาที่ซับซ้อน ออกจะเชื่องช้า
เฟรมเวิร์กที่ดีที่สุดควรทำทั้งสองอย่าง: ให้ฐานที่ดีและกำหนดข้อจำกัดในการทำงาน ช่วยให้คุณได้ผลลัพธ์ที่เหมาะสม
การวิเคราะห์ค่ามัธยฐานของข้อมูลจะไม่ได้ข้อมูลที่เราต้องการ และในความเป็นจริง วิธีการนี้ทำให้เราไม่สนใจ . แต่ฉันได้รับเปอร์เซ็นต์จากข้อมูลที่ฉันมี เหล่านี้คือ 10, 25, 50 (ค่ามัธยฐาน), 75, 90 เปอร์เซ็นต์ไทล์
ฉันสนใจเปอร์เซ็นไทล์ที่ 10 และ 90 เป็นพิเศษ เปอร์เซ็นไทล์ที่ 10 แสดงถึงประสิทธิภาพที่ดีที่สุด (หรืออย่างน้อยก็ใกล้เคียงที่สุดหรือใกล้เคียงที่สุด) สำหรับเฟรมเวิร์กหนึ่งๆ กล่าวอีกนัยหนึ่ง หมายความว่ามีเพียง 10% ของไซต์ที่ใช้เฟรมเวิร์กเฉพาะเท่านั้นที่จะไปถึงระดับนี้หรือสูงกว่านั้น ในทางกลับกัน เปอร์เซ็นไทล์ที่ 90 เป็นอีกด้านของเหรียญ - มันแสดงให้เราเห็นว่าสิ่งเลวร้ายจะเกิดขึ้นได้อย่างไร เปอร์เซ็นไทล์ที่ 90 คือไซต์ที่อยู่ตามหลัง ซึ่งเป็นไซต์ 10% ล่างสุดที่มีโค้ด JS มากที่สุดหรือใช้เวลานานที่สุดในการประมวลผลโค้ดในเธรดหลัก
ปริมาณของรหัส JavaScript
ในการเริ่มต้น คุณควรวิเคราะห์ขนาดของโค้ด JavaScript ที่ส่งโดยไซต์ต่างๆ ผ่านเครือข่าย
จำนวนรหัส JavaScript (Kb) ที่ถ่ายโอนไปยังอุปกรณ์พกพา
เปอร์เซ็นต์ไทล์
10
25
50
75
90
เว็บไซต์ทั้งหมด
93.4
196.6
413.5
746.8
1201.6
เว็บไซต์ jQuery
110.3
219.8
430.4
748.6
1162.3
เว็บไซต์ Vue
244.7
409.3
692.1
1065.5
1570.7
เว็บไซต์เชิงมุม
445.1
675.6
1066.4
1761.5
2893.2
ตอบสนองไซต์
345.8
441.6
690.3
1238.5
1893.6
จำนวนรหัส JavaScript ที่ส่งไปยังอุปกรณ์มือถือ
จำนวนรหัส JavaScript (Kb) ที่ถ่ายโอนไปยังอุปกรณ์เดสก์ท็อป
เปอร์เซ็นต์ไทล์
10
25
50
75
90
เว็บไซต์ทั้งหมด
105.5
226.6
450.4
808.8
1267.3
เว็บไซต์ jQuery
121.7
242.2
458.3
803.4
1235.3
เว็บไซต์ Vue
248.0
420.1
718.0
1122.5
1643.1
เว็บไซต์เชิงมุม
468.8
716.9
1144.2
1930.0
3283.1
ตอบสนองไซต์
308.6
469.0
841.9
1472.2
2197.8
จำนวนรหัส JavaScript ที่ส่งไปยังอุปกรณ์เดสก์ท็อป
หากเราพูดถึงเฉพาะขนาดของรหัส JS ที่ไซต์ส่งไปยังอุปกรณ์ ทุกอย่างก็จะเป็นไปตามที่คุณคาดไว้ กล่าวคือ หากใช้เฟรมเวิร์กตัวใดตัวหนึ่ง หมายความว่าแม้ในสถานการณ์ที่เหมาะสม ปริมาณของโค้ด JavaScript ของไซต์ก็จะเพิ่มขึ้น สิ่งนี้ไม่น่าแปลกใจ - คุณไม่สามารถสร้างเฟรมเวิร์ก JavaScript เป็นพื้นฐานของไซต์และคาดว่าปริมาณโค้ด JS ของโครงการจะต่ำมาก
สิ่งที่น่าทึ่งเกี่ยวกับข้อมูลนี้คือเฟรมเวิร์กและไลบรารีบางตัวถือเป็นจุดเริ่มต้นที่ดีกว่าสำหรับโปรเจ็กต์อื่น เว็บไซต์ที่มี jQuery ดูดีที่สุด ไซต์เวอร์ชันเดสก์ท็อปมี JavaScript มากกว่าไซต์ทั้งหมด 15% และบนมือถือมีมากกว่า 18% (เป็นที่ยอมรับว่ามีข้อมูลเสียหายที่นี่ ความจริงก็คือมี jQuery อยู่ในไซต์จำนวนมาก ดังนั้นจึงเป็นเรื่องธรรมดาที่ไซต์ดังกล่าวจะมีความเกี่ยวข้องอย่างใกล้ชิดมากกว่าไซต์อื่นๆ ที่มีจำนวนไซต์ทั้งหมด อย่างไรก็ตาม สิ่งนี้ไม่ส่งผลกระทบต่อข้อมูลดิบ ข้อมูลจะถูกส่งออกสำหรับแต่ละเฟรมเวิร์ก)
ในขณะที่ปริมาณโค้ดที่เพิ่มขึ้น 15-18% เป็นตัวเลขที่น่าสังเกต เมื่อเปรียบเทียบกับเฟรมเวิร์กและไลบรารีอื่น เราสามารถสรุปได้ว่า "ภาษี" ที่เรียกเก็บโดย jQuery นั้นต่ำมาก ไซต์เชิงมุมในเปอร์เซ็นไทล์ที่ 10 ส่งข้อมูลไปยังเดสก์ท็อปมากกว่าไซต์ทั้งหมด 344% และมากกว่า 377% ไปยังมือถือ ไซต์ React นั้นหนักรองลงมา โดยส่งโค้ดไปยังเดสก์ท็อปมากกว่าไซต์ทั้งหมด 193% และมากกว่า 270% ไปยังมือถือ
ก่อนหน้านี้ ฉันได้กล่าวว่า แม้ว่าการใช้เฟรมเวิร์กจะหมายถึงโค้ดจำนวนหนึ่งจะรวมอยู่ในโปรเจ็กต์ แต่ในช่วงเริ่มต้นของการทำงาน ฉันหวังว่าเฟรมเวิร์กจะสามารถจำกัดนักพัฒนาได้ในทางใดทางหนึ่ง โดยเฉพาะอย่างยิ่ง เรากำลังพูดถึงการจำกัดจำนวนรหัสสูงสุด
น่าสนใจ เว็บไซต์ jQuery ปฏิบัติตามแนวคิดนี้ แม้ว่าจะหนักกว่าทุกไซต์เล็กน้อยที่เปอร์เซ็นไทล์ที่ 10 (ประมาณ 15-18%) แต่เบากว่าเล็กน้อยที่เปอร์เซ็นไทล์ที่ 90 ที่ประมาณ 3% ทั้งบนเดสก์ท็อปและมือถือ นี่ไม่ได้หมายความว่านี่เป็นประโยชน์อย่างมาก แต่อาจกล่าวได้ว่าอย่างน้อยไซต์ jQuery ก็ไม่มีโค้ด JavaScript ขนาดใหญ่ แม้แต่ในเวอร์ชันที่ใหญ่ที่สุด
แต่ไม่สามารถพูดได้เช่นเดียวกันกับกรอบอื่น ๆ
เช่นเดียวกับในกรณีของเปอร์เซ็นไทล์ที่ 10 ที่ไซต์เปอร์เซ็นไทล์ที่ 90 บน Angular และ React แตกต่างจากไซต์อื่น แต่น่าเสียดายที่แย่กว่านั้น
ที่เปอร์เซ็นไทล์ที่ 90 ไซต์เชิงมุมส่งข้อมูลไปยังมือถือมากกว่าไซต์ทั้งหมด 141% และมากกว่า 159% ไปยังเดสก์ท็อป ไซต์ React ส่งไปยังเดสก์ท็อปมากกว่าไซต์ทั้งหมด 73% และมากกว่า 58% ไปยังมือถือ ขนาดโค้ดของไซต์ React ที่เปอร์เซ็นไทล์ที่ 90 คือ 2197.8 KB ซึ่งหมายความว่าไซต์ดังกล่าวส่งข้อมูลไปยังอุปกรณ์มือถือมากกว่าคู่แข่งที่ใกล้เคียงที่สุดตาม Vue ถึง 322.9 KB ช่องว่างระหว่างไซต์เดสก์ท็อปที่ใช้ Angular และ React และไซต์อื่น ๆ นั้นยิ่งใหญ่กว่า ตัวอย่างเช่น ไซต์ React บนเดสก์ท็อปส่งโค้ด JS ไปยังอุปกรณ์มากกว่าไซต์ Vue ที่คล้ายกันถึง 554.7 KB
เวลาที่ใช้ในการประมวลผลโค้ด JavaScript ในเธรดหลัก
ข้อมูลข้างต้นบ่งชี้อย่างชัดเจนว่าไซต์ที่ใช้เฟรมเวิร์กและไลบรารีภายใต้การศึกษามีโค้ด JavaScript จำนวนมาก แต่แน่นอน นั่นเป็นเพียงส่วนหนึ่งของสมการของเรา
หลังจากที่โค้ด JavaScript มาถึงเบราว์เซอร์แล้ว จะต้องนำโค้ดนั้นเข้าสู่สถานะที่ใช้งานได้ โดยเฉพาะอย่างยิ่งปัญหาหลายอย่างเกิดจากการกระทำที่ต้องดำเนินการกับรหัสในเธรดเบราว์เซอร์หลัก เธรดหลักมีหน้าที่ในการประมวลผลการกระทำของผู้ใช้ สำหรับการคำนวณสไตล์ สำหรับการสร้างและการแสดงโครงร่างเพจ หากคุณใช้งาน JavaScript มากเกินไปในเธรดหลัก เธรดนั้นจะไม่มีโอกาสทำงานที่เหลือให้เสร็จทันเวลา สิ่งนี้นำไปสู่ความล่าช้าและ "เบรก" ในการทำงานของเพจ
ฐานข้อมูล HTTP Archive มีข้อมูลเกี่ยวกับระยะเวลาที่ใช้ในการประมวลผลโค้ด JavaScript ในเธรดหลักของเอ็นจิ้น V8 ซึ่งหมายความว่าเราสามารถรวบรวมข้อมูลนี้และค้นหาว่าเธรดหลักใช้เวลาเท่าใดในการประมวลผล JavaScript ของไซต์ต่างๆ
เวลาประมวลผล (เป็นมิลลิวินาที) ที่เกี่ยวข้องกับการประมวลผลสคริปต์บนอุปกรณ์เคลื่อนที่
เปอร์เซ็นต์ไทล์
10
25
50
75
90
เว็บไซต์ทั้งหมด
356.4
959.7
2372.1
5367.3
10485.8
เว็บไซต์ jQuery
575.3
1147.4
2555.9
5511.0
10349.4
เว็บไซต์ Vue
1130.0
2087.9
4100.4
7676.1
12849.4
เว็บไซต์เชิงมุม
1471.3
2380.1
4118.6
7450.8
13296.4
ตอบสนองไซต์
2700.1
5090.3
9287.6
14509.6
20813.3
เวลาประมวลผลที่เกี่ยวข้องกับการประมวลผลสคริปต์บนอุปกรณ์พกพา
เวลา CPU (เป็นมิลลิวินาที) ที่เกี่ยวข้องกับการประมวลผลสคริปต์บนอุปกรณ์เดสก์ท็อป
เปอร์เซ็นต์ไทล์
10
25
50
75
90
เว็บไซต์ทั้งหมด
146.0
351.8
831.0
1739.8
3236.8
เว็บไซต์ jQuery
199.6
399.2
877.5
1779.9
3215.5
เว็บไซต์ Vue
350.4
650.8
1280.7
2388.5
4010.8
เว็บไซต์เชิงมุม
482.2
777.9
1365.5
2400.6
4171.8
ตอบสนองไซต์
508.0
1045.6
2121.1
4235.1
7444.3
เวลาประมวลผลที่เกี่ยวข้องกับการประมวลผลสคริปต์บนอุปกรณ์เดสก์ท็อป
ที่นี่คุณสามารถเห็นสิ่งที่คุ้นเคยมาก
สำหรับผู้เริ่มต้น ไซต์ที่มี jQuery ใช้จ่ายในการประมวลผล JavaScript บนเธรดหลักน้อยกว่าไซต์อื่นอย่างมาก ที่เปอร์เซ็นไทล์ที่ 10 เมื่อเทียบกับไซต์ทั้งหมด ไซต์ jQuery บนมือถือใช้เวลามากกว่า 61% ในการประมวลผลโค้ด JS บนเธรดหลัก ในกรณีของไซต์ jQuery บนเดสก์ท็อป เวลาในการประมวลผลเพิ่มขึ้น 37% ที่เปอร์เซ็นไทล์ที่ 90 ไซต์ jQuery ได้คะแนนใกล้เคียงกับคะแนนรวมมาก โดยเฉพาะอย่างยิ่ง ไซต์ jQuery บนอุปกรณ์เคลื่อนที่ใช้เวลากับเธรดหลักน้อยกว่าไซต์ทั้งหมด 1.3% และใช้เวลาน้อยลง 0.7% บนอุปกรณ์เดสก์ท็อป
ในอีกด้านหนึ่งของการให้คะแนนของเราคือเฟรมเวิร์กที่มีลักษณะโหลดสูงสุดในเธรดหลัก นี่คืออีกครั้ง Angular และ React ข้อแตกต่างเพียงอย่างเดียวระหว่างทั้งสองคือในขณะที่ไซต์เชิงมุมส่งโค้ดไปยังเบราว์เซอร์มากกว่าไซต์ React แต่ไซต์เชิงมุมใช้เวลา CPU น้อยกว่าในการประมวลผลโค้ด น้อยกว่ามาก
ที่เปอร์เซ็นไทล์ที่ 10 ไซต์เชิงมุมบนเดสก์ท็อปใช้เวลากับเธรดหลักในการประมวลผลโค้ด JS มากกว่าไซต์ทั้งหมด 230% สำหรับไซต์บนมือถือ ตัวเลขนี้คือ 313% ไซต์ตอบสนองเป็นผลงานที่แย่ที่สุด บนเดสก์ท็อป พวกเขาใช้เวลาในการประมวลผลโค้ดมากกว่าไซต์ทั้งหมดถึง 248% และมากกว่า 658% บนมือถือ 658% ไม่ใช่การพิมพ์ผิด ที่เปอร์เซ็นไทล์ที่ 10 ไซต์ React ใช้เวลา 2.7 วินาทีของเธรดหลักในการประมวลผลโค้ด
เปอร์เซ็นไทล์ที่ 90 เมื่อเทียบกับจำนวนมหาศาลเหล่านี้ อย่างน้อยก็ดูดีกว่าเล็กน้อย เมื่อเทียบกับไซต์ทั้งหมด โครงการเชิงมุมใช้เวลามากกว่า 29% บนอุปกรณ์เดสก์ท็อปในเธรดหลัก และใช้เวลามากกว่า 27% บนอุปกรณ์พกพา ในกรณีของไซต์ React ตัวเลขเดียวกันจะดูเหมือน 130% และ 98% ตามลำดับ
เปอร์เซ็นต์เบี่ยงเบนสำหรับเปอร์เซ็นไทล์ที่ 90 ดูดีกว่าค่าที่คล้ายกันสำหรับเปอร์เซ็นไทล์ที่ 10 แต่ที่นี่คือสิ่งที่ควรค่าแก่การจดจำว่าตัวเลขที่ระบุเวลาดูค่อนข้างน่ากลัว สมมติว่า 20.8 วินาทีบนเธรดมือถือหลักสำหรับเว็บไซต์ที่สร้างด้วย React (ฉันคิดว่าเรื่องราวของสิ่งที่เกิดขึ้นจริงในช่วงเวลานี้สมควรแยกบทความ)
มีหนึ่งภาวะแทรกซ้อนที่อาจเกิดขึ้นที่นี่ (ขอบคุณ เพื่อดึงความสนใจของฉันไปที่คุณลักษณะนี้ และสำหรับการพิจารณาข้อมูลจากมุมมองนี้อย่างรอบคอบ) ความจริงก็คือหลาย ๆ ไซต์ใช้เครื่องมือส่วนหน้าหลายตัว โดยเฉพาะอย่างยิ่ง ฉันเห็นไซต์จำนวนมากใช้ jQuery ร่วมกับ React หรือ Vue เนื่องจากไซต์เหล่านั้นกำลังย้ายจาก jQuery ไปยังเฟรมเวิร์กหรือไลบรารีอื่น ด้วยเหตุนี้ ฉันจึงกดไปที่ฐานข้อมูลอีกครั้ง คราวนี้เลือกเฉพาะลิงก์ที่สอดคล้องกับไซต์ที่ใช้เฉพาะ React, jQuery, Angular หรือ Vue เท่านั้น แต่ไม่ใช้การผสมผสานใดๆ นี่คือสิ่งที่ฉันได้รับ
เวลาประมวลผล (หน่วยเป็นมิลลิวินาที) ที่เกี่ยวข้องกับสคริปต์การประมวลผลบนอุปกรณ์เคลื่อนที่ในสถานการณ์ที่ไซต์ใช้เฟรมเวิร์กเดียวหรือไลบรารีเพียงไลบรารีเดียว
เปอร์เซ็นต์ไทล์
10
25
50
75
90
เว็บไซต์ที่ใช้ jQuery เท่านั้น
542.9
1062.2
2297.4
4769.7
8718.2
ไซต์ที่ใช้เฉพาะ Vue
944.0
1716.3
3194.7
5959.6
9843.8
ไซต์ที่ใช้เฉพาะเชิงมุม
1328.9
2151.9
3695.3
6629.3
11607.7
ไซต์ที่ใช้ React เท่านั้น
2443.2
4620.5
10061.4
17074.3
24956.3
เวลาประมวลผลที่เกี่ยวข้องกับสคริปต์การประมวลผลบนอุปกรณ์เคลื่อนที่ในสถานการณ์ที่ไซต์ใช้เพียงเฟรมเวิร์กเดียว หรือไลบรารีเพียงไลบรารีเดียว
ประการแรก สิ่งที่ไม่น่าแปลกใจ: เมื่อไซต์ใช้เพียงกรอบงานเดียวหรือหนึ่งไลบรารี ประสิทธิภาพของไซต์ดังกล่าวจะปรับปรุงบ่อยกว่าไม่ เครื่องมือแต่ละชิ้นทำงานได้ดีขึ้นที่เปอร์เซ็นไทล์ที่ 10 และ 25 มันสมเหตุสมผล ไซต์ที่สร้างโดยใช้หนึ่งเฟรมเวิร์กควรทำงานได้ดีกว่าไซต์ที่สร้างโดยใช้เฟรมเวิร์กหรือไลบรารีตั้งแต่สองเฟรมขึ้นไป
ในความเป็นจริงแล้ว ประสิทธิภาพของเครื่องมือส่วนหน้าแต่ละชิ้นที่ศึกษาดูดีขึ้นในทุกกรณี ยกเว้นข้อยกเว้นที่น่าสงสัยอย่างหนึ่ง สิ่งที่ทำให้ฉันประหลาดใจก็คือที่เปอร์เซ็นไทล์ที่ 50 ขึ้นไป ไซต์ที่ใช้ React จะทำงานแย่ลงเมื่อ React เป็นไลบรารีเดียวที่พวกเขาใช้ นี่เป็นเหตุผลที่ฉันนำเสนอข้อมูลนี้ที่นี่
นี่เป็นเรื่องแปลกเล็กน้อย แต่ฉันจะยังคงพยายามหาคำอธิบายสำหรับความแปลกประหลาดนี้
หากโปรเจกต์ใช้ทั้ง React และ jQuery โปรเจกต์นั้นน่าจะอยู่ในช่วงครึ่งทางของการเปลี่ยนจาก jQuery เป็น React บางทีมันอาจมีฐานรหัสที่ไลบรารีเหล่านี้ผสมกัน เนื่องจากเราเห็นแล้วว่าไซต์ jQuery ใช้เวลากับเธรดหลักน้อยกว่าไซต์ React นี่อาจบอกเราว่าการใช้ฟังก์ชันบางอย่างใน jQuery ช่วยให้ไซต์ทำงานได้ดีขึ้นเล็กน้อย
แต่เมื่อโครงการเปลี่ยนจาก jQuery เป็น React และอาศัย React มากขึ้น สิ่งต่างๆ ก็เปลี่ยนไป หากไซต์มีคุณภาพสูงจริง ๆ และผู้พัฒนาไซต์ใช้ React อย่างระมัดระวัง ไซต์ดังกล่าวก็จะเรียบร้อยดี แต่สำหรับไซต์ React ทั่วไป การใช้ React อย่างกว้างขวางหมายความว่าเธรดหลักอยู่ภายใต้ภาระหนัก
ช่องว่างระหว่างอุปกรณ์เคลื่อนที่และเดสก์ท็อป
อีกมุมมองหนึ่งที่ฉันดูข้อมูลที่วิจัยคือการศึกษาว่าช่องว่างระหว่างการทำงานกับไซต์บนอุปกรณ์เคลื่อนที่และเดสก์ท็อปนั้นใหญ่เพียงใด หากเราพูดถึงการเปรียบเทียบปริมาณโค้ด JavaScript การเปรียบเทียบดังกล่าวจะไม่เปิดเผยสิ่งที่น่ากลัว แน่นอนว่าคงจะดีหากเห็นโค้ดที่ดาวน์โหลดได้ในจำนวนที่น้อยลง แต่จำนวนโค้ดสำหรับมือถือและเดสก์ท็อปนั้นไม่แตกต่างกันมากนัก
แต่ถ้าเราวิเคราะห์เวลาที่ต้องใช้ในการประมวลผลโค้ด ช่องว่างขนาดใหญ่ระหว่างอุปกรณ์พกพาและเดสก์ท็อปจะสังเกตเห็นได้ชัดเจน
เวลาที่เพิ่มขึ้น (เปอร์เซ็นต์) ที่เกี่ยวข้องกับการประมวลผลสคริปต์บนอุปกรณ์เคลื่อนที่เมื่อเทียบกับเดสก์ท็อป
เปอร์เซ็นต์ไทล์
10
25
50
75
90
เว็บไซต์ทั้งหมด
144.1
172.8
185.5
208.5
224.0
เว็บไซต์ jQuery
188.2
187.4
191.3
209.6
221.9
เว็บไซต์ Vue
222.5
220.8
220.2
221.4
220.4
เว็บไซต์เชิงมุม
205.1
206.0
201.6
210.4
218.7
ตอบสนองไซต์
431.5
386.8
337.9
242.6
179.6
ในขณะที่คาดว่าจะมีความแตกต่างกันบ้างในความเร็วในการประมวลผลโค้ดระหว่างโทรศัพท์และแล็ปท็อป แต่ตัวเลขจำนวนมากเช่นนี้บอกฉันว่าเฟรมเวิร์กสมัยใหม่ไม่ได้มีเป้าหมายเพียงพอสำหรับอุปกรณ์ที่ใช้พลังงานต่ำ และพวกเขาพยายามที่จะปิดช่องว่างที่พวกเขาค้นพบ แม้จะอยู่ที่เปอร์เซ็นไทล์ที่ 10 ไซต์ React ก็ยังใช้เวลากับเธรดหลักบนอุปกรณ์เคลื่อนที่มากกว่าเธรดหลักบนเดสก์ท็อปถึง 431.5% jQuery มีช่องว่างที่เล็กที่สุด แต่ที่นี่ตัวเลขที่เกี่ยวข้องคือ 188.2% เมื่อนักพัฒนาเว็บไซต์สร้างโครงการในลักษณะที่การประมวลผลของพวกเขาต้องใช้เวลาในการประมวลผลมากขึ้น (ซึ่งเกิดขึ้นและแย่ลงเมื่อเวลาผ่านไป) เจ้าของอุปกรณ์ที่ใช้พลังงานต่ำจะต้องจ่ายเงิน
ผลของการ
เฟรมเวิร์กที่ดีควรให้นักพัฒนามีพื้นฐานที่ดีในการสร้างโครงการเว็บ (ในแง่ของความปลอดภัย การเข้าถึง ประสิทธิภาพ) หรือควรมีข้อจำกัดในตัวที่ทำให้ยากต่อการสร้างสิ่งที่ละเมิดข้อจำกัดเหล่านั้น
สิ่งนี้ดูเหมือนจะใช้ไม่ได้กับประสิทธิภาพของโครงการเว็บ (และน่าจะไม่ใช่กับโครงการของพวกเขา ).
เป็นที่น่าสังเกตว่าเพียงเพราะไซต์ React หรือ Angular ใช้เวลา CPU ในการเตรียมโค้ดมากกว่าไซต์อื่น ๆ ไม่ได้หมายความว่าไซต์ React จะใช้ CPU มากกว่าไซต์ Vue ในขณะที่ทำงาน อันที่จริง ข้อมูลที่เราตรวจสอบระบุเพียงเล็กน้อยเกี่ยวกับประสิทธิภาพการดำเนินงานของเฟรมเวิร์กและไลบรารี พวกเขาพูดคุยมากขึ้นเกี่ยวกับแนวทางการพัฒนาที่กรอบเหล่านี้สามารถผลักดันโปรแกรมเมอร์โดยตั้งใจหรือไม่ก็ตาม เรากำลังพูดถึงเอกสารประกอบสำหรับเฟรมเวิร์ก เกี่ยวกับระบบนิเวศของเฟรมเวิร์ก เกี่ยวกับเทคนิคการพัฒนาทั่วไป
นอกจากนี้ยังควรกล่าวถึงบางสิ่งที่เราไม่ได้วิเคราะห์ในที่นี้ กล่าวคือ ระยะเวลาที่อุปกรณ์ใช้ในการเรียกใช้โค้ด JavaScript เมื่อนำทางระหว่างหน้าต่างๆ ของไซต์ ข้อโต้แย้งที่สนับสนุน SPA คือเมื่อโหลดแอปพลิเคชันหน้าเดียวลงในเบราว์เซอร์แล้ว ในทางทฤษฎี ผู้ใช้จะสามารถเปิดหน้าต่างๆ ของไซต์ได้เร็วขึ้น ประสบการณ์ของฉันเองบอกว่านี่ยังห่างไกลจากความจริง แต่เราไม่มีข้อมูลที่จะชี้แจงปัญหานี้
สิ่งที่ชัดเจนคือหากคุณใช้เฟรมเวิร์กหรือไลบรารีเพื่อสร้างเว็บไซต์ คุณกำลังประนีประนอมในแง่ของการเริ่มโหลดโปรเจ็กต์และเตรียมพร้อมสำหรับการดำเนินการ สิ่งนี้ใช้ได้กับสถานการณ์ที่เป็นบวกมากที่สุด
เป็นไปได้อย่างสมบูรณ์แบบที่จะประนีประนอมในสถานการณ์ที่เหมาะสม แต่สิ่งสำคัญคือนักพัฒนาจะต้องประนีประนอมอย่างมีสติ
แต่เราก็มีเหตุผลในการมองโลกในแง่ดีเช่นกัน ฉันตื่นเต้นที่ได้เห็นว่านักพัฒนาซอฟต์แวร์ Chrome ทำงานใกล้ชิดกับนักพัฒนาเครื่องมือส่วนหน้าบางรายการที่เราได้ตรวจสอบเพื่อช่วยปรับปรุงประสิทธิภาพของเครื่องมือเหล่านั้น
อย่างไรก็ตาม ฉันเป็นคนจริงจัง สถาปัตยกรรมใหม่สร้างปัญหาด้านประสิทธิภาพได้บ่อยเท่าที่แก้ไขได้ และต้องใช้เวลาในการแก้ไขจุดบกพร่อง อย่างที่เราไม่ควรคาดหวัง จะแก้ปัญหาด้านประสิทธิภาพทั้งหมด คุณไม่ควรคาดหวังสิ่งนี้จากเฟรมเวิร์กเวอร์ชันใหม่ที่เราชื่นชอบ
หากคุณต้องการใช้เครื่องมือส่วนหน้าที่กล่าวถึงในบทความนี้ หมายความว่าคุณจะต้องใช้ความพยายามเป็นพิเศษเพื่อไม่ให้ประสิทธิภาพการทำงานของโครงการของคุณเสียหายในระหว่างนี้ ต่อไปนี้คือข้อควรพิจารณาบางประการที่ควรพิจารณาก่อนเริ่มกรอบงานใหม่:
- ทดสอบตัวเองด้วยสามัญสำนึก คุณจำเป็นต้องใช้กรอบงานที่เลือกหรือไม่? Pure JavaScript ในปัจจุบันมีความสามารถมากมาย
- มีทางเลือกอื่นที่เบากว่าสำหรับเฟรมเวิร์กที่เลือก (เช่น Preact, Svelte หรืออย่างอื่น) ที่ให้ความสามารถ 90% ของเฟรมเวิร์กนี้แก่คุณหรือไม่
- หากคุณใช้เฟรมเวิร์กอยู่แล้ว ให้พิจารณาว่ามีตัวเลือกมาตรฐานที่ดีกว่า อนุรักษ์นิยมมากกว่า (เช่น Nuxt.js แทน Vue, Next.js แทน React เป็นต้น)
- อะไรของคุณ ประสิทธิภาพของจาวาสคริปต์?
- ได้ยังไง กระบวนการพัฒนาที่ทำให้การแทรกโค้ด JavaScript ในโครงการยากขึ้นเกินความจำเป็นจริงหรือ?
- หากคุณกำลังใช้เฟรมเวิร์กเพื่อความสะดวกในการพัฒนา ให้พิจารณา ส่งรหัสกรอบไปยังลูกค้า บางทีคุณสามารถแก้ปัญหาทั้งหมดบนเซิร์ฟเวอร์ได้หรือไม่?
โดยปกติแล้วแนวคิดเหล่านี้ควรค่าแก่การดู ไม่ว่าคุณจะเลือกอะไรสำหรับการพัฒนาส่วนหน้าก็ตาม แต่สิ่งเหล่านี้มีความสำคัญอย่างยิ่งเมื่อคุณทำงานในโครงการที่ขาดประสิทธิภาพตั้งแต่เริ่มต้น
เรียนผู้อ่าน! คุณเห็นเฟรมเวิร์ก JavaScript ในอุดมคติอย่างไร
ที่มา: will.com