Architecture
7 min read
How We Cut Page Load Times by 50% and Bandwidth by 70% — Before Webpack Was Even a Thing
The page was slow. Not broken — just painfully slow. And when you're running a high-traffic events portal, slow is its own kind of broken.
This is the story of how I helped optimize a major events website using Redis caching and JS/CSS minification — and why that experience taught me something about engineering that no tutorial ever could.
The Problem Nobody Was Talking About
When I joined the Events team at an E-commerce firm, the website worked. Users could find events, browse listings, check details. But something was off.
Page load times were sluggish. Every user request was hammering the database. Static assets — JavaScript files, CSS stylesheets — were being served fresh on every single request, uncompressed, uncombined, as individual files. The browser was making dozens of separate HTTP requests just to render one page.
I kept wondering — is anyone else seeing this? The product was live, people were using it, so the assumption was: it's fine. But fine and optimised are very different things.
That gap was the opportunity.
The Research Phase — Going Down the Rabbit Hole
Before writing a single line of code, I spent time genuinely researching the problem. This is the part that doesn't show up on dashboards or sprint boards, but it matters enormously.
I had two distinct problems to solve:
Dynamic data — event listings being re-fetched from the database on every page load
Static assets — JavaScript and CSS files being served individually, uncompressed, on every request
For the first, the answer was relatively clear: Redis. An in-memory data store that could cache expensive database queries and serve them in milliseconds. Configure a TTL (time-to-live), warm the cache on first load, serve from memory on subsequent requests. The database breathes easier, the user gets their data faster.
For the second problem — this is where things got interesting.
Discovering Minify — Before Bundlers Existed
Today, if you need to combine and compress your JS and CSS, you reach for Webpack, Vite, or esbuild without a second thought. These tools are everywhere. They're assumed.
But this was a different era. Modern bundlers hadn't yet taken over the frontend world. There was no npm run build that magically produced a single optimised bundle. You had to find the solution yourself.
After considerable research, I came across an open-source PHP library called Minify — a 3,000-star project that did exactly what we needed. It could:
Combine multiple JS or CSS files into a single HTTP request
Compress the output by stripping whitespace, comments, and redundant characters
Cache the minified output so it wasn't reprocessed on every request
Send far-future Expires headers so browsers cached assets locally for up to a year
The setup was elegant. You'd define groups of files in a groupsConfig.php file:
Then reference them in your HTML with a single URL:
That version number at the end (1234) was the key to cache-busting — change it when files change, and browsers would fetch the fresh version. Leave it, and they'd serve from their local cache indefinitely.
Dozens of HTTP requests, reduced to two.
Putting It All Together
With both pieces in place — Redis for dynamic data, Minify for static assets — the implementation came together carefully.
For Redis, the approach was straightforward: identify the expensive, frequently-called database queries powering the events listings, wrap them with cache checks, and set appropriate TTLs based on how often the underlying data actually changed.
For Minify, it required auditing every JS and CSS file being loaded across the events pages, grouping them logically, testing that combined output didn't break anything (CSS specificity and JS load order both matter here), and then deploying with browser cache headers configured correctly.
The versioning system for cache-busting required a discipline of its own — you had to remember to bump the version number on every deployment that touched frontend files. A small process, but a critical one.
The Result
The numbers spoke for themselves:
Page load times reduced by 50%
Bandwidth reduced by 70%
Fewer database hits. Fewer HTTP requests. Smaller payloads. Browsers caching assets locally instead of re-downloading them on every visit.
For a high-traffic portal, that 70% bandwidth reduction wasn't just a performance win — it had real infrastructure cost implications too.
What This Experience Taught Me
Looking back, this project gave me something more valuable than the metrics.
It taught me that researching before building is a skill in itself. The instinct to immediately write code is strong — but the engineers who create the most impact are the ones who first ask: has someone already solved this well? Minify existed. Redis was mature. The real work was understanding the problem clearly enough to recognise the right tools when I found them.
It also gave me an early appreciation for what frontend performance actually means at scale. Every kilobyte matters. Every HTTP request has a cost. These instincts — built before bundlers made optimisation automatic — have shaped how I think about web performance ever since.
The tools have changed dramatically. The thinking hasn't.
If you're working on a legacy web application and performance is an afterthought, start with the basics: cache your expensive queries, combine your static assets, and set your cache headers correctly. The wins are often faster than you'd expect — and larger than the numbers suggest.