A client came to me with a site that worked, it just made people wait too long to see it work. Pages took over 8 seconds to load. By the time anything appeared on screen, a good chunk of visitors had already left.
The design didn't need to change. The content didn't need to change. What needed to change was everything happening behind the scenes before any of that ever reached the visitor.
The Result First
Load time dropped by 75%. What used to take 8 seconds now takes about 2. No redesign, no rebuild, the same site, just no longer standing in its own way.
That's the number that matters if you're a business owner reading this. If you want the technical breakdown of how, that's below. If not, that's the whole story: a slow site got fast, without anyone having to touch the parts customers actually see.
The Technical Breakdown
For anyone curious about the actual mechanics, here's what changed.
CloudFront in front of everything. Static assets, images, and cacheable responses were being served directly from the origin server on every request. Adding CloudFront as a CDN layer meant repeat visitors, and even first-time visitors hitting cached content, got served from an edge location close to them, instead of round-tripping to the origin every time.
Lambda for the compute-heavy paths. Instead of a single server handling every request regardless of load, the parts of the app that actually needed compute moved to Lambda, scaling automatically with traffic instead of a fixed server straining under a spike.
NeonDB replacing a slower, more traditional database setup. Cold starts on serverless compute are only as fast as the database connection behind them. NeonDB's connection model is built for exactly this pattern, serverless functions that need to connect, query, and disconnect quickly, without the overhead a traditional always-on database connection carries.
None of these were exotic choices. They're common, well-documented pieces of AWS infrastructure. The work wasn't picking clever tools, it was correctly diagnosing where the actual bottleneck was, and applying the right piece to the right problem instead of throwing infrastructure at the whole system and hoping something stuck.
Why This Kind of Fix Gets Missed
A lot of slow sites don't get fixed because the instinct is to rebuild, new framework, new design, new everything. That's expensive, slow, and often unnecessary. Most performance problems live in the infrastructure layer, not the code or the design. Fixing that layer is faster, cheaper, and doesn't touch anything the client or their customers actually see.
The site looked exactly the same after this project. It just stopped making people wait to see it.
I work on performance problems like this, NodeJS, TypeScript, AWS. If your site feels slow and you're not sure why, let's talk.