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.
> Because it’s not a consideration on the bottom line.
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.
Its always the same reason, the business just doesn't hire people qualified to do the job.
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.
Businesses do hire people qualified for the job in general. However they have lots of different jobs with different qualifications needed and so they have lots of different qualifications in play.
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?
I think part of the reason is that management usually know enough about accounting that they know enough to hire the right people, ask the experts in the area the right questions, and ensure someone implements best practices.
> 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.
Metrics, you have to track both network latency for all critical calls and page load times from multiple devices. There are multiple services out there that let you track this information.
On the margin, that is true. But it also needs a situation where there are many competitors in any market, where consumers will choose only the best product at the best price instead of paying attention to politics/religion/location/etc, where switching costs are low and where the consumers can accurately determine quality in the first place.
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.
It seems fairly trackable though? Like money spend per second of loading time?
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.
You have more users, hopefully more revenue, and a problem that can be solved by throwing connectivity and hardware at it - and you have already probably reduced your spend on one or both in making the site faster.
If that is the case, it should be almost trivial to write up a paper that quantifies the cost of poor performance and executives ymwouldnlove to read it.
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.
They aren't given the opportunity to, that's true. We've also been in an industry-wide performance drought for so many years that many devs don't even realize how fast websites can be.
Yep. I recently ran an experiment where I tried appending elements to a list in rapid succession. One with near-native JS and another with React. The former was about 40 times faster.
As for the tracking code from on high, holy hell you are right. We got bought by a big company and suddenly we've got giant support panels in the bottom left and JS loading from random domains we've got no way to keep our content security policy up to date with updated domains because they're out of our hands.
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 proposal for it that includes the downsides and long-term hidden costs of their solutions. Whatever they are asking you, follow that pattern - treat them like a customer (which they are), determine their needs, determine their budget, and propose solutions that give a full comparison of the options.
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.
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.
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.
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.
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.