Trang web GitHub hoạt động chậm trên Safari

• Trong vài tháng gần đây, tốc độ của trang web GitHub trên trình duyệt Safari đã giảm dần
• Với PR lớn hoặc các tệp mã có hàng nghìn dòng, việc render màn hình gần như trở nên bất khả thi
• Xuất hiện hiện tượng tiến trình render của trình duyệt dùng 100% và màn hình trắng khi cuộn, cùng với độ trễ nghiêm trọng ở các chức năng tìm kiếm và bình luận
• Thay đổi CSS và việc dùng transform xung đột với lỗi hiệu năng của Safari và gây ra sự cố; các trình duyệt khác như Chrome hoạt động tương đối tốt hơn
• Một số bản vá hiệu năng đã được thực hiện trong WebKit, nhưng có đề cập rằng nhóm frontend của GitHub vẫn cần biện pháp ứng phó tạm thời cho đến bản phát hành Safari tiếp theo

---

Bối cảnh và các vấn đề chính

• Gần đây, hiện tượng suy giảm hiệu năng tổng thể trở nên rõ rệt khi truy cập trang web GitHub bằng trình duyệt Safari
• Đặc biệt, khi xem các thay đổi lên tới hàng nghìn dòng trong Pull Request (PR) hoặc duyệt các tệp mã dung lượng lớn, tình trạng đã đến mức bản thân việc render gần như không thể thực hiện được
• Trong Activity Monitor, tiến trình render chiếm 100% CPU, và tốc độ render trang chậm đến mức khi cuộn, màn hình hiện ra như khoảng trống trắng
• Các tính năng tương tác như tìm kiếm, bình luận bị trễ nghiêm trọng, và ngay cả việc nhấp checkbox khi review PR cũng mất hơn vài giây
• Hiện tượng tương tự cũng xảy ra trên các mẫu MacBook Pro mới nhất dùng Apple Silicon cao cấp, trong khi trải nghiệm trên Chrome hoặc các trình duyệt khác tốt hơn nhiều

Nguyên nhân và phân tích

• Người dùng Safari 18.6 (cùng các bản beta/Tech Preview) cùng báo cáo chung về vấn đề này
• Một số người dùng cho biết tình trạng suy giảm hiệu năng đặc biệt nghiêm trọng chỉ trên GitHub, chứ không phải trên Safari nói chung
• Việc sử dụng nhiều CSS selector và transform: translateY được mô tả là xung đột trực tiếp với giới hạn xử lý lớp GPU của Safari
  • Frontend của GitHub đặt mọi dòng văn bản bằng transform: translateY, khiến Safari phải tạo ra hàng nghìn lớp GPU
  • Chrome tối ưu việc tạo layer khi không có các animation kiểu này, nên cho hiệu năng đỡ chậm hơn tương đối
  • Giải pháp tạm thời là áp dụng script loại bỏ thuộc tính transform, giúp tăng tốc nhưng độ chính xác vị trí không hoàn hảo

Trải nghiệm người dùng và các báo cáo khác nhau

• Nhiều người dùng than phiền rằng trong PR, mọi tương tác như thêm reviewer, thêm nhãn, sửa mô tả PR đều bị trễ hơn vài giây
• Khi truy cập bằng Safari, UI của trình duyệt mã và tính năng tự động hoàn thành (thanh tìm kiếm, command palette, v.v.) trở nên rất chậm
• Trên iOS Safari, cũng có trường hợp ngay cả các tính năng trình duyệt như nút quay lại gốc cũng không hoạt động bình thường
• Xét về khả năng truy cập (VoiceOver), hiệu năng cũng giảm mạnh, dẫn đến tình trạng người dùng khiếm thị gần như không thể sử dụng

Thảo luận về cách khắc phục và ứng phó

