GitHub web sitesi Safari’de yavaş çalışıyor

• Son birkaç ayda Safari tarayıcısında GitHub web sitesinin hızı giderek düştü
• Özellikle büyük PR’lerde veya binlerce satırlık kod dosyalarında ekranın render edilmesi fiilen imkânsız hale geldi
• Tarayıcının render sürecinin %100 kullanılması, kaydırma sırasında boş ekran görünmesi ve arama·yorum işlevlerinde ciddi gecikmeler yaşanıyor
• CSS değişiklikleri ve transform kullanımı, Safari’nin performans hatalarıyla çakışarak soruna yol açıyor; Chrome gibi diğer tarayıcılarda durum görece daha iyi
• WebKit tarafında bazı performans yamaları yapıldı, ancak Safari’nin bir sonraki sürümüne kadar GitHub frontend ekibinin geçici önlemler alması gerektiği belirtiliyor

---

Arka plan ve temel sorunlar

• Son dönemde Safari tarayıcısında GitHub web sitesine erişimde genel bir performans düşüşü belirgin hale geldi
• Özellikle Pull Request (PR) içinde binlerce satırı aşan değişiklikleri incelerken veya büyük kod dosyalarında gezinirken, render işlemi neredeyse yapılamaz hale geliyor
• Activity Monitor’da render süreci CPU’nun %100’ünü kullanıyor ve sayfa çok yavaş render edildiği için kaydırma sırasında ekran boş alan gibi görünüyor
• Arama, yorum gibi etkileşimli işlevlerde ciddi gecikmeler yaşanıyor; PR incelemesi sırasında bir onay kutusuna tıklamak bile birkaç saniyeden uzun sürebiliyor
• En yeni Apple Silicon’lu üst seviye MacBook Pro’larda da aynı durum görülüyor; Chrome veya diğer tarayıcılarda ise deneyim çok daha iyi

Sorunun nedeni ve analiz

• Safari 18.6 sürümü kullanıcılarından (ve beta/Tech Preview sürümlerinden) benzer şikâyetler geliyor
• Bazı kullanıcılar, Safari genelinde değil, özellikle yalnızca GitHub’da çok ciddi performans düşüşü yaşandığını belirtiyor
• CSS seçicileri ile transform: translateY kullanımının, Safari’nin GPU katmanı işleme sınırlarıyla doğrudan çakıştığı ifade ediliyor
  • GitHub frontend’i tüm metin satırlarını transform: translateY ile konumlandırınca Safari binlerce GPU katmanı oluşturmak zorunda kalıyor
  • Chrome ise bu tür animasyonlar olmadığında katman oluşturmayı optimize ederek görece daha az yavaşlıyor
  • Geçici çözüm olarak transform özelliğini kaldıran bir betik uygulandığında hız artsa da konum hassasiyeti mükemmel olmuyor

Kullanıcı deneyimi ve farklı bildirimler

• Birçok kullanıcı, PR’de reviewer·etiket ekleme, PR açıklamasını düzenleme gibi tüm etkileşimlerin birkaç saniyeden fazla geciktiğini söylüyor
• Safari’de kod tarayıcısı ve otomatik tamamlama (arama çubuğu, komut paleti vb.) arayüzü çok yavaş çalışıyor
• iOS Safari’de geri gitme yerel düğmesi gibi tarayıcı işlevlerinin bile düzgün çalışmadığı örnekler var
• Erişilebilirlik (VoiceOver) açısından da performans düşüşü çok ciddi; görme engelli kullanıcılar için kullanım neredeyse imkânsız hale gelmiş durumda

Çözüm ve alınan önlemler üzerine tartışmalar

• WebKit (Safari motoru) tarafında ilgili CSS/compositor performans sorununun bazı kısımlarına yönelik yamalar yakın zamanda uygulanmış olsa da, Safari’nin bir sonraki sürümünden önce sorunun hemen çözülmesi zor görünüyor
• GitHub mühendisleri için, Safari’nin sonraki sürümünden önce hataya yönelik önlem alma ve performans sorunları hakkında önceden iletişim kurma gerekliliğinden söz ediliyor
• Çeşitli frontend arayüz değişikliklerinin (ör. PR dosya değişikliği arayüzü, yeni özellikler vb.) performans düşüşüyle doğrudan bağlantılı olduğu düşünülüyor
• Bazı kullanıcılar Graphite.dev, GitLab veya özel protokol yönlendiricileri (ör. Finicky, Velja vb.) üzerinden geçici çözüm ya da alternatif arayüz kullanıyor

Diğer yorumlar ve pratik kullanıcı ipuçları

