Cuando alguien me pide una animación para una web, mi primer impulso —el impulso de cualquiera que lleve años programando— es abrir la lista mental de librerías que resuelven eso en cinco minutos. GSAP, Framer Motion, alguna cosa de scroll. Funcionan bien, están muy probadas, y añaden entre 30 y 100 KB de JavaScript que el visitante tiene que descargar, parsear y ejecutar antes de ver nada.
Ya he escrito antes sobre por qué eso tiene un coste real en rendimiento y en huella de carbono. Pero hay una consecuencia de imponerte ese límite que no había contado todavía: cuando te prohíbes la solución fácil, apareces con ideas mejores de las que habrías tenido con vía libre.
Qué es en la práctica un presupuesto de rendimiento
Un presupuesto de rendimiento (performance budget) es, sencillamente, un número que decides antes de escribir la primera línea de código. Puede ser un peso máximo de JavaScript por página (por ejemplo, 30 KB comprimidos). Puede ser un número máximo de peticiones HTTP. Puede ser un tiempo objetivo de LCP, o un límite de CLS que no estás dispuesto a superar por ninguna animación, por bonita que sea.
Lo importante no es el número exacto, sino el momento en que lo fijas: antes de diseñar la solución, no después como una revisión de última hora. Esto es distinto de perseguir una puntuación de Lighthouse a posteriori, que es una trampa de la que ya hablé en otro artículo. Un presupuesto no es una nota que sacas al final del examen; es la regla del juego que conoces antes de sentarte a jugar.
En este mismo sitio, el presupuesto no está escrito en ningún documento formal, pero existe: CSS embebido en el <head> sin hojas de estilo externas, sin librerías de animación, imágenes servidas en tres formatos con LQIP generado en el build, y JavaScript reducido a lo estrictamente necesario. No es una lista de restricciones que me impongo por pureza ideológica. Es una lista de restricciones que me obliga a pensar mejor cada solución.
Por qué el límite produce más ideas, no menos
Esto parece contraintuitivo. Se supone que la creatividad necesita libertad, no jaulas. Pero cualquiera que haya trabajado dentro de un límite de verdad —de tiempo, de presupuesto, de tecnología— sabe que ocurre justo lo contrario: la libertad total paraliza, porque todas las opciones parecen igual de válidas y ninguna se impone con claridad. El límite, en cambio, descarta el 90% del espacio de soluciones automáticamente y te deja pensando solo en lo que sí cabe.
Cuando me niego a usar una librería de animación, la pregunta deja de ser "¿qué librería uso?" y pasa a ser "¿qué puede hacer CSS por sí solo aquí?". Y esa pregunta, la mayoría de las veces, tiene una respuesta más elegante de lo que esperaba. Una transición de opacity y transform con @media (prefers-reduced-motion) respetado resuelve el 80% de lo que cualquier librería resolvería, pesa cero bytes adicionales de JavaScript y no tiene que mantenerse actualizada frente a la próxima versión mayor de una dependencia.
No es que el límite haga el trabajo más fácil. Lo hace más difícil en el momento, y más simple en el resultado. La solución que encuentras dentro de un presupuesto ajustado casi siempre es más legible que la que habrías montado con vía libre, porque no tiene margen para la solución perezosa.
Cómo fijar el tuyo antes de empezar
Si nunca has trabajado con un presupuesto de rendimiento explícito, la forma más simple de empezar es esta: antes de abrir el editor, escribe tres números. Cuánto JavaScript total te permites por página. Cuántas peticiones de red como máximo. Y un tiempo de carga objetivo en una conexión 4G razonable, no en tu fibra de oficina.
Esos tres números se convierten en el filtro de cada decisión posterior. ¿Necesitas un carrusel de imágenes? Antes de instalar una librería, comprueba si scroll-snap en CSS puro te da el 90% del efecto por cero JavaScript. ¿Necesitas una transición entre páginas? Antes de montar un router del lado del cliente, mira si la View Transitions API nativa del navegador ya resuelve el caso simple que tienes entre manos. ¿Necesitas cargar contenido bajo demanda? El atributo loading="lazy" en una etiqueta <img> cubre buena parte de los casos que antes exigían una librería de lazy loading completa.
En ningún caso digo que la librería esté prohibida para siempre. Digo que, dentro de un presupuesto, la librería tiene que ganarse su sitio demostrando que hace algo que la plataforma no hace ya de forma nativa. Y sorprendentemente a menudo, no lo hace.
Lo que el presupuesto no resuelve
Hay que ser honesto con los límites del propio límite. Un presupuesto de rendimiento no sustituye al buen criterio, y hay proyectos donde no se puede cumplir sin sacrificar algo que el cliente necesita de verdad: una demo 3D interactiva para un producto industrial, un configurador visual complejo, un editor en el navegador. Ahí el presupuesto no desaparece, pero se negocia con conocimiento de causa, no se ignora por comodidad.
Tampoco es gratis decir que no. Cuando alguien te pide un efecto concreto y tu presupuesto no lo admite sin romperse, tienes que ofrecer la alternativa que sí cabe, y a veces esa alternativa gusta menos a primera vista que la idea original. Ahí es donde se nota si el presupuesto es una herramienta de trabajo o una excusa: si eres capaz de explicar por qué la versión más ligera es mejor para quien va a usar la web, el límite se sostiene. Si solo te sirve para no complicarte la vida, no es un presupuesto de rendimiento, es pereza con otro nombre.
Lo que más me gusta de trabajar con un presupuesto fijado de antemano no es el número final en Lighthouse, del que ya hablé en otro sitio con la distancia que merece. Es que cambia la pregunta que me hago al empezar cada tarea. Ya no pregunto "¿cómo lo hago?", sino "¿cómo lo hago dentro de esto?". Y esa segunda pregunta, casi siempre, es la que produce la solución de la que más orgulloso acabo estando.
