Working as a freelance developer, I often made websites completely based on XSLT. In other words, on every request, an XML file is generated, containing everything we need to know about the page content: the name of the user currently logged in, the top menu entries, if this menu is dynamic/configurable, the text to display in a specific area of the page, etc. Then XSL process (caches, etc.) it to HTML/XHTML page to send to the browser.

It has a good point to make it easier to create small-scale websites, especially with PHP. It is a sort of template engine, but which I prefer to other template engines because it's much more powerful than most of template engines, and because I know it better and like it. It is also possible, when need, to give an access to raw XML data on demand for an automated access, without the need to create separate APIs.

Of course, it will fail completely on any medium-scale or large-scale website, since, even with good caching techniques, XSL still degrades overall website performance and requires more CPU serverside.


Modern browsers have the ability to take an XML file and to transform it with an associated XSL file declared in XML like <?xml-stylesheet href="demo.xslt" type="text/xsl"?>. Firefox 3 can do it. Internet Explorer 8 can do it too.

It means that it is possible to migrate XSL processing from the server to the client side for 50% of users (according on browser statistics on several websites where I may want to implement this). It means that those 50% of users will receive only the XML file at each request, thus reducing their and server's bandwidth (XML file being much shorter than its processed HTML analog), and reducing server's CPU usage.

What are the drawbacks of this technique?

