3 ms·

> you can't use the load event to compare advert-heavy vs. advert-free load times I don't see why not. It's exactly what they want to show, how much quicker pa

> you can't use the load event to compare advert-heavy vs. advert-free load times I don't see why not. It's exactly what they want to show, how much quicker pages can load if you don't have to load the ads. And I personally am not satisfied with a page that has loaded to the extend of usability. Either a site loads fast or it doesn't. > opening the developer tools causes various side-effects As long as it's done for all the tests it should not matter. Whatever "side-effects" are introduced will be applied for all tests. Of course this means that the values themselves can't be used to compare the result against other tests, but the goal here was anyways to compare between the different ad blocks and not to generate values for general statistics.

chrismorgan 11y ago
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.
- logfromblammo 11y ago
  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.
  - chimeracoder 11y ago
    > 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).
    - logfromblammo 11y ago
      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.
      - PhasmaFelis 11y ago
        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.
  - eXpl0it3r 11y ago
    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.
  - kevin_thibedeau 11y ago
    > 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.
- emn13 11y ago
  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.

chrismorgan 11y ago

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.

logfromblammo 11y ago
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.
- chimeracoder 11y ago
  > 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).
  - logfromblammo 11y ago
    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.
    - PhasmaFelis 11y ago
      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.
- eXpl0it3r 11y ago
  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.
- kevin_thibedeau 11y ago
  > 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.
emn13 11y ago
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.