Chapter III – Engineering for Performance
A fast website doesn’t happen by accident.
A fast website is the result of hundreds of small decisions, many of which are made long before anyone runs a performance test or checks a PageSpeed score.
By the time we reached this stage of the project, the platform had grown considerably. Variable products, dynamic shipping calculations, loyalty rewards, recipe interactions, AJAX-powered cart updates, and the foundations of Taste ePromise were all working together behind the scenes.
The challenge was no longer building features. It was ensuring those features never became a burden. Because no matter how innovative a platform is, customers won’t appreciate it if every click feels slow.
Designing for the Real World
One question guided many of our engineering decisions throughout this project.
Who is actually going to use this website?
The answer wasn’t developers with high-end workstations and fiber internet. It was families across Sri Lanka. Some would browse from modern smartphones over fast Wi-Fi. Others would shop using entry-level Android devices connected to mobile data networks. Those experiences deserved to feel equally reliable.
Performance, therefore, wasn’t something we planned to optimize after launch.
It became a requirement from the very beginning.
Every design decision, every new feature, and every line of code had to justify the resources it consumed.
Every Kilobyte Matters
Modern websites are often heavier than they need to be.
- Large images.
- Unused JavaScript.
- Render-blocking resources.
- Animations that contribute little beyond visual decoration.
Individually, they may seem insignificant. Collectively, they slow everything down. We approached performance as an exercise in restraint. Homepage banners were carefully optimized to preserve visual quality while reducing download sizes. Category graphics and product photography received the same attention. The goal wasn’t simply to compress images. It was to deliver assets that looked sharp without forcing customers to download more data than necessary. Scripts were evaluated based on necessity.
If a resource wasn’t immediately required, it didn’t need to compete with the initial page load.
- Critical assets were prioritized.
- Non-essential resources were deferred.
- Where appropriate, content loaded only when customers actually needed it.
None of these techniques are revolutionary on their own. Their value comes from how they work together.
Performance is rarely transformed by one dramatic improvement. It’s built through dozens of thoughtful optimizations that collectively save seconds.
Measuring, Not Guessing
One lesson we’ve learned over the years is that websites often feel fast to the people who build them. Developers usually test on powerful machines with stable internet connections and freshly cached browsers.
Customers don’t.
Rather than relying on perception, we measured performance continuously throughout development.
Tools such as Google PageSpeed Insights and GTmetrix became part of our workflow, helping us identify bottlenecks early instead of discovering them after launch.
- Sometimes a result confirmed that a recent optimization had worked.
- Sometimes it revealed an unexpected consequence.
- A seemingly harmless design adjustment might increase page weight.
- An additional script might introduce unnecessary delays.
- A new feature might trigger requests that weren’t immediately obvious.
These weren’t failures. They were opportunities to refine the platform before customers ever encountered those issues.
Performance testing wasn’t something we scheduled near the end of the project. It became part of the engineering process itself.
Fast Should Also Feel Fast
Raw speed tells only part of the story. Perceived performance matters just as much. People don’t experience milliseconds. They experience responsiveness.
- When a customer changes a product variation, they expect the interface to react immediately.
- When they update quantities, shipping costs should adjust without interruption.
- When they add an ingredient from a recipe, they shouldn’t wonder whether the action succeeded.
Throughout the platform, we relied on asynchronous interactions wherever they genuinely improved the experience.
Customers weren’t repeatedly redirected between pages. They weren’t forced to wait for unnecessary reloads. The website responded naturally, allowing shopping to feel continuous instead of fragmented.
Good performance isn’t always about making computers faster. Sometimes it’s about making waiting disappear.
Security Without Friction
Performance wasn’t the only invisible system operating behind the platform. Security required the same careful balance. Ecommerce websites face constant automated attacks.
- Credential stuffing.
- Brute-force login attempts.
- Spam submissions.
Bots don’t care whether a business is large or small. They simply look for opportunities.
Many websites respond by placing increasingly difficult CAPTCHA challenges in front of legitimate users.
The problem is obvious. Every additional obstacle designed to stop a bot also interrupts a real customer. We wanted a better balance. Cloudflare Turnstile allowed us to protect key authentication endpoints while minimizing friction for genuine visitors.
Most customers never realized additional security measures were working in the background. That’s exactly how good security should feel. Visible only when it needs to be.
Engineering Beyond the Launch
As launch approached, it became increasingly clear that we weren’t preparing a website for a single day. We were preparing a platform expected to grow for years.
- New products would be introduced.
- Recipe collections would expand.
- Marketing campaigns would attract new visitors.
- Customer accounts would continue growing.
Performance couldn’t depend on the website remaining exactly as it was on launch day. It needed room to evolve. That mindset influenced countless technical decisions, many of which visitors will never notice. And that’s perfectly fine.
Some of the most valuable engineering work remains invisible.
- Customers remember that the website feels smooth.
- They remember that pages respond quickly.
- They remember that checkout feels effortless.
- They rarely remember why.
That’s the quiet success of thoughtful engineering.
Looking Ahead
By now, most of the platform had come together. The customer journey had been refined. The performance foundations were in place. The business rules had evolved alongside changing market conditions.
Yet one feature continued to stand apart from everything else, Taste ePromise. It had started as a single question during our earliest discovery meetings.
By the end of development, it had become one of the most sophisticated systems we had ever engineered.
In the next chapter, we’ll take you behind the scenes of the feature that transformed this project from an ecommerce website into something entirely different.
Found this article useful?