The reason you're being downvoted is not necessarily because the first part of your broad sweeping generalization is always wrong. At least at the more junior levels, frontend focused engineers don't always have the same level of DS&A fundamentals as backend focused engineers. However, many engineers usually run into their first performance related issue in the first few years of their on the job experience, at which point they learn to speed things up.
It's in the second part of your statement where you're completely and totally wrong. Speeding things up on the whole does not require a lot of knowledge, and it does not require understanding how the cpu works at a low level and how javascript is compiled to machine code. Knowing how that stuff works can help you squeeze the last 1% of optimization out of code, but in practice, you get the first 99% of speed from decisions:
- Which frameworks do you use?
- What "add-ons" that are key to business do you end up embedding in the front-end and how much page size and slow down do they add?
- Where are your hot loops? Are you doing anything expensive inside them?
- Do you have things that are synchronous where they could be in parallel?
- How much eye candy are you adding to the page? Does it all need to be there?
- How much CSS are you using? Are you using it in a manner where CSS optimizations can do heavy lifting?
- What does the frontend and the backend API contract look like? Are there places where excess requests are occurring, and could they be rolled up so that there is less waste?
You may have noticed that many of these decisions boil down to architectural concerns as well as product and business level decisions, which are tangentially related to the labor of front-end engineering. I don't want to lob ad-hominems at people, but I find this kind of attitude one of the most tiresome parts about certain parts of the engineering community. There's this haughty, holier than thou mentality that places data structures and algorithms at the very top of engineering skills. There's a giant world out there where those skills are not at the top of the hierarchy, and actually are least useful because any sufficiently advanced development there ends up being commodified and available as open source software or as a paid SaaS (IE AWS).
Based on this short, flippant comment, it's obvious you actually have no idea how to actually speed up a web site because you have no idea about what the actual top ten things are that you'd do to speed it up in any kind of commercial production usage. What's even worse is that instead of trying to figure out something you don't know, you're instead making up an answer that sounds reasonable but is actually completely wrong and something any experienced frontend or full-stack engineer would understand is poor judgment and an ineffective approach. This is an extremely dangerous attitude to allow into an organization, because you end up with a culture where people are focused on one-upping each other and attempting to look elite as opposed to pragmatically arriving at the right approach for the problem, specific to all of its constraints. I've worked on these kinds of teams before, and it ends up being a miserable waste of time for everyone involved, and I've endeavored to work on teams that don't behave this way and to create teams that don't suffer from this.
Any engineer that gave this kind of a response to an interview question of "We've got a web app that's slow on the frontend and exhibiting XYZ symptoms -- how would you determine the root cause and diagnose it" would be rejected on the spot by me. That's the kind of attitude that can cause engineering organizations millions of dollars a year in engineering resource misallocation.
As a professional community, we need to evolve away from attitudes like yours. They symbolize an idealized, fictional world that is anything but the pragmatic reality of what good software engineering is.