<![CDATA[ Why compress_css and compress_js are silly - My Forums]]> https://forums.modx.com/thread/?thread=91496 <![CDATA[Re: Why compress_css and compress_js are silly]]> https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=3#dis-post-530871 Quote from: nuan88 at Sep 01, 2015, 12:43 PM
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.

Mark and I have started working on a PR together that uses Grunt to concat & minify the core MODX files as part of the front end build. This allows us to do away with server-side minification entirely.

This test shows the server-side minification wasn't even an optimization, it didn't make anything faster.
https://github.com/modxcms/revolution/pull/12611#issuecomment-135655556

This user story comparison is what the take away from this should be though. Just think about this:
https://github.com/modxcms/revolution/pull/12611#issuecomment-135659086


  • User visits a Resource edit page with compress_js enabled
  • We send them 350kb of script in a single file
  • redactor.js is one of the included files
  • User disabled Rich Text on the resource and refreshes the page
  • New URL, so we send them all the scripts again and leverage the cache for none of them even though all we are doing is sending them same scripts minus redactor

vs


  • User visits a Resource edit page with compress_js disabled
  • We send them 350kb or more of script in individual files
  • redactor.js is one of the included files
  • User disabled Rich Text on the resource and refreshes the page

In the first example we have a cache usage of 0% meaning that we don't leverage the browser cache at all even though the only thing that has changes something has been removed and we are now sending less bytes. The URL changes, so we resend everything again. On no planet should this be considered optimization.

In the second example we have a cache usage of 100%. We send nothing.

Also, I think we should be less worried about minification and more concerned with documenting and encouraging people to make sure GZIP is enabled for the manager CSS and JS.




]]> dinocorn Sep 01, 2015, 03:04 PM https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=3#dis-post-530871 <![CDATA[Re: Why compress_css and compress_js are silly]]> https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-530840 nuan88 Sep 01, 2015, 07:43 AM https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-530840 <![CDATA[Re: Why compress_css and compress_js are silly]]> https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-530735 nuan88 Aug 29, 2015, 12:47 PM https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-530735 <![CDATA[Re: Why compress_css and compress_js are silly]]> https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-530672 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. tongue 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

]]> dinocorn Aug 28, 2015, 01:56 AM https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-530672 <![CDATA[Re: Why compress_css and compress_js are silly]]> https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-530644 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.]]> dinocorn Aug 27, 2015, 11:03 AM https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-530644 <![CDATA[Re: Why compress_css and compress_js are silly]]> https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-527349 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...]]> dinocorn Jun 23, 2015, 12:35 PM https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-527349 <![CDATA[Re: Why compress_css and compress_js are silly]]> https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-503093 https://github.com/modxcms/revolution/pull/11682]]> optimuscrime Jul 14, 2014, 03:57 PM https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-503093 <![CDATA[Re: Why compress_css and compress_js are silly]]> https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-503058 sottwell Jul 14, 2014, 10:18 AM https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-503058 <![CDATA[Re: Why compress_css and compress_js are silly]]> https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-503054 optimuscrime Jul 14, 2014, 10:01 AM https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-503054 <![CDATA[Re: Why compress_css and compress_js are silly]]> https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-503037 sottwell Jul 14, 2014, 07:41 AM https://forums.modx.com/thread/91496/why-compress-css-and-compress-js-are-silly?page=2#dis-post-503037