I think this would be good, but I was afraid to change the ordering of OnReceivedCachedMetadata() and OnStartLoadingResponseBody().  I seem to recall at least some code that assumed metadata was received before the body started/completed.

Maybe that concern is not valid, though.  Have you looked at the various URLLoaderClient subclasses to see how they handle these cases?

If we end up having to change a lot of client code maybe it would be better to do the redesign necessary for bug 858908 instead.  If we could refactor the various side data paths to use a mojo::DataPipe then we would get better parallelism in general.  That's a much bigger effort, of course, though.

Some other ideas I had for optimizing the blob-specific case that service worker uses:

1. We could include a flag in SerializedBlob indicating if there is any side data or not.  Then we could skip trying to read it if its not there.
2. We could make a blob reading method that provides both the side data and starts filling the main pipe in one call.  This might let us optimize how we provide the data a bit.

Thanks for the inputs. They are very helpful. I haven't checked all URLLoaderClient subclasses so I think your concern is valid. It seems that using mojo::DataPipe for side data is worth considering. Looking at traces I noticed that side data for large JS can be ~5MB and sending it seems to block blob body read.

As far as I remember the ordering matters, so that for example the client can use the cached compiled data before starting to compile. (Will look further)