Re: Reference set in HPACK

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

Sure.

>
> 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.
> 

I still see this as a non-problem; if a resource needs to be cached
separately then it's silly to inline it, no? If it doesn't need to be a
first-order resource, then it'll cache just fine inlined. At least when
I use this technique, it's with images that are used most, if not every,
page load and I never need to refer to them individually. The result is
a simple background pre-load which saves bytes and reduces latency, and
I fail to see how the opposite is "implied" by inlining -- unless the
technique is being used improperly for resources which should have
their own URLs to begin with?

>
> 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.
> 

Poor caching consequences of *mis-*using inlining. I still don't see
how it applies to how I, or anyone I know, uses inlining. I also
disagree that an efficient push mechanism will stop me from inlining
all the little images which make up the "chrome" of a site design
(which surely don't need to be first-order resources).

Say for instance, I have several "slivers" of gradient or whatever that
I'm going to repeat-x repeat-y. Inlining these into one image has no
downside vis-a-vis caching, plus the upside that it can shave maybe 80%
of the bytes incurred by image-format overhead. How would using push to
send them individually, benefit me in any way?

Of course, there are uses for push, I'm just not seeing it as any sort
of replacement for inlining. There's also a risk that one "sliver" needs
to be re-requested, leading to initial page-load rendering where the
"chrome" fills in at different times and looks awkward -- so I'd also
lose the cheap, no-frills "pre-load" inlining gives me such that site 
visitors come away with a positive first impression of site performance.

-Eric

Received on Thursday, 3 July 2014 02:54:45 UTC