What You Need to Know About Improving Website Performance

The most important feature of your client’s website isn’t what’s on it: It’s how fast it loads.

We like to think of features as the ultimate factor in determining a website’s value. Fair enough, given all the time we put into building them! But, features don’t matter if they go unused. And, if a site takes more than a few seconds to load, they may go unseen: Up to 40% of visitors leave if it takes more than 3 seconds.

Over 30% of online shoppers expect sites to be ready in 1 second, and 46% of mobile users are unlikely to return to slow websites. Mobile users also cite slow load times as their number one annoyance. And, overwhelmingly, users care more about a smooth experience than what’s on the site itself.

The message is clear: If your business is on the web, performance is your business. This article will cover the website performance essentials you need to minimize bounce and maximize conversion, including:

• The need-to-know of website performance terminology;
• How to read waterfall charts at a glance; and
• How to make the most of the statistics they contain.

With this background, you’ll be well-prepared to understand and implement the five most important steps to speeding up your client’s site that we’ll cover in the next post!

What is Website Performance?

Ask a developer, a designer, and a user to define website performance, and you’ll get something different out of each of them.

Ultimately, the only opinion that matters is the user’s: If your metrics scream speed, but your users scream slow, you’ve lost the game.

That’s why the only meaningful definition of performance for people who build or maintain client-facing sites is user-centric. Good website performance means a swift and seamless experience for the end user.

The Most Important Tool

The most important tool in improving website performance is the waterfall chart. It shows exactly how long users have to wait for each component of your client’s site to load, and will become your go-to tool for benchmarking before and after making improvements.

WebPageTest is a free, configurable tool that can generate waterfall charts for any site you’re working on.

How the Browser Browses

To understand waterfall charts, we need to know a bit about how browsers find sites on the web.

At its heart, every website is just a collection of files hosted on a computer somewhere. Finding it is a three-step process, consisting of:

• DNS Lookup;
• Handshaking, to establish a TCP connection; and
• Content Download.

When you visit a website, the browser uses its Uniform Resource Locator (URL) to find the computer hosting the site. This process is called a Domain Name System (DNS) lookup.

Once the browser finds the host computer, it requests permission to connect, and asks for whatever resources it needs to display the site — primarily JavaScript, HTML, CSS, and image assets. If all goes well, the server accepts the connection, and sends the resources back.

This process, called handshaking, opens up a TCP connection, which is a communication channel that the browser uses to download the site’s resources from the server.

Reading Waterfalls

Waterfall charts tell us how long a site’s users have to wait for each of these steps to complete, and encode two types of information:

1. High-level metrics. Measurements of events that directly affect a user’s ability to use a website, and their perception of how fast it loads.
2. Low-level metrics. Millisecond-precision measurements of how long it takes the browser to load each individual resource.

High-Level Metrics

The most important high-level metrics are:

1. Start Render. How long a user has to wait before the browser starts displaying content.
2. DOM Interactive. Time until the website responds to button clicks, scrolling, and other interactions.
3. Document Complete. Time until the browser has loaded all page resources, including those that the user can’t see or interact with.

Take another look at that waterfall chart from earlier. The bright green line near 1 second is time to Start Render. The yellow line, at 3 seconds, is time to DOM Interactive. Finally, the dark blue line, just before 4 seconds, is time to Document Complete.

If you take a look at the video for this test, you’ll get a glimpse of what the page looks like at start render:

It may be boring to look at, but even this is enough to satisfy user impatience!

Each of these three metrics has a different relationship to user experience.

1. Start render is tied to how long users feel it takes a site to load. A quick start-render satisfies users’ expectations that a site load in 2 seconds or less.
2. DOM interactive is arguably the most important metric. If a user can interact with what they’re looking for before the page loads completely, it will feel complete to them.
3. Document Complete is the point at which the browser has rendered all static assets, including scripts a user might not even know about. This is when it’s safe to assume the user sees the site as intended.

Ideally, you’ll want these events to occur as early as possible.

Just what that means differs from site to site, as every site is different. The best plan of attack is to generate a waterfall chart for your client’s site as a benchmark, and make improvements from there.

Don’t forget to check the render videos and screenshots after making changes. After all, what your client’s users see, and how quickly they see it, is ultimately what we’re trying to optimize!

Low-Level Metrics

On the left of the chart is an ordered list of files that the browser had to download to display the page. Each of these represents an HTTP request — something the browser had to ask for, and the server had to send back.

Just to the right of each file is a multi-colored bar. The longer the bar, the longer it takes the browser to download the associated file. Where each bar begins relative to the others indicates whether it is fetched before or after other resources on the list. The fact that some come after others gives the chart its characteristic waterfall shape.

Each color represents a different step of the browser-server communication pipeline:

1. Dark Green. Indicates a DNS lookup. A browser has to do a DNS lookup for each different domain it connects to.
2. Orange. Represents time spent handshaking. Not every resource should have an orange bar.
3. Bright Green. Represents Time To First Byte (TTFB), or the time before the server starts to respond to the browser’s request for a resource.
4. Bright Blue. How long it takes the browser to download the file once the server sends it back.

You optimize each of these metrics differently:

1. DNS Lookup. DNS lookup speeds won’t usually be a bottleneck, and there’s not much you can do to optimize them.
2. TCP Connection. If most of the resources in the chart have orange bars, get in touch with Liquid Web, or whoever your host is, about enabling keepalives to reuse connections instead of reopening them.
3. TTFB. If you see a lot of green bars, you should reduce the number of resources users need to download. If the green bars look uncomfortably big, consider a CDN.
4. Content Downloads. Resource downloads are usually the biggest factor in slow load times. Reducing the number of resources your client’s site needs and using smaller files are the best ways to reduce download times.

In general, you want as few bars as possible, and you want them to be as small as possible. Again, the best way to get started is to benchmark your client’s site, and make improvements from there.

The next article will take a look at concrete ways to reduce site load times and improve user experience. In the meantime, get your benchmarks ready — we’ll shave seconds off them next time!