In depth knowledge of the DOM would serve you a lot better than knowing about CPUs. What triggers a repaint, how you can avoid it, and so on.
It usually maps to constraints they can't control.
It's not really the web developers who are the issue; they just implement what the people above them in the org chart wants. You could argue that the web developers should push back on it more than they do, but I don't buy that they're not knowledgeable enough to fix it.
That's not to say that there aren't actual technical issues; the recent trend of throwing front-end frameworks on content-heavy pages, making the users' low-powered phones parse and run hundreds of megabytes of JS before the page can be interacted with, is an example.
The worst culprit is not knowing how to use photoshop to optimise images properly.
1 A lot of the front end production staff wont be comfortable using a cli - its designers that should be providing the images not developers.
2 Photoshop in some ways produces better results and is already part of the work flow.
There are a multitude of issues that can be tweaked to speed things up more so than javascript elimination. You can switch to HTTP/2, implement server push, image compression, header compression, compressing HTML/CSS/Javascript downloads, preloading, above-the-fold downloads, and much more. A jQuery plugin user might not know half those things and I only mentioned maybe half the things one should know.
The average JS dev (like average anything dev) may not write performant code, but the functional parts of the website are not where the main problem lies.
As such, sure, it's useful to know the details, but it's usually far from necessary.
One example would be lazy-loading of images. I've worked at multiple agencies that definitely knew how to do this, but didn't, causing in the tens of megabytes of unnecessary data. Even just a small change to the templates + a jQuery plugin could have solved this one issue.
Of course, there are lots of reasons why a lot of this low-hanging fruit is left to rot, but they're not primarily to do with the developer's ability to understand all those details that you describe as necessary.
And yet somehow they decided to not use that knowledge until Google pushed them into corner.
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.
You need to understand how html css and js work and not cut and paste megabytes of cruft.