When a user first accesses a web application page, the application server will detect if the jsessionid cookie has been set, and will see that it is not. At this point, the application server does not know if cookies are even enabled on the browser, so it will try to set the jsessionid cookie, and as well, any URL that is passed in to JSF's ExternalContext's encodeActionURL(String) or encodeResourceURL(String) methods will have the jsessionid appended to them as a GET parameter. On the postback, the application server will detect that the jsessionid cookie is now set, if cookies are enabled, and cease appending them in the encodeActionURL, encodeResourceURL methods. This can cause many DOM differences to key parts of the page, like the head and form(s).
When a URL has a GET parameter on it, especially one that is new and unique, browsers won't have had that resource cached, so they'll need to be downloaded. This means that the initial page load with a new session will require a full download of all resources that have the jsessionid parameters on them.
Then, when the postback occurs, and the jsessionid GET parameters are no longer on the resource links, they are treated as different URLs then they just were. If the user has never used the application before and not previously done a postback, then they will now download all of the resources for the second time of this session. This is the worst case scenario, and every new user of an application experiences it.
Most of the resources used are not actually session scoped, they're application scoped, so a jsessionid GET parameter is unnecessary and undesirable. If we can stop it from being appended to those resources' URLs, that would solve all of these problems.
The issue in the forum post is likely due to the ;jsessionid parameter in the resource URLs. To improve this case, it would be necessary to generate non-session-specific resources with simple URLs.