The SEO Expert's Guide to Web Performance Using WebPageTest

Posted by mark.isham

Any SEO professional knows that both site performance and user experience play an important role in search engine rankings and conversion rates. And just like there are great tools to help you find your search rank, research keywords, and track links, there are also excellent tools to help you improve your site performance. In this post, we will dive into one of the best free tools you can use to measure and improve your site performance: WebPageTest.

Do you know these questions?

There are several key questions an SEO professional should answer when it comes to improving the performance and user experience (UX) of your website:

• What is my Time To First Byte? Time to first byte (or TTFB) is a measure of how fast the network and webserver returned that first byte of data in the HTML file you requested. The lower this number the better, since it means the site responded quickly. TTFB is an important metric since it is the performance measure most strongly correlated with a page's search ranking. A high TTFB can also indicate an underpowered web server.
• How quickly does my site render? Have you ever visited a page and then stared at a white screen waiting? Even if your site fully loads in only a few seconds, if the user isn't seeing any progress they have a bad experience. Getting your site to render quickly can make your site "feel" faster than the competition. And speaking of competition...
• How does my site compare to my competitors? Having a fast site is always a plus, but knowing how fast your site loads relative to your competitors can give you an idea about where you spend your resources and attention.
• How does your site respond for mobile users? Sites are increasingly receiving the majority of their traffic from mobile users. When measuring your site performance, its critical you evaluate how well your site performs on mobile devices as well.
• How do I make my site faster and provide a better UX? Collecting data and metrics is great, but creating a plan of action is even better. In this and a follow up post, we will show you clear steps you can take to improve your site's performance and UX.

Understanding the answers to these questions will help you speed up your site to improve your conversion rates and UX. Luckily the free tool WebPageTest can help you get there!

What does WebPageTest Do?

Created originally at AOL by Patrick Meenan in 2008 and now enjoying backing by prominent technology companies like Google, WebPageTest (WPT) is the swiss army knife for measuring your site's performance. While WPT's capabilities are vast (and sometimes overwhelming), with some guidance you will find that it can be indispensable to improving your site performance. And best of all, WPT is FREE and open sourced under the free BSD license!

At its most basic level, WPT measures how a particular web page loads. As the page loads, a number of useful metrics are captured, cataloged and then displayed in various charts and tables useful for spotting performance delays. These metrics and visuals can help us answer the important questions we listed above. You can also control many aspects of WPT's analysis such as the platform to use (desktop vs mobile), browser of interest (Chrome, Firefox, IE, etc), and even the geographic location.

Actually this is an incredible simplification of all the available options and abilities: WPT can do much much more...so much so a book is already in the works. Still you can get great value with just some high level basics, so let's dive in!

Testing your site with WebPageTest

Let's walk through an example. Even if you are familiar with WebPageTest, you might want to skim. We are going to select some specific options to make sure that WebPageTest collects and measures all the data we need to answer our important performance and UX questions above.

To start go ahead and visit www.WebPageTest.org. It's okay to load this URL on your browser of choice (the browser you visit the URL with is NOT the browser used to run the test, that all happens on the remote server in a controlled environment). If possible, try to use Chrome since some of the more advanced visual tools for displaying the result data work best on Chrome, but it's not a big deal if you'd rather not.

You should now see a page like this:

Right away you see 2 interesting options:

• Test Location has a list of over 40 different regions around the world. Through its partnership program, WPT is physically running (for free) on servers located in all of those locations. When you enter a page URL for testing, the server at the location will load that URL locally with the browser you select. Truly wonderful, but of course, you get what you pay for: the speed and reliability of your tests may vary greatly from location to location. In addition, not all regions support the same testing options.
• Browser contains a number of different desktop and mobile browser configurations available for testing at that location. Note that unless otherwise specified, the mobile specific browser tests are actually running on actual mobile devices and not emulators. Patrick Meenan has a neat picture of one of these configurations on his blog (below).

Let's go ahead and stick with the defaults (Dulles, VA and Chrome).

Go ahead and expand the Advanced Settings section and you'll see something like this:

Some comments here:

