Re: HTTP/2 Priorities Proposal

On 2014–04–18, at 9:17 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> 2. adds weights at all levels of the dependency tree (as opposed to
> just at the grouping layer)
> 
> The second is arguably an expansion of the capabilities, which could
> be perceived as an increase in complexity, except for the fact that it
> basically just removes a special case.  This is an increase in
> capability, which might be perceived equally as an increase in
> complexity or an increase in uniformity.

An increase in uniformity is a decrease in complexity.

I’m still in the process of implementation, but my reaction was that I plan to implement a hierarchy of groups anyway.

I’d be in favor of simply allowing the priority-group and priority-dependency flags to coexist. There’s no reason a group shouldn’t be allowed to depend on something.

Conceptually, group dependency allows the client to form a plan to download different types of resources: First get the critical markup, then all the small images, then bigger images, then bring interactive elements to life. Each category gets a group and each group depends on the last.

There’s no way to do this with dependencies alone or weighting alone. Workarounds would include picking one resource to use as a dependency-target proxy for its group, which falls apart if it completes too soon, or dynamically re-weighting groups, which loses some efficiency and is probably trickier to get working flawlessly on both the client sides.

If complexity goes up, there’s still plenty of room for graceful degradation. Website responsiveness is the only thing on the table here, we might as well provide more tools. (I’m tempted to suggest that PRIORITY frames be replaced by a variety of header frame, restricted to a set of connection-level headers, so the toolbox doesn’t need to be closed at all.)

Received on Friday, 18 April 2014 18:53:59 UTC