Imagine for a moment that you have been hired as the new assembly line foreman at Gizmos & Doodads Incorporated, a company that manufactures highly desirable widgets. Your new boss tells you about how slow production has been; orders have been taking twice as long to fulfill and the line has been unable to keep up with what is otherwise a successful increase in business. Your job is to make sure that the line workers can meet demand.

You outline a plan to not only meet demand but also have the factory running at peak efficiency. The first step of your plan is to determine the current rate of production and set goals to measure improvement. The second step is to measure and fine-tune the efficiency of each phase of the operation. Step three, of course, is profit.

In order to find out the production speeds, you implement a widget-counter system that measures how quickly each unit is made. After a week of aggregating information, you determine that the end-to-end time for manufacturing is half as fast as you need it to be to meet the quota. You’ve confirmed that there is indeed a problem in the performance process, but you still don’t know why.

To understand what’s wrong, you move to the second step and analyze what each part of the assembly line is doing. You inspect every station for inefficiencies and time how long it takes until the task is completed. Contrary to the continuous collection of data in the first step, this one is more like a snapshot of performance. With this new perspective, you’re more easily able to see how the parts work together and consume time.

Armed with concrete performance data and a detailed breakdown of each stage of widget production, you can see a path to reaching the goal of doubling assembly speed. As it turns out, the top and bottom pieces of the widget can be assembled independently and combined at the end, halving the time it takes to build!

This plan is not so different from the way you would approach web performance optimization. After determining the actual speed of your web page, you get an idea of how much faster it needs to be. Then you turn to a breakdown of what the page is actually doing while it loads to figure out ways to achieve the necessary speedup required to meet your goal. These two steps are distinct in methodology because they serve different purposes: finding out how fast a page is, and finding out how to make it faster.

This section will approach the utility of WebPageTest from a beginner’s point of view, starting with addressing a couple of ways in which it can be misused. Subsequent chapters dive into the fundamental ways WebPageTest can be used to determine how to make a page faster.