• Connection is the simulated connection speed. Doesn't matter too much unless you're doing advanced testing. Just keep the default of Cable 5/1 for now.
• Number of tests: as the name implies this controls the number of repeat tests to run. This is very important as the Internet can suffer frequent spikes and jitter in response times based on network congestion (see our earlier post on HTTP/2). To get a reliable result, its best to run multiple samples and have WPT automatically choose the median result. We recommend at least three tests, more if you have the time to wait.
• Repeat View specifies if each test should load the page just once (with the browser cache cleared), or once with the cache cleared and again with the cache primed. Why does this matter? Whenever your browser visits a URL for the first time, there is almost always a large number of images, JavaScript files and other resources that must first be downloaded by the browser to be used by that page. Once the browser has all these files, it will (depending on the server settings) cache them locally on your device for each subsequent page loaded from that website. This explains why the first page you visit almost always loads slower then subsequent pages on the same website. We recommend setting First View and Repeat View here so you can measure both the first experience for your new users and the ongoing experience for your repeat visitors.
• Capture Video: One of the coolest features of WPT. This allows you to visually see what your users would see on that device in that location. I'll dive into this more below, but for now just make sure it's checked.
• For now leave the rest of the options blank, and you can ignore the other tabs.

Go ahead and enter your site URL and hit Start Test. It'll usually take 30-60 seconds to get a result, depending on the options you selected and how deep the work queue is. If you find it taking an inordinately long time, try repeating the test from a different location.

Let's now look at the results.

WebPageTest Results

Upon completion you'll see a lot of data returned, much more then I can cover in this post. Let's stick to the highlights for now.

First, at the top you'll see some metrics on the overall page load time itself, for example:

As I mentioned above, this is the median result after 3 runs. You'll also see a breakout of the first page load (no caching by the browser) vs. the repeat page load (browser is now caching some resources). You should almost always expect the repeat view to be faster then the first view. If not, you have some caching problems and should try free tools like PageSpeed Insights and Zoompf to diagnose why your caching is not properly configured.

There's a lot to digest in these numbers, so let's stick to the highlights:

1. First Byte: This is the Time-to-first-byte metric we are looking for! As you'll see below, the HTML document is usually a small sliver of the overall time - it's all the images, JavaScript files, etc. that take most of the time to load. You want a number no more than about 200-400 ms. See our earlier article about optimizing Time to First Byte for recommendations on how to improve this value.
2. Start Render: This is the point visually where you start seeing something other then a blank white page staring back at you. This also directly maps to a number that we want for our questions above.
3. Document Complete: This is the point where the webpage has loaded up all the initial components of the HTML DOM and you can start interacting with the page (scrolling and such). You may still see images and other background parts of the page continue to "pop in" on the page after this, though. This number is helpful for developers, but less important from an SEO/UX perspective.
4. Fully Loaded: This is the point at which everything is done loading. All images, all tracking beacons, everything. Many websites intentionally design for a faster document complete time (time you can interact with the page) at the expense of a slower fully loaded time (e.g. load the "extra stuff" in the background while the user is interacting with the page). There are raging debates over whether this is a good practice or not, I'll steer clear of those and simply say "do what's best for your users". Again, this is a number that is helpful for developers, but less important from an SEO/UX perspective.
5. Speed Index: This is a metric specific to WPT averaging when the visual elements of the page load. This attempts to solve a growing discrepancy between the values above and what the user perceives as "fast". The math behind how it is calculated is kind of cool, and you can learn more about it here. The smaller the number, the faster and more completely you page loads.

These metrics help us answer some of our questions above. We will also see how to easily compare your metrics to your competitor.

Waterfall Charts

One place WPT really shines is its waterfall charts. Put simply, a waterfall chart is a graph of what resources were loaded by your browser to render a webpage, with the horizontal axis charting increasing time and the vertical axis representing the in-order sequence of loaded resources from top to bottom. In addition, each line in the chart is color coded to capture the various loading and rendering activities performed by your browser to load that resource.

For example:

Waterfall charts are valuable for identifying bottlenecks causing your page to load slowly. A simple frame of reference is that is that wider the chart, the slower your page loads, and the taller the chart, the more resources that it loads. There is a ton of information packed into a waterfall chart, and interpreting a waterfall is a big topic with a lot of nuances. So much so that we're going to dive into this topic in much more detail in our next post. Stay tuned.

Seeing how your site loads

