El sitio web de GitHub funciona lento en Safari

• En los últimos meses, la velocidad del sitio web de GitHub ha ido empeorando gradualmente en el navegador Safari
• En los PR grandes o en archivos de código con miles de líneas, renderizar la pantalla se ha vuelto prácticamente imposible
• Se presentan problemas como uso del 100% del proceso de renderizado del navegador, pantallas en blanco al desplazarse y retrasos graves en funciones de búsqueda y comentarios
• Los cambios de CSS y el uso de transform entran en conflicto con un bug de rendimiento de Safari y provocan el problema; otros navegadores como Chrome se comportan relativamente mejor
• En WebKit ya se aplicaron algunos parches de rendimiento, pero se menciona la necesidad de una respuesta temporal del equipo de frontend de GitHub hasta el próximo lanzamiento de Safari

---

Contexto y problemas principales

• Recientemente, al acceder al sitio web de GitHub desde Safari se ha hecho evidente una degradación general del rendimiento
• En particular, al revisar cambios de miles de líneas o más en un Pull Request (PR) o al explorar archivos de código muy grandes, el nivel de lentitud llega al punto de hacer imposible el renderizado
• En Activity Monitor, el proceso de renderizado ocupa el 100% del CPU, y la velocidad de renderizado de la página es tan lenta que al desplazarse la pantalla aparece como un espacio vacío
• Las funciones interactivas, como búsqueda y comentarios, sufren retrasos severos, y durante la revisión de PR incluso hacer clic en una casilla puede tardar varios segundos
• El mismo comportamiento ocurre incluso en una MacBook Pro reciente con Apple Silicon de gama alta, mientras que en Chrome u otros navegadores la experiencia es mucho mejor

Causa y análisis del problema

• Se han recibido quejas comunes de usuarios de Safari 18.6 (así como de la beta y la Technical Preview)
• Algunos usuarios señalan que la degradación grave del rendimiento ocurre de forma particularmente marcada solo en GitHub, no en Safari en general
• Se describe que el uso masivo de selectores CSS y de transform: translateY choca directamente con los límites de Safari para manejar capas GPU
  • Como el frontend de GitHub posiciona todas las líneas de texto con transform: translateY, Safari termina creando miles de capas GPU
  • Chrome, cuando no hay este tipo de animaciones, optimiza la creación de capas y por eso muestra un rendimiento relativamente menos deficiente
  • Como medida temporal, aplicar un script que quite la propiedad transform acelera el funcionamiento, aunque la precisión del posicionamiento no es perfecta

Experiencia de usuario y reportes diversos

• Varios usuarios expresan su frustración porque todas las interacciones en los PR, como agregar revisores o etiquetas y editar la descripción del PR, se retrasan varios segundos
• Al entrar desde Safari, la interfaz del navegador de código y del autocompletado (barra de búsqueda, command palette, etc.) se vuelve muy lenta
• En iOS Safari también existen casos donde funciones del navegador, como el botón nativo de retroceder, no funcionan correctamente
• También desde la perspectiva de accesibilidad (VoiceOver), la degradación del rendimiento es tan grave que para usuarios con discapacidad visual el uso se vuelve casi imposible

Discusión sobre soluciones y respuesta

• Del lado de WebKit (el motor de Safari) se han hecho recientemente algunos parches para este problema de rendimiento de CSS/compositor, pero es difícil resolverlo de inmediato antes del próximo lanzamiento de Safari
• Se menciona la necesidad de proponer una respuesta al bug para los ingenieros de GitHub y de comunicar con anticipación los problemas de rendimiento antes del próximo lanzamiento de Safari
• Se considera que varios cambios recientes en la UI del frontend (por ejemplo, la UI de cambios de archivos en PR y nuevas funciones) están directamente relacionados con la degradación del rendimiento
• Algunos usuarios optan por soluciones alternativas o interfaces sustitutas como Graphite.dev, GitLab o enrutadores de protocolo personalizados (por ejemplo, Finicky, Velja, etc.)

