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.