Safari में GitHub वेबसाइट धीमी चल रही है

 (github.com/orgs)
2 पॉइंट द्वारा GN⁺ 2025-08-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • पिछले कुछ महीनों में Safari browser पर GitHub वेबसाइट की गति लगातार घटती गई है
  • बड़े PR या हज़ारों लाइनों वाली code files में स्क्रीन rendering लगभग असंभव हो गई है
  • browser का rendering process 100% उपयोग करता है, scroll करते समय खाली स्क्रीन दिखती है, और search व comment features में गंभीर delay होता है
  • CSS बदलाव और transform के उपयोग का Safari के performance bug से टकराव इस समस्या की वजह बन रहा है; Chrome जैसे दूसरे browsers तुलनात्मक रूप से बेहतर हैं
  • WebKit में कुछ performance patches किए गए हैं, लेकिन Safari की अगली release से पहले तक GitHub frontend team की अस्थायी प्रतिक्रिया की ज़रूरत बताई गई है

पृष्ठभूमि और मुख्य समस्या

  • हाल के समय में Safari browser पर GitHub वेबसाइट खोलने पर कुल मिलाकर performance degradation साफ़ दिख रही है
  • खास तौर पर Pull Request(PR) में हज़ारों लाइनों से अधिक changes देखना या बड़े code files browse करना rendering के स्तर पर ही लगभग असंभव हो गया है
  • Activity Monitor में rendering process 100% CPU लेता हुआ दिखता है, और page rendering इतनी धीमी हो जाती है कि scroll करने पर स्क्रीन खाली जगह जैसी दिखाई देती है
  • search, comment जैसी interactive features में गंभीर delay होता है, और PR review के दौरान checkbox क्लिक करने में भी कई सेकंड लग जाते हैं
  • हाई-एंड Apple Silicon वाले नए MacBook Pro पर भी यही समस्या होती है, जबकि Chrome या दूसरे browsers में अनुभव काफ़ी बेहतर है

समस्या का कारण और विश्लेषण

  • Safari 18.6 version (और beta/tech preview) users से यह शिकायत आम तौर पर मिली है
  • कुछ users ने कहा कि Safari में नहीं, बल्कि खासतौर पर GitHub पर ही असामान्य रूप से गंभीर performance issue दिखता है
  • CSS selectors और transform: translateY के बड़े पैमाने पर उपयोग का Safari की GPU layer handling limits से सीधा टकराव बताया गया है
    • GitHub frontend हर text line को transform: translateY से place कर रहा है, जिससे Safari को हज़ारों GPU layers बनानी पड़ती हैं
    • Chrome ऐसी animation न होने पर layer creation को optimize कर लेता है, इसलिए performance तुलनात्मक रूप से कम खराब रहती है
    • अस्थायी उपाय के रूप में transform property हटाने वाला script लगाने पर speed बढ़ती है, लेकिन positioning पूरी तरह सटीक नहीं रहती

user experience और विभिन्न रिपोर्टें

  • कई users ने PR में reviewer/label जोड़ने, PR description edit करने जैसे सभी interactions में कई सेकंड की देरी की शिकायत की
  • Safari में code browser और autocomplete UI (search bar, command palette आदि) बहुत धीमे हो जाते हैं
  • iOS Safari में back native button जैसे browser features भी ठीक से काम न करने के मामले सामने आए हैं
  • accessibility (VoiceOver) के लिहाज़ से भी performance इतनी गिर गई है कि visually impaired users के लिए इसका उपयोग लगभग असंभव हो गया है

