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.
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...
True if you work at non-technical company, like a bank.
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).
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.
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.
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.
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.
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.
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.
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.
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.)
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
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.
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?
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.
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.
The author does not seem to understand the concept of premature optimization.
It isn't premature. It's very much needed.
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
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.
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.
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.
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.
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"
“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.”
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.