Situs web GitHub berjalan lambat di Safari

• Dalam beberapa bulan terakhir, kecepatan situs web GitHub di browser Safari makin menurun
• Pada PR berukuran besar atau file kode dengan ribuan baris, rendering layar praktis menjadi mustahil
• Terjadi penggunaan 100% pada proses rendering browser, layar kosong saat menggulir, serta latensi parah pada fitur pencarian dan komentar
• Perubahan CSS dan penggunaan transform berbenturan dengan bug performa Safari dan memicu masalah ini, sementara browser lain seperti Chrome relatif lebih baik
• Beberapa patch performa sudah diterapkan di WebKit, tetapi disebutkan bahwa hingga rilis Safari berikutnya, tim frontend GitHub perlu menyiapkan penanganan sementara

---

Latar belakang dan masalah utama

• Belakangan ini, penurunan performa secara menyeluruh makin menonjol saat mengakses situs web GitHub lewat browser Safari
• Terutama saat melihat perubahan dengan ribuan baris atau lebih di Pull Request (PR) atau menjelajahi file kode berukuran besar, kondisinya mencapai titik di mana rendering itu sendiri nyaris tidak mungkin dilakukan
• Di Activity Monitor, proses rendering memakan 100% CPU, dan kecepatan render halaman begitu lambat hingga saat menggulir, layar tampak sebagai ruang kosong
• Fitur interaktif seperti pencarian dan komentar mengalami jeda parah, dan bahkan mengklik kotak centang saat review PR bisa memakan waktu beberapa detik atau lebih
• Masalah yang sama terjadi bahkan di MacBook Pro terbaru dengan Apple Silicon kelas atas, sementara saat memakai Chrome atau browser lain pengalamannya jauh lebih baik

Penyebab dan analisis masalah

• Keluhan yang sama datang dari pengguna Safari versi 18.6 (serta beta/Tech Preview)
• Seorang pengguna menyebut bahwa penurunan performa yang sangat parah ini terjadi secara khusus di GitHub, bukan di Safari secara umum
• Penggunaan besar-besaran selector CSS dan transform: translateY dijelaskan berbenturan langsung dengan batas pemrosesan layer GPU Safari
  • Karena frontend GitHub menempatkan setiap baris teks dengan transform: translateY, Safari akhirnya membuat ribuan layer GPU
  • Chrome mengoptimalkan pembuatan layer saat animasi seperti itu tidak ada, sehingga performanya relatif tidak separah itu
  • Sebagai solusi sementara, menerapkan skrip untuk menghapus properti transform dapat mempercepat kinerja, tetapi ketepatan posisinya tidak sempurna

Pengalaman pengguna dan berbagai laporan

• Banyak pengguna mengeluhkan bahwa semua interaksi di PR, seperti menambahkan reviewer atau label dan mengubah deskripsi PR, tertunda beberapa detik atau lebih
• Saat diakses lewat Safari, UI code browser dan autocomplete (seperti bilah pencarian dan command palette) menjadi sangat lambat
• Di iOS Safari, ada juga kasus di mana fungsi browser seperti tombol native kembali tidak bekerja dengan benar
• Dari sisi aksesibilitas (VoiceOver), penurunan performanya juga sangat parah, sampai-sampai pengguna tunanetra nyaris tidak bisa menggunakannya

Diskusi solusi dan penanganan

• Dari pihak WebKit (engine Safari), baru-baru ini sudah ada beberapa patch untuk masalah performa CSS/compositor terkait, tetapi perbaikan langsung dinilai sulit sebelum rilis Safari berikutnya
• Disebutkan perlunya mengusulkan penanganan bug kepada engineer GitHub sebelum rilis Safari berikutnya dan melakukan komunikasi lebih awal terkait isu performa
• Berbagai perubahan UI frontend (misalnya UI perubahan file PR, fitur baru, dan sebagainya) dinilai berkaitan langsung dengan penurunan performa
• Sebagian pengguna memilih jalan memutar atau UI alternatif melalui Graphite.dev, GitLab, atau custom protocol router (misalnya Finicky, Velja, dan lain-lain)

Komentar lain dan tips pengguna nyata

