OVERWEIGHT AND BLOATED?

Having taken the broadband world for granted, we wanted to include some Ajax functions and Scriptaculous-based effects naturally, to add ‘ohh and awe’ to the theme. Though Scriptaculous (being built on the 90k Prototype) is heavy duty when it comes to mobile Safari’s capability to swallow it, and it soon proved to be a major blockade to developing the theme in the ways we had imagined.

I don’t have real-world stats for the comparison on hand as I write this, but our testing revealed that we’d have to explore other options to accomplish a lighter bandwidth footprint and still have the features we wanted, because it was disastrously slow.

Our preference was to use Scriptaculous, mostly because we were both familiar with it, and had a library of prepared code to draw up to speed up the development cycle. In short- we were lazy and looking for a quick fix to the predicament.

Enter compression. Now, I don’t claim to be an authority on this matter, as are there who need to take advantage of compression for mission critical application use, but I do know that when it comes to the raw transfer time of compressed vs. uncompressed scripts that every kilobyte makes an enormous difference, especially when we’re talking EDGE on the iPhone.

SQUEEZING INTO THESE PANTS

The combined weight of the javascript effects on WPtouch is a staggering 48kb. Consider that Prototype, Scriptaculous (Effects only) and some custom iPhone/iPod touch specific code is contained in that tiny package. Uncompressed, it was over 170kb. That savings (nearly 4 times smaller) changed the page load times dramatically, and allowed us to go forward with our Prototype/Scriptaculous plans.

STYLE FIRST

We used CSS wherever possible to provide colours and shapes, and if it weren’t for the fact that mobile Safari doesn’t support its big brother’s capability for CSS transforms, we would have been able to skip out on Scriptaculous for effects and just transform everything using CSS only.

A PICTURE IS WORTH A THOUSAND BYTES

The same was true for images. Whenever I could, I used the smallest possible sizes for files using a combination of very tiny crops for repeating images, and the ‘Save for web’ option in Photoshop.

I could have saved likely 50% more in file size if I had chosen .jpg as the predominant file type, but I really loved the quality that .png images provided. Early testing showed the difference in load times with .jpgs was nominal compared to the washouts I was seeing in colour with them.

MORE WEIGHT TO LOSE

We continue to trim and squeeze more weight out of WPtouch, and as we move towards adding new features it will certainly be something that will remain a constant challenge. With the advent of theme-capability for the plugin, we imagine that users themselves will come up with some dazzling examples of optimization- something we’re looking forward to seeing. In the mean time we’ll be focused on improving the theme as it is, and dabbling with Mootools and jQuery in compressed forms, along with other scripts available on the web for performing the functions we need will be explored.

What’s your experience with compression and file-size trimming? Have you got tricks we (and our readers) would love to know about?