Otros comentarios y consejos prácticos de usuarios

• Como solución temporal, se sugiere en Safari crear el issue/PR y luego usar la función de agregar etiquetas en formato de tabla
• Hay voces que expresan preocupación por un CSS excesivamente complejo, cambios en la estructura de ingeniería y una excesiva orientación a Chrome, y que enfatizan la necesidad de dar soporte a varios navegadores
• Algunos usuarios añadieron comentarios críticos o humorísticos sobre el problema de rendimiento (se pide cuidado en la discusión para evitar debates emocionales innecesarios)
• Tanto interna como externamente se plantean opiniones sobre repensar las prácticas de desarrollo frontend que requieren optimización de rendimiento y sobre la importancia de probar en múltiples navegadores

Conclusión

• Los cambios recientes en la estructura de la UI de GitHub y en su uso de CSS entran en conflicto con las características propias de renderizado de Safari, causando un problema grave de usabilidad del navegador en una plataforma de colaboración estándar de la industria
• Se necesita una voluntad activa de mejora tanto por parte de WebKit como de GitHub, y a corto plazo se requiere una respuesta centrada en usuarios de Safari y en accesibilidad
• Es un problema de rendimiento que llega a interferir con el trabajo de desarrollo, por lo que en la comunidad se ha generado un fuerte consenso y enojo

[GN⁺]

Opinión de Hacker News

• El sitio web de Github tiende a ser lento en general. No se puede decir que sea un buen software ni en rendimiento ni en UX/UI; da la impresión de ser el resultado de los KPI y la planeación de muchas personas metidos ahí. Lo más “innovador” es que exista como una red social para desarrolladores, y para el trabajo de desarrollo cotidiano es tan mediocre que Gitlab llega a sentirse mucho mejor. Este problema no es culpa de Rails, y no me parece correcto disfrazarlo como un tema técnico para evadir el fondo del asunto

  • El problema de Github no es Rails, sino que se movió a React. El Github anterior, basado en SSR, era realmente rápido y permitía revisar PR enormes sin problema
  • Después de no usar Github durante años, este año lo volví a usar y de verdad me sorprendió lo lento que se volvió. Tuve que cambiar por completo mi forma de usarlo por la lentitud de cada interacción. Todo el tiempo se siente que algo está mal, y si no responde por unos segundos, da ansiedad como si el servidor se hubiera caído
  • Después de usar Phabricator durante 10 años, llegar a Github y ver la diferencia de calidad desconcierta, y cuesta creer que esto sea el estándar. Es una lástima que Phabricator ahora solo reciba mantenimiento Wiki de Phabricator
  • Github antes era realmente ágil, pero desde que cambió a SPA se volvió desesperante
  • Antes tuve un CTO que culpaba automáticamente a Rails por la degradación de rendimiento de una app legacy y quería rehacer todo en Java. En realidad, la causa de fondo era la acumulación de decisiones de malos planners, ejecutivos y desarrolladores sin experiencia. Si un proyecto ha sido mal gestionado por más de 10 años, el resultado será el mismo sin importar el stack

• El equipo de WebKit aplicó en los últimos dos días mejoras para este problema de rendimiento en Github enlace relacionado. Dentro del equipo incluso crearon PR gigantescos, de más de 1000 archivos, y sus colegas les decían “te lo apruebo cuando termine de cargar”

  • Todos dicen que el problema es JS y React, pero en realidad este parche está relacionado con rendimiento de CSS
  • Dado que Chrome y sus derivados prácticamente dominan el motor de renderizado, y con Firefox perdiendo impulso últimamente, se agradece ver que Apple siga haciendo cambios para mantener a Safari competitivo en macOS/iOS
  • Me da curiosidad qué tipo de trabajo implica exactamente un PR con más de 1000 archivos
  • En realidad era un bug que se hizo visible porque Github estaba sobrecargando demasiado a Safari WebKit. Como desarrolladores o usuarios, nos es fácil culpar solo a Github por la causa
  • Me pregunto cuánto tarda en llegar un parche de WebKit a los usuarios reales. Quisiera saber si en Safari hay que esperar una actualización del sistema operativo, o si las actualizaciones son rápidas como en Chrome/Firefox

