Chrome vs Safari en una Mac vieja: lo que nadie te dice sobre RAM y disco

Mientras diagnosticaba mi MacBook 2015 lenta, algo saltaba en cada foto de Activity Monitor: Chrome, con apenas 6 u 8 pestañas abiertas, aparecía repetido más de una decena de veces en la lista de procesos, cada instancia consumiendo su propia porción de memoria. Safari, con una cantidad similar de pestañas, apenas aparecía dos o tres veces.

La explicación popular es "Chrome es lento por las extensiones". Es parcialmente cierta, pero no es la razón principal — y quedarse en esa explicación lleva a soluciones que no resuelven el problema de fondo (desinstalar dos extensiones y seguir igual de lento).

La razón real: arquitectura multi-proceso

Desde 2008, Chrome usa una arquitectura donde cada pestaña, cada extensión y varios componentes internos corren como procesos del sistema operativo independientes, en lugar de compartir un solo proceso como hacían los navegadores más antiguos. La ventaja es real: si una pestaña se congela o falla, no se cae el navegador completo. La desventaja también: cada proceso independiente reserva su propia porción de memoria, y esa multiplicación es lo que hace que Chrome con 10 pestañas pueda consumir varias veces más RAM que Safari con la misma cantidad.

A eso se suma un patrón menos visible: Chrome escribe constantemente a disco — caché de cada sitio, datos de perfil, sincronización de extensiones. En un SSD moderno esa escritura es casi imperceptible. En un SSD más lento o en una Mac con RAM al límite (donde el sistema empieza a usar swap, que también es lectura/escritura a disco), ese patrón se acumula con el resto de la actividad del sistema y contribuye directamente al tipo de saturación de I/O que documenté en el artículo anterior de esta serie.

Por qué se siente peor en hardware limitado

En una MacBook con 16GB de RAM o más, la diferencia entre Chrome y Safari es perceptible pero manejable. En una Mac con 8GB — que en 2026 es poco para trabajo de desarrollo con varias herramientas abiertas — Chrome puede llevar al sistema a usar swap con relativa facilidad, y ahí es donde la lentitud se vuelve notoria: no es que Chrome "sea lento", es que la combinación de RAM limitada y un navegador que reserva memoria de forma agresiva empuja al sistema a un estado de saturación.

Qué se pierde y qué no al migrar a Safari

Para trabajo diario de oficina, navegación y consumo de contenido, la migración a Safari es prácticamente transparente. Lo que hay que resolver antes de migrar:

• Bookmarks y contraseñas — Chrome permite exportar ambos desde su configuración; Safari los importa directamente
• Extensiones equivalentes — la mayoría de los bloqueadores de anuncios y gestores de contraseñas populares tienen versión nativa para Safari
• Sincronización entre dispositivos — Safari sincroniza vía iCloud si ya usas el ecosistema Apple, sin cuenta adicional
• DevTools — Safari tiene herramientas de desarrollo propias, pero no son intercambiables con las de Chrome si tu flujo depende de extensiones específicas de Chrome DevTools

Cuándo sí conviene mantener Chrome

Para quienes desarrollamos sitios web, Chrome sigue siendo necesario — no como el navegador que corre abierto todo el día de fondo, sino específicamente para testing cross-browser y depuración. La recomendación práctica que apliqué en mi propio flujo: Safari como navegador principal para trabajo diario, Chrome abierto solo cuando el testing lo requiere. El resultado se nota de inmediato en el Load Average del sistema.