Hello,
Thanks for the nice testing tool and site.
I am testing using default settings and getting DOM Content Loaded load time of around 1s to 1.5s and getting OnLoad Time of 1.5 to 1.9s
I would like to know the following -
Why is there more than 500ms time difference between DOM Content Loaded and
OnLoad Time ?
Why is there so much final load time variation even though I am using the same test settings (default) ?
Post a link to your test results for more informed responses.
Thanks for responding.
Here is the link of the test results - WebPageTest Test - Running web page performance and optimization tests...
No reply whatsover ? Is this forum active ?
Your best bet to see what is happening during that time is to enable timeline capture in the chrome tab of the advanced settings which will capture a dev tools timeline.
My guess since there are no images or external resources is that the browser doesn’t yield to do the layout/paint until between DCL and onload and it’s that operation that is consuming the time (you can see the CPU is pegged between the two).
Thanks Patrick for the reply.
I did enable the timeline capture. It is giving around 500 to 600 ms complete load time and DSL also same time. Other than that, I am not able to analyse.
Which browser / CPU does not yield to do the paint between DCL and onload ? The CPU and browser used by webpagetest.org ?
Do you have a link to the test result with the timeline capture?
All browsers will behave differently. You can test Firefox or IE to see if either of them behave differently. The CPU just indicates that code is running doing something in the gap and the timeline would help you understand what it is.
Measuring the time without the browser yielding won’t necessarily give you better data. The measurement might be faster but the page may also be blank. If you want the user to actually see content then you have to do layout and paint the screen.
If you want the actual measurement to be faster you can use the Dulles Thinkpad locating which has faster CPU so the processing will be shorter - but that doesn’t really do anything but make the measurement faster for CPU-constrained operations.
Patrick,
I do not know how to give link of the time line capture. I am posting here the screenshot of the same.
Testing with Dulles Think pad is also giving similar results - WebPageTest Test - WebPageTest Details
If you go to the chrome tab in the advanced settings there is a “capture devtools” checkbox. Here is a test example: http://www.webpagetest.org/result/151006_KJ_0689768376a937e07e38071c723a8646/
On the left of the waterfalls will be links to download or view the timeline.
It does look like it is the layout/paint (at least in the capture that I did) that is causing the delay between DCL and onload.
If you need to know exactly why it is taking so long to do the layout/paint then you will need to collect a trace (also in the chrome tab or in about:tracing locally) but you’ll be deep in the guts of Chrome’s internal code at that point.
The capture option is enabled but I am not getting link how you are getting. And have no idea of how to collect a trace.
Can you please help in finding out what the reason fo the delay between DCL and onload time is. The results obtained with webpagetest have a huge variation in time even when done with the same settings. What could be the reason for that ?
Here is link of another test which I did - WebPageTest Test - Running web page performance and optimization tests...
A test from close to the server ( which lowers latency all round )… http://www.webpagetest.org/result/151015_T8_3TW/
This shows an increase in CPU, so it must be processing embedded javascript. As there is almost none on the page, the I expect it’s the init () function that’s slowing everything down.
Either that, or a reorganisation of css / js from the body into the header and fixing the worst of the html errors may give the browser an easier time in parsing it.