O que aprendemos optimizando un sitio de e-commerce pequeno

Collín este proxecto sen moitas expectativas: o cliente vendía menos de 200 produtos, así que en teoría era territorio seguro para probar cousas sen liala en algo crítico.

O primeiro que descubrín, e que non esperaba, é que o problema non eran as imaxes (que si pesaban demasiado, pero era o fácil de arranxar con compresión e formatos webp). O problema de verdade era que cada páxina cargaba tres librarías de JavaScript distintas para facer basicamente o mesmo: un carrusel, un slider de imaxes de produto e un pequeno calendario de dispoñibilidade. Ninguén revisara nunca se se solapaban.

Quitar dúas das tres librarías e quedarmos cunha soa, reescribindo o calendario a man en unhas 80 liñas, baixou o peso de JavaScript da páxina de produto de algo máis de 900 KB a pouco menos de 200. O Lighthouse pasou dun 54 a un 89 en móbil, e iso sen tocar o servidor nin o hosting.

A parte que máis me sorprendeu foi canto importaba a orde de carga, non só o peso total. Había unha fonte tipográfica que se cargaba antes que o contido e bloqueaba o renderizado case un segundo enteiro. Abondou con movela a carga diferida e usar unha fonte do sistema como respaldo mentres tanto.

O que non toquei, porque non facía falta, foi a base de datos nin o backend. Con 200 produtos, ningunha consulta tardaba o suficiente como para notarse. É tentador optimizar o que soa técnico e avanzado (índices, caché, servidores) cando o problema real está en cousas moito máis aburridas, como tres librarías redundantes que ninguén limpou a tempo.

Se algo levo deste proxecto é que antes de propor unha solución sofisticada para un problema de rendemento, merece a pena mirar que se está a cargar de máis. A maioría das veces a resposta non é impresionante, é simplemente desorde acumulada.