A jsessionid is added to package resource links of the first page visited, most of which are static and don't need session info for them to be rendered. For a new session in a browser with cookies enabled this causes a 'double load' of every package resource: once for the initial page (with jsessionid added) and again for the subsequent page (with no jsessionid added).
Each time the user revisits the site with their previous session expired another (redundant) download of the package resources will occur (because they have a different jsessionid suffix)
Examining the IE cache we can see that both the jsessionid suffixed version and the version without the jsessionid suffix have both been cached as it treats each as individual resources.
This will cause a performance hit for users visiting a Wicket site for the first and subsequent times (after cookie expiration) on most average ADSL connections and might have an impact on bandwidth demand/cost on extremely busy Wicket powered web servers.
Wicket always renders stateless resources without any jsessionid regardless of whether the page is stateful or stateless. When servicing a request for a resource without a jsessionid Wicket does not attempt to establish a session which avoids creating a Session on every stateless resource request.