GitHub แพลตฟอร์มโฮสต์โค้ดที่ใหญ่ที่สุดในโลก กำลังเผชิญกับคำวิจารณ์ที่เพิ่มขึ้นจากนักพัฒนาเกี่ยวกับการลดลงของประสิทธิภาพอย่างรุนแรง ที่ได้เปลี่ยนการใช้งานที่เคยรวดเร็วให้กลายเป็นประสบการณ์ที่ช้าและน่าหงุดหงิด สิ่งที่เคยเป็นการเปลี่ยนหน้าแบบทันทีตอนนี้ใช้เวลามากกว่า 5 วินาที โดยการดำเนินการบางอย่างกลายเป็นแทบใช้งานไม่ได้บนแพลตฟอร์มที่โฮสต์โปรเจกต์ซอฟต์แวร์หลายล้านโปรเจกต์
ปัญหาประสิทธิภาพเกิดจากการย้ายของ GitHub ที่กำลังดำเนินอยู่จากสถาปัตยกรรม vanilla JavaScript และ web components เดิมไปยังแอปพลิเคชันหน้าเดียว (SPAs) ที่ใช้ React การเปลี่ยนแปลงนี้ซึ่งเริ่มต้นเมื่อหลายปีก่อน ได้สร้างภาระเพิ่มเติมที่สำคัญซึ่งทำให้การดำเนินการพื้นฐานเช่นการสลับระหว่างแท็บ pull request หรือการดูความแตกต่างของโค้ดช้าจนน่าหงุดหงิด
การเปรียบเทียบประสิทธิภาพ:
- การสลับแท็บใน GitHub : 5+ วินาที
- การเปิดหน้าเดียวกันในแท็บใหม่: ~2.5 วินาที (เร็วกว่า 2 เท่า)
- เวลาประมวลผลฝั่งไคลเอนต์: นานกว่าการโหลด HTML จากเซิร์ฟเวอร์
- ขีดจำกัดการใช้งาน diff viewer : ~5,000 บรรทัดของการเปลี่ยนแปลง
การย้ายไป React สร้างปัญหามากกว่าแก้ปัญหา
ปัญหาหลักอยู่ที่การใช้งาน client-side routing ของ GitHub โดยใช้ React และ Turbo สำหรับการเปลี่ยนหน้า แม้ว่าเทคโนโลยีเหล่านี้มีจุดประสงค์เพื่อสร้างประสบการณ์ผู้ใช้ที่ราบรื่นขึ้นโดยหลีกเลี่ยงการโหลดหน้าใหม่ทั้งหมด แต่กลับได้ผลตรงกันข้าม การวิเคราะห์จากชุมชนเผยให้เห็นว่าการประมวลผลฝั่งไคลเอนต์ตอนนี้ใช้เวลานานกว่าการโหลด HTML จากเซิร์ฟเวอร์อย่างง่าย ๆ ซึ่งเป็นความล้มเหลวพื้นฐานของแนวทาง SPA
ความขัดแย้งชัดเจนเป็นพิเศษเมื่อพิจารณาว่าการเปิดหน้า GitHub ในแท็บใหม่จริง ๆ แล้วเร็วกว่าการนำทางผ่านแอปพลิเคชันหน้าเดียวถึงสองเท่า ซึ่งทำลายจุดประสงค์ทั้งหมดของ client-side routing ที่ควรจะให้การเปลี่ยนหน้าแบบทันที
Diff Viewer กลายเป็นใช้งานไม่ได้สำหรับไฟล์ขนาดใหญ่
หนึ่งในฟีเจอร์ที่ได้รับผลกระทบมากที่สุดคือ diff viewer ของ GitHub ซึ่งมีปัญหากับไฟล์ที่มีการเปลี่ยนแปลงมากกว่าสองสามพันบรรทัด ระบบพยายามเรนเดอร์ DOM nodes จำนวนมหาศาล บางครั้งมากกว่า 100,000 โหนด ทำให้เบราว์เซอร์หยุดทำงานเป็นเวลาหลายวินาที แม้แต่การดำเนินการง่าย ๆ เช่นการปรับขนาด developer tools ก็สามารถทำให้อินเทอร์เฟซค้างเป็นเวลา 3+ วินาที
ปัญหาซับซ้อนขึ้นด้วยการปฏิบัติการเรนเดอร์ที่ไม่มีประสิทธิภาพ เช่นการสร้างปุ่มที่มองไม่เห็นหลายพันปุ่มด้วยไอคอน SVG แบบ inline ที่เหมือนกัน ตัวเลือกการใช้งานเหล่านี้สร้างภาระการคำนวณที่ไม่จำเป็นซึ่งเบราว์เซอร์สมัยใหม่ต้องดิ้นรนเพื่อจัดการอย่างมีประสิทธิภาพ
ปัญหาทางเทคนิคที่ระบุได้:
- มีการเรนเดอร์ DOM nodes มากกว่า 100,000 โหนดในบางมุมมอง
- ปุ่มที่มองไม่เห็นหลายพันปุ่มที่มีไอคอน SVG แบบ inline เหมือนกัน
- มีการร้องขอ API มากกว่า 14 ครั้งสำหรับหน้าภาพรวมไฟล์ธรรมดา
- มีการร้องขอ GraphQL API มากกว่า 5 ครั้งสำหรับรายการ issue
- เบราว์เซอร์หยุดทำงาน 3 วินาทีระหว่างการปรับขนาดหน้าต่าง
 |
