Grails UI Performance Plugin is THE BOMB

So, I added the grails UI performance plugin to my app over the weekend. It basically promises to provide build and app support for the 14 rules of High Performance Websites from Steve Sounders.

These are things like:

• Adding far futures expires headers to relatively static resources like images, CSS and JS


• minification and compression of CSS and JS


• bundling of different CSS and JS files into singular files at build time


• Keeping the CSS at the top of the page and javascript at the bottom

But does it work? Yeah, it appears to. I ran some tests having the performance tuning on and off. This first picture is with no performance tuning (cache primed). The page took 3.57 seconds to render.

No performance tuning with primed cache

This second picture is with UI performance plugin turned on. The page took 1.74 seconds to render, and the number of requests for resources dropped dramatically. That is a 48% increase in performance, and if you look at the time to return the HTML page, it was significantly higher the second time around.

All in all, it took about 2-3 hours to get the plugin wired up appropriately for my app and to make the view change necessary. In the future, I would probably wire this plugin early so you can use its tags as you go. Also, this only applies to the app when running as a war, so use grails run-war to test it out. Once you have it configured, you will need to turn it off in the development environment to be able to run your app with grails run-app again. This just requires uiperformance.enabled = false in your development config.

Cryptic grails bug

So, I ran into a grails bug with link creation as I near closer to a prod release of my super-duper top secret site.

<g:createlink absolute="true"/>

will *always* render a link that is HTTP and on the unsecured port (80 or 8080), even if the request was of the rendering page was HTTPS. It seems like there should be a property to have it honor the protocol & port of the request.

Actually, looks like this is a known bug: http://jira.codehaus.org/browse/GRAILS-3625

The workaround I used was to create a custom tag that would output the base for an absolute URL:

def baseUrl = {
  out << "${request.scheme}://${request.serverName}:${request.serverPort}${request.contextPath}/"
}

I could then chain the tags together to create links I wanted:

${baseUrl()createLink(controller: 'foo', action: 'bar')}

This worked fine enough in my case, the fix was simple, but figuring out there was an actual bug in the framework that required a workaround on my part took some time.

So I dig me some grails named URL mappings. They allow you to associate a logical name with a URL mapping, and then to specify that name later when rendering links with the

tag to have it write the URL appropriately. Here is an example...

In UrlMappings.groovy:

    name profileMapping: "/profile/show/$alias/$listOd?" {
        controller = "profile"
        action = "show"
    }

In a GSP page:

    <g:link mapping="profileMapping" params="${[alias: profile.alias, list: currentList.id]}"/>

This is important, because often the default mapping of /controller/action/id is not the best suited for the task. You might want to specify something more human readable than a numeric ID for usability and SEO, for instance.

Anyway, this is just another reason I really like grails.