Some pages will be becoming usable before the DOMContentLoaded event is fired. Some will become usable shortly after DOMContentLoaded is fired. Some will become usable when load is fired. Some will become usable several seconds after that. Some will never become usable. (Cynical aside: the ones with excessive ads might fit in that classification.) There is no event that measures readiness of a page, nor can there be; there can only be a collection of reasonable heuristics.

However, we don't need a perfect measurement, just a reasonable one.

For example, you might try to wait for all stylesheets to have loaded, and then run requestAnimationFrame until the latency is below some threshold (say, 100ms) to represent a somewhat-loaded-and-not-too-laggy page.

The point is, you want some measure that plausibly excludes ad-related resources since clearly you don't care how long it takes to load those. It'd also be polite to be transparent about the limitations of your measure.

This is where a human with a stopwatch may come in handy. The clock will start when the page request is sent. Stop the clock when, in your opinion, you think the page is ready to read. Alternately, if you feel the page is loading too slowly, and have reached the limit of your patience, press this button instead.

The event does not have to come from within the vanilla browser, without human intervention. It could be from a plugin you create to collect human feedback on load times.

Of course, the human element will significantly decrease the number of trials you can do within a fixed time period.

> Stop the clock when, in your opinion, you think the page is ready to read.

Even that is not enough. A number of sites (especially ad-heavy sites on mobile devices) look ready to read, but as soon as you try to scroll, are jerky and semi-unresponsive. It's particularly a problem on ad-laden sites of small news publications. Blocking ads sometimes mitigates this, though not always, as some sites insist on using Javascript to implement "fancy" scrolling which inevitably breaks.

(Semi-related sidenote: please, for the love of God, don't use Javascript to hijack browser scrolling. It's almost certain you will not get it perfectly right and some users will suffer. It's almost never worth it. This is the #1 reason I end up having to switch to Reader Mode in Firefox).

The maybe you stop the clock when the user navigates away from the page. If it takes 30s to read the content without ad-loading and 40s to read it with ad-loading, then by subjective user time, the page is 10s slower. That may be because the ads take 10s to load, or because the distraction causes the user to read at 75% normal speed, but it's still a measurable result from a single variable change.

You're going to get a whole lot of noise in your signal from readers who get sick of waiting for/looking at the ads and leave early.

> Stop the clock when, in your opinion, you think the page is ready to read.

And then the page completely re-flows because some big advertising asset popped into existence further up that you weren't expecting.

I'd still question the usefulness of this rather arbitrarily number.

The only reason I can think of where I'd be interested in how quickly people can navigate a site without having loaded all the content yet, is when optimizing a site for people with really slow/bad internet connections. But that seems like a whole other topic that has barely any influence on the goal of the comparison.