I thought about several ones, but it doesn't apply in this situation:

  • Difficult implementation and the need to choose, based on the browser request, when to send raw XML and when to transform it to HTML instead. Obviously, the system will not be much more difficult then the actual one. The only change to make is to add XSL file link to every XML, and to add a browser check.
  • More IO and bandwidth usage, since the XSLT file will be downloaded by the browsers, instead of being cached by the server. I don't think it will be a problem, since XSLT file will be cached by the browsers (like images, or CSS, or JavaScript files are cached actually).
  • Possibly some problems on client side, like maybe problems when saving a page in some browsers.
  • Difficulty to debug code: it is impossible to obtain an HTML source the browser is actually using, since the only displayed source is the downloaded XML. On the other hand, I rarely go look at HTML code on client side, and in most cases, it is unusable directly (whitespace being removed).
  • 1
    It doesn't matter what the raw HTML looks like. Tools like Firebug format it for you.
    – Jeremy
    Commented Dec 27, 2010 at 12:38
  • Do any browsers have XSLT 2.0 yet? Personally, I wouldn’t want to go back to XSLT 1. Commented Jan 4, 2014 at 12:39
  • @ChristopherCreutzig: I remember server-side XSLT 2.0 support being very limited (although I don't remember precisely whether the issue was with C#, Python, PHP, nginx ngx_http_xslt_module or all four). I highly doubt client-side support of XSLT 2.0 is better. Commented Jan 4, 2014 at 14:18
  • @MainMa What stops me from using, e.g., saxon on the server, completely ignoring whether my server is written in Ruby, PHP, Java, C#, or x86 assembly? The server is a place where I can freely mix code from all the languages and environments I want to – assuming I don’t have some crippled hosting solution where I cannot call external programs, of course. Commented Jan 5, 2014 at 9:50
  • 1
    @ChristopherCreutzig: I often worked in environments where one simply couldn't ask to system administrator to deploy whatever one wants to the server. This made Saxon practically impossible to use for me. Commented Jan 5, 2014 at 12:27

4 Answers 4


Browsers can't progressively render XSLT

This means that nothing else loads and nothing is displayed until all data and the whole stylesheet is loaded and processed.

You're missing out on progressive rendering and prefetching of images, CSS & JS.

Initial load is delayed by another request

For small-ish files (<20kb) number of requests, not bandwidth, is the bottleneck for front-end performance, and most pages and stylesheets will fall into this category.

If you have large pages, then it's even worse — see the first point.

You probably aren't saving any bandwidth

XSLT itself is quite verbose and might need to contain templates for the whole site and logic for all rare cases, not just the things used on the current page.

You still have to include all data marked up in the main XML file you're sending, e.g. if you're sending a blog post, then there's no magic that XSLT can do to make it substantially smaller. If you're sending complex data, then it'll have lots of markup anyway.

Caches are overrated

Browser caches are not that great:

40-60% of Yahoo!’s users have an empty cache experience and ~20% of all page views are done with an empty cache.

and on mobile, where latency makes extra requests most expensive, caches are even worse.

Check your bounce rate — those are users who don't benefit from cached XSLT, and even pay extra price to download the stylesheet and wait for it to be processed.

gzip is a reverse XSLT

Most transformations done via XSLT come down to changing terse markup to more verbose one and adding repetition. But gzip is great at removing repetition/redundancy from files!

You should be using gzip anyway (it's wasteful to send XML uncompressed). It's very likely that gzipped size of processed document will be about the same as gzipped size of unprocessed XML — but you won't have to send extra XSLT, and browsers will be able to start rendering as soon as first packets arrive.

Clients might be slow

Even assuming best case of loading from cache, XSLT processing on client-side is faster only if user's CPU is faster, and their XSLT engine is faster.

On server-side you can do all kinds of optimisation tricks (e.g., cache processed fragments or even whole pages). You can use latest, fastest XSLT processor (browsers have only XSLT 1.0 and likely not very optimized). And your server probably has beefier CPU than many cheap office computers, phones, etc.

  • Excellent Answer! I wish I could up-vote it multiple times.
    – Gaurav
    Commented Dec 27, 2010 at 13:36
  • 1
    +1 especially for gzip point
    – Nicole
    Commented Dec 27, 2010 at 15:28

There's no reason why doing this serverside should not scale as well as generating HTML directly. There's also not much reason for a big constant overhead in comparison to PHP. Appearently there are XSLT > JVM / CLR compilers and I suppose you could even translate it to native code.

However the idea of transporting data and presentation structure seperately is good as such.
It can save a lot of bandwidth and even server performance. But pomeL has mentioned a number of points.

For proper support accross browsers, xslt.js could help.

Personally, I am no fan of XML, so I would use JSON instead and a JS template engine, that will execute in the browser. Or some sort of template engine, that converts template markup into executable js on the server side, which is used for rendering on the client side.
JavaScript is reasonably fast and available virtually everywhere. JSON and JS are far more compact than XML and XSLT.

  • But you would need to develop "jsonlt" on your own to presetn properly your data or develop a client side just for the rendering, unlike XML/XSLT that already come with that.
    – Walfrat
    Commented Jun 8, 2018 at 12:21

Sending compact XML and having a cached XSLT on client may even save your bandwidth.

You leave out any browsers that don't support XSLT, like smartphones. But you should create a speialized version for these anyway.

  • 2
    There is no specialized version for the browsers that don't support XSLT (IE6, smartphone browsers, etc.). For those browsers, XSL transformation is done by the server, based on the same XSLT file, and the final HTML is sent instead. Commented Dec 27, 2010 at 12:43
  • 2
    MainMa: yes, but you usually apply a different XSL for smartphones, because screen size is quite different, you can't use :hover. etc.
    – 9000
    Commented Dec 27, 2010 at 13:14

The primary problem used to be that only a few browsers supported this well, so it was not worth the trouble essentially creating a new platform to support. Additionally older versions of IE did not support this well, and if I recall correctly at least one IE had a different XSLT dialect giving all sorts of fun problems.

  • 1
    If those few browsers are the ones used by a majority of users, it might be worth the trouble.
    – user281377
    Commented Dec 27, 2010 at 13:31
  • Plus, you have no control over what level of support the client systems offer for XSLT. If they're using some non-standard-compliant plug-in or something (I know, that almost never happens...), then your site won't work and it'll be almost impossible to support.
    – TMN
    Commented Dec 27, 2010 at 14:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.