Fija el presupuesto de rendimiento antes del diseño, no después de las quejas
El rendimiento tratado como fase de optimización siempre pierde frente a las funcionalidades. Tratado como una restricción acordada antes de diseñar, produce mejores decisiones en silencio y gratis.
Casi todos los equipos dicen que el rendimiento importa. Y casi todos lo programan como una fase cerca del final, donde compite con salir a tiempo y pierde.
Los equipos que acaban con productos rápidos hacen otra cosa, y no es optimización heroica. Deciden qué significa «lo bastante rápido» antes de que nadie abra una herramienta de diseño, y luego tratan ese número igual que la matriz de navegadores soportados: como una restricción, no como un objetivo.
Por qué falla «ya optimizaremos luego»
Tres razones, y la tercera es la que te tumba.
- Nada obliga a hacer el intercambio. Cada funcionalidad, por separado, vale lo que cuesta. Sin presupuesto nunca hay nada que diga que no, y la suma es lentitud.
- Los arreglos baratos se agotan. Compresión, caché y formatos de imagen te compran una cantidad fija y modesta. Después entras en territorio de arquitectura.
- Las causas caras son arquitectónicas. Una capa de datos que pide de más, una ruta de render bloqueada por la red, un script de terceros en la ruta crítica. Se deciden pronto y cuestan enormidades de deshacer tarde.
Para cuando puedes medir, las decisiones que determinaron el resultado tienen meses.
Qué aspecto tiene un presupuesto
Un presupuesto son unos pocos límites concretos que una compilación puede pasar o no. Los nuestros para la búsqueda de KoiSpeak, como ejemplo:
| Métrica | Presupuesto | Por qué |
|---|---|---|
| Tiempo hasta el primer resultado | Menos de 150 ms | La gente abre el diccionario a media frase. Por encima, se siente espera. |
| Largest Contentful Paint | Menos de 2,5 s en un móvil de gama media | El umbral habitual de «bueno». |
| Interaction to Next Paint | Menos de 200 ms | Escribir nunca debe notarse con retardo. |
| JavaScript enviado | Techo duro por ruta | El único número que predice a todos los demás. |
Dos propiedades hacen que un presupuesto sea real y no decorativo:
- Es un número, no un adjetivo. «Rápido» no puede hacer fallar una compilación. 150 ms sí.
- Se mide en un dispositivo que tus usuarios tienen. Un presupuesto medido en el portátil del desarrollador por el wifi de la oficina no mide nada.
Prueba en el hardware que existe de verdad
Aquí es donde la mayoría del trabajo de rendimiento se tuerce antes de empezar.
Se desarrolla en máquinas rápidas con conexiones rápidas. Tus usuarios están en móviles Android de gama media de hace unos años, con datos móviles y una docena de aplicaciones de fondo. La diferencia entre ambas experiencias no es del 20%. En trabajo limitado por CPU es habitualmente de 5 a 10 veces.
Mínimos prácticos:
- Ten un dispositivo de gama media real sobre la mesa y úsalo cada semana.
- Activa la limitación de CPU en las herramientas de desarrollo por defecto, no como ejercicio especial.
- Recoge datos de campo de sesiones reales, no solo números de laboratorio. El laboratorio dice qué cambió; el campo dice qué recibieron los usuarios.
Cómo cambia el presupuesto las decisiones
El valor no está en medir. Está en las discusiones que zanja pronto y barato, antes de construir nada.
- Una familia tipográfica se vuelve un coste. Cuatro pesos y dos familias son una fracción real del presupuesto móvil. Eliges dos pesos, en la fase de diseño, sin dramas.
- Una librería de animación tiene que justificarse frente al CSS que escribirías igualmente.
- La analítica y los widgets de chat cuentan. Los scripts de terceros son con frecuencia la partida mayor, y nadie se da cuenta porque nadie del equipo los escribió.
- La forma de los datos sigue al presupuesto. Si el primer resultado debe llegar en 150 ms, no puedes traer un payload grande y filtrar en cliente. Eso te empuja hacia un índice de prefijos, que era la respuesta correcta de todos modos.
Ese último punto es el patrón. Un presupuesto no te frena; hace evidente antes la arquitectura correcta.
El trabajo de rendimiento hecho tras el lanzamiento es una operación de rescate. El rendimiento tratado como restricción desde el principio es simplemente diseño.
Hacerlo cumplir sin ceremonias
Un presupuesto que nadie comprueba es un deseo. Que hacerlo cumplir salga barato:
- Falla la compilación por tamaño de bundle. Una línea de configuración de CI, atrapa la mayoría de regresiones y su mantenimiento es nulo.
- Lanza una auditoría sintética por cada pull request en las dos o tres rutas que más importan.
- Alerta sobre métricas de campo semanalmente, no por commit. Los datos reales son ruidosos; mira tendencias.
- Revisa el presupuesto cuando el producto cambie. No es sagrado. Subirlo deliberadamente, con motivo, está bien. Rebasarlo en silencio no.
Dónde gastar el presupuesto
Los presupuestos van de asignación, no de minimalismo. Algunas cosas valen su peso:
- La ruta crítica. Aquello a lo que vino el usuario va primero, y el resto puede esperar. En un diccionario, el buscador y el resultado. En una tienda, la imagen del producto y el precio.
- Velocidad percibida sobre velocidad medida. Mostrar un esqueleto de resultado al instante suele ganar a hacer la respuesta 40 ms más rápida.
- Respuesta inmediata a la entrada. Responder a una pulsación en unos 100 ms se percibe como instantáneo. A partir de unos 300 ms la gente lo nota.
La parte incómoda
Un presupuesto de verdad implica decir que no a cosas que, por separado, son buenas. Eso es lo que lo hace funcionar, y también por qué los equipos abandonan presupuestos en silencio: la primera vez que uno bloquea una funcionalidad que alguien quiere, lo fácil es subirlo.
La disciplina no está en fijar el número. Está en la reunión en la que lo mantienes.