• Geçici bir kaçış yolu olarak, Safari’de issue/PR oluşturduktan sonra tablo tabanlı etiket ekleme işlevinin kullanılması öneriliyor
• Aşırı karmaşık CSS, mühendislik yapısındaki değişimler ve Chrome’a aşırı odaklanma konusundaki kaygılar dile getiriliyor; çoklu tarayıcı desteğinin önemi vurgulanıyor
• Bazı kullanıcılar performans sorununa eleştirel ya da mizahi yorumlar ekliyor (gereksiz duygusal tartışmalara karşı dikkat çağrısı yapılıyor)
• Performans optimizasyonu gerektiren frontend geliştirme yaklaşımının yeniden değerlendirilmesi ve çoklu tarayıcı testlerinin önemi konusunda hem içeriden hem dışarıdan görüşler paylaşılıyor

Sonuç

• GitHub’ın son dönemdeki arayüz yapısı değişiklikleri ve CSS kullanım biçimi, Safari’nin kendine özgü render özellikleriyle çakışarak sektör standardı bir iş birliği platformunda ciddi tarayıcı sorunlarına yol açıyor
• Hem WebKit’in hem de GitHub’ın daha kararlı iyileştirmeler yapması gerekiyor; kısa vadede Safari ve erişilebilirlik kullanıcılarını merkeze alan bir müdahale gerekli
• Geliştirme işini aksatacak düzeydeki bu performans sorunu, topluluk içinde geniş bir ortak tepki ve öfke yaratmış durumda

[GN⁺]

Hacker News görüşleri

• Github web sitesi genel olarak her yerde yavaş. Performans, UX/UI, her açıdan iyi bir yazılım demek zor; birçok kişinin KPI’ı ve planlamasının içine girdiği bir ürün gibi duruyor. Geliştiriciler için sosyal ağ olması zaten en “yenilikçi” tarafı ve günlük geliştirme işlerinde o kadar sıradan kalıyor ki Gitlab’in çok daha iyi olduğunu düşündürüyor. Bu sorun Rails yüzünden değil; meseleyi teknolojiyle ambalajlayıp özünden kaçmak doğru değil

  • Github’ın sorunu Rails değil, React’e geçilmiş olması. Eskiden SSR tabanlı Github gerçekten hızlıydı ve büyük PR’lar bile sorunsuz incelenebiliyordu
  • Birkaç yıl Github kullanmadıktan sonra bu yıl tekrar deneyince ne kadar yavaşladığına gerçekten şaşırdım. Her etkileşimdeki yavaşlık yüzünden tüm kullanım alışkanlıklarımı değiştirmek zorunda kaldım. Sürekli bir şeylerin yanlış olduğu hissi oluşuyor; birkaç saniye tepki gelmeyince sanki sunucu çökmüş gibi bir tedirginlik başlıyor
  • 10 yıl Phabricator kullandıktan sonra Github’a geçince kalite farkı yüzünden afalladım ve bunun standart kabul edilmesine inanmak zor. Phabricator’ın artık sadece bakım modunda olması üzücü Phabricator wiki
  • Github eskiden gerçekten akıcıydı, ama SPA’ye geçtikten sonra hantallaştı
  • Eskiden bir CTO’nun eski bir uygulamadaki performans düşüşünü otomatik olarak Rails’e bağlayıp her şeyi Java ile yeniden yazmak istemesine tanık olmuştum. Oysa asıl neden, beceriksiz planlamacılar, yönetim ve deneyimsiz geliştiricilerin yıllar içinde biriken etkisiydi. 10 yılı aşkın süredir kötü yönetilmiş bir projede hangi stack’i seçerseniz seçin sonuç aynı olur

• WebKit ekibi son 2 günde Github performans sorununu iyileştiren bir değişiklik uyguladı ilgili bağlantı. Ekip içinde 1000’den fazla dosya içeren büyük PR’lar da açılıyormuş; ekip arkadaşları PR yüklenene kadar bekleyip “açılınca onaylarım” diyormuş

  • Herkes JS ve React’i suçluyor ama bu seferki yama aslında CSS performansıyla ilgili
  • Chrome ve türevleri render motoru alanını fiilen ele geçirmiş durumda; Firefox’un büyümesinin de yavaşladığı bir dönemde Apple’ın macOS/iOS üzerinde Safari’yi rekabetçi tutmaya devam etmesi sevindirici
  • 1000’den fazla dosya içeren bir PR’ın somut olarak nasıl bir iş olduğunu merak ediyorum
  • Aslında bu, Github’ın Safari WebKit’e aşırı yük bindirmesiyle ortaya çıkan bir hataydı. Geliştirici ya da kullanıcı olarak bizler nedeni sadece Github’a bağlamaya çok yatkınız
  • WebKit yamasının gerçek kullanıcılara ulaşması ne kadar sürer merak ediyorum. Safari için OS güncellemesini beklemek mi gerekiyor, yoksa Chrome/Firefox gibi daha hızlı mı güncelleniyor?

