All, I'm wondering just how strict we want to be in getting the stone ridge pageload test to be exactly what we would do in browser. I've been working under the assumption that we want to measure as little non-necko code as possible, so I've come up with a scheme to just create channels for each resource. This scheme would look like this:
1. Create a channel for the top level page (index.html or whatever it is) 2. When onStopRequest fires in that channel, kick off channels for each of the subresources (images, stylesheets, scripts, iframes, ...) 3. If there are any subresources that have subresources of their own (iframes come to mind), this process continues recursively. 4. Once every resource is loaded, the test is done. I have everything ready client-side to do this kind of test (including a script to take a pageload recorded with web-page-replay and figure out what resources need to be loaded when). The problem that I see with this approach is that it misses some behaviors that may be important to page load time that necko may or may not be in control of: resource prioritization, the actual order in which the resources are requested (due to placement in the document), etc. The easy(?) way to get this would be to load a page the way we normally do, just without any browser chrome (nsIDocshell? I honestly don't know what the right place to do that would be). Of course, this has the problem of adding in quite a few non-necko bits that could throw off our timing. We could also try to simulate the important things that are missing from the first approach, but this both makes the initial implementation more difficult, as well as potentially turning the page load test(s) into a maintenance nightmare, if we change things with resource prioritization, etc in the future. I'm inclined to continue down the path I'm already taking (bunch of channels fired off marginally intelligently) until we find significant issues with that approach, but I'm asking the intelligent minds on this list for opinions so that my preconceptions and/or misconceptions don't get us into trouble sooner rather than later. -Nick _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
