Hello all,
I’ve been developing an Xpage application sporadically of over the course of the last year and we’re currently in the phase 2 implementation where we’re adding even more functionality and options to it. Some feedback from our customers during the phase 1 trial was that they found it slow and sluggish (half the reason was a lot were using IE6 which is rubbish when it comes to JS, the other half was because we didn;t notice as we’re on a 10Mb pipe … oops!) so I’m hoping to find some time in phase 2 to optimize things a bit better.
I found the following 2 articles which provided a lot of useful information, if I ever get a spare block of time I’ll be using some of these notes to optimize things.
http://www.stevecastledine.com/sc.nsf/dx/xpages-memory-usage-and-performance-tips-8.5
However one thing that was touched on but not quite fully stated was the Xpage tag markup vs html markup. In various parts of the application we have plenty of static elements (i.e. tables, spans, labels) but they’re all xpage markup (i.e. xp:span</xp:span>).
I was wondering if anyone knew that if I remove all the xpage markup I can (I’ll leave the xpage markup as is for things that compute ‘render’ or display document data etc…), would it help in performance?
i.e. convert:
xp:span</xp:span> to
xp:tablexp:tr</xp:tr></xp:table> to
My feeling is ‘yes’ as it’s that much less the server has to process and convert to html (in other words, non-xpage markup is spat out as is) but I’m not 100%. Before I invest a huge amount of time in this, can anyone confirm if this is worth doing?
I’ll be going ahead with the other suggestions that the articles mention (reduction in custom controls etc…), but I’d appreciate peopls thoughts on the matter.
Thanks
Subject: I would think xp tags are converted to HTML when the XPage is built
It would be very strange if xp tags were interpreted on the fly always when an XPage is accessed. I don’t know how it works but I believe there is no performance gain in writing HTML directly.
Subject: Look at the Java files…
-
If you look at the generated Java files, it creates separate Java objects for each and every xp:tag on the XPage. Plain HTML does exactly the same thing (parses to one object per HTML tag), so it boils down to whether an UIPassThroughTag object is lighter weight than a XSPTableRow object (for tr, which I looked at). Without knowing I’d say yes, mainly because “passthrough” implies it’s a simple string container that spits out the HTML therein, where anything with XSP on it implies automagic, code to drive it, and time to execute that code.
-
Operationally, however, I can’t say. I know I have read that plain HTML on XPages dramatically increases performance. I haven’t tried it myself, however, because SO much of the XPage automagic relies on the id tag that it’s sick. Take out the wrong one and it destroys apparently random functionality, and I’m not good enough at XPages to know which is the right one. Doesn’t keep me from ripping out id= left and right and come what may.
-
Speaking of IDs, if nothing else the UIPassThroughTag object won’t spit out 75 bytes per tag for name-mangled ID attributes, for each every single tag on the page. All other things being equal, just knowing what to omit to prevent that 75 bytes per tag from going down the wire will HAVE to increase performance.
-
If you don’t want to fiddle with the Java Perspective to see what’s generated, simply do Search → Files for an id= value you know is on the XPage you want to see. Expand Local → xsp to see the Java files it built. DO NOT look for your HTML. It appears Search will automagically hide .java results in this case. Search for something like an id= value or other non-HTML text.
Hope this helps…
Subject: Cheers for the info
