Diagnosing a 'slow website' that wasn't actually a speed problem

Composite, drawn from patterns across engagements, not one specific client.

“Our website is slow” was the complaint. Page load times said otherwise, under two seconds, well within normal range. Something didn’t add up between the complaint and the data, which is usually where the real diagnosis lives.

Where the actual problem was

It wasn’t the site. It was the checkout flow, five steps deep, each one loading a third-party script that had nothing to do with speed and everything to do with friction. Customers weren’t experiencing “slow,” they were experiencing “too many steps that each felt like a decision point.”

Speed and friction get reported the same way by users who don’t have the vocabulary to separate them. “This feels slow” often means “this feels like work.”

Why the wrong diagnosis almost got expensive

The initial plan was a full technical performance audit, a real cost in time and money, aimed at a problem that wasn’t the actual problem. It would have shipped faster page loads and left the checkout exactly as frustrating.

What actually fixed it

Cutting checkout from five steps to two, removing scripts that weren’t earning their place, and combining two form fields that never needed to be separate. None of that touched server response time. All of it touched how fast the process felt.

The lesson, generalized

A complaint tells you something’s wrong. It rarely tells you what. Treating “slow” as a literal technical claim, instead of digging into what’s actually producing the feeling, is one of the most common misdiagnoses in any customer-facing system, not just websites. The fix is almost never where the complaint points first.