- From: Eric J. Bowman <eric@bisonsystems.net>
- Date: Thu, 3 Jul 2014 17:43:51 -0600
- To: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
- Cc: Roberto Peon <grmocg@gmail.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Kazu Yamamoto <kazu@iij.ad.jp>, HTTP Working Group <ietf-http-wg@w3.org>
RUELLAN Herve wrote: > > > 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). > Inlining can also refer to embedding images in CSS as data. Thanks for clarifying, I was wondering if we were talking around each other. > > 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. > OK, that makes sense, thanks. -Eric
Received on Thursday, 3 July 2014 23:44:07 UTC