|---|
| การวิเคราะห์ประสิทธิภาพของ diff viewer ของ GitHub เน้นย้ำถึงปัญหาที่เกิดขึ้นขณะ rendering ไฟล์ขนาดใหญ่ ตามที่กล่าวไว้ในบทความ |
ความโกลาหลในการนำทางและฟีเจอร์พื้นฐานที่เสียหาย
นอกเหนือจากปัญหาประสิทธิภาพแล้ว การย้ายไป React ของ GitHub ยังทำลายฟีเจอร์การเรียกดูเว็บพื้นฐานที่ผู้ใช้พึ่งพามาเป็นเวลาหลายทศวรรษ ปุ่มย้อนกลับของเบราว์เซอร์ตอนนี้ทำงานแบบคาดเดาไม่ได้ บางครั้งกระโดดหลายขั้นตอนในประวัติหรือโหลดหน้าที่เสียหายซึ่งไม่เสร็จสิ้นการเรนเดอร์ ฟีเจอร์เช่น Ctrl+Enter เพื่อเปิดลิงก์ในแท็บใหม่ได้หยุดทำงานอย่างลึกลับ
ทุกอย่างแย่ลงตั้งแต่การเขียนใหม่ด้วย React ทุกอย่างช้าลงและกระตุกมากขึ้น และสิ่งต่าง ๆ เช่น 'ปุ่มย้อนกลับ' ยังคงทำงานแปลก ๆ
ปัญหาเหล่านี้ขยายไปถึงเบราว์เซอร์มือถือด้วย ซึ่ง GitHub กลายเป็นใช้งานไม่ได้เลยบน Safari สำหรับ iOS ในช่วง 9-12 เดือน ป้องกันไม่ให้ผู้ใช้ดูโค้ดหรือเข้าร่วมการสนทนาโดยไม่ต้องเปลี่ยนไปใช้เบราว์เซอร์อื่น
ฟีเจอร์ที่เสียหาย:
- การนำทางด้วยปุ่มย้อนกลับ/ไปข้างหน้าของเบราว์เซอร์
- Ctrl+Enter เพื่อเปิดลิงก์ในแท็บใหม่
- ความเข้ากันได้กับ Safari iOS (ช่วงเวลาที่ใช้งานไม่ได้ 9-12 เดือน)
- การเก็บตำแหน่งการเลื่อนหน้าจอระหว่างการเปลี่ยนหน้า
- การอัปเดตความคิดเห็นแบบเรียลไทม์ในการสนทนา
สาเหตุทางเทคนิคที่แท้จริง
ปัญหาประสิทธิภาพสืบย้อนไปถึงความแตกต่างพื้นฐานในวิธีที่ React จัดการ state management เมื่อเปรียบเทียบกับเฟรมเวิร์กสมัยใหม่อื่น ๆ โมเดล inverted reactivity ของ React หมายความว่าฟังก์ชันคอมโพเนนต์ทั้งหมดทำหน้าที่เป็น reactive callback ซึ่งต้องการให้นักพัฒนา opt out จากการเปลี่ยนแปลงสถานะอย่างชัดเจนแทนที่จะ opt in แนวทางนี้กลายเป็นปัญหามากขึ้นเมื่อขยายขนาด เนื่องจากต้องการการปรับให้เหมาะสมอย่างระมัดระวังผ่านเทคนิค memoization ที่นักพัฒนาหลายคนมองข้าม
ในขณะเดียวกัน เฟรมเวิร์กเช่น Vue, Svelte และ Solid ใช้ signals-based reactivity ที่กำหนดเป้าหมายผู้สมัครสมาชิกเฉพาะ ส่งผลให้การอัปเดตมีประสิทธิภาพมากขึ้น การเลือกใช้ React ของ GitHub แม้จะเป็นที่นิยมเพื่อจุดประสงค์ในการจ้างงาน แต่ได้สร้างหนี้ทางเทคนิคที่แสดงออกเป็นประสบการณ์ผู้ใช้ที่แย่
ชุมชนแสวงหาทางเลือก
ประสบการณ์ที่เสื่อมโทรมได้กระตุ้นให้นักพัฒนาบางคนแสวงหาทางเลือก โซลูชันที่โฮสต์เองเช่น Gitea และ Forgejo กำลังได้รับความสนใจเนื่องจากความเร็วและความน่าเชื่อถือ แม้ว่าจะขาด network effects และความสมบูรณ์ของฟีเจอร์เหมือน GitHub ผู้ประกอบการหลายคนกำลังสร้างทางเลือก GitHub UI ที่สัญญาว่าจะมีประสิทธิภาพดีกว่าในขณะที่รักษาความเข้ากันได้กับ APIs ของ GitHub
สถานการณ์นี้เน้นย้ำแนวโน้มที่กว้างขึ้นในการพัฒนาเว็บที่การแสวงหาแนวปฏิบัติการพัฒนาสมัยใหม่บางครั้งมาพร้อมกับค่าใช้จ่ายของประสบการณ์ผู้ใช้ ในขณะที่ GitHub ยังคงเป็นแพลตฟอร์มหลักสำหรับการพัฒนาโอเพนซอร์สและการทำงานร่วมกันด้านโค้ดขององค์กร ปัญหาประสิทธิภาพเหล่านี้ส่งผลต่อนักพัฒนาหลายล้านคนทั่วโลกที่พึ่งพาแพลตฟอร์มสำหรับงานประจำวันของพวกเขา
ทีมวิศวกรรมของ GitHub ยอมรับปัญหาประสิทธิภาพและได้ดำเนินความพยายามข้ามทีมเป็นเวลาหนึ่งปีเพื่อแก้ไขปัญหาเหล่านี้ แม้ว่าการปรับปรุงที่สำคัญจะยังคงเป็นเรื่องยากที่จะบรรลุ จนกว่าจะมีการเปลี่ยนแปลงที่สำคัญ นักพัฒนาต้องยังคงนำทางแพลตฟอร์มที่ได้เปลี่ยนจากโครงสร้างพื้นฐานที่เชื่อถือได้ให้กลายเป็นคอขวดที่น่าหงุดหงิดมากขึ้นในเวิร์กโฟลว์ของพวกเขา