Load Time is smaller than Start Render. What does it mean?

Web Performance Discuss Test Results
1

I removed one .js file from my site, and when I tested it, at appears to help a bit. However, when I test it from Wellington, New Zealand, I got a result:

Load Time - 3.445s
Start Render - 4.060s

How can Start Render time be longer than Load Time? Is that an indication something is not correct about my site?

Here’s the result: http://www.webpagetest.org/result/110314_60_5CRH/

2

… and it’s not only the above mentioned New Zealand test, where my site’s speed is slow, but I occasionally get a similar result in the USA, where the site’s speed is faster.

Example is the following Los Angeles test:

Load Time - 0.714s
Start Render - 0.747s

http://www.webpagetest.org/result/110315_QX_5DS9/

How should I interpret these results, which show Load Time shorter than Start Render time?

3

I wouldn’t necessarily worry about it too much. The way screen painting works in windows is that apps usually tell windows that an area of their window needs to be updated and when the thread for the given window has some breathing room Windows will tell it to update the window (coalescing multiple requests together). Because of this, it’s not unusual to see the render happen a little while after the browser actually had all of the information ready (particularly if it’s busy doing a lot of stuff).

If the change you made pushed it out further than it was before (consistently) then it’s probably worth looking into a bit (could be that the moving of things around put code executing into the initial render path).

4

Pat, this particular modification only consisted of a removal of a .js file which was responsible for a feature that the site no longer uses. The removed .js file was not substituted with more code elsewhere, it was simply removed, so I suspect it shouldn’t have negatively impacted anything.

I will not worry about it then :slight_smile:

Thanks!

5

I said I wouldn’t worry about it, but I can’t. It won’t let me sleep :slight_smile:

I did several more before & after tests.

Here are two visual tests:

Based on the above visual, I’m happy with the result of the removal of the .js file. However, what still confuses me are the “regular” (non-visual) test results, in particular the Start Render times. When the .js file is removed, the start render times are, in some test locations, such as L.A. and ZL, actually longer than Load Time and Document Complete times.

The Document Complete & Load Time always equal the same number, but how is it possible that Start Render can be actually a larger number here?

Three questions:

  1. Does “Document Complete” mean the page is fully loaded and visible in the browser?
  2. It is at all possible that the Start Render is not accurately measured by the test?
  3. Are my test results with the .js removed an indication of something wrong with my page?

The following are typical Before & After test results:

6

I really need to make the advanced use of visual comparisons easier :slight_smile:

  • If you look at the normal testing UI, there is a “video” tab in the advanced section that lets you capture a video of any test from any location. Make sure to also fill in a label so you can remember what you tested.

  • Run tests for everything you want to compare (configure each for at least 3 runs). You’ll need to submit the tests individually

  • After you have tests for everything you want to compare, go into the “test history” tab and you will see all of the tests you have run (and any tests with video will have a checkbox available next to them)

  • Select the tests you want to compare to each other and hit the compare button

This way you’ll be able to do direct visual comparisons between the different permutations.

1 - The DocumentComplete time is a technical measurement that the browser fires (onLoad event) when all of the resources for the page have been processed but it doesn’t necessarily mean anything has been displayed to the screen.

2 - It’s possible, particularly for really fast pages, but I haven’t seen many cases where that is the case (actually none once the code was solid).

3 - Possibly, but it’s also possible that the js you removed was introducing an event or pause that allowed the browser to render the screen. Looking at the NZ w/out js test in particular, it looks like the javascript that remains is pegging the CPU at 100% which is what is pushing out the start render. That’s a great case for running dynaTrace against the site to identify the exact code that is causing the problem (though you’ll probably want a javascript developer to do the work there). I can probably identify the cause pretty quickly but fixing it could be a lot harder depending on what is going on.

7

Pat

Pat, I would be very grateful if you would try.

My apologies for overlooking some of the advanced options. This is going to be VERY helpful. I just did a video test from New Zealand. I love the New Zealand testing location because my site is slow there. Later I will be doing more video comparisons from NZ with & w/out the .js. For now I’m leaving the .js present, so you can see what the issue may be.

Thanks very much for your help!

8

btw, you can also “remove” the javascript for testing purposes by using the blocking capability (just put the file name in the “block” tab and it won’t get loaded). It will probably be a couple of hours before I can run the dynaTrace capture (once I get out of meetings).

Thanks,

-Pat

9

No rush at all, Pat, I appreciate your help. And thanks for the tip about the .js removal from tests.

10

I can’t really tell what the code is supposed to be foing since it’s minified and merged but it looks like something in the combined file is attaching to DOMReady using YUI and whatever is doing that is probably the source of the CPU spike. Do you happen to know what components are dependent on yahoo-dom-event?

11

Pat, your looking into it is much appreciated. I don’t know at the moment what components are dependent on the yahoo-dom-event, but I think I will just leave at as is (w/out the .js file present). I think it works reasonably fine.

I’ve observed that if I go to Advanced Settings on the WebPageTest, and I select the Video tab, and I place a check-mark in front of Capture Video, I never get a longer Start Render time than Load Time (which is a good thing :-). But it makes me wonder why this differs from the tests with Video Capture disabled.

I also observed that the resulting Film Strip doesn’t seem to show the screen shots in the order I would expect (in at least some tests).

Here’s a sample (New Zealand test location): http://www.webpagetest.org/video/compare.php?tests=110318_A0_6CCD-r:1-c:0

Notice that the last two screen shots show my home page with no images, even though the 3rd screen shot from the end does display the page already complete with all images. (I get the same results here with and without the last .js file I have removed.)