I agree that the problem is product development, but the framing is wrong. Engineers generally have a solid intuition for what will perform well, but when UX designers and PMs with only a vague idea of how these technologies work dreams up an idea, gives a deadline, then the engineers are evaluated on fulfilling those metrics, then the outcome will be obvious.
Some anecdata for you: I used to work for a price comparison website. We had pretty good metrics on how long pages took to load and what the drop-off from page to page of the process was. It will shock you not in the least that milliseconds translates into percentages lost pretty quickly. Speed up your sign up process and that is money in the bank.
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.
Because it’s not a consideration on the bottom line.
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.
It may seem absurd that the apps is costing Kroger that much but my family's experience backs it up.
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.
Maybe it's culture. Software is hard and the less unknowns you have in development the better. Frontend tools have exploded in complexity[1], but they get the job done. There are great alternatives nowadays, like phoenix liveview, but they would require full rewrites and possibly a change in language and software architecture that most teams just can't do, maybe because they are already heavily invested in whatever framework they are using or they can't afford to shift to elixir (or other languages, paradigms...).
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.
It’s about to get worse. It doesn’t matter if you spend weeks optimising your web performance if visitors have to wait several seconds to go through a proof-of-work JavaScript widget, Cloudflare Turnstile, or a CAPTCHA to prove they aren’t AI crawlers before they can even see your site.
My personal read on this is that everyone is still trying to recreate the "sudden success" of FAANG-like companies in their start-up phases. (Never mind how long it actually took them to become big.) Basically upper management incentivizes "big bets" that might turn into a "moon shot". Those bets are new features. You'll never get rich quick just by optimizing latency. You might get rich slowly, but how is that going to pump the stock this quarter / get me promoted?
I totally disagree with his conclusion that companies want their website to be faster. They only care about performance issues if it causes a problem. If it does not, they couldn't care less.
Because these day JS frameworks are used even for things where a website with a server side MVC framework like in the old days (in whatever language, PHP, Java, Python, etc) would be just fine. Maybe just to add some stuff like form validation in the frontend whenever needed with jQuery or even plain JS.
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.
Results like these are only possible when engineering leads have completely lost the plot. The checkout taking many minutes longer, if true, is bad enough that I doubt the problem is purely UI bloat. Either that or the benchmark itself is cooked.
What am I gonna do, leave my bank because the website loaded slow? Get tickets through some other option? Order differ food because it took 10 seconds to load a menu? I hate the slow web so much, but it just gets lost in the churn of life. I'd just as soon not buy something because the logo was silly or they have weeds growing in their side walk. I respect a well engineered site but most don't.
1) among non-tech decision makers, it's hard to keep out excess features and excess content, because that means most people don't get their pet project onto the website. The compromise is "everything goes in", which gives everybody a successful project that they can point to (successful in the sense that it got on the website)
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"
> each KB of JavaScript sent to the client was costing the company $100,000 per year. How much is Kroger sending today? 2.4 Megabytes. Out of a chonky 4 MB payload. Assuming they could rebuild the site to hit a target of 450 KB, that's conservatively $435,000,000 per year.
This math isn't mathing for me, no matter how I slice it. Can someone help?
Web performance is probably/mostly valued as efficiently as it needs to be.
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.
18 comments
[ 2.5 ms ] story [ 33.8 ms ] threadThe author does not seem to understand the concept of premature optimization.
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.
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.
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.
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.
[1]: https://news.ycombinator.com/item?id=34218003
An auto-playing TikTok video where an influencer peddles shoes.
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.
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?
“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.”
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.