If waterfall charts are the "killer app" of WPT, its performance videos are the killer upgrade. By selecting that Capture Video checkbox when you started your test earlier, WebPageTest captured a filmstrip showing exactly what your user would see if loading your website using the test parameters you provided. This is extremely valuable if, for example, you don't happen to be working in Singapore on a Nexus 7, but would still like to see what your users there experience.

To access your video, click the Summary tab on your test result, then scroll down and click the Watch Video link on the far right column next to the Test Result you want to view.

You'll then see something similar to this:

Remember those metrics that are important? If you site has a slow TTFB, you see a big delay before anything happens. The video also helps show you your start render time. This really helps provide some context: 750ms might sound fast, but being able to visualize it really drives home what your users are experiencing.

WPT's video of your page load in itself is a great way to share with others exactly what your users are seeing. It is also a phenomenal tool to help build the case internally for performance optimization if you aren't happy with the results. But can we do more?

Comparing against your competitors (and yourself)

Yes you can! WPT's video capabilities go further, and that's where it gets really interesting: you can also generate side by side videos of your site versus your competition!

To do so, repeat the steps above to generate a new test, but now using the URL of your competitor. Run your test and then click Test History. You'll see something like this:

Click compare on the 2 tests of interest and you'll see a cool side by side filmstrip like this:

Scrolling left and right will show a visual comparison of how the 2 pages loaded relative to each other. The gold boxes indicate when visual change occurred on the site getting loaded. Scroll down and you'll see an overlay showing where in the waterfall chart the visual images loaded. Click the Create Video button and you'll see a cool side by side animation like this.

This is a fantastic way of visualizing how your users see you versus your competition. In fact, you can compare up to 9 simultaneous videos, as we whimsically did some time back in this video:

But what about testing for mobile? While you can run 2 separate WPT analyses for your site using a desktop and mobile device, this is rather clunky. You have to switch back and forth comparing results. I am a big fan of using the comparing options, but to test my site using multiple different devices. This allows you to leverage all the great features above, like side-by-side video loading, and quickly see problems. Is your mobile site loading faster than your desktop site? It should, and if not, you should investigate why.

Getting even more from WebPageTest

I could spend hours going over all the advanced features of WebPageTest, and in fact Patrick Meenan has done just that in several of his great presentations and videos, but I wanted to wrap this up with a few of the more particularly noteworthy features for the SEO focused performance optimizer:

• Private Instances: If WPT is loading too slowly for you, or your geographic needs are very specific, consider hosting a private instance on your own servers. WPT is open source and free to use under the free BSD license. There are many great resources to help you here, including Google's documentation and Patrick's presentation.
• API: Most if not all the data exposed in the WPT web interface is also accessible via Restful API. If you'd like to show this data internally in your own format, this is the way to go.
• Single Point of Failure (SPOF) Testing: What happens to your site if a key partner is down? Find out with the SPOF testing option. Simply list the host name(s) you want to simulate downtime with via the SPOF tab when launching a test, and see how poorly your site performs when a key resource fails to load. You may be horribly surprised. Even "fast" sites can load in 20+ seconds if a key advertising partner is offline. In fact, this feature is so useful we will explore using SPOF testing in our next post.
• TCP Dumps: If your network engineers are debugging a truly thorny problem, additional logging is available via TCP Dumps. Especially useful for debugging server-side problems. Skip to timecode 15:50 here to learn more.

Next Time: Diagnosing performance problems with WebPageTest

WebPageTest is an indispensable tool for finding and debugging front-end performance problems, and a faster site leads to better user engagement and improved search rank. By default, WPT exposes a number of key metrics that are critical to SEO professionals and their understanding of their site's performance and UX. I hope this overview provided a basic foundation for you to start diving in and using WebPageTest to optimize your own website speed.

While we have answered nearly all the important questions listed at the start of this post, we left one largely unanswered: What do I do to make my site faster and improve the UX? To answer this question, we need to go beyond just looking at the data WPT presents us, and instead go deeper and review the data to diagnose your performance bottlenecks. This includes not only using some of the more advanced features of WPT like the SPOF testing, but also reviewing the waterfall charts and using tools like our free performance report tool to analyze what is slowing down your website and learn what you can do to improve your performance. We will do all that and more in our next post.

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don't have time to hunt down but want to read!

from Moz Blog http://ift.tt/1CKEwhr
via IFTTT