Steve Souders, “JavaScript Dominates Browser CPU”:
Ten years ago the network was the main bottleneck. Today, the main bottleneck is JavaScript. The amount of JavaScript on pages is growing rapidly (nearly 5x in the last 7 years). In order to keep pages rendering and feeling fast, we need to focus on JavaScript CPU time to reduce blocking the browser main thread.
Alex Russell, describing a prototype of “Never-Slow Mode” in Chrome:
… blocks large scripts, sets budgets for certain resource types (script, font, css, images), turns off document.write(), clobbers sync XHR, enables client-hints pervasively, and buffers resources without Content-Length set.
Craig Hockenberry, posting an idea to the WebKit bug tracker:
Without limits, there is no incentive for a JavaScript developer to keep their codebase small and dependencies minimal. It’s easy to add another framework, and that framework adds another framework, and the next thing you know you’re loading tens of megabytes of data just to display a couple hundred kilobytes of content. …
The situation I’m envisioning is that a site can show me any advertising they want as long as they keep the overall size under a fixed amount, say one megabyte per page. If they work hard to make their site efficient, I’m happy to provide my eyeballs.
It’s easy to point a finger at frameworks and third-party scripts for large amounts of JavaScript. If you’re interested in hearing more about the size of frameworks, you might enjoy me and Dave discussing it with Jason Miller.
And speaking of third-parties, Patrick Hulce created Third Party Web: “This document is a summary of which third-party scripts are most responsible for excessive JavaScript execution on the web today.”
Sometimes name-and-shame is an effective tactic to spark change.
Addy Osmani writes about an ESLint rule that prohibits particular packages, of which you could use to prevent usage of known-to-be-huge packages. So if someone tries to load the entirety of lodash or moment.js, it can be stopped at the linting level.
Tim Kadlec ties the threads together very well in “Limiting JavaScript?” If your gut reaction on this is that JavaScript is being unfairly targeted as a villain, Tim acknowledges that:
One common worry I saw voiced was “if JavaScript, why not other resources too?”. It’s true; JavaScript does get picked on a lot though it’s not without reason. Byte for byte, JavaScript is the most significant detriment to performance on the web, so it does make sense to put some focus on reducing the amount we use.
However, the point is valid. JavaScript may be the biggest culprit more often than not, but it’s not the only one.
The truth universally ignored is that latency kills performance long long way before bandwidth does.
Wanna proof? If bandwidth mattered, YouTube, Netflix would not even exist.
There is ABSOLUTELY NOTHING demanding more than 1 HTTP request PER PAGE.
What? But if network was 20 times faster, eould this post still be relevant? I think network is still the culprit. I should be able to download 1gb a second. Why not?
Huh? It’s not the network. If you download 1gb at lite-speed, but then your browser has to unravel that and attach elements to the DOM, and possibly download async resources after certain elements are rendered, the time it takes to download is the least of your worries. It’s that “modern” frameworks and patterns put too much on the browser. You’re essentially asking your browser to be your OS, while your web code is your application. The popular method now of creating a big JavaScript “bundle” which is a compiled JS app is just asking the browser to do too much. Sorry guys. Go back to clean HTML and progressively enhance from there.
Don’t blame JS for a development issue. JS is the best has happened to web development. How about the hundreds of online courses saying you could be a web developer in less than 2 months?. Today we have nice browsers, powerful processors and cheap RAM, we do need also nice web apps. Web apps are the cheapest and more effective way a company can develop a multiplatform information system. AJAX, charts or DOM manipulation are necessary to offer functional and beautiful UX. And we need JS for that.
Imma be honest I don’t like JavaScript anymore. Personally I try to use it minimally.