3 ms·

Part of the reasoning behind minification is that it theoretically makes JS parsing (and compilation) faster thanks to reduced whitespace and shorter identifier

Part of the reasoning behind minification is that it theoretically makes JS parsing (and compilation) faster thanks to reduced whitespace and shorter identifiers. At this point you won't notice the impact of that on developer hardware, but it probably still matters on cheap phones and old PCs. The file size improvement really doesn't matter compared to that - you only download the file once* but it gets parsed and compiled on every page load** * assuming your website doesn't get instantly evicted from cache. ** modern browsers have mechanisms for caching the parsed/compiled code for a given JS file hash, I think, but I don't know how it works

zelphirkalt 3y ago
I doubt, that parsing code with longer identifiers really makes any noticeable difference even on old hardware. Parsing the code will most likely not be the bottleneck. Running an JS code is most likely going to take more time than parsing it. It is such a micro-optimization, that it is not worth even the development overhead of setting up a minimizer.
- kevingadd 3y ago
  If you shrink a JS file by 50kb or more via minification (some JS libraries are a meg or more, so this is a realistic scenario - if not understating how much a minifier can do) that's a meaningful reduction in the # of bytes being processed. With how optimized and parallelized modern JS runtimes are it's probably only a few ms in total savings, but on older devices it could save more time. Historically it's been proven that small improvements to load time can have a measurable positive impact on a website. Identifiers are often turned into atoms (which makes table lookup performance not really depend on how long they are) but for cases where identifiers are being looked up in dictionaries as raw strings, making them shorter could also improve runtime performance for your JS. I'm not sure how much this actually matters in practice though - I've seen dictionary key lookups show up in profiles here and there but it's usually not the main bottleneck.

zelphirkalt 3y ago

I doubt, that parsing code with longer identifiers really makes any noticeable difference even on old hardware. Parsing the code will most likely not be the bottleneck. Running an JS code is most likely going to take more time than parsing it. It is such a micro-optimization, that it is not worth even the development overhead of setting up a minimizer.

kevingadd 3y ago
If you shrink a JS file by 50kb or more via minification (some JS libraries are a meg or more, so this is a realistic scenario - if not understating how much a minifier can do) that's a meaningful reduction in the # of bytes being processed. With how optimized and parallelized modern JS runtimes are it's probably only a few ms in total savings, but on older devices it could save more time. Historically it's been proven that small improvements to load time can have a measurable positive impact on a website. Identifiers are often turned into atoms (which makes table lookup performance not really depend on how long they are) but for cases where identifiers are being looked up in dictionaries as raw strings, making them shorter could also improve runtime performance for your JS. I'm not sure how much this actually matters in practice though - I've seen dictionary key lookups show up in profiles here and there but it's usually not the main bottleneck.