1. In my last performance post, I introduced the impact of performance and the types of tools and measurements required to get a handle on the situation at hand. In this post, we’ll take this further into user-experience (UX) and I’ll make the search engine optimization (SEO) case for performance.

Performance isn’t purely a numbers game and one of the most immediate changes many sites can make is to restructure their pages to improve the user experience. First, we need to understand that there are two types of performance:

  1. First, we have the raw page load times and time until interactivity with the page. These are fairly easy to quantify with the tools in the prior post and I’ll go into the components of this at a later time. For now, we’re focused on Product Managers, business stakeholders, designers, UX, and as always, engineers.
  2. Secondly, we have Perceived Performance. This, much like it sounds, is the user’s perception of performance.

Perceived Performance

To best discuss perceived performance, two examples immediately spring to mind. First is the page that sits blank for what can be multiple seconds before anything substantial is visible on the page. The second, most common on mobile, is the jerky loading and inability to use the page until it’s entirely loaded. Since ads are often deferred they load after the main content, often forcing the base HTML to be entirely redrawn if you’ve clicked on ads on accident because of this, raise your hand… This is critically important for one important reason. When a user seems the page loading or an indication of progress they’re going to wait longer. For those of us old enough to remember, this is why images loaded from top to bottom. On old dial-up connections, it could be minutes for photos to load. Today there are other ways to address this perception that are way more clever and keep page weight down.

First to the rendering issues…As websites have moved to a heavier client-side focus, many pages have actually seen perceived performance drops, this is occurring because these frameworks often require the entire “payload” or file to be download and then rendered by the browser before anything is visible. Due to complexities, we may get into later, browsers are faster at merely interpreting the small HTML files and then filling in the updated components of the page such as images, ads, and other pieces. If you’re delivering an optimized experience you can attend to these issues, however many sites miss this opportunity.

Second is the jerking loading, particularly on mobile. There are a number of reasons this can happen but the most obvious is often that ad block sizes aren’t known until rendered. Additionally, if the important content is client side, the user may be missing key indicators of load time. This is most common on news sites because nothing is being loaded to size those modules, the HTML is redrawn as new elements come in. This takes resources and for our purposes, give a crappy experience.

User Experience Tricks

So now we understand the problems users FEEL, let’s look at clever ways of dealing with it that you can employ, some more quickly than others.

The first is to ensure your JavaScript is loading asynchronously on traditional HTML based sites. What this does is push non-critical loading to the end of the load time. In the metrics, we’ll see this make a considerable impact. While we haven’t covered the anatomy of a page load, Dom Interactivity, or when the user can begin to use the website isn’t blocked by tags and other components loading. This is pretty basic stuff but always worth checking.

Next is to frame out the HTML as close to the final state as possible. Especially if you have large images, you can load a low-quality version of very low file size with the dimensions or proportions declared in the CSS or HTML. What this does is assist in two ways. First, the HTML will not have to redraw when the image is replaced and you’ll avoid the jerky loading as everything moves to fit the content. Second, the user perceives that the image is still loading without blocking the main content.

For a creative example in how this is done, refer to this post by Medium. In summary, they load a properly sized div and a small thumbnail version of the image stretched to fill the space and then load the full-sized image and use the blur() effect to then load the full image. There are other alternatives to do this mentioned in the post. Additionally, you have SVGs but I’ll leave that to another post.

Loading experiences are another way to give the user the perception of performance. This can be handy if you’re using a JavaScript-based view to your website without any server rendering. While your engineers get to work through your backlog, something as simple as an initial loading screen can buy you the time to return and render the full JavaScript. Ideally few will see this but those that do will have a much better experience without adding much overhead.

The summary here is you want to feed HTML to the browser without blocking the loading behind heavy elements. When you know you will pay the performance tax to maintain high image and other standards, you want to give an indication that content is coming. Within the HTML you want to both frame your DIV blocks properly (think of an HTML wireframe) and then load the heavy images and other elements.

Resaving and properly sizing your images 

This may be obvious to some but putting best practices for your designers and front end developers when saving out images is crucial to success. Two major pieces are first, to save out images at the proper quality for web viewports. Essentially, depending on the image sizes needed, you’d load a separate image for that user. This is most common on responsive sites although works across the board with retina displays, and otherwise a wide variance.

Unless you’re handy with CSS you’ll want to consult whoever manages your front end to make sure they’re following these practices. This also applies to the div techniques above. That said, I’m shocked by how often major sites don’t apply these practices.

The book Designing for Performance is a fantastic read for designers and front end developers who will be touching the front end of websites while still being largely approachable to product managers and others who may be less technical.

Further Reading:


Leave a Reply

Your email address will not be published. Required fields are marked *