เว็บไซต์ GitHub ทำงานช้าบน Safari

 (github.com/orgs)
2 คะแนน โดย GN⁺ 2025-08-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในช่วงไม่กี่เดือนที่ผ่านมา ความเร็วของเว็บไซต์ GitHub บน เบราว์เซอร์ Safari ลดลงอย่างต่อเนื่อง
  • โดยเฉพาะใน PR ขนาดใหญ่ หรือไฟล์โค้ดที่มีหลายพันบรรทัด การเรนเดอร์หน้าจอแทบจะเป็นไปไม่ได้
  • พบอาการ ใช้โปรเซสเรนเดอร์ 100% ของเบราว์เซอร์, หน้าจอว่างขณะเลื่อน, และการทำงานของการค้นหา·คอมเมนต์ล่าช้าอย่างรุนแรง
  • การ เปลี่ยนแปลง CSS และการใช้ transform ไปชนกับบั๊กด้านประสิทธิภาพของ Safari จนก่อให้เกิดปัญหา ขณะที่เบราว์เซอร์อื่นอย่าง Chrome ยังทำงานได้ดีกว่าเมื่อเทียบกัน
  • แม้ WebKit จะมีการแพตช์ด้านประสิทธิภาพบางส่วนแล้ว แต่ก็มีการกล่าวถึงความจำเป็นที่ทีมฟรอนต์เอนด์ของ GitHub ต้องมีมาตรการชั่วคราวจนกว่าจะถึง Safari รุ่นถัดไป

พื้นหลังและปัญหาหลัก

  • ช่วงหลังมานี้ เมื่อเข้าถึงเว็บไซต์ GitHub ด้วยเบราว์เซอร์ Safari จะเห็นอาการประสิทธิภาพตกลงอย่างชัดเจนโดยรวม
  • โดยเฉพาะเมื่อเปิดดูการเปลี่ยนแปลง หลายพันบรรทัดขึ้นไป ใน Pull Request (PR) หรือสำรวจไฟล์โค้ดขนาดใหญ่ อาการหนักถึงขั้นเรนเดอร์ไม่ไหว
  • ใน Activity Monitor พบว่า โปรเซสเรนเดอร์กิน CPU 100% และการเรนเดอร์หน้าเว็บช้ามากจนเวลาเลื่อนจะเห็นหน้าจอเป็นพื้นที่ว่าง
  • ฟีเจอร์แบบโต้ตอบอย่างการค้นหาและคอมเมนต์ล่าช้าอย่างหนัก และแม้แต่การคลิกเช็กบ็อกซ์ระหว่างรีวิว PR ก็อาจใช้เวลาหลายวินาที
  • อาการเดียวกันนี้เกิดแม้บน MacBook Pro รุ่นใหม่ที่ใช้ Apple Silicon ระดับสูง ขณะที่การใช้ Chrome หรือเบราว์เซอร์อื่นให้ประสบการณ์ที่ดีกว่ามาก

สาเหตุของปัญหาและการวิเคราะห์

  • มีรายงานร้องเรียนร่วมกันจากผู้ใช้ Safari 18.6 (รวมถึงรุ่นเบต้า/Tech Preview)
  • ผู้ใช้บางรายระบุว่าอาการประสิทธิภาพตกอย่างรุนแรงนี้เกิดขึ้น เฉพาะกับ GitHub ไม่ใช่กับ Safari โดยรวม
  • มีการอธิบายว่าการใช้ CSS selector และ transform: translateY จำนวนมาก ชนตรงกับข้อจำกัดในการจัดการ GPU layer ของ Safari
    • ฟรอนต์เอนด์ของ GitHub จัดวางทุกบรรทัดข้อความด้วย transform: translateY ทำให้ Safari ต้องสร้าง GPU layer หลายพันชั้น
    • ส่วน Chrome หากไม่มีแอนิเมชันลักษณะนี้ จะปรับแต่งการสร้าง layer ให้เหมาะสมกว่า จึงช้ากว่าน้อยกว่าเมื่อเทียบกัน
    • มีวิธีชั่วคราวคือใช้สคริปต์เพื่อลบคุณสมบัติ transform ออก ซึ่งช่วยให้เร็วขึ้น แต่ความแม่นยำของตำแหน่งยังไม่สมบูรณ์