• Microsoft Github’ı satın alır almaz Github neredeyse hemen JavaScript render yaklaşımına (SPA) geçti. Önceden 2011 model bir Mac Mini’de JavaScript kapalıyken bile Github’da gezilebiliyordu; şimdi ise JS açık olsa bile eski tarayıcı uyumluluğu yüzünden Github kullanılamıyor. Hangisinin daha büyük sorun olduğunu söylemek zor ama iki tarafın da payı var diye düşünüyorum. Daha yeni bir cihaza geçilebilir elbette, ama eski cihaz desteğinin bilerek bırakılması ve gelecekteki işlevsellikten çok planned obsolescence dayatılması yüzünden web standartlarına olan güven bile sarsılıyor gibi

  • Bunu bugün ilk kez öğrenenler için: OpenCore Legacy Patcher ile 2007 model Mac’lere kadar macOS’un en güncel sürümü kurulabiliyor OpenCore Legacy Patcher bağlantısı
  • Chrome ya da Firefox kurup kullanmak nasıl olur diye merak ediyorum
  • Turing completeness neden bir yalan gibi hissettiriyor diye düşünüyorum. Planned obsolescence var ama modern yazılım dünyasında asıl sorun aşırı soyutlama katmanları. Eğer tüm yazılımlar C ile yazılmak zorunda olsaydı bugün çok farklı bir dünyada olurduk. Fazla yüksek soyutlama seviyelerine saplanmış gibiyiz; ama artık buraya geldiğimiz için geri dönmek zor. Turing completeness’in kendisinin bununla pek ilgisi yok, ama sonuç olarak daha fazla kaynak tüketimi talep ediyor
  • Turing completeness’in performansla ilgisi olmadığını özellikle vurguluyorum. Teorik olarak bugünkü bir cihaz üzerinde en yeni cihazı emüle etmek bile mümkün
  • 2011 Mac Mini için OS desteğinin kesilmesine kızanlar var ama 8 yıldan eski bir tarayıcıyla internete çıkmak güvenlik açısından evin tüm kapılarını açık bırakmaya benziyor diye düşünüyorum

• React’e çok eleştiri var ama bu olay CSS transform sorunuyla ilgili. İlgili bağlantıdaki içeriği gerçekten okumayı tavsiye ederim

• Forgejo, Codeberg ve SourceHut’a geçmeyi öneririm. Github ve Gitlab’a kıyasla yıldırım gibi hızlılar Forgejo / Codeberg / SourceHut

  • Forgejo sunucusunu bozuk bir hat üzerinde (saniyede kilobit seviyesinde) haftalarca çalıştırdım, yine de oldukça iyi dayandı. Push/pull bir şekilde çalışıyordu ama Actions tarafı 100MB’tan fazla aktarım istediği için zorlandı

• Büyük organizasyonlarda bu tür sorunların nasıl tekrar tekrar yaşandığını merak ediyorum. Ana tarayıcı testlerinde performans problemlerinin kesin görülmüş olması gerekir; birinin yine de zorla onay vermiş olmasını anlamakta zorlanıyorum

  • Bugünkü IT sektöründe üç grup var: 1) PM’ler mantıksız teslim baskısı yapıyor ve sadece hıza odaklanıyor. 2) Geliştiriciler bu taleplere itiraz ederken sürekli siyasi sermaye harcıyor ve tükeniyor. 3) Her şeye kayıtsız kalıp verilen işi mekanik şekilde yapan geliştirici grubu. Sonuçta sorun kültürel; C-level düzeyinde köklü reform olmadan değişmez. Çoğu yönetici de bunu değiştirmek istemiyor
  • Büyük organizasyonlarda teknoloji stack’i seçerken en önemli ölçüt “işe alıp çıkarmanın ne kadar kolay olduğu”. React geliştiricisi çok, Rails bilen bulmak daha zor. Geliştiricilerin görüşü göz ardı ediliyor, organizasyonun ihtiyacı öne çıkıyor ve sonuç yavaş hizmetler ile kötü kalite oluyor. Geliştiriciler de sorunu biliyor ama önce hayatta kalmaya bakıyor
  • Eskiden “IBM alırsan işten atılmazsın” denirdi; şimdi de “React kullanmazsan işten atılırsın” gibi bir hava var. Herkes React kullandığı için Github bile yavaşlıyor. Kötü geliştirici başkalarının kullandığını takip eder; iyi geliştirici ise KISS ilkesine göre en basit aracı seçer
  • Büyük organizasyonlarda “sahiplik” bulanıklaşıyor; yüksek devir hızı ve kısa vadeli hedefler yüzünden bu sorunlar hep tekrarlanıyor. Özellik ekleme baskısı ve teknik borç birikiyor, sorumluluk duygusu kayboluyor. Sorunları dile getirince ise çatışma çıkıyor ve insan kendini performans iyileştirme planının içinde buluyor

