How we kept Phase2 Design Studio under 1 MB

A few months back we launched www.phase2designstudio.com as part of our ongoing efforts to market our design services. Samantha developed a beautiful and creative design of a single, very tall webpage where the scrolling created a unique interactive experience as your eye follows a pipe that carries a droplet of water from the top of the page to the bottom.

Phase2 Design Studio Website

A few months back we launched www.phase2designstudio.com as part of our ongoing efforts to market our design services. Samantha developed a beautiful and creative design of a single, very tall webpage where the scrolling created a unique interactive experience as your eye follows a pipe that carries a droplet of water from the top of the page to the bottom. Phase2 Design Studio Website This created a problem in that we had to send the equivalent of 5 webpages in a single payload. It was going to create serious page load time issues, especially for mobile users. Samantha had done an initial pass at the cut-up, which was very image-heavy. And after we got the basics of the site with the cut-up, views, and rotator images set up, the page was clocking in at over 5 MB. We timed a page load on an iPhone over 3G, and it took almost 2 minutes to load the page. Of course it loaded moderately faster on our high-speed internet connection at the office, but studies have shown that people’s patience for page load time typically runs out after about 10 seconds, after which they move their attention to something else. In the web world, a beautiful design, on its own, is simply not satisfactory if it doesn’t perform well. 5 MB was not going to fly. We had to devise an attack plan. An early strategy we discussed was to build some sort of lazy-loading mechanism. In other words, load the top part of the page first so the page appeared to be finished loading, then use javascript to sequentially load the subsequent chunks of the page. This strategy created a new set of technical challenges and would have been time-consuming to implement. If someone clicked a navigation link for a part of the page that hadn't loaded yet, how should it react? What exactly would be different from the way a page loads by default, which is from top to bottom? Besides the fact that this wouldn't have solved the root problem of there simply being too many bytes traveling across the wire. We decided the only option was to prune the page load. But how could we squeeze that down without sacrificing the quality of such a big and elegant design?

#1 Build a smarter rotator

The first thing we did was look at the architecture of our image rotator. At the time we had 3 websites featured on the rotator. When you clicked one of the slides, a lightbox would open up with 4 images of that website. 3 x 4 = 12, so on page load we were loading up 12 images, most of which the user might never even click to see. We changed the way the rotator worked so that only the initial 3 images would get loaded right away, and the rest would be accessed via an AJAX request when the user opened up the lightbox. Right off the bat this reduced our page load by almost 2 MB.

#2 Get really aggressive about image compression

The second thing we put under the microscope was our image compression. Not only did I fiddle with Photoshop's "Save for Web" settings to find the best balance between filesize and image quality, but I looked into how the images were sliced to see if there was any possible way to reduce their dimensions. For example, the initial dimensions of the body background image was 735 x 831 pixels. I used Photoshop's offset filter to help me draw a more tile-able 100 x 100 pixel image that I could use instead. The result was barely noticeable to the eye but saved me almost 70 KB. Tweaking the ImageCache settings in Drupal 6 went a long way as well. The default presets were not well suited to the images we were processing, and we were able to increase the compression drastically without any noticeable loss in quality.

#3 Draw as much of the design as possible using HTML and CSS

The design featured a long pipe that traversed across the page all the way from the top to the bottom. Fortunately for me the pipe was nothing more than a set of blocks, each one adjacent to the next. In the original cut-up, the pipe was being drawn by a series of 5 PNG-8 images, divided up into the different sections of the page. Since it was just a bunch of blocks, why not draw those using DIV elements and CSS? I started tinkering around and discovered I was able to find a combination of color and opacity to apply to these DIV elements that looked almost exactly like the original blocks in the image. Inspecting the Phase2 Design Studio Website What ensued was a day of creating over 100 DIVs and absolutely positioning them throughout the page. Not only was I able to re-draw the pipe in this manner, I was also able to re-draw the billboard, which was a set of DIVs and 'X's, as well as the water under the well. This allowed me to remove 90% of the image data out of the PNG-8s. Certain parts of the pipes had to be drawn with images since they were oddly shaped. The clouds could have been drawn in this manner as well, taking advantage of the CSS3 border-radius property, which would have required a fallback image solution for IE, but this was prohibitively time-consuming.

Conclusion

After making all these improvements, we had wrangled the page load down from over 5 MB to almost 700K. Some finishing touches bumped it back up closer to 1 MB including Google Analytics and some additional content. Finding this balance between unique design and fast performance was crucial to making an experience worthy of the web. Elegant visual design and elegant code design must go hand-in-hand, and this was something that we could feel proud showing to our potential clients.

 

David Coffey