La confusión entre estas dos palabras es la razón por la que casi todo el mundo contesta mal la primera pregunta de una entrevista senior.
Optimizar es hacer lo mismo más rápido. Escalar es sostener el crecimiento sin tener que cambiar el modelo cada vez.
Piensa en una carretera. Optimizar es subir el límite de velocidad: llegas antes, pero caben los mismos coches. Escalar es añadir carriles: no vas más rápido, pero caben más. Y hay una tercera cosa, que es lo que de verdad se pregunta en una entrevista: saber cuál de las dos necesita el problema.
El error clásico: te dicen "la lista va lenta" y contestas "le puse memoización a cada elemento". Eso es optimizar. Si el problema es que hay 5.000 elementos puestos, memoizar no escala: sigues teniendo 5.000. Escalar es dejar de tenerlos.
No es "¿cómo lo hago más rápido?". Es "¿qué se rompe primero cuando esto crece diez veces?". Todo lo demás es consecuencia de esa respuesta.
Un sistema no se degrada de forma uniforme: se degrada por el recurso que se agota primero. Si tienes agua, gasolina y tiempo, el viaje lo corta lo que se acabe antes. En un navegador pasa igual, y los recursos son pocos y siempre los mismos.
Por eso la palabra "lento" no significa nada por sí sola. "Lento" puede ser: demasiadas piezas puestas (nodos), demasiado trabajo de una vez (hilo principal), demasiada memoria, o demasiadas idas y vueltas por la red. Son cuatro enfermedades distintas con cuatro tratamientos distintos, y casi nadie empieza preguntando cuál es.
El método tiene cinco pasos y el orden importa. Si te saltas el primero, optimizas lo que no era; si te saltas el quinto, vuelves al mismo problema en seis meses.
El quinto paso es el que casi nadie da y el que más se nota, porque demuestra que piensas en sistemas y no en tickets.
La diferencia se ve mejor en código. Las dos versiones de abajo hacen "lo mismo" para el usuario, pero solo una deja de costar más cuando la lista crece:
// OPTIMIZAR: el mismo modelo, con menos trabajo por fila const Fila = memo(function Fila({ dato }) { return <li>{dato.nombre}</li> }); // sigue habiendo 8.000 filas puestas // ESCALAR: otro modelo — solo existe la ventana visible const [scroll, setScroll] = useState(0); const desde = Math.floor(scroll / ALTO); const hasta = desde + filasVisibles + OVERSCAN; return ( <div style={{ height: datos.length * ALTO }}> // el scroll miente {datos.slice(desde, hasta).map((dato) => ( // solo ~40 existen <Fila key={dato.id} dato={dato} /> ))} </div> );
Si mañana llegan 80.000 filas en vez de 8.000, la primera versión se vuelve 10 veces más lenta. La segunda no se entera: el trabajo depende del tamaño de la ventana, no del tamaño de los datos. Esa es la prueba de que escalaste.
"Diagnosticar" aquí significa responder a una sola pregunta: ¿cuál de los cuatro recursos se está agotando? Se contesta con método, no con intuición.
| Herramienta | Qué se mira | Cómo se ve el síntoma |
|---|---|---|
| DevTools › Performance | Tareas largas y repintados | Barras rojas de más de 50 ms; el frame rate cae a 10–15 fps |
| DevTools › Network | Forma de la cascada y peso | Una escalera de peticiones encadenadas, o 2 MB de JS antes del primer texto |
| Elements | Cuántos nodos hay puestos | Miles de elementos en el árbol; el scroll recalcula todo |
| Memory › heap snapshot | Objetos que no se liberan | El conteo de objetos "detached" crece entre dos tomas |
En una entrevista no vas a abrir DevTools. Razona desde los recursos: en un navegador solo se agotan cuatro cosas — nodos, tiempo del hilo principal, memoria y red; en un servidor, otras cuatro — conexiones, escrituras por segundo, tamaño de cola y costo de consulta.
Y dilo así: "Let me figure out which resource this is before I propose a fix." Eso convierte un "no sé" en método.
“Scaling isn't making it faster. It's changing what breaks.”
“In a browser there are only four things to run out of: DOM nodes, main-thread time, memory, and network.”
“This gets us to about X. Past that, the model breaks and here's what I'd change.”
Comprueba que lo tienes
Cuatro preguntas. Al comprobar se marca la lección como completada.
Una tabla de 8.000 filas va lenta. Añades memo a cada fila y sigue igual de lenta. ¿Qué falla?
Por qué: el costo no estaba en recalcular cada fila, sino en tener 8.000 filas puestas. Memoizar reduce el trabajo por fila, pero sigue habiendo 8.000. El arreglo de escala es no montarlas.
¿Cuál de estas cuatro frases describe una decisión de escalabilidad y no de optimización?
Por qué: comprimir hace lo mismo más pequeño (optimizar); cambiar a una ventana con cursor cambia el modelo: ya no existe la lista completa en ningún sitio, así que crecer deja de costar lo mismo.
Tu app tarda 9 segundos en aparecer y el servidor responde en 40 ms. ¿Cuál de los cuatro recursos es el sospechoso?
Por qué: si el servidor contesta rápido, el tiempo se está yendo en descargar y ejecutar JavaScript, o en una cascada de peticiones. Los nodos y la memoria se notan al interactuar, no al cargar.
¿Por qué el paso "¿qué se rompe después?" vale tanto en una entrevista?
Por qué: cualquiera puede proponer una solución. Decir en qué punto tu propia solución deja de servir es la señal más clara de que piensas en sistemas y no en tickets.