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.
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).