According to Steve Souders: About 15% of folks dont have gzip. So unzipped sizes do matter. While I understand
On Wed, Jun 10, 2009 at 10:45 AM, Kevin Brown<[email protected]> wrote: > Getting rid of IFPC brings the gzipped size down to around 2k, which was my > personal preference. > > Compared to the opensocial-0.8, or even 'core', though, rpc is pretty small. > Those libraries weigh in at 30k and 10k, respectively. > > On Wed, Jun 10, 2009 at 7:06 AM, Paul Lindner <[email protected]> wrote: > >> Of all the optimizations out there this seems like the least interesting >> and >> more disruptive than necessary. The (current) whole of rpc.js is >> 6285 Jun 8 13:28 ./features/target/classes/features/rpc/rpc.opt.js >> >> Making this 6k private instead of CDN cacheable would mean that I would >> have >> to find another 6k to move onto the CDN to insure that I (and others) hit >> our cold-cache numbers for loading profile / home pages. >> >> Do you mind sharing your goals here? What kind of byte-savings are you >> expecting? >> >> Is it not possible to have the browser send a filtering parameter along >> with >> the request? The getRelayChannel() function figures out your capabilities >> based on what the browser can do, not the value of it's >> UA. For example there are some people that change their User-Agent to >> (mostly) Internet Explorer to get around server restrictions. These people >> would get broken nix. >> >> I just wonder if there are other ways to achieve the wanted byte savings? >> >> >> On Tue, Jun 9, 2009 at 2:18 PM, John Hjelmstad <[email protected]> wrote: >> >> > I'm sold, relying on Cache-Control: private is the better option. >> > This behavior does affect IFRAME rendering paths as well, though doesn't >> > necessarily need to. Container-side rpc can be optimized without >> > gadget-side >> > rpc, since gadgets.rpc(function getRelayChannel()) will return the same >> > value on each side. >> > >> > As Brian mentions, every code path in GadgetRenderingServlet sets >> > Cache-Control: private[,*] (except nocache=1, not an issue), so the >> > potential effects are limited to JsServlet. >> > >> > So 1. Admittedly, any given deployment will likely see higher JsServlet >> > traffic if choosing to opt into this feature; 2. this suggests that >> > JsLibrary field isBrowserSpecific should be added, with JsServlet >> signaling >> > noProxy behavior in caching headers when this bit is true for any library >> > it >> > emits. >> > >> > John >> > >> > On Tue, Jun 9, 2009 at 1:53 PM, Brian Eaton <[email protected]> wrote: >> > >> > > I don't trust the vary header any farther than I can spit. >> > > >> > > For example, at least one version of IE interprets a Vary header with >> > > any value other than user-agent to mean "OMG, I don't understand, >> > > don't cache this": >> > > http://marc.info/?l=apache-modgzip&m=103958533520502&w=2 >> > > >> > > In a comment to Mark's blog post, he mentions other implementation >> > issues: >> > > >> > > "More complex situations -- e.g., with multiple Vary headers and >> > > multiple request headers -- caused problems on a number of >> > > implementations (i.e., they'd return the wrong thing)." >> > > >> > > IMHO, we should stick to "cache-control: private." >> > > >> > > We need that on most iframes anyway, so this keeps the cache-control >> > > changes from rippling out quite so far. >> > > >> > > On Tue, Jun 9, 2009 at 1:44 PM, John Panzer<[email protected]> wrote: >> > > > This seems relevant: >> http://www.mnot.net/blog/2007/06/20/proxy_caching >> > > > (It appears that Vary: is fairly safe in the sense that caches that >> > don't >> > > > deal with it nicely -- e.g., caching variants -- will just mark the >> > > content >> > > > as uncacheable. Though I don't think this was rigorously tested.) >> > > > >> > > > -- >> > > > John Panzer / Blogger >> > > > [email protected] / abstractioneer.org < >> > http://www.abstractioneer.org/> >> > > / >> > > > @jpanzer >> > > > >> > > > >> > > > >> > > > On Tue, Jun 9, 2009 at 1:25 PM, <[email protected]> wrote: >> > > > >> > > >> Hi Paul: >> > > >> >> > > >> You're absolutely right. Vary: User-Agent; is preferable to me. Do >> you >> > > >> have any reason in mind for why Cache-Control: private in addition >> to >> > or >> > > >> instead of Vary would be preferable? Ie. common support by various >> > CDNs. >> > > >> >> > > >> I've been thinking how best to link service of custom rpc to setting >> > > >> this header. Ultimately JsServlet or a Filter needs to do so. >> Thoughts >> > > >> on this? The best idea I had was to add something like >> > > >> isBrowserSpecific() to JsLibrary so that the relevant output code >> > > >> (gadget rendering, js servlet) could act accordingly. >> > > >> >> > > >> Kevin - re: StringBuffer, comment isn't particularly prescriptive so >> > > >> I'll assume the complaint is use of StringBuffer rather than >> > > >> StringBuilder. If so, fixed. If not, let me know. >> > > >> >> > > >> >> > > >> http://codereview.appspot.com/63210 >> > > >> >> > > > >> > > >> > >> >
