com.smartgwt.client.docs

Interface NetworkPerformance

public interface NetworkPerformance

Network Performance

This section describes various methods for optimizing delivery of your Smart GWT-based application to the browser. The various techniques discussed here should enable you to drastically reduce the time to load your Smart GWT based application and to cut down on bandwidth costs and server-side CPU usage.

Note that in addition to these network performance considerations, you should also be aware of the recommended application design practices discussed in SmartArchitecture.

There are three main ways of improving the performance of your application:

Compression

You'll want to deliver as much of your application assets compressed as possible. For a start, the Smart GWT modules come pre-compressed. The Compression section describes how to make sure that Smart GWT modules and your application logic are delivered compressed and how to enable dynamic compression of your dynamic content.

Compression drastically reduces transfer times to the browser. Compression ratios for css and javascript files can be as high as 8:1.

Caching

The Caching section deals with delivering as much content as possible with caching headers. Setting these headers allows the end-user's browser and any intermediary proxies to keep a local copy of the file across browser reloads, ensuring the subsequent visits require almost no fetches from the server. Eliminating these fetches is also important for the reasons explained under File Assembly below.

File Assembly

Modern browsers limit the number of HTTP connections they use to fetch the assets required to render your pages - typically to just 2 connections. As a result, connection latency can play a much higher role than available bandwidth and the two connection limit effectively drastically limits the user's usable bandwidth. For this reason, it's important to minimize the number of HTTP requests made to the server. The File Assembly services make it easy to deliver multiple css and javascript file via one HTTP response. Assembling files together also helps to increase the compression ratio because the compression engine has more redundant data to work with.

FileLoader

The FileLoader is a standalone client-side module that allows you to performing caching or loading of various resources in the background on any page. The typical usage pattern is to use this module to pre-cache Smart GWT modules, skin images, and application logic while the user is, for example filling in a login form. See the FileLoader documentation on usage.

SSL Considerations

Some quirks to be aware of when optimizing for pages serviced via HTTPS:

• If your top-level https page loads an image via http, IE will pop a warning to the user asking if it's ok to serve the "unsecure" content. Firefox does not pop an alert, bug shows a different lock icon to indicate that not all content is served from a secure server.
• Firefox will not write images fetched via SSL to disk, even if expires headers are set. But it will cache them in memory for the duration of the browser session. This makes the use of the FileLoader even more important for SSL applications. IE will cache SSL content across browser restarts.
• If your only concern is with actual security and not with perception, it makes a lot of sense to serve the top-level page via plain HTTP and then use the Smart GWT RPC mechanism to fetch sensitive data with no-cache headers via HTTPS. Unfortunately this almost never practical because most users look for the secure lock icon on the top-level page and may become worried that the application is not secure if they don't see it.

Other Tips

1. Modern applications often use a number of cookies to keep track of session state, application state, etc. If you don't limit the paths these cookies are served for, you can easily end up with these cookies being sent to the server with every HTTP request as part of the HTTP headers. This can severely limit bandwidth where a large number of requests are made - typically for skin images. Also note that most technologies used by end-users to connect to the internet such as DSL and Cable are half-duplex, meaning that downstream must pause for upstream traffic to be sent and these connections also are asymmetric, allowing much faster download speeds than upload speeds. As a result, the limited upstream capability of most connections ends up limiting the download bandwidth by delaying the download of other assets required to render the page.

2. Whenever possible, don't set the "Cache-Control" header to "private" - this tells intermediary proxies to not allow caching of the specified content, eliminating that cache as a useful intermediary for other users behind it.

3. For a good overview of performance considerations, see this post: http://www.die.net/musings/page_load_time/