Bug Tracker

Opened 5 years ago

Closed 5 years ago

#14712 closed feature (notabug)

Use performance.timing to detect already ready state

Reported by: phistuck Owned by: phistuck
Priority: undecided Milestone: None
Component: unfiled Version: 2.1.0-rc1
Keywords: Cc:
Blocked by: Blocking:


Now that we have performance.timing (prefixed or not), it might make sense to use it in order to trigger the ready event at the right time, instead of delaying it until the load event or trust the weird readyState property for that.

markelog comments - https://github.com/jquery/jquery/pull/1488#issuecomment-32784986 - that this is not the purpose of the API. This may be correct, it is not the initial use case, but is there any reason to disregard it as a proper use case? I do not see any. While this is not for statistical purposes at all, we use the statistics to gather information about the page. It may also lead to some performance benefits, since code may start running sooner (but still in time, because the DOM is actually surely there already).

Indeed, earlier browser support might not be worth the code size - http://caniuse.com/#search=performance I thought Safari (and especially, Mobile Safari) supports it as well, but unless the information is outdated or incorrect, supporting a prefixed variant will not gain anything worthy.

See the pull request for the technical details - https://github.com/jquery/jquery/pull/1488/files

I do not have a way to test the 8KB buffer situation from http://bugs.jquery.com/ticket/12282#comment:15 - but unless the browsers are buggy in this regard (and I expect them not to be), it should accurately detect that the DOMContentLoaded event has already been dispatched.

I am not sure domContentLoadedEventStart or domContentLoadedEventEnd should be used, though.

Change History (3)

comment:1 Changed 5 years ago by dmethvin

Owner: set to phistuck
Status: newpending

What is the compelling reason to do this? In which browsers and under what conditions does this fire? Why not use DOMContentLoaded for this as it was intended?

Really, we should be pushing people to avoid running code at .ready() rather than trumpeting the fact that they can rush themselves in the door a few microseconds earlier.

Last edited 5 years ago by dmethvin (previous) (diff)

comment:2 Changed 5 years ago by anonymous

What do you mean? you cannot use DOMContentLoaded if it were already triggered by the time jQuery has loaded.

I just thought of this as a way to trigger ready more accurately. It might be irrelevant and you may want people to stay away from ready, but ready is better than having inline scripts in the middle of the document and not every website can wait until the entire page has loaded in order to start running scripts.

comment:3 Changed 5 years ago by dmethvin

Resolution: notabug
Status: pendingclosed

I don't think we want to make this change, especially because it using an API in a rather unusual way.

Note: See TracTickets for help on using tickets.