समाधान और प्रतिक्रिया पर चर्चा

  • WebKit (Safari engine) की ओर से इस CSS/compositor performance problem के कुछ हिस्सों पर patch किया गया है, लेकिन Safari की अगली release से पहले तुरंत समाधान मुश्किल है
  • GitHub engineers के लिए अगली Safari release से पहले bug response proposal और performance issues पर proactive communication की ज़रूरत बताई गई है
  • frontend UI में हुए विभिन्न बदलाव (जैसे PR file changes UI, नई features आदि) को performance गिरने से सीधे जुड़ा माना जा रहा है
  • कुछ users Graphite.dev, GitLab, और custom protocol routers (जैसे Finicky, Velja आदि) का workaround या alternative UI के रूप में उपयोग कर रहे हैं

अन्य टिप्पणियाँ और practical tips

  • एक अस्थायी workaround के रूप में Safari में issue/PR बनाने के बाद table-style label add feature इस्तेमाल करने की सलाह दी गई है
  • बहुत ज़्यादा जटिल CSS, engineering structure में बदलाव, और Chrome-केंद्रित एकरूपता को लेकर चिंता जताई गई है, साथ ही विभिन्न browsers के समर्थन की ज़रूरत पर ज़ोर दिया गया है
  • कुछ users ने performance समस्या पर आलोचनात्मक या हास्यपूर्ण टिप्पणियाँ कीं (अनावश्यक भावनात्मक बहस से बचने की सलाह दी गई)
  • performance optimization की ज़रूरत वाले frontend development तरीकों की फिर से समीक्षा और multi-browser testing के महत्व पर अंदरूनी/बाहरी राय सामने आई

निष्कर्ष

  • GitHub के हालिया UI structural changes और CSS usage pattern का Safari की विशिष्ट rendering characteristics से टकराव हो रहा है, जिससे उद्योग-मानक collaboration platform पर गंभीर browser असुविधा पैदा हो रही है
  • WebKit और GitHub, दोनों की ओर से सक्रिय सुधार की ज़रूरत है, और short term में Safari व accessibility users को केंद्र में रखकर प्रतिक्रिया देनी होगी
  • यह performance समस्या इतनी गंभीर है कि development work प्रभावित हो रहा है, और community में इसके प्रति व्यापक सहमति और गुस्सा बन चुका है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-08-29
