The process of site performance

One of the most important aspects of any website is its performance. Studies show that nearly half of all web users will abandon a site after 3 seconds if the site hasn’t loaded, and even small improvements can dramatically improve your conversion rate.

There are a lot of factors that impact performance, like gzipping, caching, using CDNs for images, but I’m going to be focusing on what you can do from the display/front end perspective. A site’s performance must be considered from the very beginning—from the wireframe stage. Designer and developer must work closely together to understand how design and architecture affect performance.

Wireframing

It might be surprising that you can avoid a lot of performance problems down the road at the wireframing stage—in other words, this isn’t just the developer’s challenge.

Every time you add something, anything, to a webpage, you’re slowing it down. Some of those things will slow it down much more than others. Text? Don’t worry about it. Ads, Flickr feeds and Twitter feeds–those external resource calls are often the biggest offenders. What about “possibly related posts” or tag clouds, comments, categories lists, recent posts, etc…? Your server has to go query the database for each of these items, and every time it has to do this, you slow your site. Caching will certainly solve some of these problems, something that FUEL CMS does by default. WordPress has the ability to do this, namely using the WP Cache plugin.

It’s not that any one of these things is terrible all by itself (usually), but when you cram a page full of ads and social media feeds, loading will grind to a halt. Have you ever started reading an article or tried to click something right after the content loaded, and suddenly the whole page starts jumping around? Those are external resources being loaded asynchronously, ie, after the initial content is “painted” to the screen, feeds and ads are then loaded in. Unfortunately there is often little thought to how this will effect already loaded content.

So what does all this have to do with wireframing? During this phase, you can cut out the cruft and figure out what’s really important. The developer can figure out how to best implement what you have decided to include, but consider cutting out that barely-used Flickr feed.

Visual Design

From a visual design standpoint, there are many things that can impact page weight and performance, including web fonts, images and animations. No one is going to dictate “no images” or “no web fonts”, but rather we need to perform a delicate balancing act. If we have one huge hero image at the top of the page, can we ditch all those thumbnails? Let’s use web fonts, but before using them, let’s make sure they’re under 100k.

Many people are setting a “performance budget”—and one part of this budget can be page weight, meaning we want to keep the total size of the page under a certain number. This would include everything, from the HTML to the CSS to that big juicy product shot. So if you absolutely need to have all the font weights, thin and regular and semi bold and extra bold, then you probably have to rid your site of all photography. It’s all give and take.

Front End Development

When Daylight begins a project, we start with a non-opinionated boilerplate that allows us to create lightweight code specific to the project. Many people are using front end frameworks like Bootstrap to speed up development time, but this can add a lot of weight to the site if you don’t cut out unneeded styles and JavaScript.

We use SASS which allows us to use @extends to make more compact code, as well as approaching CSS mobile first, which boosts performance for mobile devices. There are a lot of small decisions that can add up to savings down the road, but they must be considered from the beginning.

JavaScript is probably the number one performance drag—not in terms of weight, but in terms of general performance. Does the site scroll smoothly? Does the site cause a computer’s fan to suddenly turn on? And worst case: does the browser momentarily freeze or even crash?

Again we have a balancing act. If you must have an animated carousel, do not autoplay it. And if you must autoplay it, don’t have anything else running on the site at the same time. One of the worst offenders in recent years has been the popularity of parallax and scrolling effects. Any time you have events firing constantly, on page scroll or on browser resize, you’re potentially looking at trouble. Keep JavaScript animations to a minimum (use CSS animations where possible) and use a debounce function to keep the event from firing too often. If you have a lot of JavaScript event listeners added to a page, please remember to remove listeners when you no longer need them. JQuery makes this very easy—where you use $.on, you can just as easily use $.off.

Finally, every time you add a “snippet” of code to your site from any kind of third party, including Google Analytics, Marketo, and live chat, you are drastically impacting performance. Some of these are crucial to your business, but others less so. Keep this in mind every time someone decides they need to add a new marketing or sales app to the pile.

As is pretty evident, a site’s performance depends on too many factors to list here. But the most important thing to keep in mind is that it’s not just something the developer adds at the end (sadly, there is no “make fast” function). It must be a consideration at all times, from the beginning to the end of the process—and it must be something that is evaluated and monitored after site launch. If the abandonment rate of certain pages are higher than others, remember to check performance—if that cool animation is taking 10 seconds to load, your users may have given up and moved on. Consider running your own A/B tests to determine if faster speeds increase conversion, or if that five slide carousel is really worth the wait.