• Bir React geliştiricisi olarak bu başlığı okurken dünyanın nefretini hissediyorum. Gerçek dışı takvimler ve backend mantığını da frontend’e yığan SPA tuzakları çok fazla. React’in kendisi mi yanlış bir tercih, yoksa gerçekten iyi yapılmış React uygulamaları var mı merak ediyorum

  • Uzun süre React/SPA hayranıydım ama zamanla şunu fark ettim: geliştirme, C++ MFC masaüstü uygulamaları yaptığımız dönemden bile daha zor hale geldi. Deklaratif işaretlemenin bilişsel yükü azalttığı söylenirdi; ama deklaratif UI ile event/state yönetiminin birleşik karmaşıklığı, prosedürel geliştirme döneminden bile daha ağır geldi. Eski C++ kodu, React hook’larından daha anlaşılırdı
  • SPA’lere çok eleştiri var ama gerçekten iyi yapılmış React/Angular uygulamaları da var. Örneğin: Clockify. Sorunlu uygulamalar SSR ile render ediliyor olsa UX’in bir anda düzeleceğini sanmıyorum. Asıl neden, kalite yerine hızlı özellik çıkarmaya odaklı organizasyon kültürü
  • Bu tür teknolojiler sadece performans kötü olduğunda görünür hale geliyor. Herkes her gün web teknolojileri kullandığı için eleştirmesi kolay. Özellikle çok sayıda acemi geliştiricinin kullandığı teknolojiler olduğu için daha da fazla saldırı alıyor. Sınırların aşınmasının tipik bir örneği
  • Sorun React’in kendisi değil; onu kullanan geliştiricilerin yanlış kullanması. Tonla optimizasyon imkânı olsa da yanlış kurgulanınca tıklama tepkisinin 1.3 saniye sürmesi gibi şeyler yaşanıyor
  • React kendi başına kötü değil; çoğu zaman yapısal olarak sorunlu olan SPA kurgusu. React yalnızca SPA yazmayı kolaylaştıran bir araç

• Genel olarak bilişim dünyasında her şey yavaşlamış gibi geliyor. En yeni Mac Studio M4 Max ve 64GB RAM kullanıyor olsam da tüm web siteleri 2011 MacBook Pro dönemine göre daha yavaş hissettiriyor

  • 15 yıl önce internet kesinlikle daha yavaştı ama o zaman web üzerinde karmaşık hesap tabloları ya da tasarım araçları kullanmıyorduk. M serisi Mac’ler, şimdiye kadar kullandığım en hızlı bilgisayarlar (Linux masaüstü hariç)
  • Bence web geliştiricileri, kullanıcıların en alt %10’luk donanım seviyesine sahip cihazları deneyip öyle geliştirme yapmalı. Ya da performansı doğrudan WCAG benzeri bir erişilebilirlik ölçütü haline getirmek de bir yol olabilir

• HN’de Github’ın UI’ı React’e taşındıkça yavaşladığını çok duydum ama gerçekten öyle mi merak ediyorum. Küçük projelerde bu etkiyi görmediğim için daha sağlam bir dayanak arıyorum

  • Yakın zamanda okuduğum bir blog yazısı nedeni iyi açıklıyordu. Özetle PR görünümünde 100 binden fazla DOM düğümü render ediliyor ve bunların önemli bir kısmı görünmeyen SVG düğümleri. SPA routing yüzünden gezinme de çok daha yavaş hale geliyor deniyor ilgili blog / HN tartışması
  • Son dönemde PR diff sayfası yeniden tasarlandı ve DOM daha da şişmiş gibi görünüyor

• Sadece Safari değil, Firefox’ta da Github aşırı yavaş; her yerde loading spinner görünüyor ve sayfa geçişleri eskisine göre daha uzun sürüyor. Eskiden kusursuz çalışan SSR’ı hangi metriğe bakıp SPA’ye çevirdiler gerçekten anlamıyorum

  • Son zamanlarda Chrome’da da benzer sorunlar var. Üç tarayıcıda da, PR çok büyük olmasa bile düzgün çalışmayan durumlar yaşanıyor