Why compress_css and compress_js are silly

Quote from: optimuscrime at Jul 14, 2014, 10:34 AM

I just have to bump this.

I support OP 100%. Using compressed js/css makes no sense in the maanger like we do today. What would actually make sense would be to do a build for every version with ONE js- and ONE css-file that are minified. These two files would then be included at every pageload in the manager.

It would:
1. Cache once, fetch locally afterwards
2. Put no load on the server, because the minification is already done

Win-win imo.

Agreed.

As 2.3 is using Grunt just output an additional static file that is minified. Adding additional overhead is unnecessary and involves an initial performance hit.

Mixing third-party code breaks things which is why minification is the first thing I disable when installing MODX. Besides it should be down to the developers how they ship their code.

NOTE: There is a difference in merging the files and minifying them. I'm all in favour of merging third-party stylesheets/js.

It is quite possible to use MODX resources as your development environment, with plugins and/or snippets to concatenate, merge, minify and otherwise massage your CSS or JS or even PHP code and write the files to wherever you want them to go.

Not sure what you are getting at here sottwell. What you are talking about is not the issue we're discussing right now.

Just pointing out that you don't need all kinds of stuff installed on your machine for development of CSS, JS and PHP code, whether for front-end or back-end.

I've made a simple proof of concept for this: https://github.com/modxcms/revolution/pull/11682

What would actually make sense would be to do a build for every version with ONE js- and ONE css-file that are minified.

I'm all for doing this instead as it makes much more sense but honestly I think the best thing to do is absolutely nothing. Don't bundle all the files together at all. Yes you'll have a lot of HTTP request to reach out for the first time a user logs into the manager, and then every subsequent visit within the manager those many requests are cached. Remember, the /manager is a interface not a website. The same best practices do not apply.

It is more configurable if they are separate but it is also more future-forward. HTTP/2 basically does away with the notion that HTTP requests are costly and we need to work around them with concatenation. Regardless of that, the server should not be concatenating and it definitely shouldn't be minifying scripts. For a front end developer, it's very frightening to know that some random server environment could malform your scripts and break everything.

For MODX 3, I'd like to work on a proposal for how the manager loads assets because I think it should support loading common assets from a CDN. This is something I've spoken with Skytoaster about. They log into many many MODX managers a day, as I'm sure many of us do. Imagine if the bulk of the manager assets were cached just by logging into another MODX site...

Some people mentioned wanting to be able to compare my suggested optimization against the 2.4- compress_js system. There's a PR ready that you can pull from to check things out.
https://github.com/modxcms/revolution/pull/12611

Notice That Extra assets such as redactor-1.5.3.min.js are not combined with the minified core files. compress_js is still respected and will load the minified version of the file created by Grunt. So for fair testing you should turn this back on even if it was off.



Hopefully with 2.5 we can put this all behind us.

Quote from: markh at Jun 15, 2014, 12:12 PM

This thread lost me, simply because it promised performance tests and numbers and failed to deliver. If you just want to discuss the merits, that's fair game, but if you want to sway me I need to see numbers that show it doesn't do what it promises or even makes it worse.

I think what you really need to do is ask yourself two questions:

1. How do browsers cache files?
2. What happens when that thing browsers use to cache files changes?

My second attempt at a PR to introduce a Grunt compress_js workflow is solid without numbers to prove it makes sense but having been specifically ask by Mark, one of the integrators here we go.

As you can judge yourself from these test results everything about the server side minification was a waste of time. Do you have any evidence that contradicts that? On it's best day it still didn't out perform serving individual files.
https://github.com/modxcms/revolution/pull/12611#issuecomment-135655556

[ed. note: dinocorn last edited this post 8 years, 8 months ago.]

*pandemonium ensues*

To be clear I think JP is on to something. I can't say if he is right or wrong in this case, but he is asking the right questions and I think his rough calculus is really useful, of requiring some clear benefit considering the number of users who run into problems because of the option. I don't know what percentage this is but if its not insignificant then it should be part of the calculation.