Reconstruimos nuestra web quitando cosas

Nuestra web tenía dos de cada cosa. Dos hojas de estilo, dos paquetes de JavaScript, dos versiones de cada plantilla — una para el sitio que la gente veía, otra para el sitio que ya habíamos sustituido. Un interruptor en un fichero de configuración decidía cuál te tocaba, y llevaba meses respondiendo siempre lo mismo.

Es un estado normal durante una reconstrucción. Es un mal estado para dejar funcionando, porque la versión que nadie mira sigue costando. Cada página enviaba 28KB de JavaScript escrito para una maqueta que ya no existía. Cada despliegue arrastraba 240KB de CSS que ningún navegador llegaba a interpretar. Y cada cambio había que hacerlo dos veces — o hacerlo una y olvidarlo en la otra copia.

Así que lo borramos. 6865 líneas, 560KB de ficheros, el marcado de diecinueve plantillas de un sitio que ya había sido sustituido. El resultado es una web que hace más que el mes pasado y pesa bastante menos.

«Menos es más» es un presupuesto, no un estado de ánimo

«Menos es más» se usa como argumento de gusto — menos cajas, más espacio en blanco, tipografía más tranquila. Esa parte es cierta, y es la fácil. La versión que de verdad cambia cómo se siente un sitio es la que se puede contar: cada elemento de la página tiene que justificar sus bytes, su tiempo de parseo y su pintado.

Una fotografía de portada se justifica. Una segunda copia de la misma fotografía, descargada a 2400px porque nadie escribió un srcset, no. Un cursor dibujado a mano se justifica si te dice qué vas a pulsar. Un carrusel de logotipos de clientes que nadie recorre no — y ese lo quitamos del diseño original antes incluso de publicarlo.

La disciplina es la misma que aplicamos en proyectos de clientes: puedes añadir algo bonito, siempre que sepas decir qué cuesta y qué sustituye.

Lo que se fue

La lista completa, porque las afirmaciones vagas sobre «optimización» no valen nada:

• La hoja de estilo antigua y el paquete antiguo. main.css (240KB sumando ambas copias) y main.js (74KB) ya no están. Lo que el sitio actual usaba de verdad de aquel paquete — búsqueda, selector de idioma, aviso de cookies, formulario de contacto, franja de clientes — se recortó literalmente a un único fichero de 11,7KB. No reescrito. Recortado, para que nada pudiera cambiar de comportamiento por el camino.
• Cinco ficheros de «critical CSS» que ninguna plantilla incluía desde la reconstrucción, y un parcial de navegación móvil para una navegación que ya no existe.
• Un diorama 3D — 45KB de JavaScript y una textura de 167KB — que la portada de niebla había sustituido y seguía en el repositorio.
• Un modal de proyectos que abría los casos en una capa superpuesta. Se enganchaba a nombres de clase que las plantillas actuales nunca escriben, que es una manera educada de decir que llevaba meses muerto.

Lo que aligeramos en vez de borrar

La portada es una fotografía de niebla atravesando el pinar a las afueras de Leiria, dibujada en WebGL con una capa de ruido deformado por delante. Es lo más caro del sitio, y se queda, porque es el argumento: construimos cosas más difíciles de lo que necesitan ser, con cuidado.

Lo que no necesita es llegar dos veces. La página precargaba un JPEG de 113KB para la portada móvil y descargaba aparte una versión de 247KB como textura de WebGL — la misma fotografía, dos veces, en dos tamaños. Ahora hay una imagen en tres formatos: 27KB de AVIF para quien lo entiende, 29KB de WebP para el resto, y el JPEG original debajo para lo más antiguo. Medido contra el original, el AVIF da 41dB de PSNR, que es la forma técnica de decir que nadie ve la diferencia.

Lo mismo en el resto de la página. Las imágenes a sangre pedían 2000px daba igual la pantalla que hubiera delante. Ahora llevan una escalera de anchos, así que un móvil descarga una fotografía de tamaño de móvil: 461KB de imágenes en móvil, frente a más de un megabyte.

El fallo que solo veía un navegador limpio

Hay un hallazgo que merece quedar escrito, porque es de los que se esconden durante meses.

Nuestro servidor le dice a los navegadores que guarden el JavaScript un año, marcado como immutable. Es correcto y es seguro, porque cada etiqueta de script lleva la fecha de modificación del fichero en la query string — cambia el fichero, cambia la URL, llega el código nuevo.

Salvo que uno de los ficheros no se cargaba con una etiqueta de script. Lo importaba otro módulo, por una ruta sin versión. Así que cuando lo cambiamos, quien ya había visitado el sitio siguió ejecutando la copia vieja — durante un año, si aguantaba tanto. El síntoma era pequeño y exasperante: la pantalla de carga, que debe aparecer una vez por sesión, volvía a aparecer al regresar a la portada.

El arreglo son tres líneas: el import pasa ahora por un import map que el servidor escribe con la versión dentro. La lección es lo que conviene guardar — una política de caché vale lo que valga la URL más débil del grafo de dependencias, y los imports de módulos son fáciles de olvidar.

Cómo supimos que no rompimos nada

Borrar 6865 líneas de un sitio en producción solo es responsable si puedes demostrar que la salida no cambió. Así que lo hicimos por la vía aburrida: generamos las 33 rutas antes de la cirugía, las generamos otra vez después, y las comparamos byte a byte, normalizando solo lo que debe cambiar entre dos peticiones — el nonce antispam del formulario y el reloj del pie.

Cero diferencias, salvo el bloque de marcado que queríamos quitar. Después la misma pasada contra producción: todas las rutas, todos los códigos de estado, cero errores en consola. Esa pasada es ahora un fichero del repositorio, para que la próxima persona que toque esto pueda ejecutarla antes de prometer nada.

Dónde ha quedado

Lighthouse da 100 en rendimiento, accesibilidad, buenas prácticas y SEO en escritorio, en todos los tipos de página, y 96–99 en móvil. El Largest Contentful Paint queda entre 0,4 y 0,6 segundos en escritorio. No hay build step, ni bundler, ni framework: el sitio es PHP renderizado en servidor contra un CMS headless, publicado por FTP, con dos ficheros minificados mantenidos a mano.

Esa última parte es deliberada. La web de un estudio es el único proyecto en el que eres cliente e ingeniero a la vez, y es el sitio honesto para averiguar si tus opiniones sobreviven al contacto con una fecha de entrega. Las nuestras sobrevivieron, casi todas. Las que no, ya están borradas.

La parte que no va de nuestra web

La mayoría de los sitios que nos piden arreglar no van lentos por una mala decisión. Van lentos por cuarenta decisiones pequeñas, cada una defendible el día que se tomó, ninguna retirada jamás: un segundo script de analítica, una tipografía que nadie usa, una librería de componentes para tres botones, un pipeline de imágenes que le da a un móvil la fotografía de un escritorio.

Nadie planifica la retirada. No es una funcionalidad, no luce en una demo, y es invisible para todos menos para quien espera que cargue la página. Es también, sin fallo, el trabajo de rendimiento más barato que existe — y el único que mejora el diseño al mismo tiempo.

Si tu web pesa más de lo que debería, eso normalmente no es una reescritura. Es un inventario.