Original Source
Burt Beckwith has released the first version of the grails-ui-performance plugin. On a previous post he describes a handful of optimizations he has done at work, which eventually led to the birth of the plugin
I’ve been looking at performance issues for the site we’re building at work. The database is obviously going to be the biggest bottleneck, so we’ve configured 2nd-level caching for read-only tables and some read-mostly tables. We’ve also configured query caching for obvious candidates.
Currently the big hitter is the search page, and some profiling showed that we just needed a few extra indexes and some extra 2nd-level caching, but otherwise it performs pretty well. I still need to test it on production hardware with a large database – the stuff I’ve done so far is on my own high-end developer box with the database, server, and clients all running on the same box.
So I’m now working on applying the 14 rules
from Steve Souders and the Yahoo performance team. YSlow has been very useful to measure improvement after each change, and of course Firebug is indispensable.
This is a Grails app, and Grails makes several parts of the process a lot easier, but of course all of these approaches apply to non-Grails apps too.
This plugin is not the first one aimed at improving the performance of a Grails application, or a regular web application for that matter, Burt makes sure to mention the Jawr plugin, here are his reasons for trying out the new plugin
One significant feature that I’m providing is versioning and far-future Expires headers and caching for images in addition to JavaScript and CSS. Of course images aren’t very compressible, so gzipping them doesn’t make much sense, but the image payload of most sites is going to be a lot larger than that of the .js and .css files, so it makes sense to try to get clients to cache those also.
Another is a taglib that helps keep javascript at the end of the page. Sitemesh gets in the way here - there can be a lot of code in your layout GSPs after the layoutBody call, so DependantJavascriptTagLib allows you to define one or more hidden JavaScript declarations in your GSPs and render them all from the layout at the end of the body (Sitemesh has “content” tags that support this but there’s a bug where script tags lose their opening bracket so I’m using a technique borrowed from here).
Finally there’s simplicity - this was designed as a Grails plugin, so it has a more focused feature set and has fewer moving parts, preferring convention over configuration.
Having said that, there are advantages and disadvantages of both approaches:
Reasons to use Jawr versus using this plugin:
- a lot more features, e.g. I18n, DWR, and JSF support, choice of minification approach, etc.
- more configurable, e.g. exclusion lists - I gzip/minify/version everything
- it’s not Grails-specific, so the time you spend learning its features will be useful when you want to use it in non-Grails apps
Reasons to use this plugin versus using Jawr:
- the bulk of the work is done during the build, so no temp files, everything is in the war and problems are caught during the build instead of after deployment
- it versions and sets Expire on images, and rewrites inner urls in css files to point to versioned images
- supports Sprites via a taglib
- helps move JavaScript to the end of the body via a taglib
- doesn’t use a servlet - only a few taglibs and a Filter, letting the container continue to serve static resources
- less processing at the server - it only needs to check if client supports gzip when rendering <javascript>, <css>, and <img> tags in GSPs
The plugin can be downloaded from Burt’s site (here) for the time being. We look forward on the next update.
more Grails-friendly - in development mode it does nothing, and is only enabled in production mode, so there’s no need to check for modifications since Grails doesn’t support that in production mode
Tags: Burt Beckwith, Grails, Plugin
About
