Siteglass: A Developer’s Quest for Better Performance

Hi, my name is Elisha, and I’m a developer. I know that most of you aren’t, but I want to talk about a fairly technical problem related to website optimization, and a new tool I developed to solve it — called Siteglass. Why would I want to do that? Because performance is an essential ingredient in good UX. But before I delve into that relationship, it might help to first know a little about what I do here at Cooper.

I’m a User Interface Developer. That means I take designs and turn them into interactive interfaces. As with all translations, there is a lot of room for interpretation. So, aside from the technical side of things, I consider it my main task to try to convey the intention of the design through the chosen platform (iOS, web, etc.). Sometimes there are creative choices, like defining the exact characteristics of an animation, but ultimately the goal is not to make the design my own but rather to not get in its way. This means doing whatever is possible to avoid degrading the design vision due to technical artifacts of the translation process.

Now let’s descend from the lofty height of that last paragraph and talk about websites. A lot of what I build these days are websites and they pose unique challenges, as each platform does. Browser inconsistencies, lack of typographical control and wide variations in screen size are some of the hurdles to creating a solid experience for users. Today I want to talk about an issue that is easily overlooked during design and development but can have a huge impact on user experience: page load performance.

If your page is slow, so is your design

The time between the user hitting enter in the location bar and the page loading is time the user is spending not just sitting there, but waiting in anticipation. This is a state of mind that makes seconds seem long, and it is well documented how quickly users get bored. This affects bounce rates, hence it affects conversions and the bottom line. It also affects the user’s perception of the product. It doesn’t matter how sleek and cool that 3D rotating button effect may feel, if it takes 4 seconds to load the page, the user will label the site slow before they even see it.

Again. Performance is key to successful UX.

A quick primer on page loading

So what can make a page slow, and why? Stick with me, this will only take a minute.

When your browser loads a web page it makes a lot of requests: one for the HTML page, one for each of the included CSS and JavaScript files (including those Like and Tweet buttons), one for each image on the page, one for each font file, you get the idea. Each request takes time and until all the HTML and CSS have loaded, the page can’t render.

The amount of time it takes to complete a single request is based on two factors. One is the latency of the network connection. This just means how long it takes for a byte to get from here to there. If you think about throwing a ball, this is the time the ball spends in the air. The other factor is bandwidth. This is how many balls you can throw at once. Each individual request incurs the overhead of the latency plus the amount of time it takes to download the file.

The two biggest gains in page load performance come from decreasing the number of requests necessary to load the page and making the files as small as possible.

Isn’t this solved?

This is not a new problem. Developers have been working on it for a long time and there are various solutions. Some tools focus on one aspect like making the CSS or Javascript as small as possible, and there are a few comprehensive solutions but they tend to be tied to a single platform like WordPress or Django. PageSpeed is a neat idea that shows promise, but it has a number of shortcomings that make it impractical or impossible to use for some projects.

So, somewhat surprisingly, the answer is no, it’s not solved. The current choices are to stitch together various existing tools and write some not insignificant code to bring it all together in a way that works for a given system or to use a specific platform that has comprehensive support.

At Cooper, we work with a lot of different clients that have varying technical requirements. Sometimes there is a clear, green field and sometimes there’s an existing garden that needs tending. Each project is different and requires a different approach to optimization since we rarely get to choose a platform that already has an ideal optimization solution.

Designing a developer tool

Siteglass grew out of my frustration at the lack of a flexible, comprehensive tool. All the optimization knowledge was there but nothing existed to tie it all together. At least, nothing that I could actually use. As I began development on my next web project and again was faced with setting up automated optimization, I resolved to build out something I could use more than once.

The first attempt, written as a side project while under deadline, was a bit awkward. It achieved the main goal of providing a single command for optimization but it required the user to install a bunch of different software packages and keep some of the code in their own codebase. This went against the clean, simple experience I wanted to provide. So, I rewrote the thing.

I had more time to devote to the second version. Written in python, it was super easy to install and worked just about everywhere. Also, it only required the user to provide a simple config file that could live in the project directory or anywhere else, and I added a couple of new cache-busting strategies that made it easier to integrate with different kinds of projects. This version worked great, until my next project.

Having now used Siteglass on three different platforms, I had a much better idea of what needed to be done to make the configuration both simple and flexible enough to handle a lot of different setups. I made a third major revision and I am pretty happy with how it’s turned out.

Optimized assets being loaded by the browser.

The process for me was very self-referential and iterative. I mainly created Siteglass to make my life easier, believing that it would help out some other folks as well. Not the standard practice for design, I know, and maybe that’s why so few developers tools achieve wide adoption.

However, looking at each iteration, what I did was step back, look at the big picture problem, evaluate my design against my goals and abandon anything I had produced that worked against me or failed to live up to the vision. Whether or not that produced a great tool remains to be seen, but I do know that it has saved me (and will continue to save me) a lot of time and helped me deliver a higher quality product to my clients.

If you would like to use Siteglass in your own projects, visit the project pageon github for installation instructions.I’m going to keep working on making Siteglass better. If you have questions or comments, feel free to get in touch.

1 Comment

Doug LeMoine
A few hundred milliseconds here, a few hundred milliseconds there, and pretty soon you're talking about real time! ... But seriously, this is super-interesting stuff to me because it illustrates a thought / work process that is typically invisible to designers -- performance optimizing, planning, etc. Philosophically, this is all stuff that should be super-familiar to design folk, but it takes a different form than the kind of planning we do.

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment