Why Is Web Performance Undervalued?
blaines-blog.com
blaines-blog.com
If someone comes to your company and says they want to give them money to buy an advertisement, nobody in power says “no thanks, that will make our website slow.” If someone in marketing says “put this tracking garbage on our site” nobody says “no can do, too slow.” If the designers, or executives looking at the design, are enamored with something really flashy looking nobody says “no, that will make the website slow.”
The engineers likely do complain it will make the website slow. I have been that engineer. But they are never in a position of power to overrule other parts of the company. This is especially true if it’s not a tech company. Web performance does now show up on the earnings report.
I would say (maybe this is what you mean by consideration on"?) that it has an impact on the bottom line, but this is not obvious and not understood by the people in charge.
If in 2025 you're not a content farm, your business is to get people to buy stuff from you, you don't have a team tracking every millisecond change in your p99 latency and page load speed across multiple devices, you're just incompetent.
The free market is an interesting idea, but it assumes many preconditions that are not always true in practice. It's an approximation at best.
I'm not an accountant so if I do something that negatively affects accountants I won't find out - unless what I do shows up in an audit. My company has put things in place so that it is unlikely I would accidentally do something that would show up in an audit (most of them are best practices that every company has). I do have a company credit card, and I can make other purchases on behalf of my company - but if I tried to send my brother in law a million dollars I doubt I could do that (not that I would)
As web engineers what do you have in place so that if someone who competent in a different area does something in the web area and breaks things will will notice and stop them?
> if I tried to send my brother in law a million dollars I doubt I could do that (not that I would)
If you did it would almost certainly be noticed and you would face consequences. That is why something more complex than just a transfer (very often something very elaborate) is required for fraud.
Then again everyone accepts you need to do things to stop fraud, that the trade offs (things taking more time and effort, not being able to do somethings) from the necessary precautions.
You do run into a weird problem where as the site gets faster for the p99 the median speed can get worse as people that originally avoiding the site over speed start to use it more often so you get a worse p99 population than before and the old-p99 creeps down into p50. But also you have more users so that's nice.
Another issue is that you often simply aren’t given the time to make it performant. Deadlines are heavily accelerated for web products. You’re barely allotted time to fix bugs, never mind enhancements.
Most web devs don’t want to make slow sites, they’re not given the opportunity to.
[0]: https://dev.to/tigt/making-the-worlds-fastest-website-and-ot...
Worst case scenario, they say no. But often you'll at least open a dialogue and get involved in the decision making. You might even get your solution implemented. And you are definitely more likely to be consulted on future decisions (as long as you are professional and polite during the discussions).
However, it’s requires a lot more mental energy (and can be riskier) than just doing the exact dumb thing the jira ticket asks for, or just saying “this is bad” (and then doing the dumb thing anyway because there’s a deadline).
Because of that most people don’t do it and even food engineers won’t have the energy to do it all the time.
This is a huge part of why big companies can’t produce high quality, high performance software consistently.
When you offer to build a real solution, that sure is a lot of work, time, and expense to give them something they could have instantly. A tough sell. Also, volunteering yourself to do a lot of work on top of the responsibilities you already have.
This is why product teams have cadences of triaging and prioritizing the work. You need a PM (or someone who fulfills that role) who will listen to engineering as much as the business and allow for the time to get the right solutions in place. That way, it is not an additional burden on the dev team, it is part of the standard work process. Then it is not a tough sell, it is day-to-day communication with whomever prioritizes the work, which should already be happening.
Now, that being said, I fully recognize that many PMs are not good at this part of the job. But then your focus needs to be on working better with the PM. Because a good PM will push back and establish boundaries with the business to prevent last-minute, urgent "wants" from disrupting the actual development of the product.
This also brings us back full-circle to how performance goes down in the first place. Devs get sick of all this, PMs cave in, and just put in Google Analytics or some other tool in place. Once that hook is live, marketing can add all kinds of crap to the site. Look, they got their instant gratification on analytics! And took down the site performance in the process.
"We can get an instant solution" is a red flag to me as a PM, not a selling point.
Every company has a website. A very small percentage of those are tech companies. They just have some team, or some person, that makes the website. That team has little to no control over what appears on the website. The bosses at the company are in the business of what the company actually does, like sell food, or clothing, or whatever. They order the tech team to do something to the website, and they expect what they say to be done. They will sign contracts with other companies and agree to things that make the website slower without even consulting any technologically knowledgeable person until after the ink has dried. This is the norm.
True if you work at non-technical company, like a bank.
In the post-COVID era, my wife has become quite accustomed to digital shopping. We actually live closer to a Meijer, which is basically the Midwest's answer to Walmart, except it's decades older. (You may be able to thank Meijer for Super Walmarts; it's Meijer that proved out the concept of attaching a grocery store to a general superstore for Walmart, and it gave Walmart some difficulty penetrating in to the Midwest so they had to add it to compete.) Of course COVID caused a big app rush and at first everybody's app was pretty crappy, so we just stuck with the closest one.
Over time, Meijer's app slowed down pretty badly, so my wife ended up switching to Kroger. I saw a lot of Kroger bags. One of the biggest problems with the Meijer was that trying to add a second of any item was a synchronous round-trip to a rather busy and slow server, so goodness help you if you wanted, say, 6 bananas. Going from 1 to 6 could literally take 30 seconds on the worst days. And that was just the worst issue, the whole app was generally slow and prone to failure.
But somewhere around two years ago, clearly someone at Meijer got the performance religion and cleaned up their app and website. I still wouldn't call it blazing fast, but I would call it acceptable by modern standards, and it blew away the Kroger app of the time... again, not because it was pushing 120fps with super low latency, but just because it was fairly reasonable to use. Adding five more bananas is now just tapping the button five times, and while I can still kind of see the async requests chasing each other a bit, it pretty much always ends up converging on the correct number in a couple of seconds. So my wife switched back.
I don't know what Kroger's current performance is, because now that we don't have a problem we haven't been seeking solutions. So they've lost thousands of dollars of business over the years to Meijer from us.
An anecdote, of course, but I suspect a common one.
I put this out there in the hope that it will push more people into caring a bit more about performance. I think there's a fairly large range where "normal people" will use a sluggish app or website, and wander away, and if you do manage to rope them into a marketing survey they won't necessarily say it's because it's slow, you'll get other rationalizations, because it isn't a fully-conscious reaction and realization for them... but nevertheless, you'll have a very, very leaky funnel and just reading those surveys may not tell you why.
The numbers mentioned in the article are...quite egregious.
> Oh, Just 2.4 Megabytes. Out of a chonky 4 MB payload. Assuming they could rebuild the site to hit Alex Russell's target of 450 KB, that's conservatively $435,000,000 per year. Not too bad. And this is likely a profound underestimation of the real gain
This is not a "profound underestimation." Not by several orders of magnitude. Kroger is not going save anywhere even remotely close to $435 million dollars by reducing their js bundle size.
Kroger had $3.6-$3.8 billion in allocated capex in the year of 2024. There is no shot javascript bundle size is ~9% of their *total* allocated capex.
I work with a number of companies of similar size and their entire cloud spend isn't $435,000,000 -- and bandwidth (or even networking all up) isn't in their time 10 line items.
A leak showed that Walmart spent $580m a year on Azure: https://www.datacenterdynamics.com/en/news/walmart-spent-580...
These numbers are so insanely inflated, I think the author needs to rethink their entire premise.
Instead they were arguing that in addition to saving maybe a million or two in server costs, they would gain an additional 435 million dollars in revenue because less people would leave their website
There’s are a few cases where the engineering side isn’t helping things though, like how the Spotify desktop app loads a full redundant set of JS dependencies for each pane since they’re each independent iframes, which they do so the teams responsible for the panes never have to interact.
So then you load their site - unbelievable garbage, tons of pop-up ads for promos, video frames all over the place, high res graphics, megabytes of javascript.
The backend just as messy, with dozens and dozens of layers that made the latency budget by the time you reached the database backend super slim. Think: orders dropping when database request latency hit 10ms at the 99th percentile.
Insanity.
The most hilarious if you go to pirate sites (for stuff like comics, manga or movies), and it's 100x faster and works better than the official paid for alternative, even though I'm sure the former runs off some dudes former gamer PC in his bedroom.
This explodes the cost of development and it makes current web development miserable IME.
I am forced to deal with everything being totally overengineered when a Flask app with a PostgresSQL backend could probably do the job on a reasonably priced VPS.
It's just that "done right" means the web pages are actually crafted to be what they need, and there's none of the modern extras like 1850 ad tracking agencies all being copied in, nor an ad server injecting just about anything…
This is also a huge contributor to the curse of Full Stack Engineering. “Full Stack” should mean that you have significant experience with and knowledge of every system and language you’re interacting with (I’ll give systems administration a pass for the sake of argument). For most web apps, that means frontend and backend, as well as some flavor of RDBMS, some flavor of caching, and likely a message queue. It likely also means you need to understand distributed systems. The number of developers I’ve met who tick all of those boxes is zero. Honestly, as soon as you include an RDBMS, it’s game over for most. Yes, you can get away with horrible things via ORMs, but as soon as you start hitting scaling limits, you’ll discover what people have known for decades: databases are tricky, and chucking everything into JSON columns with UUID PKs isn’t a good idea.
All our code was basically - check user auth - do some stuff with the db/perhaps call out to some external service - serve request.
I never saw a single request above 50ms, with most being way less. Nobody ever talked about performance.
Then I moved to a fancy startup. EKS, nodejs servers, microservices of every denomination, GraphQL, every fashionable piece of tech cca 2018. I realized node was shockingly slow, and single threaded to boot, all that overhead added up to requests with a median latency of about 200ms, with the 99% latency measured in seconds.
Performance engineering was front and center, with dashboards, entire sprints dedicated to optimization, potential optimizations constantly considered, adding fake data and suspense to our React frontend, to hide latency etc. It was insane.
I worked for about 15 years as a frontend developer. I've seen very little evidence of this being the case.
I've seen a huge amount of developers (backend, frontend doesn't matter much) will do things that are really dumb e.g. repeated look of values that don't change often, not trying to minimise roundtrips.
Right now, I'm converting some C++ game code that is very obviously originally meant for a 68k mac (with resource forks etc.) into vanilla JS. It's marginally easier to work with than SwiftUI + VIPER, and I'm saying that as someone who has been working on iOS apps since the first retina iPod came out and has only 14 months experience of C++ and perhaps about that, perhaps a bit less than that, total experience of JS since getting one of those "lean foo in 24 hours" books from WHSmith using pocket money in the late 90s.
Not to say that React is useless, it has its applications, but just 95% of the websites shouldn't need it, and I shouldn't download 20+Mb of JS files just to load the homepage of a site.
Another thing to consider, most people that work in tech have probably gigabit or better internet connections. Unfortunately, the user of the website don't have this luxury, and often use either mobile (4G if lucky) connections, or slow ADSL connection (at my house fiber has still to be brought, and I have a 13mbit ADSL).
I hate when just to load the homepage of a site it takes more than 30 seconds (I'm looking at you, ClickUp!). It shouldn't be acceptable: just use HTTP for what was created for, serving hyper text, and serve me hypertext. I would rather load in continuous small HTML files (that is fast even with slow connections because the latency is typically in the ms order even with ADSL) that download a full JS application each time I access a page.
An auto-playing TikTok video where an influencer peddles shoes.
But for things like impulse purchases from social media ads, I’ll definitely just close the site if it’s just moderately slow.
There are small slowdowns that will change your behavior in little ways that add up. Maybe you have a Walmart pickup order in, and you think oh I’ll add some ice cream for dessert tonight. If you know the process is super slow, you might just remember how slow it is and decide it’s not worth it because you don’t really need ice cream anyway.
There are tons of studies showing that wait times costs money, and that users will drop if the load time is too long.
2) among tech decision-makers, i.e. alpha developers and young hotshots, the urge to use what FAANG uses was very strong, because that's how you get the trendy tech on your resume. Basically the same at (1), above, but for developers.
Exacerbating this is that each additional thing is only a small part of the problem: "No single raindrop believes it is responsible for the flood"
This math isn't mathing for me, no matter how I slice it. Can someone help?
4 MB ~= 4000 kB, (4000 kB - 450 kB) * $100,000/kB/year = $355,000,000/year
(With a bit of fiddling to get the same answer as them, I think they may have done this: (4000 kB + 350 kB) * $100,000/kB, though I wouldn't want to guess why this error happened).
Whatever the case, it's still immense numbers. So large, in fact, that I was skeptical about it. But Kroger has 150 billion in revenues and 2.5 billion in profits. I have to figure the loss is revenues, not profits - that would, indeed, be too high.
“If you normalize your schema, it will be 20x smaller, and you’ll eliminate an entire class of bugs.”
“Hmm, but then we’ll have to write joins in the query, so we’ll pass.”
But how much would it cost to have a few senior engineers fix it, and ensure zero mistakes or missing functionality while doing it?
Even if I were CTO of Kroger… nope. I’m not doing it. I’m not spending months of engineer effort to save $435K, unless there’s proof of greater savings.
EDIT: Yes, I terribly misread that this is million, not thousand, which makes a lot more sense even though I do not believe, even for a second, this actually costs Kroger $435M a year.
And "zero" mistakes is not part of the goal. It clearly wasn't in the requirements during initial development, why would they add it afterwards?
Imagine having to tell management your optimization to save $400K cost $100K in engineer time and caused a $700K outage where the “Add to cart” button sometimes didn’t work. Great job. You’re possibly fired.
(Edit: Due to my misreading, add a few digits to the outage cost.)
- Savings $400K
- Direct expenditures $100K
- Mistake expenditures $700K
- Net loss $400K; immediate loss $800K
And that’s it. You’re fired, replaced with someone who is better at not fixing things that ain’t broken; who wouldn’t have made this mistake in the first place. And heaven help you if your code is deployed before the Nintendo Switch 2 launch (or another major launch) when you made this mistake; or if you just ruined another company’s launch and your company’s contract with them to support it. Pointing to a Wikipedia article, musing about how risk analysis should be done, isn’t going to save your skin.
Would you do it to save 1000x that much? Because you're missing 3 zeroes.
… but at the same time, I don’t believe for a second this actually causes a $435M loss. There are way too many assumptions - for example, if people are ordering groceries, they are way more tolerant of delays for needs than, say, the latest TV deal.
The loss that it causes on conversion rate for a brand new company trying to get leads does not track with buying oatmeal.
The articles fault is trying to appeal to this logic at all.
Reality is you don’t know how to estimate this, I don’t know either and I doubt anyone really knows.
This kind of logic is used to push things in the direction that the person wants, it really doesn’t seem genuine
But what do web developers want? What do web designers want? Some developers pride themselved on being craftsmen. They would write tests. They would design architectures. Why wouldn't they want websites they are building to be faster?
There are lots of good reasons to make your website faster, but given the number of sites I've seen that fall over and die if you block Google Analytics, I don't feel that it's the biggest issue most websites have.
Sure, I get it. The same argument can be applied to web accessibility. Most frontend developers are young and healthy. Should they care about accessibility of the sites they build?
The idea that most websites should broadly work for people even on a 2G signal is absurd. Some should. However I’m not going to try to configure a BMW and email dealers from the middle of the woods, and I’m sure they know their target audience is not either.
A web page and a native app all suffer from the same issue. It frequently needs to talk to a server somewhere. No you are downloading the UI/Logic, but often it needs to talk to a server.
> The idea that most websites should broadly work for people even on a 2G signal is absurd.
I worked in a large company and we did optimise for some random guy that was in Spain on a crappy 2G/3G signal (this was a real customer). It was a good test case of how the app responded with a poor bandwidth & signal. As a result the application would behave well when having poor signal.
Large companies such as google pore huge resources into optimising, that why YouTube (both their app and their mobile site) will work on a flakey connection on a train going through the countryside and something like kick.com won't.
Often It isn't the bandwidth that is frequently the issue. It is the latency between requests and stability of a signal. Sometimes a request can fail, the phone goes to sleep and sometimes that can suspend the browser thread. This affects higher bandwidth connections such as 4G and 5G.
If the web site/web app or even native app is coded poorly often you will get into a state where you have to reload the app.
Also downloading an app could be relatively large compared to a web page. If you just want to check the train times / bus times / closing time of a shop or similar it will take longer to use the app as you need to download the whole thing first.
> However I’m not going to try to configure a BMW and email dealers from the middle of the woods, and I’m sure they know their target audience is not either.
Things like this do happen. I've bought vehicles from farmhouses in the middle of nowhere in the UK. Bank transfers, road tax I have literally done in someone's garden.
A huge number of places are not data-driven. Therefore it is difficult to show in anyway that improving service speed will improve ROI.
So even if you are a craftsmen, your colleagues aren't. They will never care, they have no incentive to, because management doesn't care.
I've totally given up with it and I can write fast JS code. I just don't get rewarded for it. In fact it has be a detriment to my career.
> I've totally given up with it and I've can write fast JS code. I just don't get rewarded for it. In fact it has be a detriment to my career.
Do you write tests? They also are something that doesn't directly bring money.
I've just explained why. What part didn't you understand?
> Do you write tests? They also are something that doesn't directly bring money
I do (I like to know my code works). That doesn't mean other people will.
Much like site performance unless there is an emphasis on quality, then many developers won't bother writing tests.
I've had people copy and paste tests, then jig the code around so they got the green tick in the IDE. The feature didn't work at all. The test was complete nonsense. I have colleagues that put up PRs where the code doesn't even compile.
So they stay in this marshlands of bloated UI frameworks, and they need to push updates and new features which makes the problem worse.
We seem to try to explain everything in software in technical terms, but sometimes at the end of the day culture and communication plays a larger role I think. Software is built by humans after all.
The author does not seem to understand the concept of premature optimization.
It isn't premature. It's very much needed.