> Am 29.12.2016 um 12:10 schrieb Kyriakos Zarifis <kyr.zari...@gmail.com>: > > > 1. priority dependencies: streams with lower prio, but depending on a high > level stream, inherit this priority. This would make all preloads *together* > have the same prio as page B. Last I knew, chrome did no dependencies. Were > these resources PUSHed by the server? > > Not PUSHed; they were requested by the browser upon A's onLoad using the ' > link rel=”prefetch” ' directive in HTML A's <head>. > > Right, I forgot to add this in the description: Chrome's log shows the > priorities/dependencies as follows: > HTML A : stream_id=1, parent_stream=0, weight=256 > 1st Prefetched image : stream_id=3, parent_stream=0, weight=110 > 2nd Prefetched image : stream_id=5, parent_stream=3, weight=110 > 3nd Prefetched image : stream_id=7, parent_stream=5, weight=110 > ... > 8th Prefetched image : stream_id=17, parent_stream=15, weight=110 > HTML B : stream_id=19, parent_stream=0, weight=256 > > So my understanding was that the dependencies looked reasonable, i.e. the > prefetched objects form a separate lower priority chain starting at the root > and as such should not block anything with higher prio with the same parent > (0). Am I reading this correctly?
That is different than Firefox is doing things, but it should work. Notice though, that the images are chained with weight 110 on stream 0 and HTML B with max weight 255. That means the images should get a minim of ~30% of the available bandwidth as long as they have data. My reading. > > 2. mod_http2 is, in its current implementation, very eager to fill the core > network buffers. That means a lot of frames have already been pre-packaged > for sending before page B becomes ready to sent. These are then not > pre-empted by page B, but will be sent first. > > If you are willing to test a github beta of the module, I might find the time > next week to tweak the behaviour in 2) and you could verify the benefits in > your setup. I will not promise anything, though. > > This was my (as well as a few Chrome devs') guess, especially considering > that HTML B is not blocked behind the prefetched images (in fact not even > blocked by completing any single one of them: the images are sent serially > and HTML B is correctly interleaved between frames of one of those images - > it just doesn't seem to happen as quickly as it could have (~500ms earlier, > in this particular case) ). > > I'd be really interested in repeating the experiment with a tweaked version > of the module. Please feel free to let me know if/how I can help. I see what I can come up with. Thanks! > > Thanks, > Kyriakos > > > -Stefan > > > > > Stefan Eissing <green/>bytes GmbH Hafenstrasse 16 48155 Münster www.greenbytes.de
