It happened again this morning on the commuter rail. A woman in a charcoal wool overcoat and salt-and-pepper hair was trying to load a simple news article. I watched her from two seats away, pretending to be asleep against the vibrating window, my eyes narrowed just enough to see the blue light reflecting off her glasses.
She tapped a link. The progress bar crawled three millimeters and stopped, a thin green line frozen in a desert of white space. She didn’t huff. She didn’t curse the carrier. Instead, she tilted her phone toward the window as if physical proximity to the sky would coax the data down, saw four bars of LTE, and then immediately looked ashamed. She tucked a strand of hair behind her ear, glanced around to see if anyone noticed her “failure,” and closed the tab.
This is the most successful gaslighting campaign in the history of infrastructure. When a bridge collapses, we blame the engineering firm or the salt on the roads. When a page takes nine seconds to become interactive, we blame our old iPhone 13, our carrier’s spotty coverage in the valley, or the fact that we have twenty-seven other tabs open in the background. We have been conditioned to absorb the cost of technical debt as a personal moral failing.
The Legacy of “Driver Error”
In the mid-20th century, the American automotive industry faced a similar psychological pivot with the introduction of the “accident.” Before safety became a standardized engineering metric, a crash was almost always framed as “driver error.” If your steering column impaled you during a minor fender bender, it wasn’t the car’s fault for being a spear; it was your fault for hitting the bush.
It took decades of advocacy to shift the burden of proof from the person behind the wheel to the person at the drafting table. We are currently in the “driver error” era of the internet.
We treat a slow Largest Contentful Paint like a bad weather day-something to be endured with a shrug. But a slow site isn’t weather. It’s a choice. It’s a series of decisions made by a product team that prioritized a heavy tracking script or an uncompressed hero image over the person sitting on a train just trying to read the news.
The danger of this self-blame is that it creates a closed loop where feedback never reaches the source. When that woman closed her tab, she became a “bounce” in an analytics dashboard. To the developers, she is just a 1 in a column of 4,000 people who “lost interest.”
They assume her intent changed. They assume she decided she didn’t want the information after all. They never see the moment of self-doubt where she decided she was the problem. The signal is consumed at the point of impact, leaving the builders in a state of blissful, data-driven ignorance.
I remember my time as a driving instructor, sitting in the passenger seat with a dual-brake pedal under my foot. Students would stall the manual transmission car and immediately apologize to me. They’d turn red, grip the wheel of the Volkswagen Golf until their knuckles went white, and mutter about how they were “just bad at this.”
“They never considered that the clutch was worn down to a nub by three years of teenagers, or that the idle air control valve was sticking. They took the mechanical failure and wore it like a heavy coat.”
Software builders rely on that heavy coat. It’s a load-bearing structural element of modern web development. If users actually complained every time a layout shifted 40 pixels just as they were about to tap a button, the internet would grind to a halt under the weight of the tickets. But they don’t. They just think their thumb slipped.
Why “Lab Data” is a Lie
You can run a Lighthouse test in a pristine development environment in San Francisco and get a 98 score, but that isn’t the reality of the 75th percentile of your actual users. Real life happens on a 62-year-old woman’s phone in a moving train car with a fluctuating signal. Real life happens when the main thread is blocked by a third-party ad tech script while a user is trying to scroll.
Most agencies sell you the lab score because it’s easy to hit in a demo. They show you the polished chrome of the car while it’s parked in the showroom. But the moment that site hits the open road, it starts falling apart.
This is the gap where Digital Heroes operates. They don’t just promise that a site will be fast; they write the performance thresholds into the contract. If the Largest Contentful Paint isn’t under 2.5 seconds for 75% of your real users-not just the ones on high-speed fiber in a basement-they lose money. It turns performance from a vague “best effort” into a financial obligation.
The Taxation of Frustration
We have reached a point where we need to stop being so polite to our technology. When an internal tool is so slow that employees start keeping “shadow” spreadsheets just to get their work done, that isn’t a training issue. That is a failure of architecture.
When a headless Shopify store takes four seconds to respond to a “Add to Cart” tap, that isn’t a “user distraction” issue. That is a direct tax on the bottom line that the user is paying in frustration and the owner is paying in lost revenue.
The most insidious part of this dynamic is that the “quietest” users-the ones who don’t have the technical vocabulary to describe a Cumulative Layout Shift-are the ones subsidizing the mess. They are the ones who assume they just “aren’t good with computers.”
Every time we ship a bloated, unoptimized application, we are reinforcing a digital divide that says some people are “meant” to use the web and others are just guests who should be grateful it works at all.
The User’s Right to Speed
We need to build for the woman on the train. We need to build for the person who assumes the phone is the problem. Because the moment we stop letting users blame themselves is the moment we are finally forced to actually fix the things we build.
We owe them more than a “sorry for the delay” spinner. We owe them a world where the connection between their intent and the result is so seamless that they never have to look at their signal bars and wonder if they’ve done something wrong.
Systemic Failure: Blame the user, hide the debt.
Systemic Integrity: Fix the code, respect the time.
The next time you see that progress bar stall, or that button refuse to click, don’t tilt your phone. Don’t check your settings. Don’t apologize to the air. The world isn’t broken because you’re doing it wrong; it’s broken because someone else decided your time wasn’t worth the effort it takes to make things fast.
It’s time we started sending the feedback back to the source. It’s time we stopped absorbing the debt.
If the site is slow, it isn’t your phone’s fault. It isn’t your signal’s fault. And it certainly isn’t yours.