Por qué Linear se siente tan rápido

Linear se siente rápido por una razón simple: no depende de una sola técnica. Su sensación de velocidad sale de varias decisiones pequeñas que, juntas, reducen el tiempo entre tu acción y el resultado visible. No es solo “optimizar React” ni solo “usar una buena API”. Es una combinación de renderizado cuidadoso, sincronización eficiente, estado local bien pensado y una arquitectura que evita trabajo innecesario.

Si tú construyes una app SaaS, este análisis te sirve aunque no estés haciendo un clon de Linear. Lo útil no es copiar su producto, sino entender los patrones: qué se debe renderizar, cuándo pedir datos, cómo evitar bloqueos en la UI y cómo diseñar una app que parezca instantánea incluso cuando la red no lo es.

La sensación de velocidad no empieza en la red

Cuando una app se siente lenta, muchas veces el problema no está en la API. Está en el navegador. Si cada clic dispara un rerender grande, si la interfaz espera a que llegue el servidor para mostrar algo, o si la pantalla completa depende de un solo estado global, tu usuario percibe fricción aunque el backend responda en 120ms.

Linear aprovecha algo que en SaaS modernas se subestima: la percepción manda. Si el usuario ve feedback inmediato, la app se siente rápida incluso si la operación completa tarda un poco más. Eso se logra con optimismo controlado: actualizar la UI de forma local, confirmar después con el servidor y resolver conflictos sin interrumpir el flujo.

En productos de gestión, la diferencia entre una app “rápida” y una “pesada” suele estar en milisegundos de interacción. Un botón que responde en 50ms se siente inmediato. Uno que espera 300ms ya empieza a notarse. No necesitas una medición perfecta para verlo: basta con abrir una lista, marcar un item y observar si la pantalla parpadea, se congela o mantiene continuidad.

Lo que el usuario realmente percibe

Tu usuario no mide CPU, mide continuidad. Si el cursor se mueve fluido, la lista no salta y el cambio aparece sin recargar toda la vista, la experiencia se siente sólida. Si, en cambio, un clic provoca un spinner global y luego una reconfiguración completa del DOM, la percepción cambia aunque el servidor haya sido eficiente.

Hay tres señales que suelen definir esa sensación:

1. Respuesta visual inmediata al input.
2. Cambios locales en lugar de rerenders masivos.
3. Estados intermedios claros: loading, optimistic, confirmed, error.

Eso explica por qué muchas apps modernas adoptan patrones como optimistic updates, suspense parcial, virtualización de listas y prefetching. No son adornos. Son herramientas para que la interfaz nunca parezca bloqueada.

Renderizado: menos trabajo por interacción

Una parte importante de la velocidad de Linear viene de no obligar al navegador a rehacer más de lo necesario. En una app de tareas, issue tracker o CRM, el error común es hacer que una acción simple toque demasiados componentes. Si cambias un estado global y eso hace rerender de toda la app, pagas un costo innecesario.

La idea es dividir la interfaz en piezas más pequeñas y conectarlas con precisión. Así, cuando editas el título de una tarea, no deberían volver a calcularse la barra lateral, el panel de filtros y el historial completo. Solo lo necesario.

Esto encaja muy bien con React moderno, pero no es exclusivo de React. También aplica a cualquier UI basada en componentes: el árbol debe ser predecible, los props deben ser estables y el estado debe vivir lo más cerca posible del lugar donde se usa.

Evitar rerenders en cascada

Un rerender no siempre es malo. El problema es el rerender en cascada, cuando un cambio pequeño dispara una cadena de actualizaciones que terminan afectando pantallas enteras. Eso suele pasar por tres motivos:

• Estado global demasiado amplio.
• Selectores poco precisos.
• Props nuevas en cada render, aunque el contenido no cambie.

En una app SaaS, esto se traduce en listas que se vuelven a pintar, modales que pierden foco y paneles laterales que se recalculan sin necesidad. Si tienes 200 items visibles y cada uno renderiza 5 subcomponentes, el costo crece rápido.

Un patrón útil es separar el estado de lectura del estado de edición. Por ejemplo, la lista puede leer datos desde un cache compartido, pero el formulario de edición puede manejar su propio estado local hasta confirmar el cambio. Así reduces el área de impacto de cada interacción.

Virtualización y listas grandes

Linear trabaja con interfaces donde hay muchas entidades: issues, proyectos, comentarios, estados, etiquetas. En ese tipo de producto, renderizar todo lo que existe en memoria no escala bien. La virtualización resuelve parte del problema porque solo pinta lo que entra en pantalla.

Esto es especialmente útil en listas largas, historiales de actividad y tablas densas. Si el usuario ve 20 filas, no necesitas montar 2,000 nodos DOM al mismo tiempo. La diferencia en performance y memoria es real, y en máquinas medias o navegadores con varias pestañas abiertas se nota más.