• Sebagai jalan memutar sementara, ada saran untuk membuat issue/PR di Safari lalu menggunakan fitur penambahan label berbasis tabel
• Ada juga suara yang menyoroti perlunya dukungan untuk berbagai browser, serta kekhawatiran terhadap CSS yang terlalu kompleks dan perubahan struktur engineering yang terlalu berpusat pada Chrome
• Sebagian pengguna menambahkan komentar kritis atau bernada humor tentang masalah performa ini (perdebatan emosional yang tidak perlu patut dihindari dalam diskusi)
• Muncul pendapat internal maupun eksternal tentang perlunya meninjau ulang pendekatan pengembangan frontend yang membutuhkan optimasi performa dan pentingnya pengujian lintas browser

Kesimpulan

• Perubahan terbaru pada struktur UI GitHub dan cara pemakaian CSS berbenturan dengan karakteristik rendering khas Safari, sehingga menimbulkan ketidaknyamanan browser yang serius pada platform kolaborasi standar industri ini
• Diperlukan kemauan perbaikan yang aktif dari WebKit maupun GitHub, dan penanganan yang berfokus pada pengguna Safari serta aksesibilitas dibutuhkan dalam jangka pendek
• Ini adalah masalah performa yang cukup parah hingga mengganggu pekerjaan pengembangan, sehingga memicu empati sekaligus kemarahan besar di komunitas

[GN⁺]

Komentar Hacker News

• Situs web GitHub memang cenderung lambat di mana-mana. Dari sisi performa maupun UX/UI, ini sulit disebut sebagai perangkat lunak yang bagus, dan terasa seperti hasil dari tumpukan KPI serta perencanaan banyak orang. Bahwa ini adalah jejaring sosial untuk developer mungkin justru bagian yang paling “inovatif”, sementara untuk pekerjaan pengembangan sehari-hari terasa terlalu biasa sampai-sampai GitLab terasa jauh lebih baik. Masalah ini bukan karena Rails, dan menurut saya tidak tepat membungkusnya sebagai isu teknologi untuk menghindari inti persoalan

  • Masalah GitHub bukan Rails, melainkan karena berpindah ke React. GitHub lama yang berbasis SSR benar-benar cepat, dan review PR berukuran besar pun tidak bermasalah
  • Setelah beberapa tahun tidak memakai GitHub lalu mencobanya lagi tahun ini, saya benar-benar kaget melihat betapa melambatnya. Setiap interaksi terasa lambat sampai saya harus mengubah seluruh cara memakainya. Terus ada perasaan ada yang tidak beres, dan kalau tidak ada respons selama beberapa detik, rasanya seperti servernya macet
  • Setelah 10 tahun memakai Phabricator lalu pindah ke GitHub, saya kaget dengan perbedaan kualitasnya dan sulit percaya bahwa ini adalah standar. Sayang sekali Phabricator sekarang hanya dipelihara dalam mode maintenance Wiki Phabricator
  • Dulu GitHub benar-benar nyaman dipakai, tapi sejak berubah menjadi SPA jadi terasa menyebalkan
  • Saya pernah punya CTO yang selalu menyalahkan Rails sebagai penyebab penurunan performa aplikasi legacy dan ingin menulis ulang semuanya ke Java. Padahal akar masalahnya adalah akumulasi ketidakmampuan perencana, manajemen, dan developer yang kurang berpengalaman. Kalau proyek salah dikelola lebih dari 10 tahun, hasilnya akan sama dengan stack apa pun

• Tim WebKit telah menerapkan perbaikan isu performa GitHub dalam 2 hari terakhir tautan terkait. Tim mereka juga pernah membuat PR berskala besar, lebih dari 1000 file, dan rekan kerja sampai berkata, “Kalau sudah kebuka nanti saya approve” sambil menunggu PR-nya selesai dimuat

  • Semua orang bilang JS dan React yang jadi masalah, tetapi patch kali ini sebenarnya terkait performa CSS
  • Karena Chrome dan browser turunannya pada praktiknya sudah menguasai rendering engine, di saat pertumbuhan Firefox belakangan melambat, saya senang melihat perubahan dari Apple yang terus membuat Safari tetap kompetitif di macOS/iOS
  • Saya penasaran pekerjaan seperti apa yang secara spesifik menghasilkan PR dengan lebih dari 1000 file
  • Sebenarnya ini adalah bug yang terlihat karena GitHub memberi beban berlebihan pada Safari WebKit. Sebagai developer maupun pengguna, kita mudah menyalahkan GitHub saja sebagai penyebabnya
  • Saya penasaran berapa lama patch WebKit sampai ke pengguna nyata. Apakah Safari harus menunggu pembaruan OS, atau update-nya cukup cepat seperti Chrome/Firefox

