O site do GitHub está lento no Safari

• Nos últimos meses, a velocidade do site do GitHub no navegador Safari vem piorando gradualmente
• Em PRs grandes ou arquivos de código com milhares de linhas, a renderização da tela se tornou praticamente impossível
• Ocorrem uso de 100% do processo de renderização do navegador, exibição de tela em branco ao rolar e atrasos severos em recursos de busca e comentários
• Mudanças de CSS e uso de transform entram em conflito com bugs de desempenho do Safari e causam o problema; outros navegadores como o Chrome se saem relativamente melhor
• O WebKit aplicou alguns patches de desempenho, mas foi mencionada a necessidade de uma resposta temporária da equipe de frontend do GitHub até o próximo lançamento do Safari

---

Contexto e principais problemas

• Recentemente, a degradação geral de desempenho ao acessar o site do GitHub pelo Safari ficou evidente
• Em especial, ao revisar alterações com milhares de linhas ou mais em Pull Requests (PRs) ou navegar por arquivos grandes de código, a situação chegou ao ponto de a própria renderização se tornar inviável
• No Activity Monitor, o processo de renderização consome 100% da CPU, e a renderização da página fica tão lenta que a tela aparece em branco durante a rolagem
• Recursos interativos como busca e comentários sofrem atrasos severos, e até clicar em uma caixa de seleção durante a revisão de PR pode levar vários segundos
• O mesmo acontece até em MacBook Pro recentes com Apple Silicon de alto desempenho, enquanto o uso no Chrome ou em outros navegadores oferece uma experiência muito melhor

Causa do problema e análise

• Reclamações em comum de usuários do Safari 18.6 (e também de beta/Tech Preview)
• Alguns usuários mencionam que a degradação severa de desempenho acontece de forma especialmente crítica apenas no GitHub, e não no Safari como um todo
• Foi descrito que o uso massivo de seletores CSS e de transform: translateY entra em conflito direto com os limites de processamento de camadas GPU do Safari
  • Como o frontend do GitHub posiciona todas as linhas de texto com transform: translateY, o Safari acaba criando milhares de camadas GPU
  • O Chrome, quando não há esse tipo de animação, otimiza melhor a criação de camadas e por isso apresenta desempenho relativamente menos ruim
  • Como solução temporária, aplicar um script para remover a propriedade transform acelera o site, mas a precisão do posicionamento não fica perfeita

Experiência dos usuários e relatos diversos

• Vários usuários relatam o incômodo de ter todas as interações atrasadas em vários segundos em PRs, como adicionar revisores e labels ou editar a descrição do PR
• Ao acessar pelo Safari, a interface do navegador de código e os recursos de autocompletar (barra de busca, command palette etc.) ficam muito lentos
• Há casos em que até funções do navegador, como o botão nativo de voltar no Safari do iOS, não funcionam corretamente
• Do ponto de vista de acessibilidade (VoiceOver), a perda de desempenho também é severa, tornando o uso praticamente inviável para pessoas com deficiência visual

Discussão sobre solução e resposta

• O lado do WebKit (motor do Safari) aplicou recentemente alguns patches para esse problema de desempenho de CSS/compositor, mas uma correção imediata segue difícil antes da próxima versão do Safari
• Foi mencionada a necessidade de propor aos engenheiros do GitHub medidas de mitigação antes do próximo lançamento do Safari e de comunicar previamente os problemas de desempenho
• Diversas mudanças recentes na UI de frontend (por exemplo, a interface de alterações de arquivos em PRs e novos recursos) são vistas como diretamente relacionadas à queda de desempenho
• Alguns usuários contornam o problema usando Graphite.dev, GitLab ou roteadores de protocolo personalizados (como Finicky e Velja) para redirecionamento ou interfaces alternativas

Outros comentários e dicas práticas

• Como solução provisória, foi sugerido criar a issue/PR no Safari e depois usar o recurso de adicionar labels no formato de tabela
• Há vozes preocupadas com CSS excessivamente complexo, mudanças na estrutura de engenharia e a centralização em torno do Chrome, reforçando a necessidade de suporte real a vários navegadores
• Alguns usuários acrescentaram comentários críticos ou bem-humorados sobre o problema de desempenho (com alerta para evitar discussões emocionais desnecessárias)
• Surgem opiniões internas e externas pedindo uma revisão das práticas de desenvolvimento frontend que precisam de otimização de desempenho, além de destacar a importância de testes em múltiplos navegadores

Conclusão

• As mudanças recentes na estrutura de UI do GitHub e na forma de usar CSS entram em conflito com características específicas de renderização do Safari, causando um problema grave de usabilidade em uma plataforma padrão da indústria para colaboração
• Tanto o WebKit quanto o GitHub precisam agir de forma mais proativa, e no curto prazo são necessárias respostas voltadas a usuários do Safari e de acessibilidade
• Trata-se de um problema de desempenho sério o suficiente para atrapalhar o trabalho de desenvolvimento, gerando forte identificação e indignação na comunidade

[GN⁺]

Comentários no Hacker News

