Lo que aprendimos optimizando un sitio de e-commerce pequeño

Cogí este proyecto sin muchas expectativas: el cliente vendía menos de 200 productos, así que en teoría era territorio seguro para probar cosas sin liarla en algo crítico.

Lo primero que descubrí, y que no esperaba, es que el problema no eran las imágenes (que sí pesaban demasiado, pero era lo fácil de arreglar con compresión y formatos webp). El problema de verdad era que cada página cargaba tres librerías de JavaScript distintas para hacer básicamente lo mismo: un carrusel, un slider de imágenes de producto y un pequeño calendario de disponibilidad. Nadie había revisado nunca si se solapaban.

Quitar dos de las tres librerías y quedarnos con una sola, reescribiendo el calendario a mano en unas 80 líneas, bajó el peso de JavaScript de la página de producto de algo más de 900 KB a poco menos de 200. El Lighthouse pasó de un 54 a un 89 en móvil, y eso sin tocar el servidor ni el hosting.

La parte que más me sorprendió fue cuánto importaba el orden de carga, no solo el peso total. Había una fuente tipográfica que se cargaba antes que el contenido y bloqueaba el renderizado casi un segundo entero. Bastó con moverla a carga diferida y usar una fuente del sistema como respaldo mientras tanto.

Lo que no toqué, porque no hacía falta, fue la base de datos ni el backend. Con 200 productos, ninguna consulta tardaba lo suficiente como para notarse. Es tentador optimizar lo que suena técnico y avanzado (índices, caché, servidores) cuando el problema real está en cosas mucho más aburridas, como tres librerías redundantes que nadie limpió a tiempo.

Si algo me llevo de este proyecto es que antes de proponer una solución sofisticada para un problema de rendimiento, merece la pena mirar qué se está cargando de más. La mayoría de las veces la respuesta no es impresionante, es simplemente desorden acumulado.