No hace falta adivinar si te beneficia. Haz una prueba simple: mide tiempo de render inicial y FPS al hacer scroll con y sin virtualización. En muchas apps SaaS, la mejora es visible desde el primer prototipo.

Sincronización: la app no espera, se adelanta

La otra clave de Linear está en cómo maneja la sincronización. Una app rápida no es solo la que responde rápido, sino la que mantiene el flujo aunque haya red, latencia o actualización en segundo plano. Ahí entra el diseño de sincronización incremental.

En lugar de recargar todo el estado cada vez que cambia algo, la app puede recibir deltas, aplicar cambios locales y reconciliar después. Eso reduce tráfico, evita parpadeos y mantiene la interfaz viva. Para el usuario, el resultado es simple: la app no se siente como una página que carga, sino como una herramienta que ya está lista.

Esto es crítico en productos colaborativos. Si varias personas editan el mismo espacio, el sistema debe resolver conflictos sin borrar lo que el usuario está haciendo. Cuanto menos interrumpas el contexto, más fluida se siente la app.

Estado optimista con reconciliación

El estado optimista funciona así: tú haces una acción, la UI se actualiza de inmediato y luego el servidor confirma o corrige. Si el sistema está bien diseñado, ese ida y vuelta no rompe la experiencia. Si está mal diseñado, aparecen duplicados, saltos visuales o mensajes de error tardíos.

Un ejemplo común es cambiar el estado de una tarea. La app puede moverla a “Done” al instante, registrar la mutación en segundo plano y corregir solo si hay conflicto. Ese patrón reduce la latencia percibida y evita que el usuario espere por una confirmación que, en la práctica, no necesita ver.

La clave está en tener una capa de reconciliación clara. No basta con “hacer optimistic update”. Necesitas saber cómo revertir, cómo fusionar cambios y cómo mantener consistencia cuando llegan eventos fuera de orden.

WebSockets, polling y eventos

No todas las apps necesitan tiempo real total. A veces, polling cada cierto intervalo es suficiente. Otras veces, WebSockets o SSE son mejores porque reducen la latencia de actualización. La elección depende del tipo de interacción y de cuánto importa la inmediatez.

Para un tablero colaborativo, un issue tracker o una herramienta de soporte, la sincronización por eventos suele tener más sentido que refrescar toda la vista. Si un comentario nuevo llega por evento, no necesitas volver a pedir toda la conversación. Si cambió un estado, actualizas solo ese fragmento.

Según la documentación oficial de MDN, WebSocket permite comunicación bidireccional persistente entre cliente y servidor, útil cuando necesitas intercambio continuo de datos: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API. Esa persistencia ayuda, pero también exige más disciplina en el manejo de reconexión, orden de eventos y consumo de memoria.

Arquitectura de datos: cachear bien es parte de la velocidad

La velocidad percibida no depende solo de pintar rápido. También depende de cuánto trabajo evitas. Si cada pantalla hace una consulta nueva aunque ya tengas los datos en memoria, estás pagando doble: red y render. Linear reduce ese costo con una arquitectura que favorece cache, normalización y acceso predecible.

En apps SaaS modernas, la arquitectura de datos define si la interfaz se siente confiable o errática. Cuando el cache está bien diseñado, puedes navegar entre pantallas sin esperar cargas completas. Cuando está mal diseñado, cada cambio parece empezar desde cero.

Esto es especialmente importante si tu producto tiene relaciones complejas: usuarios, equipos, proyectos, permisos, etiquetas, vistas guardadas. Si duplicas datos sin control, mantener coherencia se vuelve caro. Si normalizas demasiado sin pensar en la lectura, terminas con consultas difíciles y UI más frágil.

Cache local, invalidación y consistencia

El cache no sirve solo para acelerar. Sirve para desacoplar la experiencia del tiempo de red. Si el usuario vuelve a una vista que ya visitó, no debería pagar la misma carga completa otra vez. Pero el cache también necesita reglas claras de invalidación, o mostrarás datos viejos.

Una estrategia práctica es combinar tres capas:

• Cache en memoria para navegación inmediata.
• Persistencia local para reabrir la app sin empezar de cero.
• Revalidación en segundo plano para corregir cambios.

Ese modelo no es gratis: complica la lógica. Pero en productos donde el usuario pasa horas trabajando, vale la pena. Lo importante es que la UI no dependa de una única fuente de verdad que bloquee todo el flujo.

Normalización de datos y selectores

Cuando los datos están normalizados, puedes actualizar una entidad una sola vez y propagar el cambio a las vistas que la usan. Eso evita inconsistencias y reduce payloads redundantes. En una app con miles de issues, repetir el mismo objeto en cada pantalla es una receta para cargar más de la cuenta.

Los selectores también importan. Si seleccionas solo el fragmento que necesitas, reduces rerenders y haces más predecible el comportamiento. Si un componente recibe un objeto gigante con campos que no usa, cualquier cambio en ese objeto puede forzar trabajo extra.

