05 janvier 2011

GWT round trips

Pour bien entamer l'année je vous propose un petit point sur la phase de chargement d'une application GWT.

La page HTML hôte est chargée par le navigateur (potentiellement mise en cache) et inclut un lien vers le script de sélection, qui lui est configuré pour ne jamais être en cache. Ce script s'exécute et sélectionne la permutation qui convient à votre environnement : navigateur, langue, etc (potentiellement mise en cache) L'exécution de ce script construit l'UI de l'application web et enchaine généralement avec un (voir plusieurs si vous n'avez pas trop bien pensé votre appli) appels RPC.

Au final, on a donc 4 requêtes séquentielles avant que l'application soit disponible pour l'utilisateur.

Pour améliorer les performances du chargement d'une appli GWT, autrement dit la première impression qu'auront vos utilisateurs, il existe plusieurs techniques.

La première, consiste à utiliser une page hôte dynamique [1], une JSP qui va directement inclure le contenu du script de sélection, ainsi que le résultat du premier appel RPC (encodé au format JSON ou GWT-RPC) [2].
La page hôte dynamique nous évite 3 requêtes, contre une petite surcharge de travail côté serveur.

Une autre piste pour aller encore plus loin est proposé dans les derniers builds du compilo GWT, via l'issue 941802. Il s'agit de remplacer la sélection du script côté client par du code côté serveur. La page hôte peut alors contenir directement la permutation GWT adaptée au navigateur client. Ne vous emballez pas, cette option est totalement expérimentale et même pas complète dans le SDK : il vous faudra surcharger le Linker et développer le code d'identification de la permutation, autrement dit retrousser vos manches.


[1] http://code.google.com/intl/fr-FR/webtoolkit/articles/dynamic_host_page.html
[2] http://www.techhui.com/profiles/blogs/simpler-and-speedier-gwt-with