• Begitu Microsoft mengakuisisi GitHub, GitHub hampir langsung beralih ke metode rendering JavaScript (SPA). Sebelumnya, di Mac Mini keluaran 2011 pun GitHub masih bisa dijelajahi walau JavaScript dimatikan, tetapi sekarang GitHub tidak bisa dipakai bahkan saat JS dinyalakan karena kompatibilitas browser lama. Sulit mengatakan mana yang lebih bermasalah, tetapi saya rasa kedua pihak sama-sama punya tanggung jawab. Saya memang bisa ganti ke perangkat terbaru, tetapi ketika dukungan untuk perangkat lama sengaja ditinggalkan dan planned obsolescence dipaksakan alih-alih fungsionalitas jangka panjang, rasanya kepercayaan pada standar web pun ikut runtuh

  • Kalau baru tahu hari ini, dengan OpenCore Legacy Patcher Anda bahkan bisa memperbarui macOS ke versi terbaru sampai untuk Mac keluaran 2007 tautan OpenCore Legacy Patcher
  • Bagaimana kalau memasang dan memakai Chrome atau Firefox?
  • Saya bertanya-tanya kenapa Turing completeness terasa seperti kebohongan. Planned obsolescence memang ada, tetapi lingkungan software modern juga punya terlalu banyak abstraksi. Kalau semua software harus ditulis dalam bahasa C, dunia sekarang pasti akan sangat berbeda. Kita tampaknya sudah terlalu tenggelam dalam abstraksi tingkat tinggi, tetapi karena sudah sampai sejauh ini, sulit untuk kembali. Turing completeness sendiri hampir tidak terkait dengan ini, dan justru akibatnya adalah kebutuhan konsumsi sumber daya yang lebih besar
  • Saya ingin menekankan bahwa Turing completeness tidak ada hubungannya dengan performa. Secara teori, perangkat saat ini bahkan bisa mengemulasikan perangkat yang lebih baru
  • Ada orang yang kecewa karena dukungan OS untuk Mac Mini 2011 dihentikan, tetapi menurut saya memakai internet dengan browser yang sudah lebih dari 8 tahun tidak diperbarui secara keamanan sama seperti membiarkan semua pintu rumah terbuka

• Banyak kritik diarahkan ke React, tetapi isu kali ini adalah masalah CSS transform. Saya sarankan benar-benar membaca isi tautan terkait

• Saya menyarankan migrasi ke Forgejo, Codeberg, atau SourceHut. Dibandingkan GitHub dan GitLab, mereka secepat kilat Forgejo / Codeberg / SourceHut

  • Saya pernah menjalankan server Forgejo selama beberapa minggu di koneksi rusak, tingkat kilobit per detik, dan tetap cukup bertahan. Push/pull masih bisa jalan entah bagaimana, tetapi actions sulit karena perlu transfer lebih dari 100MB

• Saya penasaran bagaimana masalah seperti ini bisa terus berulang di organisasi besar. Rasanya dalam pengujian browser utama mereka pasti sudah menemukan masalah performa yang jelas, jadi saya tidak paham apakah ada seseorang yang tetap memaksa memberi persetujuan

  • Saat ini industri TI terdiri dari tiga kelompok: 1) PM yang menekan rilis secara berlebihan dan hanya mementingkan kecepatan. 2) Developer yang menolak permintaan seperti ini, terus-menerus menghabiskan modal politik, lalu burnout. 3) Kelompok developer yang acuh terhadap semuanya dan hanya mengerjakan tugas secara mekanis. Pada akhirnya masalahnya ada pada budayanya, dan tidak akan berubah tanpa reformasi menyeluruh dari level C. Kebanyakan eksekutif tidak punya kemauan untuk mengubah ini
  • Saat organisasi besar menentukan stack teknologi, kriteria paling penting adalah “seberapa mudah merekrut dan memecat”. Developer React banyak, sedangkan Rails sulit dicari. Pendapat developer diabaikan, kebutuhan organisasi diutamakan, dan hasilnya layanan lambat serta kualitas buruk. Para developer pun tahu masalahnya, tetapi bertahan hidup adalah prioritas utama
  • Dulu ada ungkapan “tak akan dipecat karena membeli IBM”, sekarang suasananya seperti “kalau tidak pakai React, Anda yang akan dipecat”. Karena semua orang memakai React, bahkan GitHub pun terus mengalami kelambatan. Developer buruk mengikuti apa yang dipakai orang lain, sedangkan developer baik memilih alat paling sederhana sesuai prinsip KISS
  • Di organisasi besar, “kepemilikan” jadi kabur, tingkat pergantian orang tinggi, dan fokus pada target jangka pendek membuat masalah seperti ini terus terulang. Tekanan menambah fitur dan utang teknis terus menumpuk, sementara rasa tanggung jawab menghilang. Kalau mengangkat masalah, malah timbul konflik dan orang bisa didorong ke performance improvement plan