Hacker News राय

  • Github वेबसाइट हर जगह धीमी लगती है। परफ़ॉर्मेंस हो या UX/UI, किसी भी लिहाज़ से इसे अच्छा सॉफ़्टवेयर कहना मुश्किल है, और यह कई लोगों के KPI और planning का मिला-जुला नतीजा लगता है। डेवलपर्स के लिए social network होना ही शायद इसका सबसे “innovative” हिस्सा है, जबकि रोज़मर्रा के development काम के लिए यह इतना साधारण है कि Gitlab कहीं बेहतर लगता है। यह समस्या Rails की वजह से नहीं है, और तकनीक का पर्दा डालकर मूल समस्या से बचना सही नहीं लगता

    • Github की समस्या Rails नहीं, बल्कि React पर शिफ्ट होना है। पहले का SSR-आधारित Github सच में तेज़ था और बड़े PR भी बिना दिक्कत review किए जा सकते थे
    • कई साल Github इस्तेमाल न करने के बाद इस साल फिर इस्तेमाल किया तो यह देखकर सच में हैरानी हुई कि यह कितना धीमा हो गया है। हर interaction पर होने वाली देरी की वजह से इस्तेमाल करने का पूरा तरीका बदलना पड़ा। लगातार लगता रहा कि कुछ गड़बड़ है, और अगर कुछ सेकंड तक कोई प्रतिक्रिया न मिले तो अजीब-सी चिंता होती है कि शायद server रुक गया हो
    • 10 साल Phabricator इस्तेमाल करने के बाद Github पर आना गुणवत्ता के फ़र्क की वजह से काफ़ी असहज लगा, और यह मानना मुश्किल है कि यही standard है। अफ़सोस है कि Phabricator अब सिर्फ maintenance mode में है Phabricator wiki
    • Github पहले सच में बहुत smooth था, लेकिन SPA में बदलने के बाद से घुटन-सी महसूस होती है
    • पहले एक CTO थे जो legacy app की performance गिरने का कारण हर बार Rails को बताते थे और Java में पूरा rewrite करना चाहते थे। असल समस्या अयोग्य planners, management, और कम अनुभवी developers के जमा हुए असर थे। अगर कोई project 10 साल से ज़्यादा समय तक ग़लत तरीके से manage हुआ हो, तो stack कोई भी हो, नतीजा वही रहेगा

  • WebKit टीम ने पिछले 2 दिनों में Github performance issue के लिए सुधार लागू किए हैं संबंधित लिंक. टीम के अंदर 1000 से ज़्यादा files वाले बड़े PR भी बनाए गए, और सहकर्मी PR के लोड होने का इंतज़ार करते-करते कहते थे, “खुल जाए तो approve कर दूँगा”

    • सब लोग JS और React को समस्या बता रहे हैं, लेकिन इस बार का patch असल में CSS performance से जुड़ा है
    • Chrome और उसके derivative browsers ने rendering engine पर लगभग कब्ज़ा कर लिया है, इसलिए Firefox की growth धीमी पड़ने के इस दौर में macOS/iOS पर Safari को competitive बनाए रखने के लिए Apple के बदलाव अच्छे लगते हैं
    • 1000 से ज़्यादा files वाले PR में आख़िर किस तरह का काम हो रहा था, यह जानने की जिज्ञासा है
    • असल में यह Safari WebKit में सामने आया bug था, जो Github की ज़्यादा लोड डालने वाली स्थिति में उजागर हुआ। डेवलपर या यूज़र के रूप में हमारे लिए वजह का पूरा दोष सिर्फ Github पर डाल देना आसान होता है
    • जानना है कि WebKit patch असली users तक पहुँचने में कितना समय लेता है। क्या Safari के लिए OS update का इंतज़ार करना पड़ता है, या Chrome/Firefox की तरह updates जल्दी आते हैं

  • Microsoft ने Github को acquire करते ही लगभग तुरंत उसे JavaScript rendering style (SPA) में बदल दिया। पहले 2011 Mac Mini पर JavaScript बंद होने पर भी Github browse किया जा सकता था, लेकिन अब JS चालू होने पर भी पुराने browser compatibility की वजह से Github इस्तेमाल नहीं हो पाता। किस तरफ़ की गलती ज़्यादा है, यह कहना मुश्किल है, लेकिन दोनों की ज़िम्मेदारी लगती है। नया device लिया जा सकता है, लेकिन जब जानबूझकर पुराने devices का support छोड़ा जाता है और future functionality से ज़्यादा planned obsolescence थोपने वाला माहौल बनता है, तो web standards पर भरोसा भी टूटता हुआ लगता है

    • अगर आज पहली बार पता चल रहा हो, तो OpenCore Legacy Patcher का इस्तेमाल करके 2007 Mac तक में macOS का latest version चलाया जा सकता है OpenCore Legacy Patcher link
    • Chrome या Firefox install करके इस्तेमाल करने के बारे में क्या विचार है
    • समझ नहीं आता कि Turing completeness झूठ जैसा क्यों लगने लगता है। planned obsolescence अपनी जगह है, लेकिन modern software environment में abstractions बहुत ज़्यादा हो गई हैं। अगर सारा software C भाषा में लिखना पड़ता, तो आज की दुनिया बहुत अलग होती। लगता है हम बहुत ऊँचे abstraction level में फँस गए हैं, लेकिन अब यहाँ तक आ चुके हैं तो लौटना मुश्किल है। Turing completeness का इससे लगभग कोई लेना-देना नहीं, बल्कि उसके नतीजे में और ज़्यादा resources की माँग होने लगती है
    • यह बात ज़ोर देकर कही जानी चाहिए कि Turing completeness का performance से कोई संबंध नहीं है। सिद्धांततः आज की मशीन पर नई मशीन को emulate भी किया जा सकता है
    • कुछ लोग 2011 Mac Mini के OS support बंद होने पर नाराज़ हो सकते हैं, लेकिन 8 साल से ज़्यादा पुराने browser से इंटरनेट चलाना सुरक्षा के लिहाज़ से घर के सारे दरवाज़े खुले छोड़ देने जैसा है

  • React पर बहुत आलोचना हो रही है, लेकिन यह issue CSS transform की समस्या है। लोग लिंक की सामग्री सच में पढ़ें, यही बेहतर होगा

  • Forgejo, Codeberg, SourceHut पर migrate करने की सलाह है। Github और Gitlab की तुलना में ये बिजली की तरह तेज़ हैं Forgejo / Codeberg / SourceHut

    • मैंने Forgejo server को टूटी-फूटी लाइन (प्रति सेकंड kilobits स्तर) पर कई हफ़्तों तक चलाया, फिर भी यह काफ़ी ठीक चला। push/pull किसी तरह काम कर रहे थे, लेकिन actions मुश्किल थे क्योंकि उनमें 100MB से ज़्यादा transfer चाहिए था

  • समझ नहीं आता कि बड़े organizations में ऐसी समस्याएँ बार-बार कैसे दोहराई जाती हैं। बड़े browser tests में performance issue ज़रूर दिखे होंगे, तो फिर किसी ने इसे ज़बरदस्ती approve कैसे कर दिया

    • अभी IT industry में तीन समूह दिखते हैं: 1) PM जो release के लिए अत्यधिक दबाव डालते हैं और सिर्फ speed देखते हैं। 2) developers जो ऐसी माँगों का विरोध करते-करते लगातार अपना political capital खोते हैं और burnout हो जाते हैं। 3) developers का वह समूह जो हर चीज़ से उदासीन होकर बस दिया गया काम मशीन की तरह करता है। आख़िरकार समस्या culture में है, और C-level से पूरी reform के बिना यह नहीं बदलेगी। ज़्यादातर executives में इसे बदलने की इच्छा ही नहीं है
    • बड़े organization में tech stack चुनते समय सबसे अहम मापदंड होता है, “hire और fire करना कितना आसान है।” React developers बहुत हैं, लेकिन Rails वाले मिलना मुश्किल है। developers की राय नज़रअंदाज़ होती है, organization की ज़रूरत पहले आती है, और नतीजा होता है धीमी service और ख़राब quality। developers भी समस्या जानते हैं, लेकिन survival पहले है
    • पहले कहा जाता था, “IBM खरीदो तो नौकरी नहीं जाएगी,” अब माहौल ऐसा है कि “React इस्तेमाल नहीं किया तो नौकरी जाएगी।” सब React इस्तेमाल कर रहे हैं, इसलिए Github तक धीमा हो रहा है। ख़राब developer वही है जो दूसरों के पीछे चलता है, और अच्छा developer KISS principle के अनुसार सबसे simple tool चुनता है
    • बड़े organizations में “ownership” धुंधली हो जाती है, attrition और short-term goals की वजह से ऐसी समस्याएँ बार-बार लौटती हैं। feature जोड़ने का दबाव और technical debt जमा होता जाता है, जबकि जवाबदेही ग़ायब हो जाती है। समस्या उठाओ तो उल्टा टकराव पैदा होता है और performance improvement plan तक की नौबत आ जाती है

  • React developer होने के नाते इस thread को देखकर दुनिया की नफ़रत महसूस होती है। अवास्तविक timelines, और backend logic तक frontend पर लाद देने वाले SPA के बहुत से जाल हैं। समझ नहीं आता कि React खुद ग़लत चुनाव है, या सच में अच्छे React apps भी मौजूद हैं

    • मैं लंबे समय तक React/SPA का बड़ा प्रशंसक रहा, लेकिन धीरे-धीरे लगा कि C++ MFC desktop apps बनाने के दिनों से भी development अब ज़्यादा कठिन हो गया है। कहा जाता था कि declarative markup cognitive load कम करता है, लेकिन हुआ उल्टा—declarative UI के साथ event/state management की जटिलता इतनी बढ़ गई कि procedural development के समय से भी चीज़ें ज़्यादा जटिल लगती हैं। पुराना C++ code कई बार React hook से ज़्यादा आसान लगता था
    • SPA की आलोचना बहुत होती है, लेकिन बहुत अच्छे React/Angular apps भी हैं। उदाहरण: Clockify. किसी problematic app को SSR से render कर देने भर से UX अचानक बेहतर हो जाएगा, ऐसा नहीं लगता। असली वजह वह organizational माहौल है जो quality से ज़्यादा feature जल्दी release करने पर केंद्रित है
    • ऐसी technologies पर ध्यान तभी जाता है जब performance ख़राब होती है। हर कोई रोज़ web technologies इस्तेमाल करता है, इसलिए इन पर नाराज़ होना आसान है। ख़ासकर क्योंकि इन्हें बहुत से शुरुआती developers इस्तेमाल करते हैं, इसलिए और ज़्यादा आलोचना होती है। यह boundary collapse का एक बड़ा उदाहरण है
    • React खुद समस्या नहीं है, समस्या यह है कि इसे इस्तेमाल करने वाले developers इसे ग़लत तरह से इस्तेमाल करते हैं। ढेर सारे optimization होने के बावजूद अगर चीज़ें ग़लत तरह से जोड़ी जाएँ, तो click response में 1.3 सेकंड तक लग सकते हैं
    • React अपने आप में बुरा नहीं है, और कई बार संरचनात्मक समस्या SPA composition में होती है। React बस एक tool है जो SPA बनाना आसान करता है

  • लगता है computing की दुनिया में हर चीज़ धीमी हो गई है। Latest Mac Studio M4 Max, 64GB RAM होने पर भी हर वेबसाइट 2011 MacBook Pro के समय से धीमी लगती है

    • 15 साल पहले इंटरनेट निश्चित रूप से धीमा था, लेकिन तब हम web पर complex spreadsheets या design tools इस्तेमाल नहीं करते थे। M series Mac अब तक इस्तेमाल किए गए सबसे तेज़ computers हैं (Linux desktop को छोड़कर)
    • मुझे लगता है web developers को users के निचले 10% spec वाले devices पर चलाकर development करना चाहिए। या फिर performance को ही WCAG (web accessibility) जैसा मानक बनाना चाहिए

  • HN पर Github के React में UI migrate करने के बाद धीमा होने की बात बहुत सुनी है, लेकिन सच में ऐसा है या नहीं, यह जानना चाहता हूँ। छोटे projects में इसका असर नहीं दिखता, इसलिए पक्का आधार ढूँढना चाहता हूँ

    • हाल में पढ़े एक blog post में इसकी वजह अच्छे से समझाई गई है। सार यह है कि PR view में 100,000 से ज़्यादा DOM nodes render हो रहे हैं, और उनमें काफ़ी हिस्से invisible SVG nodes हैं। विश्लेषण यह भी कहता है कि SPA routing की वजह से navigation भी काफ़ी धीमा हो गया है संबंधित ब्लॉग / HN चर्चा
    • हाल में PR diff page का redesign हुआ है, और उसके बाद DOM शायद और भी भारी हो गया है

  • सिर्फ Safari ही नहीं, Firefox में भी Github बहुत धीमा है, loading spinners हर जगह दिखते हैं और page transition पहले से ज़्यादा समय लेते हैं। जो SSR पहले पूरी तरह ठीक चल रहा था, उसे आख़िर किस metric के आधार पर SPA में बदला गया, समझ नहीं आता

    • हाल में Chrome में भी ऐसी ही समस्या है। तीनों browsers में स्थिति यह है कि PR बड़ा न हो तब भी चीज़ें ठीक से काम नहीं कर रहीं