ประสบการณ์ผู้ใช้และรายงานที่หลากหลาย

  • ผู้ใช้หลายรายบ่นว่า ทุกการโต้ตอบ เช่น เพิ่ม reviewer·label หรือแก้ไขคำอธิบาย PR ล้วนหน่วงเกินหลายวินาที
  • เมื่อเข้าใช้งานผ่าน Safari, ทั้ง code browser และ UI ของระบบ autocomplete (เช่น search bar, command palette) จะช้ามาก
  • มีกรณีบน iOS Safari ที่ฟังก์ชันของเบราว์เซอร์เอง เช่น ปุ่ม ย้อนกลับ แบบเนทีฟ ก็ทำงานไม่ถูกต้อง
  • ด้านการเข้าถึง (VoiceOver) ก็ได้รับผลกระทบหนักจากประสิทธิภาพที่ตกลง จนผู้ใช้ที่มีความบกพร่องทางการมองเห็นแทบใช้งานไม่ได้

การแก้ไขและการรับมือ

  • ฝั่ง WebKit (เอนจินของ Safari) เพิ่งมีการแพตช์บางส่วนสำหรับ ปัญหาประสิทธิภาพของ CSS/compositor นี้ แต่ก็ยังแก้ได้ไม่ทันทีจนกว่าจะถึง Safari รุ่นถัดไป
  • มีการกล่าวถึงความจำเป็นที่จะต้องเสนอแนวทางรับมือบั๊กและสื่อสารเรื่องปัญหาประสิทธิภาพกับวิศวกร GitHub ล่วงหน้าก่อนกำหนดปล่อย Safari รุ่นถัดไป
  • มีการมองว่าการเปลี่ยนแปลง UI ฝั่งฟรอนต์เอนด์หลายอย่าง (เช่น UI ไฟล์ที่เปลี่ยนใน PR, ฟีเจอร์ใหม่ ฯลฯ) เกี่ยวข้องโดยตรงกับอาการประสิทธิภาพตก
  • ผู้ใช้บางรายหลบเลี่ยงปัญหาด้วย Graphite.dev, GitLab หรือ custom protocol router (เช่น Finicky, Velja เป็นต้น) รวมถึงการใช้ UI ทางเลือก

ความเห็นอื่น ๆ และเคล็ดลับจากผู้ใช้จริง

  • มีคำแนะนำชั่วคราวว่า หลังสร้าง issue/PR บน Safari แล้ว ให้ใช้ฟังก์ชันเพิ่ม label แบบตารางแทน
  • มีเสียงกังวลต่อ CSS ที่ซับซ้อนเกินไป การเปลี่ยนแปลงโครงสร้างวิศวกรรม และการมุ่งเน้น Chrome เพียงเบราว์เซอร์เดียว พร้อมย้ำความสำคัญของการรองรับหลายเบราว์เซอร์
  • ผู้ใช้บางรายแสดงความเห็นเชิงวิจารณ์หรือเชิงขำขันต่อปัญหาประสิทธิภาพนี้ (และมีการเตือนให้ระวังการถกเถียงทางอารมณ์ที่ไม่จำเป็น)
  • มีทั้งความเห็นภายในและภายนอกที่เสนอให้ทบทวนแนวทางพัฒนาฟรอนต์เอนด์ที่ต้องการการปรับแต่งประสิทธิภาพ และย้ำความสำคัญของการทดสอบข้ามหลายเบราว์เซอร์

บทสรุป

  • การเปลี่ยนแปลงโครงสร้าง UI ล่าสุดของ GitHub และวิธีใช้ CSS ไปชนกับลักษณะการเรนเดอร์เฉพาะของ Safari จนก่อให้เกิดปัญหาร้ายแรงต่อการใช้งานเบราว์เซอร์บนแพลตฟอร์มทำงานร่วมกันที่เป็นมาตรฐานของอุตสาหกรรม
  • ทั้ง WebKit และ GitHub จำเป็นต้องเร่งปรับปรุงอย่างจริงจัง และในระยะสั้นต้องให้ความสำคัญกับผู้ใช้ Safari และผู้ใช้ที่ต้องพึ่งพาฟีเจอร์การเข้าถึง
  • ปัญหาด้านประสิทธิภาพนี้รุนแรงถึงระดับที่รบกวนงานพัฒนา และทำให้เกิดทั้งความเห็นพ้องและความไม่พอใจอย่างกว้างขวางในชุมชน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-08-29
