Can You Minify or Compress XSL?
I got this question in one of my courses over at the USPJ Academy, and I though the answer might be more widely useful.
JavaScript files (and CSS files) can be minified for production use) – ref. your post on the JavaScript CompressorRator. I was wondering – by pure curiosity – if compressing xsl templates would make sense? Could not find anything on MSDN or searching via Google (except this but it sent back an error).
And my reply…
No, you can’t compress XSL with SharePoint, nor would it really make much sense. The reason we compress (or ‘minify’) script is to reduce the number of bytes over the wire and to reduce processing time in the browser. (Both of these concerns are becoming less and less important, as bandwidth and processing power continue to get faster and cheaper.) The only other mini-benefit is some small obfuscation of your code, but it’s really not because if you know what you’re doing, you can make sense of it.
XSL is interpreted on the server side, so there’s no “wire”, and you’ve got a powerful server (you do have a powerful server, right?) that can eat XSL for breakfast. So most, if not all of the benefits of minification are moot, and besides, the XSL parser wouldn’t know what to do with compressed XSL, anyway. XSL is interpreted, not compiled. You can remove some of the white space and comments, but you probably won’t see much of a performance advantage for it.
Make sense?
M.
“there’s no “wire” <— Does this hold true if you are using I’m beginning to think there may be some drawbacks to holding all of my XSL in one site collection and importing it in for the whole web app…
Matt:
I think your question got chopped. By wire, I mean from a server to a client, where the normal bandwidth issues crop up. Server to server communication ought to be lightning fast if your environment is set up right.
M.
Please allow me to disagree on the importance of compressed/minified code.
Having more bandwidth or processing power doesn’t mean that you can waste it. The trend is to ask more and more from JavaScript, for example charting or other client side applications, Scripts are growing in number and size, and compression is a key factor in making this work.
Look at Yahoo and Google, they both make compressors available to support their rich frameworks. As for Microsoft, you’ll notice that SharePoint 2010 scripts are minified, which was not the case in 2007.
Christophe:
I’m not saying that you *shouldn’t* minify, I’m just saying that it’s becoming less important. We used to reduce ALL code to binary format because there was no economical way to execute it otherwise; thus compilers. With modern hardware and browsers, it’s becoming less important.
M.
That’s why I commented that I don’t agree, and that in my opinion compression is becoming more important.
The bottleneck is not the execution part, but sending the files over the wire. That’s why we do compression, which reduces the file size while actually putting more load on the client (you need to uncompress the file).
This is also the reason why people develop tools that load scripts on demand (for example LABjs you mention in a previous post).
Well, there’s compression, which the server and the browser negotiate, (generally gzip), and there’s minification.
Compression reduces the number of bytes over the wire and requires overhead on both the server and the client. The server gzips the text and the browser ungzips it (if we can call that a word).
Minification reduces the size of the script in a one-time operation which incurs no overhead on the server or the client once deployed.
M.
Exactly. Minification is a safe bet and will always bring performance gains. That’s what SP 2010 does.
Just to make it clear for everybody, the above comments are for JavaScript. For XSL (the central topic of the post) I totally agree with what the post says.
So the post focus on XSL for use on the server. For that application, I agree with Mark’s response. However, what if that XSL file is being used on the browser, together with a xslt jQuery library and SPServices plugin output to create reports? For that use case, then in my opinion, minification does make since and should be used.
Paul:
I’m curious what techniques you use to minify XSL. Can you share?
M.
Marc,
I’m not using any tool (yet), but will be approaching this topic soon as I implement some “client” side JS to create reports (using SPServices)…I’m thinking about using jQuery plugin Transform (http://plugins.jquery.com/project/transform) along with your SPServices libary to implement that area of the project I’m working on… The performance assessment will come in at that time, and thus if my xsl templates start to get too large, I may want to research further the use of tools to minify them prior to staring them on SP (a List), so that transfer (http) time is reduced.
Paul:
I’ll be interested in hearing where you go with this. I’m not aware of any way to minify XSL other than removing the white space manually. I don’t think it’d be worth the trouble.
M.
IMHO Minification for xsl files would only be interesting if there are lots of comments to remove.
What would be the benefit of this transform plugin over using an xml Web Part?
I’ll take it a little further and say that there’s very little “stuff” you could remove from well-written XSL. I don’t see a benefit.
I think that what Paul is trying to do is use the XSL on client-side changes. So no postbacks. I know that someone else in this blog’s comments or more probably in the SPServices discussions actually did this successfully. Here’s one example.
M.
Hi Mark,
As far as tools and as I had pointed out initialy http://www.boryi.com/free-web-tools/compress-xslt.html
is what makes me wonder if it was even possible (‘ignoring’ whether it would make sense which you perfectly adressed).
I also agrees that well written xsl should be ‘lightweight’.
Since we all agree SPD is doing a horrid job at formatting in a consistent manner an always includes ‘stuff’ you may need. Would it make sense to ‘compress’ (not in the strict sense) the default DVWP XSL code and create a global template?
I am starting to work on SP2010 and the new XSLTListViewWebPart and the ‘default’ xsl is quite extensive to say the least. A XSL ‘code generator (similar to what Christophe has on his website for ‘formula generator’ http://www.pathtosharepoint.com/HTMLcc/FormulaGenerators/IndicatorValues.aspx.
I will have to dig deeper in the xsl code default structure of this new web part but what SPD throw at you by default is a lot to digest!
Greg
Greg:
I’ve looked at the site a little. All it really does is remove the white space. You’ll get very little benefit, IMHO.
Remember that in most cases the XSL is interpreted on the server, so there’s less benefit than minifying script.
M.
XSL is verbose, it can be minified to a degree but not as much as javascript can be.
http://code.google.com/p/xslmin/