Para aterrizarlo, piensa en una vista de proyecto con 3 paneles: lista, detalle y actividad. Si cada panel escucha todo el estado global, editar una etiqueta puede tocar los 3. Si cada panel consume su slice de datos, el costo baja y la sensación de velocidad sube.

Qué puedes copiar en tu SaaS hoy

No necesitas la escala de Linear para aplicar sus patrones. De hecho, muchas mejoras útiles se pueden implementar en una app pequeña o mediana sin reescribir todo. La ventaja es que el usuario nota la diferencia rápido, y tú puedes medirla con herramientas básicas.

Empieza por identificar las interacciones que más se usan: abrir una vista, editar un campo, cambiar estado, buscar, navegar entre secciones. Ahí es donde una mejora de 100ms o 200ms cambia la percepción del producto.

Si trabajas con un equipo en Latinoamérica, también hay un factor práctico: no todos tus usuarios tienen la misma conexión o el mismo hardware. Una app que depende de cargas pesadas y rerenders innecesarios castiga más en equipos de gama media, redes móviles o contextos con varias pestañas abiertas.

Prioridades de implementación

Si quieres un plan concreto, este orden suele dar buen resultado:

1. Mide la interacción más frecuente con React DevTools, Performance panel o Web Vitals.
2. Reduce el estado global y mueve estado efímero al componente que lo usa.
3. Virtualiza listas largas y tablas con más de 100 filas visibles.
4. Implementa optimistic updates en acciones de bajo riesgo.
5. Revalida datos en segundo plano en lugar de recargar pantallas completas.
6. Revisa props, memoización y selectores para evitar rerenders en cascada.

No intentes optimizar todo al mismo tiempo. Si el problema real es una lista pesada, no vas a arreglarla con más cache. Si el problema es una mutación que bloquea la UI, no lo solucionas solo con virtualización.

Herramientas que sí valen la pena

La documentación oficial de React es un buen punto de partida para entender renderizado, memoización y composición de componentes: https://react.dev. Si usas Next.js, su guía de rendering y caching también te puede ayudar a decidir qué va en servidor y qué va en cliente: https://nextjs.org/docs.

La elección de herramientas no reemplaza el criterio. Puedes tener el stack más moderno y seguir sintiendo lentitud si tu arquitectura fuerza trabajo innecesario. La pregunta correcta no es “¿qué framework usa Linear?”, sino “¿qué parte de mi UI está haciendo demasiado trabajo por cada interacción?”.

Tabla resumen

Linear no es rápido por una sola decisión brillante. Es rápido porque cada capa evita fricción: renderiza lo justo, sincroniza sin bloquear y modela los datos para que la UI no tenga que rehacer trabajo que ya hizo. Ese es el patrón que te conviene copiar.

Si tú construyes una app SaaS, la lección es clara: la velocidad percibida se diseña. No depende solo del framework ni de la infraestructura. Depende de cuántas veces obligas al usuario a esperar, mirar un spinner o ver la pantalla reacomodarse por completo.

Preguntas frecuentes sobre performance en SaaS

¿Linear es rápido solo por usar buen frontend?

No. El frontend ayuda, pero la velocidad percibida sale de varias capas trabajando juntas. Si tu backend responde bien pero la UI rehace demasiado trabajo, igual vas a sentir lentitud.

¿Optimistic updates siempre son buena idea?

No siempre. Funcionan mejor en acciones de bajo riesgo, como cambiar estados o editar texto corto. Si la operación puede fallar con frecuencia o afecta datos críticos, necesitas una estrategia más conservadora.

¿Qué es más importante, virtualización o cache?

Depende del problema. Si tienes listas enormes, la virtualización te da una mejora inmediata en render y memoria. Si el dolor está en navegación repetida o datos que se vuelven a pedir, el cache te va a rendir más.

¿Cómo sé si mi app tiene rerenders innecesarios?

Puedes verlo con React DevTools y el panel Performance del navegador. Si un cambio pequeño hace que se actualicen componentes que no usan ese dato, tienes una señal clara de sobre-renderizado.

¿WebSockets son obligatorios para tiempo real?

No. Para algunos casos, polling o SSE basta. WebSockets sirven cuando necesitas comunicación bidireccional persistente y eventos frecuentes, pero también agregan complejidad de reconexión y manejo de estado.

¿Esto aplica a equipos pequeños en Latinoamérica?

Sí, y mucho. En equipos pequeños conviene priorizar patrones que mejoren la experiencia con menos infraestructura, porque eso reduce soporte y hace más estable el producto en redes y dispositivos variados.

¿Qué métrica debería mirar primero?

Empieza por el tiempo de interacción percibida: cuánto tarda la app en responder después de un clic o una edición. Luego revisa render time, tamaño de bundle y cantidad de trabajo en la pantalla que más usas.