ความคิดเห็นจาก Hacker News

  • เว็บไซต์ Github ช้าทุกที่อยู่แล้ว โดยรวมแล้วคงเรียกว่าเป็นซอฟต์แวร์ที่ดีไม่ได้ทั้งในแง่ประสิทธิภาพหรือ UX/UI และให้ความรู้สึกว่าเป็นผลลัพธ์จาก KPI กับการวางแผนของคนหลายฝ่าย ส่วนที่ “ล้ำสมัย” ที่สุดอาจเป็นการที่มันคือโซเชียลเน็ตเวิร์กสำหรับนักพัฒนา แต่สำหรับงานพัฒนาประจำวันกลับธรรมดาเกินไปจนรู้สึกว่า Gitlab ดีกว่ามาก ปัญหานี้ไม่ใช่เพราะ Rails และการเอาเรื่องเทคโนโลยีมาห่อหุ้มเพื่อเลี่ยงประเด็นหลักก็ดูไม่ถูกต้อง

    • ปัญหาของ Github ไม่ใช่ Rails แต่เป็นเพราะย้ายไปใช้ React ต่างหาก Github แบบ SSR ในอดีตเร็วมาก และรีวิว PR ขนาดใหญ่ก็ทำได้ไม่มีปัญหา
    • ไม่ได้ใช้ Github มาหลายปี พอกลับมาใช้อีกครั้งในปีนี้ก็ตกใจมากว่ามันช้าลงไปแค่ไหน ช้าทุกครั้งที่มีการโต้ตอบจนต้องเปลี่ยนวิธีใช้งานทั้งหมด มันให้ความรู้สึกเหมือนมีอะไรผิดปกติตลอดเวลา และถ้าไม่มีการตอบสนองอยู่หลายวินาทีก็อดรู้สึกกังวลไม่ได้ว่าเซิร์ฟเวอร์ค้างไปแล้วหรือเปล่า
    • ใช้ Phabricator มาตลอด 10 ปี พอย้ายมา Github ก็รู้สึกอึดอัดกับความต่างด้านคุณภาพ และไม่อยากเชื่อว่านี่คือมาตรฐาน น่าเสียดายที่ Phabricator ตอนนี้เหลือแค่การบำรุงรักษา วิกิ Phabricator
    • เมื่อก่อน Github ลื่นมาก แต่หลังเปลี่ยนเป็น SPA ก็เริ่มอืดและน่าอึดอัด
    • เคยมี CTO ที่โทษ Rails ว่าเป็นต้นเหตุของปัญหาประสิทธิภาพในแอป legacy แล้วจะรื้อใหม่เป็น Java ทั้งหมด ทั้งที่จริงสาเหตุรากคือการสะสมของนักวางแผนที่ไม่มีความสามารถ ผู้บริหาร และนักพัฒนาที่ประสบการณ์ไม่พอ ถ้าเป็นโปรเจ็กต์ที่ถูกดูแลผิดพลาดมานานเกิน 10 ปี ไม่ว่าจะใช้สแตกไหนผลก็ออกมาเหมือนกัน

  • ทีม WebKit ได้ปล่อยการปรับปรุงปัญหาประสิทธิภาพของ Github ในช่วง 2 วันที่ผ่านมา ลิงก์ที่เกี่ยวข้อง ภายในทีมเองก็เคยสร้าง PR ขนาดใหญ่มากด้วย (มากกว่า 1000 ไฟล์) จนเพื่อนร่วมงานพูดกันว่า “เดี๋ยวถ้ามันเปิดขึ้นมาแล้วจะ approve ให้”

    • ทุกคนพูดว่า JS และ React คือปัญหา แต่จริง ๆ แล้วแพตช์รอบนี้เกี่ยวกับประสิทธิภาพของ CSS
    • ตอนนี้ Chrome และเบราว์เซอร์สายเดียวกันแทบผูกขาด rendering engine ไปแล้ว ดังนั้นในช่วงที่ Firefox โตช้าลงแบบนี้ การที่ Apple ยังทำให้ Safari บน macOS/iOS แข่งขันได้อยู่จึงเป็นการเปลี่ยนแปลงที่น่ายินดี
    • อยากรู้จริง ๆ ว่า PR ที่มีไฟล์เกิน 1000 ไฟล์นั้นเป็นงานแบบไหน
    • จริง ๆ แล้วมันเป็นบั๊กที่โผล่ออกมาเพราะ Github สร้างภาระให้ Safari WebKit มากเกินไป ในฐานะนักพัฒนาหรือผู้ใช้ เรามักเผลอโทษว่าเป็นความผิดของ Github อย่างเดียวได้ง่าย
    • อยากรู้ว่าแพตช์ของ WebKit จะใช้เวลานานแค่ไหนกว่าผู้ใช้จริงจะได้รับ ต้องรออัปเดต OS สำหรับ Safari หรือว่าอัปเดตได้เร็วเหมือน Chrome/Firefox

  • ทันทีที่ Microsoft เข้าซื้อ Github ก็แทบจะเปลี่ยน Github ไปเป็นการเรนเดอร์ด้วย JavaScript (SPA) ทันที ก่อนหน้านั้นแม้ปิด JavaScript บน Mac Mini ปี 2011 ก็ยังท่อง Github ได้ แต่ตอนนี้เปิด JS แล้วก็ยังใช้ Github ไม่ได้เพราะปัญหาความเข้ากันได้กับเบราว์เซอร์รุ่นเก่า จะบอกว่าฝั่งไหนผิดกว่ากันก็ยาก แต่คิดว่าทั้งสองฝ่ายมีส่วนรับผิดชอบ ถึงจะเปลี่ยนไปใช้อุปกรณ์ใหม่ก็ได้ แต่ในบรรยากาศที่จงใจเลิกซัพพอร์ตอุปกรณ์เก่าและบีบให้ยอมรับ planned obsolescence มากกว่าความสามารถใช้งานในอนาคต มันทำให้ศรัทธาต่อ web standard เองก็สั่นคลอนด้วย

    • ถ้าเพิ่งรู้วันนี้ OpenCore Legacy Patcher สามารถใช้เพื่ออัปเกรด macOS ไปเวอร์ชันล่าสุดได้แม้กระทั่งบน Mac ปี 2007 ลิงก์ OpenCore Legacy Patcher
    • อยากรู้ว่าลองติดตั้ง Chrome หรือ Firefox มาใช้แทนได้ไหม
    • สงสัยว่าทำไม Turing completeness ถึงฟังดูเหมือนคำโกหก แม้ planned obsolescence จะเป็นส่วนหนึ่ง แต่สภาพแวดล้อมซอฟต์แวร์สมัยใหม่มี abstraction มากเกินไป ถ้าซอฟต์แวร์ทั้งหมดต้องเขียนด้วยภาษา C โลกตอนนี้คงต่างไปมาก ดูเหมือนเราจมอยู่กับ abstraction ระดับสูงเกินไป แต่ก็มาถึงจุดที่ยากจะย้อนกลับแล้ว Turing completeness เองแทบไม่เกี่ยวกับเรื่องนี้ และกลับทำให้ต้องใช้ทรัพยากรมากขึ้นเสียด้วยซ้ำ
    • ขอย้ำว่า Turing completeness ไม่เกี่ยวกับประสิทธิภาพ ในทางทฤษฎีแล้วอุปกรณ์ปัจจุบันอาจเอาอุปกรณ์รุ่นใหม่มาจำลองการทำงานก็ได้
    • บางคนอาจไม่พอใจที่ Mac Mini ปี 2011 หมดการรองรับระบบปฏิบัติการ แต่การใช้อินเทอร์เน็ตด้วยเบราว์เซอร์ที่เก่ากว่า 8 ปีก็แทบไม่ต่างจากการเปิดประตูบ้านทิ้งไว้ทั้งหมดในแง่ความปลอดภัย

  • มีคนวิจารณ์ React เยอะ แต่ประเด็นนี้คือปัญหา CSS transform แนะนำให้อ่านลิงก์ที่เกี่ยวข้องจริง ๆ

  • แนะนำให้ย้ายไป Forgejo, Codeberg, SourceHut เมื่อเทียบกับ Github และ Gitlab แล้วเร็วราวสายฟ้า Forgejo / Codeberg / SourceHut

    • เคยรันเซิร์ฟเวอร์ Forgejo บนลิงก์ที่พัง ๆ ระดับแค่กิโลบิตต่อวินาทีอยู่หลายสัปดาห์ แต่มันก็ยังทนได้ดีพอสมควร push/pull ยังพอทำงานได้ แต่อะไรที่เป็น actions นั้นลำบากเพราะต้องส่งข้อมูลเกิน 100MB

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

    • ตอนนี้วงการ IT มีอยู่สามกลุ่ม: 1) PM กดดันให้ปล่อยของแบบเกินเหตุและสนใจแต่ความเร็ว 2) นักพัฒนาต่อต้านคำขอแบบนี้และค่อย ๆ เผาทุนทางการเมืองของตัวเองจนหมดแรง 3) กลุ่มนักพัฒนาที่ไม่สนใจอะไร ทำงานตามที่ได้รับมอบหมายเหมือนเครื่องจักร สุดท้ายแล้วปัญหาอยู่ที่วัฒนธรรมองค์กรเอง และถ้าไม่มีการปฏิรูปจากระดับ C-level แบบจริงจังก็ไม่เปลี่ยน คนเป็นผู้บริหารส่วนใหญ่ก็ไม่ได้มีความตั้งใจจะเปลี่ยนมัน
    • เวลาองค์กรใหญ่เลือก tech stack เกณฑ์ที่สำคัญที่สุดคือ “จ้างและปลดคนได้ง่ายแค่ไหน” นักพัฒนา React มีเยอะ แต่ Rails หายาก ความเห็นของนักพัฒนาถูกมองข้าม ความต้องการขององค์กรถูกให้ความสำคัญก่อน และสุดท้ายก็กลายเป็นบริการที่ช้าและคุณภาพแย่ นักพัฒนาเองก็รู้ปัญหา แต่การเอาตัวรอดมาก่อน
    • ถ้าเมื่อก่อนมีคำว่า “ไม่มีใครถูกไล่ออกเพราะซื้อ IBM” ทุกวันนี้บรรยากาศคล้ายเป็น “ถ้าไม่ใช้ React ก็อาจถูกไล่ออก” ทุกคนใช้ React กันหมด เลยทำให้แม้แต่ Github ก็ยังช้า นักพัฒนาที่แย่จะทำตามที่คนอื่นใช้ ส่วนนักพัฒนาที่ดีจะเลือกเครื่องมือที่เรียบง่ายที่สุดตามหลัก KISS
    • ในองค์กรใหญ่ “ความเป็นเจ้าของ” มักคลุมเครือ และด้วยอัตราการหมุนเวียนคนสูงกับการโฟกัสเป้าหมายระยะสั้น ปัญหาแบบนี้จึงเกิดซ้ำตลอด แรงกดดันให้เพิ่มฟีเจอร์และหนี้เทคนิคสะสมขึ้นเรื่อย ๆ ขณะที่ความรับผิดชอบกลับหายไป ถ้าลุกขึ้นมาชี้ปัญหาก็มักกลายเป็นความขัดแย้ง และอาจถูกผลักเข้าสู่แผนปรับปรุงผลงานเสียอีก

  • ในฐานะนักพัฒนา React อ่านเธรดนี้แล้วสัมผัสได้ถึงความเกลียดชังจากโลกภายนอก มีกับดักของ SPA เยอะมาก ทั้งกำหนดเวลาที่ไม่สมจริงและการยัด logic ฝั่ง backend มาไว้ฝั่ง frontend เลยสงสัยว่า React เองเป็นตัวเลือกที่ผิดตั้งแต่ต้นหรือเปล่า หรือจริง ๆ มี React app ที่ทำออกมาดีมากอยู่ไหม

    • เคยเป็นแฟน React/SPA ตัวยงมานาน แต่ยิ่งนานไปก็ยิ่งรู้สึกว่าการพัฒนากลับยากกว่าสมัยทำแอปเดสก์ท็อป C++ MFC เสียอีก เขาบอกว่า declarative markup จะลดภาระการรับรู้ แต่ความจริงความซับซ้อนของ declarative UI รวมกับ event/state management กลับยิ่งมากขึ้น จนซับซ้อนกว่าสมัยพัฒนาแบบ procedural เสียอีก โค้ด C++ สมัยก่อนยังเข้าใจง่ายกว่า React hook ด้วยซ้ำ
    • คนวิจารณ์ SPA กันมากก็จริง แต่ก็มี React/Angular app ที่ทำได้ดีจริง ๆ เช่น Clockify ต่อให้แอปที่มีปัญหาเปลี่ยนไปเรนเดอร์แบบ SSR ก็ไม่ได้แปลว่า UX จะดีขึ้นทันที สาเหตุจริงคือบรรยากาศองค์กรที่สนใจแต่ปล่อยฟีเจอร์ให้เร็วมากกว่าคุณภาพ
    • เทคโนโลยีพวกนี้มักถูกพูดถึงเฉพาะตอนที่ประสิทธิภาพแย่ ทุกคนใช้เทคโนโลยีเว็บทุกวันเลยด่าได้ง่าย โดยเฉพาะเทคโนโลยีที่นักพัฒนามือใหม่ใช้กันมากจึงยิ่งโดนโจมตี เป็นตัวอย่างที่ชัดของการลบเส้นแบ่งขอบเขต
    • ปัญหาไม่ใช่ React เอง แต่เป็นการที่นักพัฒนาใช้มันผิดวิธี ต่อให้มี optimization มากมาย ถ้าร้อยมันเข้าด้วยกันผิด ๆ ก็ทำให้การตอบสนองต่อคลิกช้าได้ถึง 1.3 วินาที
    • React เองไม่ได้แย่ และบ่อยครั้งที่โครงสร้างแบบ SPA ต่างหากที่มีปัญหาในเชิงสถาปัตยกรรม React เป็นเพียงเครื่องมือที่ทำให้การสร้าง SPA ง่ายขึ้น

  • รู้สึกว่าโลกคอมพิวติงโดยรวมทุกอย่างช้าลงหมด ต่อให้ใช้ Mac Studio M4 Max รุ่นล่าสุดพร้อม RAM 64GB ก็ยังรู้สึกว่าเว็บไซต์ทุกแห่งช้ากว่าสมัย MacBook Pro ปี 2011

    • ตอนใช้อินเทอร์เน็ตเมื่อ 15 ปีก่อนมันก็ช้าจริง แต่ตอนนั้นเราไม่ได้ใช้สเปรดชีตซับซ้อนหรือเครื่องมือออกแบบผ่านเว็บ M-series Mac เป็นคอมพิวเตอร์ที่เร็วที่สุดเท่าที่เคยใช้มา (ยกเว้น Linux desktop)
    • คิดว่านักพัฒนาเว็บควรลองพัฒนาบนอุปกรณ์สเปกระดับล่างประมาณ 10% ล่างสุดของผู้ใช้จริง ไม่อย่างนั้นก็อาจกำหนดให้ประสิทธิภาพเป็นส่วนหนึ่งของเกณฑ์ WCAG (การเข้าถึงเว็บ) ไปเลยก็ได้

  • ใน HN มักได้ยินว่าหลัง Github ย้าย UI ไป React แล้วมันช้าลง แต่อยากรู้ว่าเป็นแบบนั้นจริงหรือไม่ เพราะในโปรเจ็กต์เล็ก ๆ ยังไม่เห็นผลชัด จึงอยากได้หลักฐานที่แน่นอน

    • บล็อกโพสต์ที่เพิ่งอ่านอธิบายสาเหตุไว้ดีมาก สรุปคือในหน้า PR view มีการเรนเดอร์ DOM node มากกว่า 100,000 ตัว และจำนวนไม่น้อยเป็น SVG node ที่มองไม่เห็น อีกทั้งการ routing แบบ SPA ก็ทำให้การนำทางช้าลงมากด้วย บล็อกที่เกี่ยวข้อง / การถกเถียงใน HN
    • ช่วงหลังเหมือนหน้า PR diff ถูก redesign ใหม่จน DOM ยิ่งพองโตขึ้นอีก

  • ไม่ใช่แค่ Safari แต่บน Firefox ก็ช้ามากเช่นกัน มี loading spinner โผล่ให้เห็นทั่ว ๆ ไป และการเปลี่ยนหน้าก็ใช้เวลานานกว่าเดิมมาก ไม่เข้าใจเลยว่าใช้ตัวชี้วัดอะไรถึงตัดสินใจเปลี่ยนจาก SSR ที่เดิมทำงานได้สมบูรณ์อยู่แล้วไปเป็น SPA

    • ช่วงหลังบน Chrome ก็มีปัญหาคล้ายกัน ทั้งสามเบราว์เซอร์ตอนนี้อยู่ในสภาพที่ต่อให้ PR ไม่ใหญ่ก็ทำงานได้ไม่ดีแล้ว