When you are making your web applications for non-intranet usage (or for mobile users via VPN), you cannot emphasize the importance of compression too much. Google’s developer tools will blame you for missing compression and we have written several articles about this previously.
Still, we have seen it in action that Vaadin developers don’t take care of this. They have chosen Vaadin, because they want to delegate web app complexity to the framework, so why should they have to think about compression? It is also expensive to put engineers to fine tune the hosting setup. They shouldn’t have to, so we decided to do something about this.
What is new in 7.5 ?
In Vaadin applications, resource usage is weighted to the first load of the application. The “client side thin client” aka widgetset, which a Vaadin application needs to load before it can start communicating. This thin client often is far more expensive (in terms of transferred data) than the actual UI state changes that the thin client then does with the server. Thin client resources are also static, same for each and every user, which make it a sweet spot for some optimization.
The largest part of the widgetset is the JavaScript that the GWT compiler spits out. GWT has a really handy post processor that gzips all generated artifacts in a matter of milliseconds, but that is not enabled by default. In Vaadin widgetsets, it now is. If you look at the generated resources, you’ll see that the output has a “.gz” version of all generated JS files, which is only a fraction of the non-compressed version.
Some application servers (like Jetty and Tomcat 8, with configuration) support this kind of pre-compressed resources out of the box. But the problem is that many Vaadin projects serve these files through VaadinServlet, not through the default servlet by the servlet engine. In Vaadin 7.5 we now include a similar feature in VaadinServlet, and for your convenience, it is on by default. So, in practice, if a “VAADIN/foo/bar.js” is requested from the servlet, it checks if there is a “vaadin/foo/bar.js.gz” file available. If there is, this pre-compressed content is streamed to the browser, with proper content encoding headers.
This solution has four things that make it really good: it is a good default, it is completely transparent to users and developers, it consumes less bandwidth and it consumes less server resources (as it needs to send less stuff through the wire). The only downside we have found is that some really simple compression filters don’t work properly with the feature, but there is an easy fix for that.
What about themes?
The theme files (mostly CSS in modern themes) are the second largest resources in typical Vaadin applications - and also required to be loaded before the application can start to render. The VaadinServlet improvement treats theme files in exactly the same manner as JS files, but our tooling doesn’t yet create a “.gz” version of css files by default. This is, however, really easy to set up in your own build with e.g. the yui-compressor Maven plugin:
<plugin>
<groupId>net.alchim31.maven</groupId>
<artifactId>yuicompressor-maven-plugin</artifactId>
<version>1.5.1</version>
<configuration>
<nosuffix>true</nosuffix>
<gzip>true</gzip>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>compress</goal>
</goals>
</execution>
</executions>
</plugin>
The above configuration will also use yui-compressor to strip obsolete comments and whitespaces from the css file, making it even smaller. In my test, a basic theme based on Valo compresses from original 304kB to just 29kB (minified + gzipped).
In future versions, we plan to add similar CSS compression features to our own tooling as well.
What does this mean?
If you have previously had an “advanced hosting setup” with a proper compression setup and even a CDN for static resources, this change doesn’t help you too much. If you were using a filter or Tomcat’s connector based features to compress stuff on the fly, you might save some CPU cycles, as the resources don’t need to be run through a gzip algorithm.
But for new and existing Vaadin apps, with a bare bones hosting setup, the change is noticeable. If you or your users have a slow network connection, the improvement might be huge. In a typical “office setup”, you’ll just notice a snappier application startup on Monday mornings. In our tests that simulate slow network users, the initial startup time in of a Vaadin app (nothing cached in the client) dropped to 1/4th of the bare bones setup just by compressing the widgetset and the theme!
Although the default setup is now much faster out of the box, you still shouldn’t forget hosting fine tuning, especially in cases where you strive for the best possible performance. We still don’t compress the actual “state communication”, which may in some data heavy applications be considerable as well. It wouldn’t be that difficult to compress that part dynamically in the VaadinServlet, but in some cases you want to do that in a e.g. front proxy instead. Also CDN distribution of your static files has additional benefits as well.
If you’re uncertain about your Vaadin apps’ hosting setup, I’m sure some of our consultants are more than happy to help you, as well. They’re based around the world and are happy to fly over to your office as well. Contact our sales for more info.