Open AlexanderSk opened 8 years ago
10-2-2016 Update: I found out also that in the case one has the option "Merge JS" to NO but has the option Compress JS enabled the page outputs encoding error. I guess the same might be going on for css too.
This is intended behaviour. When ScriptMerge is not used for merging, no CSS or JS will be picked up, hence no optimization can be done. The main thing is that ScriptMerge should never overwrite the original files. Moving them to a different location, would actually mean that CSS and JS is still parsed and that merging should be undertaken as well from a logical point of view. To optimize CSS and JS when ScriptMerge is not used for merging, tools like grunt and gulp should be used instead.
The issue of "Merge JS" being "No" and "Compress JS" being on of the "Yes" options, does not generate any output encoding issues here. It should not involve the HTML anyway. I'm not sure how to replicate this issue.
Hello and thank you for the replies. Regarding the issue i could not replicate it either. Perhaps with the recent merges something it was regulated.
Hello i hope me message finds you well.
I would like to state that after a generic speed opt test i found out that in the case a website may have the option"Merge Js" to No then the compress Js option is ignored and any script that is outputted is not compressed at all.
Is this a normal / intended behavior? In my opinion compression should be set and operate with and without script merging both on the merged scripts and on each script that is not merged separately.
You may test any website using the google page speed tool: https://developers.google.com/speed/pagespeed/insights/ You will notice the scripts are outputted with the same level of compression always.