Thank for the response of Sripathi and Chris, We have used firebug page speed, YSlow and Chrome Speed Tracer, GWT debug panel.
Few changed already applied and few are in the pipeline The actions have been done so far for the performance: 1. Used Akamai.com content cache implementation to cache the result of RPC, images, Jascript and css files, so the user can get content from nearest Akamai servers. 2. Group bunch of third party Javascript(s) into one server call. 3. Bind several requests into one RPC call (dayContentService.rpc) 4. Multi thread in server side to fetch result for dayContentService.rpc 5. Changed the execution flow to load/execute GWT module first and then load/execure third party Javascript(s) 6. Applied ClientBundle for the images loaded from GWT module. (you can see it from logo, calendar, Find The Hotel images) 7. Defer to load Google map key on demand 8. Code splitting to reduce home page size. 9. Gzip the response. Changes in the pipeline: 1, Like Sripathi point it out, we will add expires header to images (most images coming from the result of RPC, so it is hard for us to use ClientBundle with GWT) 2. Add additional image domain for browser to parallel to load images. Current we only have image3, we will add image4. The website serves the user around the global, the challenge we are facing with: Most user's response time is fine, but some complain that the site is slow. Some region such as China reports that the page is slow to download. That is the main reason I start to look at the initial load. Chris, I am interesting in the 'server-side selection' approach. Let me know if you have any new progress on it. I am also thinking to use App engine to load GWT module, so user can get initial load from the server near by. As far as you know, does anyone successfully use App engine to load GWT. On May 7, 6:47 pm, Chris Conroy <[email protected]> wrote: > On Thu, May 6, 2010 at 11:05 PM, Sripathi Krishnan > > > > <[email protected]> wrote: > >> Technically, in the very first request, the server already knows user > >> browsers' type, is that feasible to: > >> combine 1), 2) and 3) together or > >> combine 1) and 2) together or > >> some other consideration > > > You are right, this is possible. See this discussion thread - > >http://groups.google.com/group/google-web-toolkit/browse_thread/threa... > > > But, before going down that optimization path, there are several other > > low-hanging-fruits to speed up your website. I looked at your website via > > firebug, and the following issues come to my mind - > > > *.cache.xxx file don't have a 'far into the future' expires header. > > Several (30 or so) images get downloaded at startup. None of these images > > have aggressive cache settings. You are not using GWTs ImageBundles to > > potentially inline these images. > > You have atleast 2 RPC calls at startup (getDayContent and > > getTargettedContent).The response of these calls is known ahead of time > > (since they don't depend on any user input), and hence you could potentially > > inline their response in the html and then use a Dictionary to read it in > > onModuleLoad. Or you could use a ClientBundle to compile the data with your > > application. Either way, you save two important 'pseudo-asnyc' requests that > > delay initial rendering of your application. > > I see you have a custom implementation to trace performance events. Have you > > taken a look at GWTs Lightweight Metrics? > > > --Sri > > > On 7 May 2010 02:21, Michael W <[email protected]> wrote: > > >> We launched our GWT production ofhttp://www.holidayinn.comfew months > >> ago and we are in the phrase to tune the performance. > > >> We see quick high percentage of traffics coming from nocach.js and > >> cache.html, and just thinking how to reduce over all traffics. > > >> The normal flow of GWT would be like followings: > >> 1) The user request the website, the first server call is to get > >> generated html file (from JSP/Servlet) > >> 2) Then browser sends second request to fetch nocach.js with > >> <script type="text/javascript" language="javascript" src="/ > >> directory/xyz.nocache.js"></script> > >> 3) Based on the user browser's type, the browser send third request > >> to > >> get .cache.html > >> 4) Few RPC calls to get real content. > > >> So at least three requests are executed in sequence before the user > >> can see something. It is kind of expensive. > > >> Technically, in the very first request, the server already knows user > >> browsers' type, is that feasible to: > >> combine 1), 2) and 3) together or > >> combine 1) and 2) together or > >> some other consideration > > >> Would like to hear your opinions. > > >> Thanks > > >> --Michael > > Michael, > > You may find it easier to analyze performance issues in your app using > SpeedTracer:http://code.google.com/webtoolkit/speedtracer/get-started.html > > (You are correct that you can eliminate that initial round trip by > doing the selection on the server. We refer to this as 'server-side > selection'. Unfortunately it is not yet part of GWT proper) > > -- > Chris Conroy > Software Engineer > Google, Atlanta > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/google-web-toolkit?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