• Phía WebKit (engine của Safari) gần đây đã triển khai một phần bản vá cho vấn đề hiệu năng CSS/compositor liên quan, nhưng rất khó khắc phục ngay trước bản phát hành Safari tiếp theo
• Có đề cập rằng cần chủ động đề xuất cách xử lý lỗi và trao đổi sớm về vấn đề hiệu năng với các kỹ sư GitHub trước khi bản Safari tiếp theo được phát hành
• Nhiều thay đổi UI frontend khác nhau (ví dụ: UI thay đổi tệp trong PR, các tính năng mới, v.v.) được xem là có liên hệ trực tiếp với sự suy giảm hiệu năng
• Một số người dùng chuyển hướng sử dụng Graphite.dev, GitLab hoặc bộ định tuyến giao thức tùy chỉnh (ví dụ: Finicky, Velja, v.v.) để né tránh hoặc dùng UI thay thế

Bình luận khác và mẹo từ người dùng thực tế

• Một cách lách tạm thời là sau khi tạo issue/PR trên Safari, nên dùng tính năng thêm nhãn theo kiểu bảng
• Cũng có những ý kiến bày tỏ lo ngại về CSS quá phức tạp, thay đổi trong cấu trúc kỹ thuật, xu hướng chỉ tối ưu cho Chrome, và nhấn mạnh sự cần thiết phải hỗ trợ nhiều trình duyệt
• Một số người dùng để lại bình luận chỉ trích hoặc hài hước về vấn đề hiệu năng (cần tránh tranh cãi cảm tính không cần thiết trong thảo luận)
• Có cả ý kiến nội bộ và bên ngoài cho rằng cần xem lại cách phát triển frontend cần tối ưu hiệu năng, cũng như tầm quan trọng của việc kiểm thử đa trình duyệt

Kết luận

• Những thay đổi gần đây trong cấu trúc UI của GitHub và cách dùng CSS đang xung đột với đặc tính render riêng của Safari, gây ra bất tiện nghiêm trọng trên một nền tảng cộng tác tiêu chuẩn của ngành
• Cần có nỗ lực cải thiện tích cực từ cả WebKit lẫn GitHub, và trong ngắn hạn cần ưu tiên ứng phó theo hướng lấy người dùng Safari và người dùng cần trợ năng làm trung tâm
• Đây là vấn đề hiệu năng nghiêm trọng đến mức ảnh hưởng trực tiếp tới công việc phát triển, khiến sự đồng cảm lẫn sự phẫn nộ trong cộng đồng tăng mạnh

[GN⁺]

Ý kiến trên Hacker News

• Website của Github nhìn chung chỗ nào cũng chậm. Khó có thể xem đây là phần mềm tốt xét về hiệu năng hay UX/UI, và tạo cảm giác như một sản phẩm được ghép lại từ KPI và kế hoạch của nhiều người. Bản thân việc nó là một mạng xã hội cho lập trình viên có lẽ là phần “đổi mới” nhất, còn với công việc phát triển hằng ngày thì lại quá tầm thường đến mức khiến người ta cảm thấy Gitlab tốt hơn hẳn. Vấn đề này không phải do Rails, và tôi không nghĩ việc khoác lên nó một lớp vỏ công nghệ để né tránh bản chất là đúng đắn

  • Vấn đề của Github không phải Rails mà là vì họ chuyển sang React. Github trước đây dựa trên SSR thực sự rất nhanh, và có thể review cả các PR rất lớn mà không gặp vấn đề gì
  • Sau vài năm không dùng Github, năm nay quay lại tôi thực sự sốc vì nó đã chậm đi đến mức nào. Sự chậm chạp ở mỗi lần tương tác buộc tôi phải thay đổi toàn bộ cách sử dụng. Lúc nào cũng có cảm giác có gì đó không ổn, và nếu vài giây không có phản hồi thì lại thấy bất an như thể máy chủ đã treo
  • Sau 10 năm dùng Phabricator rồi chuyển sang Github, tôi bối rối vì chênh lệch chất lượng quá lớn và khó tin đây lại là tiêu chuẩn. Thật đáng tiếc khi Phabricator giờ chỉ còn được bảo trì Wiki Phabricator
  • Github trước đây thực sự rất mượt, nhưng từ sau khi chuyển sang SPA thì trở nên ngột ngạt, ì ạch
  • Tôi từng có trải nghiệm một CTO luôn đổ nguyên nhân xuống cấp hiệu năng của ứng dụng legacy cho Rails và đòi viết lại toàn bộ bằng Java. Thực ra căn nguyên là kết quả tích lũy của những PM kém năng lực, lãnh đạo yếu và các lập trình viên thiếu kinh nghiệm. Nếu một dự án bị quản lý sai trong hơn 10 năm thì dùng stack nào kết quả cũng vậy

