I'm trying to reduce the amount of inlined Javascript at the bottom of the pages. Concerning that, I have one main question: Is there any reason why the language string constants are inlined on all pages? Why couldn't we place them in the merged js file?
I'm talking about the below parts
_.tr({
cannot_buy:
...
and
$.extend(_, {
index_script:
...
Any idea?
because you don't want to regnerate the full js file everytime a lanugage variable is changed. Would be a large performance issue.
If your scripts are all at the end then there's no real penalty being paid other than to parse the script tags like any other tag. What is the goal of your wanting to reduce the amount of embedded scripts?
But the language constants (these are notification and error strings) are likely not going to change over a long period of time, yet the inline JS is included in every single page which is a lot of wasted traffic. If it was part of the single unified JS file (containing jQuery, etc), it would be much more logical, wouldn't it?
But the language constants (these are notification and error strings) are likely not going to change over a long period of time, yet the inline JS is included in every single page which is a lot of wasted traffic. If it was part of the single unified JS file (containing jQuery, etc), it would be much more logical, wouldn't it?
What about if you use several languages? One common .js file is compiled for all languages
Hello,
I can certainly see your point. Instead of creating new script tags there should be a template for javascript defined language variables which can easily be extended. This would certainly remove a fair amount of the useless script tags.
Kind regards,
What about if you use several languages? One common .js file is compiled for all languages
Perhaps my setup is different (although the cs-cart demo also has this), but for me the JS notifications, error strings and other JS constants are stuck at the bottom of the HTML page itself, inlined, instead of being part of the one large compiled JS file. It comes from the bottom part of scripts.tpl.
I certainly hope that multi-language setups don't have all languages strings inlined inside each and every single HTML page!!
I have an English only site and that part of the HTML file consists of around 4K of data. Granted for a 71K file overall it's not much (>5%), but 4K is not nothing!
Not to mention that the browser must parse it with every page. I just want to understand the logic. Maybe there's a reason it's in every page and must be parsed for every page... But I'm missing it.
No, you get the language variables for the language in use for the page.
I will guarantee tou that if you removed all the inline scripts, you would not be able to measure the performance difference in TTFB or even for completing page load. The gain would be in single digit milliseconds if it could be measured at all. Network variability probably has a greater impact and that change would be lost in the noise.
And do note that the notifications and language variables included are only use in JS, not generally for the rest of the code base.
No, you get the language variables for the language in use for the page.
I will guarantee tou that if you removed all the inline scripts, you would not be able to measure the performance difference in TTFB or even for completing page load. The gain would be in single digit milliseconds if it could be measured at all. Network variability probably has a greater impact and that change would be lost in the noise.
And do note that the notifications and language variables included are only use in JS, not generally for the rest of the code base.
Oh absolutely, we're talking milliseconds! But that's how you get to more significant improvements. It's not just the network latency, but the browser as well. And it's 4K, I've seen libraries smaller than that! Again, I was just trying to understand the logic for it being there, that's it.