Recent Posts1
JavaScript / Re: Optimization
« Last post by Jason Knight on 13 Sep 2021, 01:37:27 pm »Combining down files when possible -- be it CSS, JS, or even presentational images (see the incorrectly named "CSS Sprites") -- has a lot of advantages.
1) less handshaking. The raw number of separate files increased load time because each request ends up a connection.
2) Better caching. for a small penalty on the first cache empty page load, you can pre-cache what's used on other pages even if it's not used on the current one. If you have sites where users are visiting lots of different pages, anything you can move out of the HTML can result in faster load times AFTER the first page.
This is something a lot of garbage "JS For Nothing" -- such as "Single Page Applications" -- oft tries to "fix" in situations where the dev isn't qualified to write HTML. Because of course throwing more code at things will make it faster -- NOT!
3) Better compression. "gzip" compression of files is more efficient the more often the same run of characters is repeated. As a single file the odds of repetition of words like "function" or "typeof" or any other word/run of characters increases. Compression also tends to include a lookup table / dictionary of said words/phrases that are replaced in the data stream. Having a single file increases the odds of "hits' resulting in smaller files.
That said, there ARE scenarios where you will have so much JS and so many files you get diminishing returns on that, but 99% of the time that just means the code in question is shite. See where people crap out megabytes of JavaScript to do two or three dozen kilobyte's job, or worse where a page doesn't even NEED JavaScript. See the time-wasting energy-exhausting code-bloat mental-huffing-midgetry known as "frameworks"
When it comes to the Google Tag Manager, my opinion is that steaming dung heap should be ripped out of every site it's used on. Between the mix of creep level spyware, page load delays, and general micromanagement of pointless data points that wastes time that could and would be better spent GENERATING CONTENT OF VALUE, it serves no purpose other than providing pointless data-points for marketing turds to circle-jerk each-other over. GET RID OF IT! It's doing you zero favors.
As to "defer", it can be useful if you want to skip hooking DOMDocumentReady but you need to be aware that when the script actually loads and executes is a bit willy-nilly. To me it's a bit pointless since server-side you likely just want the script to load and run NOW, and client-side if it makes a difference you've likely got too much scripting or worse, are inducing FOUC instead of preventing it.
It's useful, but I'm not a fan. If you can't just move all your scripts to before </body>, you've got bigger problems than adding an attribute to the language is going to fix.
1) less handshaking. The raw number of separate files increased load time because each request ends up a connection.
2) Better caching. for a small penalty on the first cache empty page load, you can pre-cache what's used on other pages even if it's not used on the current one. If you have sites where users are visiting lots of different pages, anything you can move out of the HTML can result in faster load times AFTER the first page.
This is something a lot of garbage "JS For Nothing" -- such as "Single Page Applications" -- oft tries to "fix" in situations where the dev isn't qualified to write HTML. Because of course throwing more code at things will make it faster -- NOT!
3) Better compression. "gzip" compression of files is more efficient the more often the same run of characters is repeated. As a single file the odds of repetition of words like "function" or "typeof" or any other word/run of characters increases. Compression also tends to include a lookup table / dictionary of said words/phrases that are replaced in the data stream. Having a single file increases the odds of "hits' resulting in smaller files.
That said, there ARE scenarios where you will have so much JS and so many files you get diminishing returns on that, but 99% of the time that just means the code in question is shite. See where people crap out megabytes of JavaScript to do two or three dozen kilobyte's job, or worse where a page doesn't even NEED JavaScript. See the time-wasting energy-exhausting code-bloat mental-huffing-midgetry known as "frameworks"
When it comes to the Google Tag Manager, my opinion is that steaming dung heap should be ripped out of every site it's used on. Between the mix of creep level spyware, page load delays, and general micromanagement of pointless data points that wastes time that could and would be better spent GENERATING CONTENT OF VALUE, it serves no purpose other than providing pointless data-points for marketing turds to circle-jerk each-other over. GET RID OF IT! It's doing you zero favors.
As to "defer", it can be useful if you want to skip hooking DOMDocumentReady but you need to be aware that when the script actually loads and executes is a bit willy-nilly. To me it's a bit pointless since server-side you likely just want the script to load and run NOW, and client-side if it makes a difference you've likely got too much scripting or worse, are inducing FOUC instead of preventing it.
It's useful, but I'm not a fan. If you can't just move all your scripts to before </body>, you've got bigger problems than adding an attribute to the language is going to fix.
