Re: Reference set in HPACK

It is fairly common to want to use the same css, js, and often even images
on the first pageload and subsequent navigations.

When you inline a resource, you cannot cache that inlined resource.
That means that you'll need to send it again if it is to be in the cache.
This implies wasted bytes, additional latency for that page load, or
complexity in doing fancy background loads.

With an efficient push mechanism, you don't inline.
You send the resources as themselves, achieving the benefit of inlining
without the poor caching consequences of using it.


-=R


On Wed, Jul 2, 2014 at 6:38 PM, Eric J. Bowman <eric@bisonsystems.net>
wrote:

> Roberto Peon wrote:
> >
> > You can cache an object that has inlined resources within it, but you
> > cannot cache those resources separately.
> > You can't cache a resource that doesn't have a name.
> >
>
> If I need to cache a resource separately, I don't inline it. I'm just
> not seeing the latency problem with inlining, if it only occurs when
> the technique isn't used properly?
>
> -Eric
>
> >
> > -=R
> >
> >
> > On Wed, Jul 2, 2014 at 5:54 PM, Eric J. Bowman <eric@bisonsystems.net>
> > wrote:
> >
> > > Roberto Peon wrote:
> > > >
> > > > Inlining is the technique most often used to reduce the number of
> > > > request.
> > > >
> > >
> > > I've also always considered it a worthwhile technique for
> > > byte-shaving, as combining lots of small images into one mosaic
> > > image eliminates whatever redundant bytes are inherent to the
> > > chosen image format.
> > >
> > > >
> > > > It is a strategy that works well most of the time for cold
> > > > pageloads, but it also harms latency for subsequent navigations
> > > > deeper into the site as those resources cannot be cached.
> > > >
> > >
> > > But you lost me there, as I've never had a problem caching those
> > > resources? Or does "inlining" not mean what I think it means?
> > >
> > > -Eric
> > >
>