• O site do Github é lento em geral. Não dá para dizer que seja um bom software em termos de desempenho ou UX/UI; parece o resultado de vários KPIs e planejamentos de muita gente empilhados juntos. O aspecto mais “inovador” é ele ser uma rede social para desenvolvedores, e para o trabalho de desenvolvimento do dia a dia ele é tão mediano que chega a fazer o Gitlab parecer muito melhor. Esse problema não é por causa de Rails, e acho errado usar a tecnologia como embalagem para desviar do ponto principal

  • O problema do Github não é Rails, é que ele migrou para React. O Github antigo, baseado em SSR, era realmente rápido e dava para revisar PRs enormes sem problema
  • Fiquei vários anos sem usar Github e voltei este ano; fiquei realmente chocado com o quanto ele ficou lento. Tive que mudar completamente meu jeito de usar por causa da lentidão em toda interação. Dá uma sensação constante de que algo está errado, e quando nada responde por alguns segundos bate até uma ansiedade, como se o servidor tivesse travado
  • Depois de usar Phabricator por 10 anos, chegar no Github e ver essa diferença de qualidade é desconcertante, e é difícil acreditar que isso virou o padrão. É uma pena que o Phabricator esteja agora só em manutenção Wiki do Phabricator
  • O Github já foi realmente agradável de usar, mas depois que virou SPA ficou travado e frustrante
  • Já tive um CTO que culpava Rails por qualquer queda de desempenho em um app legado e queria reescrever tudo em Java. Na verdade, a causa raiz era o acúmulo de decisões de planejadores incompetentes, executivos e desenvolvedores inexperientes. Se um projeto foi mal gerido por mais de 10 anos, o resultado seria o mesmo em qualquer stack

• A equipe do WebKit aplicou uma melhoria para o problema de desempenho do Github nos últimos dois dias link relacionado. O time chegou a criar PRs gigantescos, com mais de 1000 arquivos, e os colegas diziam “quando abrir eu aprovo” enquanto esperavam o PR carregar

  • Todo mundo diz que o problema é JS e React, mas na prática este patch é relacionado a desempenho de CSS
  • Como o Chrome e seus derivados praticamente dominaram os motores de renderização, e o Firefox anda sem tanto crescimento, é bom ver a Apple fazendo mudanças para manter o Safari competitivo no macOS/iOS
  • Fico curioso sobre que tipo de trabalho, especificamente, gera um PR com mais de 1000 arquivos
  • Na prática, era um bug do Safari WebKit exposto porque o Github estava sobrecarregando demais o navegador. Nós, como desenvolvedores ou usuários, tendemos a culpar só o Github pela causa
  • Fico curioso sobre quanto tempo leva para esse patch do WebKit chegar aos usuários reais. No Safari é preciso esperar atualização do sistema operacional, ou ele recebe updates rápidos como Chrome/Firefox?

• Assim que a Microsoft adquiriu o Github, o Github quase imediatamente mudou para renderização em JavaScript (SPA). Antes, em um Mac Mini de 2011, ainda dava para navegar no Github mesmo com JavaScript desativado; hoje, mesmo com JS ativado, o Github fica inutilizável por causa da compatibilidade com navegadores antigos. É difícil dizer qual lado é mais culpado, mas acho que ambos têm responsabilidade. Dá para trocar por um dispositivo mais novo, mas parece que abandonaram de propósito o suporte a hardware antigo e empurraram obsolescência programada em vez de funcionalidade futura, a ponto de até a confiança nos padrões da web ficar abalada

  • Caso alguém descubra isso hoje pela primeira vez, com o OpenCore Legacy Patcher dá para atualizar o macOS até em Macs de 2007 link do OpenCore Legacy Patcher
  • Fico pensando se não valeria instalar e usar Chrome ou Firefox
  • Fico me perguntando por que Turing completeness parece uma mentira. Existe obsolescência programada, mas o ambiente moderno de software também está afogado em abstrações demais. Se todo software tivesse que ser escrito em C, o mundo hoje seria muito diferente. Parece que fomos longe demais em abstração, mas agora é difícil voltar. Turing completeness em si quase não tem relação com isso; pelo contrário, o resultado é exigir ainda mais recursos
  • Vale reforçar que Turing completeness não tem relação com desempenho. Em teoria, até seria possível emular um dispositivo mais novo no hardware atual
  • Há quem reclame do fim do suporte de sistema operacional para um Mac Mini de 2011, mas usar a internet com um navegador de mais de 8 anos é, em termos de segurança, quase como deixar todas as portas de casa abertas

• Há muita crítica ao React, mas neste caso o problema é de CSS transform. Recomendo ler o conteúdo do link de fato

• Recomendo migrar para Forgejo, Codeberg e SourceHut. Comparados a Github e Gitlab, são rápidos como um raio Forgejo / Codeberg / SourceHut

  • Rodei um servidor Forgejo por algumas semanas em um link quebrado, na faixa de quilobits por segundo, e ele aguentou surpreendentemente bem. Push/pull funcionavam de algum jeito, mas as actions eram difíceis porque exigiam transferência de mais de 100MB

