El rendiment és una decisió de disseny, no un pas d'optimització
Per què la velocitat es determina molt abans que entrin en joc les auditories i les eines.
És un patró familiar en el desenvolupament de programari: construir primer les funcionalitats, assegurar que tot funcioni i després, just abans del llançament, programar un “esprint de rendiment” per fer-ho ràpid.
Tractem la velocitat com una capa de polida, que s’aplica un cop acabada la feina estructural. Però aquest enfocament es basa en una premissa errònia: que el rendiment és quelcom que es pot afegir. En realitat, el rendiment és principalment el resultat de què decideixes no incloure.
Un cop un sistema s’ha orquestrat entorn de dependències pesades i una lògica complexa en el costat del client, cap quantitat de divisió de codi o compressió d’imatges pot solucionar-ho realment. No es pot optimitzar un desajust arquitectònic fonamental.
La velocitat és arquitectura
El rendiment no és una mètrica que s’hagi de perseguir; és una restricció sobre la qual s’ha de dissenyar.
Quan veiem el rendiment com una decisió de disseny, reconeixem que cada elecció —des de la infraestructura de hosting fins al framework de UI— comporta un cost. L’objectiu no és obtenir una puntuació perfecta a Lighthouse, sinó construir un sistema que respecti el temps i els recursos de l’usuari per defecte.
Un lloc que carrega a l’instant no està simplement “optimitzat”. És respectuós. Indica que l’equip d’enginyeria valora l’eficiència i l’estabilitat per sobre de la comoditat del desenvolupador.
La il·lusió de l’amplada de banda
Sovint construïm en màquines ràpides, amb connexions de fibra estables i en entorns controlats. Oblidem que la internet pública és hostil. Les xarxes mòbils fluctuen, la latència augmenta i els dispositius envelleixen.
Si el teu disseny depèn de condicions òptimes per sentir-se ràpid, és, probablement, fràgil. Un sistema resilient està dissenyat per funcionar bé fins i tot quan les condicions són adverses. Aquí és on passa la presa de decisions:
1. Pressupostos abans que codi
Abans d’escriure una sola línia de codi, hauríem d’establir restriccions vàlides. Quant JavaScript és raonable? Quin és el temps màxim acceptable per a la interactivitat (Time to Interactive)? Les decisions de disseny han d’encaixar en aquests pressupostos. Si una funcionalitat supera el límit de la mida del paquet, la solució no és carregar l’excés mitjançant lazy loading, sinó replantejar la funcionalitat o la seva implementació.
2. El cost de l’abstracció
Les eines modernes ofereixen una potència increïble, però sovint a costa de capes d’abstracció que acaben al navegador de l’usuari. Encara que l’experiència del desenvolupador és important, mai hauria d’anar en detriment de l’experiència de l’usuari. Preferim solucions que enviïn menys codi, adherint-se a les capacitats natives de la plataforma (HTML i CSS) sempre que sigui possible.
3. Restar, no sumar
La petició més ràpida és la que no es fa mai. El codi més ràpid és el que no existeix. En lloc de preguntar “quina eina pot fer això més ràpid?”, preguntem “què podem eliminar sense perdre valor?”. La simplificació és l’eina d’optimització més potent que existeix.
Estabilitat per sobre de velocitat
Idealment, no busquem només velocitat bruta, sinó consistència. Un sistema que respon de manera predictible genera confiança. Un que requereix un spinner de càrrega per a interaccions bàsiques l’erosiona.
L’estabilitat a llarg termini ens obliga a acceptar que no podem controlar l’entorn del client. Només podem controlar el que li enviem. En prendre decisions conservadores i reflexives sobre la nostra arquitectura, assegurem que el sistema continuï sent eficient durant anys, no només el dia de l’estrena.
El rendiment no és un pas en el procés. És el procés.