I certainly intend to keep my Java skills up to date, but I think the framework stack is fairly well established for the while: Java + Spring + Hibernate + MVC (WebWork would be my choice). This framework stack delivers pretty well, and whilst improvements will come along, I don’t envisage a sea-change in how web-applications are delivered, for a while.

I do however forsee some fairly fundamental groundshift in how web sites, or more precisely, web applications are developed (not delivered). The change in emphasis is that functionality is moving from the (web) server to the client (browser).

These emerging technologies (and challenges) place new demands on the web designer/developer. Gone are the days of a web designer slicing and dicing a photoshop image into a slick, brochure web site. Nowadays the developer must learn how to programme the client.

The demand for Rich Internet Applications (RIA) is moving the web forward with giant leaps. AJAX/XHR is now well established, and in recognition of this requirement, the latest web browsers have worked hard to improve Javascript performance, as have the developers of the cross-browser Javascript libraries (JQuery, Prototype, DoJo, MooTools etc).

The next evolutionary stage is to provide support for offline-browsing, whereby browsers can synchronise locally held data with the web server. Firofox supports this, as does Google Gears, Adobe AIR and Microsoft Silverlight. The HTML5 spec. will eventually provide some standards around this feature.

These two technologies, alongside the adoption of next-generation mobile phones (3G iPhones are imminent) plus a fervent appetite for social networking(FaceBook, LinkedIn, Twitter) are driving a demand for RIA. Savvy business leaders are recognising this; The phrase Digital PR is becomign common parlance. I, along with Stan PR, hope to be able to fulfill these demands.

So, from a technology perspective, I need to re-skill. Java will always be there, but it’s time to concentrate on client technologies. Look forward to blog entries about AJAX, Adobe Flex, iPhone development and Social Networking.

I’ll also be blogging about PHP, or more specifically, CakePHP. Why? Well, that’s a blog post of it’s own, but if I’m going to abandon Java, then I still need to deliver web content. PHP is quick and easy. CakePHP is a mature PHP framework providing a wealth of functionality. Sure, Ruby or Python are more powerful languages, but for now, I need to get up and running as quickly as is possible. As of Monday, I enter a whole new world.

I’ve known about YSlow for some time. I analysed my site a while back, saw what needed to be done, but until recently did nothing. Much of what the plug-in recommended was not new to me. It was one of those tasks that I just never got round too.

However, having recently given my company website a facelift, I thought it was an opportune time to make amends. By providing a measurable benchmark (and even a score), YSlow can show you instantly what affect your site optimisations have made.

Some of the recommendations provided by YSlow, might not be available depending on your hosting set up, but most of the improvements are gained by applying common optimisations. Namely:

• compression of web assets
• setting HTTP Expires Headers on web assets
• minimising CSS and Javascript
• combining CSS and Javascript into fewer files

before optimisation

after optimisation

Above is a snapshot of my YSlow metrics before and after optimisation. I managed to reduce the initial download size by 50 per cent, and decrease the number of HTTP requests from 18 to 11. These are the initial figures, before the cache is primed. In my case, the gains made after assets have been cached, were mainly with regard to the number of HTTP requests being made - reduced from 17 prior to optimisation, down to a single request.

Optimisation was relatively easy. Here’s how the improvements I made.

###Compression of web assets
Compressing the web assets reduces the payload size of each web request. Anything that is not already compressed (such as images) should be. The downside to compression is that the client (browser) must inflate the content upon receipt, but for many home computers these days, the processing power is ample for this task. Similarly, the server must deflate the content prior to sending it, thus putting a load on the server.

If your content is static, one approach is to compress all your assets and upload them to your web server, alongside the uncompressed assets. If you’re using Apache web server, a few Content Negotiation rules can then be added to the Apache config files to return the compressed assets, if the client supports it (the request headers indicate if compression is supported).

Another approach is to compress assets on the fly using Apache modules such as mod_deflate (Apache 2) or mod_gzip (Apache 1.3). This does put some load on the server, and may not always be supported by your web host (mine didn’t allow it).

I went for a simpler solution. My site is templated using PHP, so adding these few lines to the top of my template header, compresses all the PHP web pages. The remaining web assets - CSS and Javascript are handled seperately (see below)

###Setting Expires Headers
Nothing new here, but how many web designers/developers think about ensuring that expiry headers are set correctly? There’s no rules as to what expiry to set. It all depends on what the site does. BBC News won’t want to cache their content for too long, but don’t want every hit to request their servers, so they set their content to expire after 10 minutes. My site content doesn’t change daily, so I set it to expire after one week.

Again, I used Apache rules to set both the HTTP Expires Header and the ETags, which had the desired effect. My rules in my .htaccess file were as follows:

###Minimising and Combining CSS JavaScript
This is where optimisation gets clever. It’s a given that reducing white space or minifying CSS and Javascript files will reduce the payload size. The clever bit is in reducing the number of HTTP requests, by combining the files before minifying them. With the adoption of Javascript libraries such as JQuery, Prototype etc. plus the inevitable breakdown of CSS files into more manageable files, there is plenty of opportunity for optimisation here.

I used Combine. Simply drop combine.php into the root folder of my web application, and modify my HTML to call this script rather than URI to the various assets as shown below. Before I used combine, my HTML header referenced 12 CSS and Javascript assets. After using combine, this was reduced to just four.

There are a other tools around like Combine such as minify, though I had problems with it combining some of the CSS files due to the presence of CSS hacks.

###Summary
As many of us web developers now use fast broadband connections, it’s easy to forget and ignore those less fortunate souls who, for one reason or another, are still on slower connections. YSlow is a quick, simple and measurable reminder of how we can improve the overall user experience with a few server-side configuration changes. It took me about 20 minutes to sort my site out, and in the future, it will take just minutes. You’ve no excuse!