• Nhóm WebKit đã áp dụng bản cải thiện cho vấn đề hiệu năng của Github trong 2 ngày qua liên kết liên quan. Trong nhóm họ thậm chí còn tạo các PR khổng lồ (hơn 1000 file), và đồng nghiệp thường nói kiểu “khi nào mở được thì tôi sẽ duyệt” trong lúc chờ PR tải xong

  • Ai cũng nói JS và React là vấn đề, nhưng thực tế bản vá lần này lại liên quan đến hiệu năng CSS
  • Trong bối cảnh Chrome và các trình duyệt phái sinh gần như thống trị engine render, và Firefox dạo này tăng trưởng chậm lại, thật đáng mừng khi Apple vẫn có những thay đổi để giữ Safari cạnh tranh trên macOS/iOS
  • Tôi tò mò cụ thể PR có hơn 1000 file là loại công việc gì
  • Thực ra đây là một lỗi lộ ra khi Github gây tải quá mức lên Safari WebKit. Là nhà phát triển hay người dùng, chúng ta rất dễ chỉ đổ lỗi cho Github về nguyên nhân
  • Tôi muốn biết phải mất bao lâu để người dùng thực sự nhận được bản vá WebKit. Với Safari thì có phải đợi cập nhật OS không, hay tốc độ cập nhật nhanh như Chrome/Firefox?

• Ngay sau khi Microsoft mua lại Github, Github gần như lập tức chuyển sang kiểu render bằng JavaScript (SPA). Trước đây trên Mac Mini 2011, ngay cả khi tắt JavaScript vẫn có thể duyệt Github, còn hiện tại thì dù bật JS cũng không thể dùng Github do vấn đề tương thích với trình duyệt cũ. Khó nói bên nào đáng trách hơn, nhưng tôi nghĩ cả hai phía đều có trách nhiệm. Có thể đổi sang thiết bị mới hơn, nhưng trong bối cảnh người ta cố tình từ bỏ hỗ trợ thiết bị cũ và áp đặt planned obsolescence thay vì ưu tiên tính bền vững về lâu dài, tôi có cảm giác ngay cả niềm tin vào tiêu chuẩn web cũng đang lung lay

  • Nếu hôm nay mới biết thì bạn có thể dùng OpenCore Legacy Patcher để nâng macOS lên bản mới nhất cho cả những máy Mac từ năm 2007 liên kết OpenCore Legacy Patcher
  • Tôi tò mò liệu cài Chrome hay Firefox để dùng có phải là một lựa chọn tốt không
  • Tôi thắc mắc vì sao Turing completeness lại nghe như một lời nói dối. Không chỉ có planned obsolescence, mà môi trường phần mềm hiện đại còn có quá nhiều lớp trừu tượng. Nếu mọi phần mềm đều phải viết bằng C thì thế giới bây giờ hẳn đã rất khác. Có cảm giác chúng ta đã sa vào mức trừu tượng quá cao, nhưng đã đi đến đây thì khó mà quay lại. Bản thân Turing completeness gần như không liên quan đến điều này, mà ngược lại kết quả của nó là đòi hỏi tiêu tốn tài nguyên nhiều hơn
  • Cần nhấn mạnh rằng Turing completeness không liên quan đến hiệu năng. Về lý thuyết, thậm chí có thể mô phỏng thiết bị mới nhất trên thiết bị hiện tại
  • Có người không hài lòng vì OS của Mac Mini 2011 đã ngừng được hỗ trợ, nhưng tôi nghĩ dùng Internet bằng trình duyệt đã hơn 8 năm tuổi cũng gần giống như mở toang mọi cửa trong nhà xét về mặt bảo mật

