この記事では、GWTで使用されるクライアント最適化手法について説明しています。
ブラウザごとにアプリケーションの別個のバージョン
各ブラウザーには独自の特性があり、既知の方法で開発者の生活を複雑にします。 したがって、たとえば、IE6でXMLHttpRequestオブジェクト（JavaScriptからサーバーへの非同期要求を実行するために必要）を取得するには、ActiveXObjectを使用するように渡されます。
var xhr = 新しいウィンドウ。 ActiveXObject （ "Microsoft.XMLHTTP" ） ;
他のすべての（IE以外の）ブラウザーは、XMLHttpRequestオブジェクトのネイティブサポートを提供します。
var xhr = 新しいウィンドウ。 XMLHttpRequest （ ） ;
通常（これがほとんどのJavaScriptライブラリの動作方法です）、Webアプリケーションのこのような状況では、ブラウザーに依存するすべての実装が含まれ、特定のブラウザーではそれぞれ1つのみを使用し、実行中、つまりロードおよび解析後にそれを選択します不要な実装を含みます。
Google Web Toolkitは、（あらゆる意味で）優れたソリューションを使用します。ブラウザーごとに、順列と呼ばれるWebアプリケーションの個別のバージョンが呼び出されます。 各順列には1つのブラウザーでのみ動作するために必要なすべてが含まれているため、たとえば、「fire fox」はIEに固有のJavaScriptまたはCSSをダウンロードして解析する必要はありません。
最適化、最小化、難読化
Webアプリケーションの読み込みを高速化するために、JavaScriptとCSSは通常、たとえばYUI Compressorを使用して最小化されます。YUICompressorは、空白やその他のオプションの構成要素を除去するとともに難読化によってサイズを大幅に縮小します。
Google Web Toolkitも最小化と難読化を実行しますが、最小化プログラムの入力は、人が書いたのではなくJavaScript-in-JavaScriptコンパイラの結果として取得したJavaScriptを受け取ります。 コンパイラは、未使用のコードを安全に削除し、メソッドを拡張し、多態的な関係を最適化し、定数式などを計算し、最適化された（サイズと速度）JavaScriptをもたらします。
小さな（プリミティブ）例：
パブリック クラス CircleMath {
public static double getArea （ double radius ） {
数学を 返します。 PI *半径*半径;
}
public static double getCircumference （ double radius ） {
数学を 返します。 PI *半径* 2 ;
}
}
...
ダブル a = CircleMath。 getArea （ 7.5 ） ;
double c = CircleMath。 getCircumference （半径） ;
コンパイル時に、CircleMathは削除され、その静的メソッドはインライン挿入に置き換えられ、数式は最適化されます。 結果は次のJavaScriptです。
var a = 176.714586788 、 c = 6.283185308 *半径;
より良いGzip圧縮のための最適化
最新のブラウザはすべて圧縮をサポートしています。これにより（Webサーバーが正しく構成されていれば）、送信されるデータのサイズを大幅に削減できます。 HTML、CSS、およびJavaScriptは特に圧縮率が高く、平均で75％減少しています。
データ自体に大きく依存しているこのような結果は、Googleのエンジニアにとっては不十分なようでした。そのため、Google Web Toolkitの一部である難読化ツールを変更し、結果の難読化コードが常にGzipを可能な限り圧縮するようにしました。
これがどのように機能するかを想像するには、GNU Gzipを使用して2行を絞ります。
a b c b a c a b c a b c b a c a b c
a a a a a a a a b b b b b b c c c c c c c
両方の行は同じ文字数で構成されていますが、それらの一部の順序が異なるだけであり、圧縮後、最初の行は1バイト減少せず、2番目の行は3バイト短くなります。 同様に、繰り返しコードが同じ「 スライディングウィンドウ 」内に収まるようにJavaScriptで関数を宣言する順序を変更すると、スクリプトは関数を宣言するランダムな順序よりも圧縮します。
CSSスプライトとインライン画像（データ：URL）
CSSスプライトと埋め込み画像は、Webアプリケーションのフロントエンドグラフィックスを読み込むために必要なサーバー呼び出しの数を減らすのに役立ちます。 ほとんどの場合、組み込みのイメージに限定することは可能ですが、まだ広く使用されているIEのバージョンではサポートされていないため、両方の方法を適用する必要があります。
ユーザーインターフェイスを構築するために、Google Web Toolkitを使用すると、HTMLおよびCSSという使い慣れたテクノロジーを使用できます。HTMLおよびCSSは、多少の高度な構文により、追加の労力や知識なしで画像読み込みのクロスブラウザー最適化を保証する問題を解決するのに役立ちます。
<！DOCTYPE ui：UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
<ui：UiBinder xmlns：ui = "urn：ui：com.google.gwt.uibinder" >
<ui：image field = "image1" src = "1.png" />
<ui：画像 フィールド = "image2" src = "2.png" />
<ui：スタイル>
@sprite .image1 {
gwt-image ： "image1" ;
/ * ... CSSプロパティ... * /
}
@sprite .image2 {
gwt-image ： "image2" ;
/ * ... CSSプロパティ... * /
}
</ ui：スタイル>
<div >
<div class = "{style.image1}" > </ div >
<div class = "{style.image2}" > </ div >
</ div >
</ ui：UiBinder >
このようなUIテンプレートを含むWebアプリケーションのアセンブリ中に、1.pngと2.pngは1つの画像に結合され、CSSスプライトを介してIE6とIE7の順列で使用されます。 他のすべての順列では、ソース画像はデータ：URLとして埋め込まれます。 どちらの場合でも、必要なすべてのプロパティがimage1およびimage2 CSSクラスに自動的に追加されます。
アプリケーションのモジュールへの分離
Google Web Toolkitの順列メカニズムにより、最新のブラウザは、HTML、Javascript、CSS、および画像（Webアプリケーションのすべてのコンポーネント）を単一のサーバー呼び出しの単一ファイルとしてダウンロードできます。
Webアプリケーションの機能が大きくなると、順列のサイズが必然的に大きくなり、それに応じて各順列のダウンロードに必要な時間が長くなります。 すべての可能な最適化を考慮に入れても、「コールドスタート」（ブラウザキャッシュが空）が許容できないほど長い時間がかかり始める場合があります。
この場合、Google Web Toolkitは、Webアプリケーションを個別にダウンロード可能な複数のモジュールに分割する機能を提供します。 したがって、大規模なアプリケーションの主要な機能は、小さな起動モジュールをロードした直後にユーザーが利用できるようになり、モジュールに追加機能を提供する残りは必要に応じてロードする必要があります。 モジュールは自動的に作成およびロードされ、開発者は分割ポイントを指定するだけです。
Google Waveの開発者は、このモジュールを使用して、頭脳の平均ロード時間を数秒にすることができましたが、この「モンスター」のフルサイズは約3 MBです。