Time Variable Issue

Hey there,

I noticed on the main test result pages there is a column that has three rows that says “First View (TIME)”, “Repeat View (TIME)”, and “Content Breakdown”.

The TIME variable there sometimes reflects Document Complete and other times Fully Loaded.

Should this TIME variable be based on a consistent event?

Even the table at the top of the results (when the results finish executing) has a “Load Time” column, which sometimes the value is based on Document Complete and other times Fully Loaded.

Travis Walters

The “Load Time” (at least as it stands right now) is one of either the document complete or fully loaded time and it tries to make it’s best guess as to which is appropriate for the page. If > 50% of the requests came after document complete then it uses the fully loaded time.

This was an attempt to include support for the richer ajax pages that may fill in most of their content after on-load.

You can force it to use the Document Complete time by checking the 'stop at document complete" checkbox on the advanced tab.

I’d be willing to change it to always use the Document Complete time if the bulk of the users think that would be more useful (would certainly be consistent) but any ajax apps would have to know to use the fully loaded time instead.

Hey there,

I can see the reasoning for the coding to be like this now.

I see under test options you have the following:

Maybe you could have a way:

  • Stop measurement at Document Complete
  • Stop measurement at Fully Loaded (activity stops)

This way you could always force a fully loaded time. To get the average loading times of your webpages, it may be useful to base the times on a consistent event such as document complete or fully loaded.

If I am not mistaken, Google bases page speed on document complete correct? I think the majority of the website traffic will be people wanting to make their website faster to get that 1% extra edge in the SERPs. Thus, I recommend having the default setting as whatever Google bases their page speed on. Having that second setting to force the fully loaded measurements would still allow for richer ajax applications.

That’s my two cents for the day :slight_smile:

Travis Walters

Hey there,

I just thought about something. I will give an example:


It says the first view is 3.458s and the repeat view is 5.123s.

If you look closer:

Initial View: Doc Complete 3.458s - Fully Loaded 7.165s
Repeat View: Doc Complete 2.603s - Fully Loaded 5.123s

The values on the main page are taking the Doc Complete value for the initial view and the fully loaded value for the repeat view.

You said that the test will show the fully loaded time if there are more than 50 percent of requests after the document complete event.

However, it is not taking into consideration requests to resources that have been cached. If it would take this into consideration, there would be the same number of requests as the initial view. It would make it have more than 50% of requests before the document complete event and the initial and repeat test would be based on the same event.

Travis Walters

Yeah, I’m actually leaning more towards just using the document complete times for the load times which would solve the problem as well. I think I came up with a 1-line change to the server code that would do it transparently so if I get a few minutes I may even push the change today.

I just went ahead and pushed the change. The CSV results will be the same as they were before but the “load time” across the site will always be the document complete time now. That way it’s a lot more deterministic and easier to explain.