• Có nhiều chỉ trích nhắm vào React, nhưng vấn đề lần này là lỗi CSS transform. Tôi khuyên nên đọc kỹ nội dung ở liên kết liên quan

• Tôi khuyên nên chuyển sang Forgejo, Codeberg, SourceHut. So với Github và Gitlab thì chúng nhanh như chớp Forgejo / Codeberg / SourceHut

  • Tôi từng chạy máy chủ Forgejo trên một đường truyền tệ hại (mức kilobit mỗi giây) suốt vài tuần mà nó vẫn trụ khá tốt. Push/pull vẫn xoay xở hoạt động được, nhưng actions thì vất vả vì cần truyền hơn 100MB

• Tôi thắc mắc tại sao trong các tổ chức lớn những vấn đề như vậy cứ lặp đi lặp lại. Hẳn họ phải phát hiện rõ vấn đề hiệu năng trong các bài test trên những trình duyệt chính, nên thật khó hiểu khi lại có ai đó phê duyệt cho triển khai bằng mọi giá

  • Hiện ngành IT có ba nhóm: 1) PM ép ra mắt vô lý và chỉ coi trọng tốc độ. 2) Lập trình viên phản đối các yêu cầu này, liên tục tiêu hao vốn chính trị và bị burnout. 3) Nhóm lập trình viên thờ ơ với mọi thứ, chỉ máy móc làm phần việc được giao. Cuối cùng vấn đề nằm ở chính văn hóa, và nếu không cải tổ toàn diện từ cấp C-level thì sẽ không thay đổi được. Phần lớn lãnh đạo không có ý chí để làm điều đó
  • Khi quyết định stack công nghệ ở tổ chức lớn, tiêu chí quan trọng nhất là “tuyển và sa thải có dễ không”. Lập trình viên React thì nhiều, còn Rails khó tìm hơn. Ý kiến của kỹ sư bị phớt lờ, nhu cầu tổ chức được đặt lên trước, và điều đó dẫn đến dịch vụ chậm chạp cùng chất lượng tệ. Lập trình viên cũng biết vấn đề, nhưng sống sót mới là ưu tiên
  • Nếu trước đây có câu “mua IBM thì sẽ không bị sa thải”, thì giờ không khí là “không dùng React thì sẽ bị sa thải”. Vì ai cũng dùng React nên ngay cả Github cũng cứ tiếp tục chậm đi. Lập trình viên tệ sẽ chỉ chạy theo những gì người khác dùng, còn lập trình viên giỏi sẽ chọn công cụ đơn giản nhất theo nguyên tắc KISS
  • Trong các tổ chức lớn, “quyền sở hữu” trở nên mơ hồ và do tỷ lệ thay người cao cùng mục tiêu ngắn hạn, các vấn đề kiểu này luôn lặp lại. Áp lực thêm tính năng và nợ kỹ thuật cứ chồng chất, còn tinh thần trách nhiệm thì biến mất. Nếu nêu vấn đề ra thì ngược lại còn dễ phát sinh xung đột và bị đẩy vào kế hoạch cải thiện hiệu suất

