What happens between navigationStart and fetchStart in navigationTiming?

[Shawn]

When I clear the cache and open www.facebook.com, the navigationTiming shows 

connectEnd: 1413680798547

connectStart: 1413680798343

domComplete: 1413680801758

domContentLoadedEventEnd: 1413680799472

domContentLoadedEventStart: 1413680799416

domInteractive: 1413680799416

domLoading: 1413680798820

domainLookupEnd: 1413680798343

domainLookupStart: 1413680798340

fetchStart: 1413680798336

loadEventEnd: 1413680801759

loadEventStart: 1413680801758

navigationStart: 1413680798066

redirectEnd: 0redirectStart: 0

requestStart: 1413680798547

responseEnd: 1413680798821

responseStart: 1413680798816

secureConnectionStart: 0

unloadEventEnd: 0

unloadEventStart: 0

The gap between navigationStart and fetchStart takes as long as 270ms. I am wondering what chrome is doing between navigationStart and fetchStart. There is no redirect between them.

If I refresh the page, navigationStart is equal to fetchStart.

This can be repeatable on my laptop. Machine model: macbook pro, OS: OSX 10.10, chrome version 38.0.2125.104.

According to the specification on https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html, navigationStart means "the time immediately after the user agent finishes prompting to unload the previous document", fetchStart means "the time immediately before the user agent starts checking any relevant application caches" or " the time when the user agent starts fetching the resource". I have no idea what is between them besides redirect. Any idea? Thanks a lot.

[Shawn]

One thing to notice is that Facebook is opened in a new tab. According to w3c specification, If there is no previous document, navigationStart must return the same value as fetchStart.

[Przemysław Pietrzkiewicz]

Thanks for your message, Shawn.

This is indeed related to the fact that you open the page in a new tab - the 270ms of the difference is the time it takes to initialize the tab for the navigation: between the time at which the browser decides to navigate (navigationStart) and the time at which the newly spawned renderer is ready to fetch the main resource (fetchStart). I'm surprised that it takes 270ms on a desktop platform though.

The spec is actually a bit misleading at this point - the condition "if there is no previous document" doesn't, technically speaking, ever apply, as every browsing context (tab) has to load about:blank before loading anything as per the HTML spec.

There was a discussion recently on the web performance mailing list about clarifying the specs - you can read a summary / proposal for changes in the doc: https://docs.google.com/a/chromium.org/document/d/1XjmlMpbPgQkBpj_sayrXyiyyImPiL0wyueWfiuD7bk0/ .

Hope that sheds some light, please let me know if you have further questions.

Cheers,

Przemek

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[葛光乐]

Can I read the docs:

 https://docs.google.com/a/chromium.org/document/d/1XjmlMpbPgQkBpj_sayrXyiyyImPiL0wyueWfiuD7bk0/ .

Thank you!!!

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[葛光乐]

Sorry,my bad. My vpn stop it.

[piaoling]

we monitor our website by performance.timing, it occupy a small proportion when user-agent is chrome.

I can recurrence this on my laptop sometimes , but firefox and IE are OK.

1. connectEnd: 1439204978009
2. connectStart: 1439204977661
3. domComplete: 1439204981119
4. domContentLoadedEventEnd: 1439204980807
5. domContentLoadedEventStart: 1439204979888
6. domInteractive: 1439204979888
7. domLoading: 1439204979128
8. domainLookupEnd: 1439204977659
9. domainLookupStart: 1439204977659
10. fetchStart: 1439204977659
11. loadEventEnd: 1439204981121
12. loadEventStart: 1439204981119
13. navigationStart: 1439204976215
14. redirectEnd: 0
15. redirectStart: 0
16. requestStart: 1439204978010
17. responseEnd: 1439204979505
18. responseStart: 1439204979123
19. secureConnectionStart: 1439204977663
20. unloadEventEnd: 0
21. unloadEventStart: 0

fetchStart - navigationStart = 1444ms

chrome 44.0.2403.130 m

OS:win7 64-bit

Memory: 8G

CPU: Intel Core i5-3230M @ 2.60GHz.

I found the source code:

//src/third_party/WebKit/Source/core/loader/DocumentLoader.cpp

void DocumentLoader::startLoadingMainResource()
{
    RefPtrWillBeRawPtr<DocumentLoader> protect(this);
    m_mainDocumentError = ResourceError();
    timing().markNavigationStart();
    ASSERT(!m_mainResource);
    ASSERT(m_state == NotStarted);
    m_state = Provisional;

    if (maybeLoadEmpty())
        return;

    ASSERT(timing().navigationStart());
    ASSERT(!timing().fetchStart());
    timing().markFetchStart();

Would  maybeLoadEmpty()  blocking for a  long time ?

How to avoid this problem to decrease the pageload time ?

在 2014年10月30日星期四 UTC+8上午5:05:58，Przemysław Pietrzkiewicz写道：

[Carlos Knippschild]

Hi Piaoling and others.

I'm not certain this information I will provide is useful but I did collect some data on this period of time of navigations: between when the request is made and the first IO operation starts. Even though the average is not that high it does have a very long tail.

Performance is especially worse on Windows and has a strong correlation with the amount of RAM the system has. This leads me to think in terms of "newer" and "older" hardware or maybe too much disk swapping going on.

But by the specs of your laptop, with Win 7 and 8 GB of RAM, I am a bit surprised with a time close to 1.5 s. How did you run your tests? Was the laptop running low on memory or at heavy CPU usage? As Przemysław mentioned earlier, the creation of a new renderer (if needed) happens in that period and I also think it should be the main source of delays.

Notice that navigationStart is set in this snippet of code that you pasted by the call to DocumentLoadTiming::markNavigationStart(), but also by DocumentLoadTiming::setNavigationStart() which is (indirectly) called from RenderFrameImpl::NavigateInternal. So I don't think maybeLoadEmpty() is where your problem lies.

One thing you could do to find out where that long delay is being spent at is to use record a tracing of that navigation using chrome://tracing. When recording I suggest selecting "Manually select settings" and then leaving only "navigation" and "netlog" enabled. If you are able to repeat that measurement while recording a trace you can save the results, share them here and we can take a look.

Hope this helps a bit.

Carlos.

[piaoling]

Thanks Carlos Knippschild.
I run my tests with memory and CPU almost idle, just open a new-tab and type the URL "https://www.baidu.com/" to visit the website..

Please see attachment for details.

在 2015年8月12日星期三 UTC+8上午6:43:47，Carlos Knippschild写道：

[Matthew Menke]

Also worth noting that fetch start is when the browser process actually starts the request, so the request will have to make it from blink to the browser process, and a bunch of browser-side objects will need to be created.

After that, a bunch of components can further delay starting a request.  During startup, if there are WebRequest extensions, we have to wait for them to load before starting a request, as they may want to do weird things to it.  Safebrowsing may decide to to delay it while comparing the URL to its database.  It also has to go through the ResourceScheduler, though that should let through main frame requests (That will affect ResourceTiming, just not NavigationTiming).

There may well be others.

...

[qianyi]

What happens between navigationStart and redirectStart, my code:

Statistical Results of gap1:    

 The gap between navigationStart and redirectStart takes as long as 814ms。And this page embedded a frame  

在 2014年10月30日星期四 UTC+8上午5:05:58，Przemysław Pietrzkiewicz写道：

Thanks for your message, Shawn.