The best you can do for a cold cache is 2 round-trips (including the host page) if you inline the selection script (.nocache.js) in the host page. You definitely do want the compiled script (.cache.html) *not* embedded in the host page, so that it can have "cache forever" semantics. Then, when users have a warm cache, it's literally exactly 1 round-trip for the module to start. BTW, once you do inline the selection script, it will be more important to get the HTTP semantics just right. Although it says "nocache", the proper semantics are "must-revalidate", so typically, the host page won't have changed on the server, and thus it becomes an If-Modified-Since (IMS) request with a Not-Modified (NM) response.
In other words, the best case for a warm cache is this 1 round-trip: IMS => NM, which is very cheap because there's no response payload. Your code can start essentially instantly on a decent network. On Fri, Aug 7, 2009 at 11:39 AM, Arthur Kalmenson <arthur.k...@gmail.com>wrote: > > > Are you counting fetching the host HTML page? With this approach, the > > selection script is done away with but you still have a fetch for the > > compiled script so that it can remain permanently cacheable. You could > > theoretically inline it into the host page, but since none of that is > > cacheable that would only make sense for very tiny compiled outputs. > > I don't think firebug counts the initial request to fetch the host > page, so two requests. One for the nocache.js and another for the > cachable HTML. With the inlining of the nocache.js file, you could get > it down to 0 requests if the retrieved page is cached forever. > > Are you saying to inline the generated JS in the host page too? How > could you do that? Don't you need the selector script to pick the > correct compiled version? Maybe I'm just not understanding what you > mean. > > > 2 requests is very impressive, Arthur! This is the sort of > conscientiousness > > (i.e. for optimizing user experience) I hope all GWT developers would > strive > > for. Nice work. > > And yes, we'd like to help you get that down to 1, too. > > Thanks Bruce! But it's really all thanks to Bob's ClientBundle :) > > -- > Arthur Kalmenson > > > > On Fri, Aug 7, 2009 at 9:57 AM, John Tamplin<j...@google.com> wrote: > > On Fri, Aug 7, 2009 at 9:43 AM, Arthur Kalmenson <arthur.k...@gmail.com> > > wrote: > >> > >> I'd love to see this in the trunk too. We have only 2 round trips on > >> start up now, thanks to ClientBundle. Getting it down to one will be > >> very slick! > > > > Are you counting fetching the host HTML page? With this approach, the > > selection script is done away with but you still have a fetch for the > > compiled script so that it can remain permanently cacheable. You could > > theoretically inline it into the host page, but since none of that is > > cacheable that would only make sense for very tiny compiled outputs. > > > > Note that there is a cost, as your host HTML page now can't be cached > (since > > the selection script essentially runs in the server). If your host page > is > > complex, this may be a net loss. You could try leaving it cacheable but > > setting Vary headers for the pieces that you use to make the decision, > but > > my understanding is that many caches do not handle this properly. > > > > Also, you cannot use any deferred binding properties that can't be > > determined by the HTTP fetch of your host page. > > > > -- > > John A. Tamplin > > Software Engineer (GWT), Google > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
