The Need For Speed: Measuring web performance
If you want to know the speed of your page, your first step should be to define exactly what you’re trying to measure. Be wary, as even the tool report on the metric you care about isn’t necessarily representative of the page’s true speed. The true speed is actually that which the real users experience, once on the page. Real users live all over the world, use different devices, browsers, and connect to the Internet differently. The reality is, the true speed is extremely hard to reflect in a single test.
The two most popular approaches are known as Synthetic Performance Monitoring and Real User Monitoring (RUM). WebPageTest falls under the synthetic category.
Running a Simple Test
Let’s try to run our first test…
First, go to www.webpagetest.org. Let’s get started by providing the web address of a page we want to test. For our first test, let’s simply start with a URL and see what happens when we leave everything else to its default value. To run the test, click on the big ‘Start Test’ button next to the URL input field.
That’s it! When the test reaches completion, the progress page becomes a report summary. This is where we can start to analyse the performance of our page.
The first place you should look is at the table of data. This is the metrics summary of the test, containing a breakdown of important milestones of the page-load process.
From left to right:
Load Time
The time from the initial request until the browser load event. Also known as the document complete time. This is the default performance metric on WebPageTest.
First Byte
Time until the server responds with the first byte of the response.
Start Render
Time until the browser paints content to the screen.
User Time
The User Timings API allows you to mark when you reach certain points on the page.
https://www.html5rocks.com/en/tutorials/webperformance/usertiming/
Speed Index
Measures how quickly the page contents are visually populated, ( lower numbers are better).
First Interactive (beta)
This is a newer metric and reports when the page is first expected to be usable and will respond to input quickly.
Document Complete Section
Time
Same as Load Time.
Requests
Number of HTTP requests before the load event, not including the initial request.
Bytes In
Total size of the Document Complete Requests’ response bodies in bytes.
Fully Loaded Section
Time
The time from the initial request until WebPageTest determines that the page has finished loading content. The page might have waited for the load event to defer loading secondary content. The time it takes to load the secondary content is accounted for in the Fully Loaded Time.
Requests
Total number of HTTP requests recorded in this test run, not including the initial request.
Bytes In
Total number of bytes received in this test run.
Cost
This is the cost of the site based on data from the International Telecommunication Union (ITU).
Before each test, WebPageTest clears the browser cache to ensure that it downloads all resources. This is considered to be the first view, representing a new user visiting the page without any local copies of the resources. One of the default WebPageTest configurations is to load the page a second time without clearing the browser cache; this is known as the repeat view. The difference between the number of requests of first and repeat views is an indicator of the number of cacheable resources on the page. The metrics for each view are enumerated in the summary table.
Stay tuned for the next installment where we’ll focus on how to read the waterfall diagram to find out exactly what could be slowing your page down.
Tip of the day
Application-Specific Metrics
You can log custom application-specific metrics to WebPageTest with the User Timing API. Using the YouTube example, when the video starts to play, that moment in time can be marked with a line of JavaScript:
performance.mark(‘playback-start’);WebPageTest will capture these marks and make them available in test results.
Images: Shutterstock