• Là một lập trình viên React, nhìn thread này tôi cảm nhận rõ sự căm ghét của thế giới. Có rất nhiều cạm bẫy của SPA: lịch trình phi thực tế, rồi cả logic backend cũng bị đẩy sang frontend. Tôi tự hỏi liệu React bản thân nó có phải là lựa chọn sai không, hay có những ứng dụng React thực sự được làm tốt

  • Tôi từng là fan cuồng nhiệt của React/SPA trong thời gian dài, nhưng dần nhận ra việc phát triển giờ thậm chí còn khó hơn cả thời làm ứng dụng desktop C++ MFC. Người ta nói declarative markup giúp giảm gánh nặng nhận thức, nhưng thực tế độ phức tạp của UI khai báo cùng quản lý event/state lại tăng lên, khiến nó còn phức tạp hơn cả thời viết theo kiểu thủ tục. Mã C++ ngày xưa thậm chí còn dễ hiểu hơn React hook
  • Dù có nhiều phê phán với SPA, vẫn có những ứng dụng React/Angular được làm rất tốt. Ví dụ: Clockify. Với các ứng dụng có vấn đề, tôi cũng không nghĩ chỉ cần render bằng SSR thì UX sẽ đột nhiên tốt lên. Nguyên nhân thực sự là bầu không khí tổ chức chỉ quan tâm phát hành tính năng nhanh hơn chất lượng
  • Những công nghệ như thế này chỉ bị soi khi hiệu năng không tốt. Vì ai cũng dùng công nghệ web hằng ngày nên rất dễ chê bai. Đặc biệt đây còn là loại công nghệ được nhiều lập trình viên mới vào nghề sử dụng, nên càng bị chỉ trích nhiều hơn. Đây là một ví dụ điển hình của việc làm mờ ranh giới
  • Vấn đề không nằm ở React mà là ở cách lập trình viên dùng nó. Dù có vô số kỹ thuật tối ưu, nếu móc nối sai thì vẫn có thể dẫn tới tình trạng phản hồi click mất tới 1,3 giây
  • Bản thân React không tệ, vấn đề thường nằm ở chỗ cấu trúc SPA có những điểm bất ổn. React chỉ đơn giản là công cụ giúp việc dùng SPA trở nên dễ dàng hơn

• Có cảm giác mọi thứ trong toàn bộ lĩnh vực điện toán đều chậm đi. Dù dùng Mac Studio M4 Max mới nhất với 64GB RAM, mọi website vẫn chậm hơn so với thời MacBook Pro 2011

  • Khi dùng Internet 15 năm trước, đúng là có chậm hơn theo một nghĩa nào đó, nhưng khi đó chúng ta không dùng các bảng tính hay công cụ thiết kế phức tạp trên web. Mac dòng M là những máy tính nhanh nhất tôi từng dùng cho tới nay (trừ desktop Linux)
  • Tôi nghĩ các lập trình viên web nên phát triển trên những thiết bị thuộc nhóm 10% thấp nhất về cấu hình của người dùng. Hoặc cũng có thể xem hiệu năng như một tiêu chí WCAG (khả năng truy cập web)

• Tôi thường nghe trên HN rằng Github chậm đi vì họ migrate UI sang React, nhưng không biết có thực sự như vậy không. Với các dự án nhỏ thì tôi chưa thấy ảnh hưởng, nên muốn tìm bằng chứng rõ ràng hơn

  • Một bài blog tôi đọc gần đây giải thích nguyên nhân khá tốt. Tóm lại, ở màn hình PR có hơn 100.000 DOM node được render, và một phần đáng kể trong đó là các SVG node không hề hiển thị. Phân tích cũng cho rằng điều hướng chậm hơn nhiều do SPA routing blog liên quan / thảo luận HN
  • Có vẻ trang diff PR gần đây được redesign lại nên DOM còn phình to hơn

• Không chỉ Safari, Github còn cực kỳ chậm cả trên Firefox; spinner tải xuất hiện khắp nơi và chuyển trang cũng lâu hơn trước. Tôi thật sự không hiểu họ đã dựa vào chỉ số nào để thay SSR vốn hoạt động hoàn hảo bằng SPA

  • Gần đây trên Chrome cũng có vấn đề tương tự. Cả ba trình duyệt đều đang ở tình trạng hoạt động không ổn, ngay cả khi PR không lớn lắm