• En cuanto Microsoft adquirió Github, Github cambió casi de inmediato a un modelo de renderizado con JavaScript (SPA). Antes se podía navegar Github incluso en un Mac Mini 2011 con JavaScript desactivado, pero ahora, aun con JS activado, ya no se puede usar Github por la compatibilidad con navegadores antiguos. Es difícil decir qué lado tiene más culpa, pero creo que ambos la comparten. Uno podría cambiarse a un dispositivo más nuevo, pero cuando el soporte para hardware antiguo se abandona deliberadamente y se impone la obsolescencia programada por encima de la funcionalidad futura, hasta la fe en los estándares web se tambalea

  • Si te enteras hoy por primera vez, con OpenCore Legacy Patcher puedes actualizar macOS hasta la versión más reciente incluso en Macs de 2007 enlace de OpenCore Legacy Patcher
  • Me pregunto qué tal sería simplemente instalar y usar Chrome o Firefox
  • Me pregunto por qué la Turing completeness se siente como una mentira. No es solo la obsolescencia programada; el entorno moderno de software tiene demasiadas capas de abstracción. Si todo el software tuviera que escribirse en C, el mundo actual sería muy distinto. Parece que nos hundimos en una abstracción demasiado alta, pero ya llegamos demasiado lejos como para volver atrás. La Turing completeness en sí casi no tiene relación con esto; más bien, su consecuencia es exigir todavía más recursos
  • Quiero enfatizar que la Turing completeness no tiene relación con el rendimiento. En teoría, incluso podría emularse un dispositivo moderno en el equipo actual
  • Hay quienes se quejan de que se dejó de dar soporte al SO del Mac Mini 2011, pero usar internet con un navegador de más de 8 años también es, en términos de seguridad, como dejar todas las puertas de tu casa abiertas

• Hay mucha crítica hacia React, pero este problema en particular es de CSS transform. Recomiendo leer de verdad el contenido del enlace relacionado

• Recomiendo migrar a Forgejo, Codeberg o SourceHut. Comparados con Github y Gitlab, son rapidísimos Forgejo / Codeberg / SourceHut

  • Tuve un servidor Forgejo funcionando durante varias semanas sobre una conexión rota (a nivel de kilobits por segundo) y aguantó bastante bien. Los push/pull funcionaban como podían, pero las actions fueron difíciles porque requerían transferencias de más de 100MB

• Me pregunto cómo este tipo de problema se repite en organizaciones grandes. Seguramente detectaron problemas de rendimiento en pruebas con los navegadores principales, así que no entiendo cómo alguien dio luz verde para seguir adelante

  • Hoy la industria de TI está dividida en tres grupos: 1) PM que presionan lanzamientos imposibles y solo priorizan la velocidad. 2) Desarrolladores que se oponen a estas exigencias, gastan constantemente su capital político y terminan quemados. 3) Un grupo de desarrolladores que, indiferentes a todo, solo hace mecánicamente lo que se les pide. Al final, el problema es cultural, y si no hay una reforma total desde el nivel C, nada va a cambiar. La mayoría de los ejecutivos no tiene voluntad de cambiar esto
  • Al decidir el stack técnico en una gran organización, el criterio más importante es “qué tan fácil es contratar y despedir”. Hay muchos desarrolladores React, pero es difícil encontrar gente de Rails. La opinión de los desarrolladores se ignora, las necesidades de la organización van primero, y eso termina en servicios lentos y mala calidad. Los desarrolladores también conocen el problema, pero sobrevivir es la prioridad
  • Antes se decía “nadie te despide por comprar IBM”; ahora el ambiente es más bien “si no usas React, te despiden”. Como todos usan React, hasta Github sigue volviéndose lento. Los malos desarrolladores copian lo que usan los demás; los buenos eligen la herramienta más simple según el principio KISS
  • En las grandes organizaciones, la “propiedad” se vuelve difusa y, por la alta rotación y el enfoque en objetivos de corto plazo, estos problemas siempre se repiten. Se acumula la presión por agregar funciones y también la deuda técnica, mientras se pierde el sentido de responsabilidad. Si señalas el problema, incluso se genera conflicto y te empujan a un plan de mejora de desempeño

