Gzip is useful indeed. We are currently experimenting with this.
I do not know which version of the mendix application you are profiling, but beginning with version 2.5 all css and js files are minified. This means that all necessary files are getting flattened into one single file, resulting in less requests at startup and faster load time.
Yet, you are totally right, with gzip you can gain even more increase in request speed. As I'm concern almost all production applications are running beyond web-servers, like Apache, Tomcat, nginx, etc. For this reason, if you want to provide gzip'ed content, you have to enable necessary module in that web-server and not in the mendix application itself. Please note, that Internet Explorer (IE6 pre-SP2) has some issues when dealing with gzip'ed content.
Why not compress the AJAX calls to /xas? Do you have any experience in that area?
I am currently testing this using Apache 2.2 and the mod_deflate module. I've configured it (together with ProxyPass /xas and ProxyPassReverse /xas) using the following directive:
This seems to work well in Firefox, but I have yet to test it thoroughly (also in other browsers). Also, I haven't yet measured the reduction in bandwidth use.
Update: I have been able to test this in the QA environment of a customer. The customer has very limited network bandwidth, resulting in response times of 800-1200ms when browsing through pages in a data grid (with 20 rows and 16 columns). The returned JSON was +/- 14KB in size. After applying the DEFLATE output filter as specified above, the JSON response was reduced to 2KB and the response time was reduced to ~300ms. Note that this is an environment where the size of the response has a big impact on performance, which is not always the case. However, Internet Explorer (version 7 at least) doesn't seem to handle the (JSON) compression very well. After clearing out the temporary internet files and logging in to the application, all you see is an empty top pane :-( Firefox works like a charm, of course...
From 2.5.1 and on, we'll be distributing .gz versions of all static mxclient files. These will automagically be picked up when in development mode for all browsers that send the "Accept-Encoding: gzip" HTTP header.
For production environments, we recommend people use something else than jetty (the built in HTTP web server) to serve static media. Both nginx and apache have support for dynamic gzip compression.
As for static compression (again: mxclient), I know nginx has a module that supports pre-gzipped files. See here
Of course, you could always dynamically gzip everything with both nginx or apache, but that would consume a little processing power on the webserver frontend.
That's kind of hard to do because we don't output (that much) html. Almost all of the application runs via ajax calls. While google page speed and yslow may show that mendix applications are slow, once they've been loaded the pages are actually quite fast.