• Sebagai developer React, melihat thread ini membuat saya merasakan betapa besar kebencian dunia. Ada banyak jebakan dalam SPA, dari jadwal yang tidak realistis sampai logika backend yang ikut ditumpuk ke frontend. Saya jadi bertanya-tanya apakah React sendiri memang pilihan yang salah, atau adakah aplikasi React yang benar-benar dibuat dengan baik

  • Saya dulu penggemar berat React/SPA untuk waktu lama, tetapi makin lama saya sadar bahwa pengembangannya justru menjadi lebih sulit daripada zaman membuat aplikasi desktop C++ MFC. Katanya markup deklaratif mengurangi beban kognitif, tetapi kenyataannya UI deklaratif ditambah kompleksitas event/manajemen state malah lebih rumit daripada saat dulu mengembangkan secara prosedural. Kode C++ lama saya justru lebih mudah dipahami daripada React hook
  • Memang banyak kritik terhadap SPA, tetapi ada juga aplikasi React/Angular yang benar-benar dibuat dengan baik. Contohnya Clockify. Aplikasi yang bermasalah pun belum tentu UX-nya mendadak membaik hanya karena dirender dengan SSR. Penyebab sebenarnya adalah budaya organisasi yang hanya peduli pada rilis fitur cepat, bukan kualitas
  • Teknologi seperti ini biasanya hanya disorot saat performanya buruk. Semua orang memakai teknologi web setiap hari, jadi mudah untuk mencacinya. Terutama karena ini teknologi yang banyak dipakai developer pemula, jadinya makin sering jadi sasaran kritik. Ini contoh yang kuat dari boundary erosion
  • Masalahnya bukan pada React itu sendiri, melainkan developer yang memakainya dengan cara yang salah. Walaupun ada banyak optimasi, jika dirangkai dengan buruk, respons klik bisa sampai 1,3 detik
  • React sendiri tidak buruk, tetapi struktur SPA sering kali yang bermasalah secara arsitektural. React hanyalah alat yang mempermudah penggunaan SPA

• Dalam komputasi secara umum, rasanya semuanya jadi lebih lambat. Bahkan dengan Mac Studio M4 Max terbaru, RAM 64GB, semua situs web terasa lebih lambat dibanding zaman MacBook Pro 2011

  • Memang saat memakai internet 15 tahun lalu jelas terasa lebih lambat, tetapi waktu itu kita tidak memakai spreadsheet kompleks atau alat desain di web. Mac seri M adalah komputer tercepat yang pernah saya pakai sampai sekarang, kecuali desktop Linux
  • Menurut saya developer web seharusnya mengembangkan sambil mencoba perangkat yang spesifikasinya berada di sekitar 10% terbawah pengguna. Atau, performa itu sendiri bisa dijadikan bagian dari standar WCAG (aksesibilitas web)

• Saya sering mendengar di HN bahwa GitHub menjadi lambat setelah memigrasikan UI ke React, tetapi saya penasaran apakah memang benar begitu. Pada proyek kecil dampaknya tidak terasa, jadi saya ingin mencari dasar yang lebih pasti

  • Ada tulisan blog yang baru saya baca dan menjelaskan penyebabnya dengan baik. Ringkasnya, di tampilan PR dirender lebih dari 100 ribu node DOM, dan sebagian besar di antaranya adalah node SVG yang tidak terlihat. Analisisnya juga menyebut navigasi menjadi jauh lebih lambat karena routing SPA blog terkait / diskusi HN
  • Sepertinya halaman diff PR belakangan didesain ulang dan DOM-nya jadi makin membengkak

• Bukan hanya di Safari, di Firefox pun GitHub sangat lambat, spinner loading muncul di mana-mana, dan perpindahan halaman memakan waktu lebih lama daripada sebelumnya. Saya benar-benar tidak paham dengan metrik apa SSR yang tadinya bekerja sempurna itu sampai diganti menjadi SPA

  • Belakangan masalah serupa juga ada di Chrome. Di ketiga browser itu, bahkan PR yang tidak besar pun berada dalam kondisi tidak berfungsi dengan baik