• Fico me perguntando como esse tipo de problema se repete em organizações grandes. Em testes com os principais navegadores, certamente alguém deve ter visto esses problemas de desempenho, então é difícil entender quem aprovou isso mesmo assim

  • Hoje a indústria de TI tem três grupos: 1) PMs pressionando por lançamentos a qualquer custo e priorizando só velocidade. 2) Desenvolvedores resistindo a isso, gastando capital político continuamente e entrando em burnout. 3) Um grupo de desenvolvedores que age de forma mecânica, indiferente a tudo, apenas fazendo o que foi mandado. No fim, o problema é cultural, e sem uma reforma total no nível C não muda. A maioria dos executivos não tem vontade de mudar isso
  • Em organizações grandes, o critério mais importante para escolher uma stack é “quão fácil é contratar e demitir”. Há muitos desenvolvedores React, mas é difícil achar gente de Rails. A opinião dos desenvolvedores é ignorada e as necessidades da organização vêm primeiro, o que leva a serviços lentos e baixa qualidade. Os próprios devs sabem do problema, mas sobreviver vem antes
  • Se antes existia o ditado “ninguém é demitido por comprar IBM”, hoje parece ser “você é demitido se não usar React”. Como todo mundo usa React, até o Github continua ficando lento. Maus desenvolvedores seguem o que todos usam; bons desenvolvedores escolhem as ferramentas mais simples, seguindo o princípio KISS
  • Em grandes organizações, a “propriedade” fica nebulosa, e com rotatividade alta e foco em metas de curto prazo esses problemas sempre se repetem. A pressão para adicionar funcionalidades e a dívida técnica se acumulam, enquanto o senso de responsabilidade desaparece. Se alguém levanta o problema, ainda cria conflito e pode acabar empurrado para um plano de melhoria de desempenho

• Como desenvolvedor React, ver esta thread faz sentir o ódio do mundo. Há muitos cronogramas irreais e muitas armadilhas no modelo de SPA, incluindo jogar lógica de backend no frontend. Fico me perguntando se React em si é uma escolha errada, ou se existem apps em React realmente bem feitos

  • Fui fã de React/SPA por muito tempo, mas aos poucos percebi que hoje o desenvolvimento ficou ainda mais difícil do que na época em que eu fazia apps desktop em C++ MFC. Diziam que markup declarativo reduziria a carga cognitiva, mas na prática a combinação entre UI declarativa e a complexidade de eventos/estado acabou ficando mais complicada do que quando se desenvolvia de forma procedural. Código antigo em C++ às vezes era até mais fácil de entender do que hooks de React
  • Há muita crítica a SPA, mas também existem apps muito bem feitos em React/Angular. Exemplo: Clockify. E não acho que um app problemático vá magicamente ganhar uma UX melhor só por ser renderizado com SSR. A causa real é uma cultura organizacional obcecada por lançar funcionalidades rápido, acima da qualidade
  • Esse tipo de tecnologia só ganha destaque quando o desempenho é ruim. Como todo mundo usa tecnologia web todos os dias, é fácil criticar. E como é tecnologia muito usada por desenvolvedores iniciantes, acaba sendo ainda mais atacada. É um bom exemplo de diluição de fronteiras
  • O problema não é React em si, e sim desenvolvedores usando errado. Existem inúmeras otimizações, mas se tudo for mal encadeado, até um clique pode levar 1,3 segundo para responder
  • React em si não é ruim; muitas vezes o problema estrutural está na composição de uma SPA. React é apenas a ferramenta que tornou mais fácil construir SPAs

• Em computação no geral, parece que tudo ficou mais lento. Mesmo usando um Mac Studio M4 Max moderno com 64GB de RAM, todos os sites parecem mais lentos do que no meu MacBook Pro de 2011

  • Quando eu usava a internet há 15 anos, ela claramente era mais lenta, mas naquela época ninguém usava planilhas complexas ou ferramentas de design na web. Os Macs com chip da série M são os computadores mais rápidos que já usei até hoje, tirando desktops Linux
  • Acho que desenvolvedores web deveriam testar e desenvolver usando dispositivos que estejam pelo menos entre os 10% piores em especificação entre seus usuários. Ou então transformar desempenho em um critério de WCAG (acessibilidade web)

• Já ouvi bastante no HN que o Github ficou lento quando migrou a UI para React, mas queria saber se isso é realmente verdade. Em projetos pequenos não senti impacto, então queria uma base mais concreta

  • Um post de blog que li recentemente explica bem a causa. Resumindo: na view de PR são renderizados mais de 100 mil nós de DOM, e boa parte deles são nós SVG invisíveis. A análise também diz que a navegação ficou muito mais lenta por causa do roteamento de SPA blog relacionado / discussão no HN
  • Parece que a página de diff de PR foi redesenhada recentemente e o DOM ficou ainda mais inchado

• Não é só no Safari; no Firefox o Github também está absurdamente lento, com spinners de carregamento aparecendo por toda parte e trocas de página demorando mais do que antes. Não entendo com que métrica trocaram um SSR que funcionava perfeitamente por uma SPA

  • Recentemente o Chrome também vem apresentando problema parecido. Nos três navegadores, a situação é de não funcionar direito mesmo quando o PR nem é grande