Live data from Hacker News

Why Is Web Performance Undervalued?

blaines-blog.com

71–80 of 83 posts

Re: Why Is Web Performance Undervalued?

#71
post #62

Earlier quoted context omitted.

As a web developer who also uses web sites I care less about speed than I do usability. Most of the time I'm on a 1Gbps+ connection, all I want is your site flows to make sense and any actions I take to be reliable and clearly handle errors. For things that are truly critical I want 99% of my UI to be precached by a native application, so we're only talking in data (and yes, keep that data small). There are lots of g…

> As a web developer who also uses web sites I care less about speed than I do usability. Most of the time I'm on a 1Gbps+ connection 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?

It’s not the same argument at all. Accessibility is important. What I’m saying is if you want it to be fast offload the UI to a native app, don’t even bother me with a web page. If it’s critical serve it in plain text or simple HTML. Either of those are both fast and accessible.

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.

Re: Why Is Web Performance Undervalued?

#72
post #49
post #46

> 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?

I also think they made a mistake, but it doesn't look like a huge one? 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).

Hmm. But the JS is only 2.4mb, so not sure why the 4mb is probably being used.

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.

Re: Why Is Web Performance Undervalued?

#73
post #56

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 undere…

it's not just their direct cost, it's also the loss of revenue. the author wasn't arguing that they could save 435 million dollars in server costs. 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

Bizarre that this had to be spelled out...

Re: Why Is Web Performance Undervalued?

#74
post #11

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 loo…

There is a better approach, as an engineer, to get this type of point across. Don't just reject their solution... offer a better one. If they come to you saying they want tracking on a web site, ask what goal they are trying to achieve. Ask them what costs they are paying for the service they want you to implement. And then see if you can design a server-based system that gives them the info they want, and write up a…

This is 100% the correct way to do things. The tactic of never saying no but proposing better alternatives is the best way to guide stakeholders into making better technical decisions.

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.

Re: Why Is Web Performance Undervalued?

#75

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.

If there’s a competitor I’ll definitely switch. For things like banks the pain would have to be pretty bad.

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.

Re: Why Is Web Performance Undervalued?

#76
post #62

Earlier quoted context omitted.

> As a web developer who also uses web sites I care less about speed than I do usability. Most of the time I'm on a 1Gbps+ connection 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?

It’s not the same argument at all. Accessibility is important. What I’m saying is if you want it to be fast offload the UI to a native app, don’t even bother me with a web page. If it’s critical serve it in plain text or simple HTML. Either of those are both fast and accessible. 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 confi…

> It’s not the same argument at all. Accessibility is important. What I’m saying is if you want it to be fast offload the UI to a native app, don’t even bother me with a web page. If it’s critical serve it in plain text or simple HTML. Either of those are both fast and accessible.

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.

Re: Why Is Web Performance Undervalued?

#77
post #11

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 loo…

There is a better approach, as an engineer, to get this type of point across. Don't just reject their solution... offer a better one. If they come to you saying they want tracking on a web site, ask what goal they are trying to achieve. Ask them what costs they are paying for the service they want you to implement. And then see if you can design a server-based system that gives them the info they want, and write up a…

Sure. But they want it tomorrow.

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.

Re: Why Is Web Performance Undervalued?

#78
post #77

Earlier quoted context omitted.

There is a better approach, as an engineer, to get this type of point across. Don't just reject their solution... offer a better one. If they come to you saying they want tracking on a web site, ask what goal they are trying to achieve. Ask them what costs they are paying for the service they want you to implement. And then see if you can design a server-based system that gives them the info they want, and write up a…

Sure. But they want it tomorrow. 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.

Yep, they want it tomorrow, and so does everyone else who has requested a feature.

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.

Re: Why Is Web Performance Undervalued?

#79
post #77

Earlier quoted context omitted.

Sure. But they want it tomorrow. 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.

Yep, they want it tomorrow, and so does everyone else who has requested a feature. 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 pro…

Clearly you have only worked at large tech companies with organization, processes, hierarchy, etc. Most places don’t have a PM, or even know what that is. They don’t have a cadence or a triage. What you are talking about is a rare exception.

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.

Re: Why Is Web Performance Undervalued?

#80

Earlier quoted context omitted.

A lot of companies seem to architect their web apps to deal with millions of users. When in reality they may have a couple of hundred hitting the site at once. 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 used to work at a boring mid-sized finance-y company a while ago. Our stack was full Microsoft - IIS,ASP.NET,MS SQL, plus some appliance doing load balancing/API throttling stuff (not sure, not a sysadmin guy). The whole thing fit in a closet, handled 10k+ requests day and night. All our code was basically - check user auth - do some stuff with the db/perhaps call out to some external service - serve request. I nev…

This has been my precisely my experience. There are lots of odd gotchas when working with these fancy stacks and the platform themselves often don't provide much benefit.
Post reply on HN