Are there known performance issues with Internet Explorer? My application runs just fine with Firefox and Chrome but on IE 7 it is painfully slow. Every mouse click takes at least a second or two to respond. UI consists of all the basic components including labels, text fields, select lists, panels and dialog windows with static data and no back end operations yet. I’m using toolkit version 5.2.11.
Sadly, IE’s javascript engine rendering speed is not exactly fast. This article sums it up, and the picture tells everything http://development.lombardi.com/?p=166.
As an upside, IE8 that recently got out as a final release feels a lot more snappier than IE7, to bad we can’t force everyone to update their system. I guess there is something small you can do to get performance up in IE7, but nothing really miraculous.
Do you have any suggestions?
I tested it with YSlow for Firebug and this is what it has to say regarding stylesheets and javascript:
This page has 5 external JavaScript files.
This page has 12 external StyleSheets.
This page has 21 CSS background images.
12 external stylesheets were found outside the document HEAD.
Is combining style sheets and javascript files going to be worth the trouble?
Most of the loaded stylesheets in use are the toolkit default styles like ITMILL/themes/default/tree/tree.css
[quote=Anonymous]
Is combining style sheets and javascript files going to be worth the trouble?
Most of the loaded stylesheets in use are the toolkit default styles like ITMILL/themes/default/tree/tree.css
[/quote]Is there any possibility you could move to using Toolkit 5.3? I highly recommend that you upgrade as soon as possible, to keep up with following updates as well. The 5.2 branch won’t receive any major new features any more, only necessary maintenance/bugfix releases.
At least, upgrade to 5.2.15 
In version 5.3, the default theme that comes with Toolkit is already packed, and is located in /ITMILL/themes/default/styles.css. It only involves 1 request then.
The background image count could be reduced within the default theme (with CSS sprites), but that is not currently my interest, since I’m building a completely new theme which will address this issue.
I don’t think we can pack the JS files together, it just the way GWT compiles the client side code.
Just to make things clear. There will be no new releases from the 5.2 branch. Everybody is urged to move to 5.3 as soon as possible.
Is there a detailed guidelines how to move from ITMill 5.2.x to 5.3?
I tried it briefly, but encountered problems (some components dissapeared) and I suppose they were somehow related to OrderedLayout and css-files. I noticed that some components got 0 (zero) width?
There are major changes in the layout system between 5.2.x and 5.3.0. The main difference is that if you specify a relative width/height for a component, its parent must have a defined width/height. In practice this means e.g. that a 100% wide panel cannot be inside a layout with undefined width. A layout with undefined width means its size is calculated from the content while the 100% wide child wants to calculate its width from its parent. This has been a bit simplified but is generally true.
In order to make debugging of layouts easier there is a new “Analyze layouts” function implemented in 5.3.0 which will tell you what is wrong with your layouts if you for instance get 0px wide components. Just add the “?debug” parameter to the application url and click “Analyze layouts” in the debug window.
More information about the layouting can be found in the reference manual:
http://www.itmill.com/documentation/itmill-toolkit-5-reference-manual/layout.html
An article at dev.itmill.com also might give you some more information:
http://dev.itmill.com/wiki/DevDocs/RFC/RelativeSizes
Layout issues have also been discussed in this thread:
http://forum.itmill.com/posts/list/590.page
Oh yes, there really are major changes in layout system…
Sad that it seems that it is extremely difficult to move from 5.2.x to 5.3 when ui has customized stylesheet.
Performance issues turned to css-studying…
Main problem now seems that toolkit adds several div-elements with zero height or width.
Another big surprise is that dialogs that works in Firefox, are blank and size about 1 centimeter * 1 centimeter in IE8!
[quote]
Oh yes, there really are major changes in layout system…
Sad that it seems that it is extremely difficult to move from 5.2.x to 5.3 when ui has customized stylesheet.
[/quote]Sorry to hear that. But once you’ve done the upgrade, you’ll be all the more happy from there on with the new, more robust layouts
So are you saying that you have customized the default theme, or do you have a completely revamped theme? Custom themes should otherwise move quite pleasantly to the new layouting system, but almost all margins defined in the CSS need to be removed.
Some sizes defined in CSS might also get overridden by the layout calculations, and in those cases, you need to move the size setting into the server-side code (unfortunately). That might actually be a bug of some sort…
[quote]
Main problem now seems that toolkit adds several div-elements with zero height or width.
[/quote]And this happens in every browser, I assume. That is just the result of haphazardly conceived layouts: relative sized elements inside an undefined sized layout. Not your fault, though, since they worked before. I guess you have tried to use the “Analyze layouts” button in the debug-window to try and correct the problems?
[quote]
Another big surprise is that dialogs that works in Firefox, are blank and size about 1 centimeter * 1 centimeter in IE8!
[/quote]Hmm, I guess we haven’t done enough IE8 testing yet. Could you post a ticket about this issue?
-Jouni
We changed from 5.2 -> 5.3 with not that much issues. Most of the fixes was simply finding and replacing the word orederedlayout to either horizontallayout or verticallaout.
eg.
.i-orderedlayout-header { ----> .i-horizontallayout-header {
About that ie8 and popup bug. We had that problem in an internal project, but it seems to be fixed. Maybe Johannes could give some input on how to fix those.
Workaround for ie8 popup bug is to force the ie8 to use the ie7 rendering mode. This should be accomplished automatically when using toolkit 5.3.x (not sure about latest 5.2.X) but problem may still appear if the application is used inside a webpage (e.g. liferay portlet). In case of portlets one should add compatibility meta tag into head of the web page where the portlet is:
<html>
<head>
<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />
<title>Portal</title>
...
As a general comment about the topic: IE7 is really slow - IE6 is manages to be even slower. When targeting these browsers, please do test you UI on development time with these browsers in a slowest possible PC that should be usable with the system.
IT Mill Toolkit itself works fine with IE6, but it is really easy to put too many components on screen for IE6 to handle with reasonable delays.
Really interesting browser benchmark:
http://marcus.bointon.com/uploads/SunSpiderJSbenchmarks.pdf
(Summary IE7 is 16 times slower than WebKit and IE6 manages to be almost three times slower than IE7)
My conclusion after trying out several Vaadin demos today (2010-02-02) on IE7:
After clicking on a node in the tree to select a demo, it takes about 5 seconds to open the demo in the main pane. It does not matter whether I already clicked on that node before or whether the demo opened the first time (caching?).
I am looking for a powerful framework for implementing solutions for huge companies with quite a lot of concurrent users (not as much as amazon or so, but therefor the users are named, do work longer with their application and come back more often).
After all, I got the impression that the performance with the most popular browser for larger businesses, Internet Explorer, is a showstopper
. My test bed relies on a three-year old notebook, i.e. an average computer that is used by many users at the customer’s.
Can anybody tell me whether the performance on popular IE will be increased? Or is it that the Vaadin server is that slow?
Thanx for your kind answers.
Klaus
Caching can be achieved on some level, e.g. TabSheet will preserve the tab contents in the DOM, even when the tab is not visible, and making the tab visible again won’t cause a whole lot of re-rendering on the Vaadin part, but the browser still has to do the work to actually render the DOM changes.
That’s something Vaadin can’t optimize, it has to be done on the application level, making sure you’re views are easy for the browser to render (i.e. relatively shallow DOM hierarchy, not much advanced CSS etc.). But of course Vaadin will play a big role on the initial rendering of the tab, can’t argue that.
Sampler uses plain layouts for the views, so when you change the view, all the previous view contens are cleared from the DOM and considered garbage. So each view change effectively re-renders the whole view (well, the parts that change, to be correct).
Scaling generally won’t be an issue. The Vaadin servlet is fast and scalable (search the forums for that topic). The troubles you’re facing are on the individual users client machine, which won’t affect any other user directly. The slowness is experienced on the client side.
Three year old computers should do fine rendering Vaadin apps, unless of course they are the moderest ones from that time. Can you give some more concrete specs of the notebooks?
You can make IE perform fast as well, but it requires a bit more thought in the implementation. You need to keep your application views modest, consider rendering some parts of the UI lazily (e.g. by using the Refresher component, search the forums for that, too), and by using the fastest layouts available, i.e. CustomLayout and CssLayout. You should also consider using some other theme than Reindeer, if you wish to squeeze every last drop of performance out of the system, since Reindeer is quite a heavy theme size and performance wise.
And do note, that IE8 is the most popular IE on the market at the moment, as reported by
several
different
sources
.
Hope these help some, be sure to ask more.