domLoading entry does not seem to have a purpose in modern browsers

[toddreifsteck]

Per @DLehenbauer who investigated this recently using dev tools of various browsers.

Pretend that all of the browsers are reporting the time of the document/parser association for ‘domLoading’ today. If so, the current numbers would mean that:

• Chrome speculatively created the document/parser before the response
  started.
• IE created the document/parser exactly when the response
  started.
• Firefox created the document/parser after some buffering of
  the response.

Those are all reasonable implementation choices per the current wording of domLoading. It’s also information about the internals of the browser that is of no use to a page author.

Should we consider deprecating this value or are we missing the value of this specific entry?

[igrigorik]

Hmm, interesting.. I think this is worth forwarding to the mailing list. I'd be curious to see if any of the existing RUM vendors track this metric. FWIW, GA does not: http://stackoverflow.com/a/19016616/510112

[nicjansma]

I think the metric is useful to include for the sake of being consistent, as it's one of the readyStates of the document (eg loading, interactive and complete).

domInteractive and domComplete are arguably more actionable for the consumer of the metrics, but I think it would be strange to not include domLoading just because it's not consistent across browsers.

[igrigorik]

@nicjansma consistent with previous implementations?

I agree with @toddreifsteck, if the value is all over the map between implementations, and we can't think of any good reason for where or why it would be useful to developers, then we should consider deprecating it.

https://html.spec.whatwg.org/multipage/browsers.html#initialise-the-document-object

[nicjansma]

@igrigorik I guess I'm saying it'd be strange to include two of the readyState states and not the third, even if the third isn't consistent in value across browsers. Someone may find value in analyzing it, especially if they're only looking at values from a specific browser.

[toddreifsteck]

This particular readyState state is just an internal state of the user-agent and the start time of this state does not seem to be useful to web site developers for any purpose. Because of this, it is my opinion that we should redefine it as having the same value as responseStart to avoid unnecessary discussions about the meaning of the differences between browsers.

The problem I’m attempting to correct is that server providers seem to be trying to reason about the meaning of the difference between domLoading and domInteractive when a more useful time is almost always responseStart and domInteractive.

[igrigorik]

@toddreifsteck from experience, changing definitions of existing metrics can (read, will) cause quiet a bit of pain... alerts start firing, people are woken up, etc. As such, redefining the metric doesn't feel like a big improvement: we're still reporting what appears to be a useless metric, but in the process we'd cause even more pain.

FWIW, the simplest thing we could do is add a note in the spec that this metric is implementation specific and should probably not be used for anything meaningful.

[plehegar]

How about the following note for domLoading:
[[
This attribute is deprecated and may be removed in future versions of this specification. Due to differences in when a Document object is created in existing user agents, the value returned by the domLoading is implementation specific and should not be used in meaningful metrics.
]]

[igrigorik]

lgtm.

[toddreifsteck]

Lgtm

Sent from my Windows Phone

---

From: Ilya Grigorikmailto:notifications@github.com
Sent: ‎5/‎27/‎2015 2:26 PM
To: w3c/navigation-timingmailto:navigation-timing@noreply.github.com
Cc: Todd Reifsteckmailto:toddreif@microsoft.com
Subject: Re: [navigation-timing] domLoading entry does not seem to have a purpose in modern browsers (#13)

lgtm.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/13#issuecomment-106084457.

[nicjansma]

Makes sense