Every month or two I seem to get into a heated debate with another MODX developer about why I feel strongly compress_css and compress_js should:
- default to false
- never have been added in the first place
So, I'd like to shed some light on this subject and get a discussion going. Now, before we get into the performance tests and numbers (we'll do that later) let's establish a few things first.
The MODX Manager is NOT a website
. In fact, it is the exact opposite of one. Let's compare the user experience of each to illustrate how different they are.
- is public facing
- has short (<30s) page visits
- has a high bounce rate
- has many inbound users visiting for short periods of time
- is commonly viewed on mobile
- serves the same CSS/JS, for every user and maybe every page
- runs on the same controlled server for all your users
- has some form of dependency management
Your MODX Manager:
- is not public facing
- has longer page visits
- has an incredibly low bounce rate
- has fewer users logging in for longer periods of time
- is commonly accessed from a high bandwidth desktops
- may serve different CSS/JS for different users/pages
- runs on a server MODX has no control of (with the exception of MODX Cloud of course)
- has no dependency management at all
We're starting to realize that our website is very much a like a drive-thru fast food restaurant. We have lots of users in the queue, who are looking to both digest and leave your establishment quickly.
The MODX Manager is more like a gourmet kitchen. You take your coat off, punch your time card, stay a while, and work on something really nice for people to efficiently enjoy at a later time. You and your sous chefs will probably be back tomorrow.
It is our responsibility as developers to examine the user experience(s) of what we are building first, and apply critical thinking to how we go about implementing, or not implementing given features.
On the web, we have to build very snappy pages because our users likely may visit one page and never come back to our site again. Since we have control over the assets we'll be loading, we can optimize them accordingly. With something like a CMS Manager you can ensure that users will both be back, and stay a while. The performance benefit of compress_css and compress_js is only noticeable on the first visit to a given page
. After that, the assets are cached in the browser.
So performance doesn't matter?
Performance absolutely matters. It is very important that MODX performs. There are countless threads and tickets related to compress_css and/or compress_js completely breaking the entire MODX Manager. Most commonly, this is due to what we call server misconfiguration. It's your server's fault we tell users. No, it's our fault for shipping such vulnerable software.
By allowing the MODX Manager to trip on it's own shoelaces and fall flat on it's face all in the name of performance benefits of compression we've established the assumption that said performance is *critical* to our user experience. My questions are as follows:
- Is this supposed benefit critical to the user experience?
- Have we measured this mission critical performance benefit?
- Have we gained more users with "snappiness" than those we have lost who gave up installation at the white screen of death?
- Should servers ever concat & minify front end assets?
Now I actually have tested 2.2 extensively in this regard. The intent of this post is to prove the benefit, if any, is irrelevant so I am leaving those numbers out for now.
. Did MODX test compress_css and compress_js on the server you are running? Nope.
A few other questions to ponder:
- Are there no instances where a server takes longer to process, concat, and minify an array of files than it would take to serve them flat?
- Do we really deserve to play the performance card?
- Is this methodology future-proof?
In my opinion, we have no right to play the performance card. Not because ExtJS is slower than molasses in the winter time, but because the MODX Manager has no dependency Management
. Install a couple of Extras and premium or not, you are probably loading 5 separate versions of jQuery. I thought we were talking about saving bytes here...
If the intent of compress_css and compress_js was to save bytes, practical features like dependency management should have been looked at instead. If the intent was to improve the reliability and performance of the software, we failed.
[ed. note: dinocorn last edited this post 7 years, 3 months ago.]