What we learned optimizing a small ecommerce site

I took on this project without high expectations: the client sold fewer than 200 products, so in theory it was safe territory to try things out without risking anything critical.

The first thing I discovered, and didn’t expect, is that the problem wasn’t the images (which were too heavy, sure, but that was the easy part to fix with compression and webp formats). The real problem was that every page loaded three different JavaScript libraries to do basically the same thing: a carousel, a product image slider and a small availability calendar. Nobody had ever checked whether they overlapped.

Removing two of the three libraries and keeping just one, rewriting the calendar by hand in about 80 lines, brought the product page’s JavaScript weight down from a bit over 900 KB to just under 200. Lighthouse went from a 54 to an 89 on mobile, and that’s without touching the server or the hosting.

The part that surprised me most was how much loading order mattered, not just total weight. There was a typeface loading before the content that blocked rendering for almost a full second. Moving it to lazy loading and using a system font as a fallback in the meantime was enough to fix it.

What I didn’t touch, because it wasn’t needed, was the database or the backend. With 200 products, no query took long enough to notice. It’s tempting to optimize whatever sounds technical and advanced (indexes, caching, servers) when the real problem lies in much more boring things, like three redundant libraries nobody cleaned up in time.

If there’s one thing I’m taking from this project, it’s that before proposing a sophisticated solution to a performance problem, it’s worth checking what’s being loaded unnecessarily. Most of the time the answer isn’t impressive, it’s simply accumulated clutter.