• Como desarrollador de React, al ver este hilo siento el odio del mundo. Hay demasiadas trampas: calendarios irreales, y SPA que cargan incluso la lógica de backend en el frontend. Me pregunto si React en sí fue una mala decisión, o si de verdad existen apps en React bien hechas

  • Durante mucho tiempo fui un fanático de React/SPA, pero cada vez me doy más cuenta de que desarrollar se volvió incluso más difícil que en la época en que hacía apps de escritorio en C++ MFC. Se decía que el markup declarativo reducía la carga cognitiva, pero en realidad la complejidad de la UI declarativa junto con la gestión de eventos/estado ha crecido tanto que se volvió más complejo que desarrollar de forma procedural. El código viejo en C++ hasta era más fácil de entender que los hooks de React
  • Hay muchas críticas a las SPA, pero también hay apps de React/Angular realmente bien hechas. Ejemplo: Clockify. En apps problemáticas, no creo que el UX vaya a mejorar mágicamente solo porque rendericen con SSR. La causa real es una cultura organizacional que solo se enfoca en liberar funciones rápido, no en la calidad
  • Este tipo de tecnologías solo llama la atención cuando el rendimiento es malo. Como todo el mundo usa tecnologías web todos los días, es muy fácil criticarlas. En especial, son tecnologías muy usadas por desarrolladores novatos, por eso reciben todavía más ataques. Es un ejemplo de límites completamente difusos
  • El problema no es React en sí, sino los desarrolladores que lo usan mal. Por más optimizaciones que existan, si todo está mal ensamblado, puede pasar que una respuesta a clic tarde 1.3 segundos
  • React en sí no es malo, y muchas veces el problema estructural está en la arquitectura SPA. React es simplemente una herramienta que hizo más fácil usar SPA

• Da la sensación de que, en general, todo en la computación se volvió más lento. Incluso usando una Mac Studio M4 Max reciente con 64GB de RAM, todos los sitios web se sienten más lentos que en la época de un MacBook Pro 2011

  • Hace 15 años, internet ciertamente era más lento, pero en ese entonces no usábamos en la web hojas de cálculo complejas ni herramientas de diseño. Las Mac con chip M son las computadoras más rápidas que he usado hasta ahora (excepto desktops Linux)
  • Creo que los desarrolladores web deberían probar y desarrollar usando dispositivos del 10% inferior en especificaciones entre sus usuarios. O, si no, también podría hacerse que el rendimiento mismo sea un criterio tipo WCAG (accesibilidad web)

• En HN he visto muchas veces que Github se volvió lento al migrar su UI a React, pero me pregunto si realmente fue así. En proyectos pequeños no se nota tanto, así que quisiera encontrar evidencia más sólida

  • Un post de blog que leí recientemente explica bien la causa. En resumen, en la vista de PR se renderizan más de 100 mil nodos del DOM, y una parte considerable son nodos SVG invisibles. El análisis también dice que la navegación se vuelve mucho más lenta por el routing SPA blog relacionado / discusión en HN
  • Parece que, con el rediseño reciente de la página de diff de PR, el DOM se hizo todavía más pesado

• No solo en Safari: en Firefox Github también está increíblemente lento, aparecen spinners de carga por todos lados y los cambios de página tardan más que antes. No entiendo con qué métricas decidieron reemplazar por SPA un SSR que funcionaba perfectamente bien

  • Últimamente hay problemas parecidos incluso en Chrome. En los tres navegadores, la situación es que ni siquiera funciona bien aunque el PR no sea grande