El rendimiento es una decisión de diseño, no un paso de optimización
Por qué la velocidad se determina mucho antes de que entren en juego las auditorías y las herramientas.
Es un patrón familiar en el desarrollo de software: construir primero las funcionalidades, asegurar que todo funcione y luego, justo antes del lanzamiento, programar un “sprint de rendimiento” para hacerlo rápido.
Tratamos la velocidad como una capa de acabado, algo que se aplica una vez terminado el trabajo estructural. Pero este enfoque se basa en una premisa errónea: que el rendimiento es algo que se puede añadir. En realidad, el rendimiento es principalmente el resultado de lo que decides no incluir.
Una vez que un sistema se ha orquestado en torno a dependencias pesadas y una lógica compleja en el lado del cliente, ninguna cantidad de división de código o compresión de imágenes puede solucionarlo realmente. No se puede optimizar un desajuste arquitectónico fundamental.
La velocidad es arquitectura
El rendimiento no es una métrica que deba perseguirse; es una restricción sobre la cual se debe diseñar.
Cuando vemos el rendimiento como una decisión de diseño, reconocemos que cada elección —desde la infraestructura de hosting hasta el framework de UI— conlleva un coste. El objetivo no es obtener una puntuación perfecta en Lighthouse, sino construir un sistema que respete el tiempo y los recursos del usuario por defecto.
Un sitio que carga instantáneamente no está simplemente “optimizado”. Es respetuoso. Indica que el equipo de ingeniería valora la eficiencia y la estabilidad por encima de la comodidad del desarrollador.
La ilusión del ancho de banda
A menudo construimos en máquinas rápidas, con conexiones de fibra estables y en entornos controlados. Olvidamos que la internet pública es hostil. Las redes móviles fluctúan, la latencia aumenta y los dispositivos envejecen.
Si tu diseño depende de condiciones óptimas para sentirse rápido, es, probablemente, frágil. Un sistema resiliente está diseñado para funcionar bien incluso cuando las condiciones son adversas. Aquí es donde ocurre la toma de decisiones:
1. Presupuestos antes que código
Antes de escribir una sola línea de código, deberíamos establecer restricciones válidas. ¿Cuánto JavaScript es razonable? ¿Cuál es el tiempo máximo aceptable para la interactividad (Time to Interactive)? Las decisiones de diseño deben encajar en estos presupuestos. Si una funcionalidad supera el límite del tamaño del paquete, la solución no es cargar el exceso mediante lazy loading, sino replantear la funcionalidad o su implementación.
2. El coste de la abstracción
Las herramientas modernas ofrecen una potencia increíble, pero a menudo a costa de capas de abstracción que terminan en el navegador del usuario. Aunque la experiencia del desarrollador es importante, nunca debería ir en detrimento de la experiencia del usuario. Preferimos soluciones que envíen menos código, adhiriéndose a las capacidades nativas de la plataforma (HTML y CSS) siempre que sea posible.
3. Restar, no sumar
La petición más rápida es la que nunca se hace. El código más rápido es el que no existe. En lugar de preguntar “¿qué herramienta puede hacer esto más rápido?”, preguntamos “¿qué podemos eliminar sin perder valor?”. La simplificación es la herramienta de optimización más potente que existe.
Estabilidad por encima de velocidad
Idealmente, no buscamos solo velocidad bruta, sino consistencia. Un sistema que responde de manera predecible genera confianza. Uno que requiere un spinner de carga para interacciones básicas la erosiona.
La estabilidad a largo plazo nos obliga a aceptar que no podemos controlar el entorno del cliente. Solo podemos controlar lo que le enviamos. Al tomar decisiones conservadoras y reflexivas sobre nuestra arquitectura, aseguramos que el sistema siga siendo eficiente durante años, no solo el día del estreno.
El rendimiento no es un paso en el proceso. Es el proceso.