- From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
- Date: Thu, 3 Jul 2014 17:31:34 +0000
- To: "Eric J. Bowman" <eric@bisonsystems.net>, Roberto Peon <grmocg@gmail.com>
- CC: Poul-Henning Kamp <phk@phk.freebsd.dk>, Kazu Yamamoto <kazu@iij.ad.jp>, HTTP Working Group <ietf-http-wg@w3.org>
> 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? I think you are using different definitions of inlining. Your view of inlining is to pack several images into one big image. Roberto's view is to encode these images inside the html document (this is more relevant for javascript and css than for images). With one large html document including the images, you don't need to request these images after receiving the html, but you can't cache them for the next html document. Hervé.
Received on Thursday, 3 July 2014 17:32:17 UTC