A number of people have asked us how our skins are optimized to load quickly. In this post, I’m going to try to explain how our compression script works and what benefit it has. Let me start by explaining how we can optimize web pages in order to reduce their loading time.

The Theory

The time it takes a page to load is dependent on a number of variables. Let’s take a look at a few of these variables:

  • HTML page size (excluding external assets)
  • External asset sizes (external JavaScript and Cascading Style Sheets)
  • Number of external assets (1 style sheet or 5?)
  • HTML objects (images, flash object etc.)
  • Server delivery speed
  • Client retrieval speed

We’re unable to control the client retrieval speed. The client retrieval speed is a fixed variable. We can’t miraculously increase the speed of their internet connection. We can increase the server delivery speed though. CDNs (Content Delivery Networks) can help here. However, this is not something that I’m going to discuss in here in detail.

If you are interested in utilizing a CDN, take a look at Amazon’s CloudFront and Rackspace’s Cloud Files. Both of these seem to perform well and can help increase the delivery speed of your static assets.

Each external asset adds an additional HTTP request. This is not good so we’re going to reduce these. At the risk of stating the obvious, large assets are going to take the end-user a long time to download. Clearly, reducing the size and number of external assets is going to be our main objective.

ShopDev’s Solution

ShopDev’s solution is to merge all the JavaScript files used by the skin into a single “large” file. By merging each individual JavaScript file, we reduce the number of HTTP Requests for JavaScript files to just 1. This may seem like a simple solution for reducing the number of HTTP Requests. However, we’re probably making it quite a bit more difficult for the client (that’s you) to edit the JavaScript. Why not dynamically merge the files on demand? This way you’re able to easily edit each file individually whilst the end users (your visitors) receive a single “merged” file.

Fast Page Loading

Why not go a step further? Source files contain white space and comments. Whilst these help you read and edit the files, this is not something that the end-users are going to be concerned with. Our compression script strips white space and comments. So now we have a single JavaScript file without all the unnecessary white space and comments (that add to the file size).

Can we improve this yet again? Certainly! We’ve built the compression script to use the jsmin JavaScript Minifier. That’s going to cut a chunk off our file size. We now have a single, pretty well optimized, JavaScript file. At this point, I estimate that we’ve cut the file size by around 20% – 50%.

There’s one last thing that we can do to shave off yet more bytes. We can gzip the file. Most modern browsers support gzipped data. In most cases, gzipping external assets (such as JavaScript files) can cut the file size by around 50% – 80%.

We’re finally left with a very reasonable file size. As you can imagine, merging the files, removing white space & comments, optimizing with jsmin and gzipping dynamically (for each page request) is going to eat up CPU cycles. Our compression script caches the final result in order to significantly reduce the load on your server. If you make a change to a file, the compression script recognizes this and regenerates the optimized file before caching it.

The Result

Let’s compare the skin before and after optimization:
Optimized Files Total Size
No
  • jslibrary.js
  • jquery-1.3.2.min.js
  • noConflict.js
  • cookie.js
  • form.js
  • jquery.cycle.lite.js
  • shopdev_effects.js
100 KB
Yes
  • Single compressed file
28.32 KB

Not bad… That’s just 18.7% of the source (uncompressed) size. Let’s compare this with CubeCart’s standard (stock) skins:

Skin Files Total Size
KitaBlue
Caretta
Classic
  • jslibrary.js
  • scriptaculous.js
  • prototype.js
  • lightbox.js
156.26 KB

We can see that even the uncompressed (source) version of the Sandbox skin is lighter than CubeCart’s stock skins. The optimized version is just 18% of the size of CubeCart’s stock skins. What’s more, we’re using just a single HTTP request for the JavaScript (rather than 4 – as per the stock skins).

comparison

Finally, a quick comparison of the Cascading Style Sheets:

Skin Optimized Files Total Size
KitaBlue No
  • layout.css
  • style.css
10.01 KB
Sandbox No
  • grid.css
  • jquery.fancybox.css
  • layout.css
  • slideShow.css
38.55 KB
Sandbox Yes
  • Single compressed file
7.13 KB

You’ll notice that this time the Sandbox source CSS files total to a much larger size than the KitaBlue stock skin. This is mostly due to the well commented and formatted nature of the Sandbox skin’s style sheet. Furthermore, since the Sandbox skin is somewhat more complex than the KitaBlue skin, it is reasonable to expect extra styling. Nevertheless, the optimized file is just 18% of the total source size and still smaller than the KitaBlue’s style sheets.

CSS Comparison


Comments

  1. Nice! The Sandbox skin certainly feels fast when compared to the standard skins included with CubeCart. I did wonder why the compression script merged the files.

    By Mark Keswick on Reply
    • By the looks of it, not much. Minify seems to use the same techniques. In fact, it also uses jsMin for the JavaScript files.

      By Homar on Reply

Add your comment

(will not be published)