将XML发送到浏览器并让它们应用XSLT有什么缺点？

语境

作为自由开发人员，我经常使网站完全基于XSLT。换句话说，在每次请求时，都会生成一个XML文件，其中包含我们需要了解的有关页面内容的所有信息：当前登录的用户名，顶部菜单项（如果此菜单是动态/可配置的），文本显示在页面的特定区域等。然后XSL将其处理（缓存等）到HTML / XHTML页面以发送到浏览器。

这样做的好处是可以简化创建小型网站的工作，尤其是使用PHP。它是一种模板引擎，但是我比其他模板引擎更喜欢它，因为它比大多数模板引擎要强大得多，并且因为我对此更加了解并且喜欢它。如果需要，还可以根据需要提供对原始XML数据的访问权，以进行自动访问，而无需创建单独的API。

当然，它将在任何中型或大型网站上完全失败，因为即使使用良好的缓存技术，XSL仍会降低网站的整体性能，并需要更多的CPU服务器端。

题

现代浏览器具有获取XML文件并用XML声明的关联XSL文件（如）转换的能力<?xml-stylesheet href="demo.xslt" type="text/xsl"?>。Firefox 3可以做到。Internet Explorer 8也可以做到。

这意味着可以将50％的用户的XSL处理从服务器迁移到客户端（根据我可能要实现此目的的多个网站上的浏览器统计信息）。这意味着，这50％的用户在每次请求时将仅接收XML文件，从而减少了其和服务器的带宽（XML文件比其处理的HTML模拟物短得多），并减少了服务器的CPU使用率。

这种技术的缺点是什么？

我考虑了几个，但不适用于这种情况：

• 实施困难，并且需要根据浏览器请求选择何时发送原始XML，以及何时将其转换为HTML。显然，该系统不会比实际系统困难得多。唯一要做的更改是将XSL文件链接添加到每个XML，并添加浏览器检查。
• IO和带宽使用更多，因为XSLT文件将由浏览器下载，而不是由服务器缓存。我认为这不会有问题，因为XSLT文件将由浏览器缓存（例如图像，CSS或JavaScript文件实际上已缓存）。
• 可能是客户端方面的一些问题，例如在某些浏览器中保存页面时可能出现的问题。
• 难以调试代码：不可能获得浏览器实际使用的HTML源，因为唯一显示的源是下载的XML。另一方面，我很少去看客户端的HTML代码，在大多数情况下，它是直接不可用的（已删除空格）。

浏览器无法逐步呈现XSLT

这意味着在加载并处理所有数据以及整个样式表之前，不会加载任何东西，也不会显示任何东西。

您缺少图像，CSS和JS的渐进式渲染和预取功能。

初始加载因另一个请求而延迟

对于小文件（<20kb），请求数量而不是带宽是瓶颈前端性能，大多数页面和样式表都属于此类。

如果页面很大，那就更糟了–请参阅第一点。

您可能没有节省任何带宽

XSLT本身很冗长，可能需要包含整个站点的模板和所有罕见情况的逻辑，而不仅仅是当前页面上使用的东西。

您仍然必须将所有标记的数据都包含在要发送的主XML文件中，例如，如果要发送博客文章，那么XSLT可以做得大大减小了它的魔力。如果您要发送复杂的数据，那么无论如何它都会有很多标记。

缓存被高估了

浏览器缓存不是很好：

Yahoo!的用户中有40-60％的用户拥有空的缓存体验，而所有页面浏览量的约20％是由空的缓存完成的。

在移动设备上，延迟使额外的请求变得最昂贵，而缓存则更糟。

检查您的跳出率-那些没有从缓存的XSLT中受益的用户，甚至还需要支付额外的费用来下载样式表并等待其处理。

gzip 是反向XSLT

通过XSLT进行的大多数转换都归结为将简洁的标记更改为更详细的标记并添加重复。但是gzip非常适合删除文件中的重复/冗余！

无论如何，您都应该使用gzip（发送未压缩的XML很浪费）。压缩后的文档的大小很有可能与未处理的XML的大小大致相同，但是您不必发送额外的XSLT，并且浏览器将能够在第一个数据包到达时立即开始呈现。

客户可能很慢

即使假设是从缓存中加载的最佳情况，也只有在用户的CPU速度更快并且其XSLT引擎速度更快时，客户端的XSLT处理才会更快。

在服务器端，您可以执行各种优化技巧（例如，缓存处理后的片段甚至整个页面）。您可以使用最新，最快的XSLT处理器（浏览器仅具有XSLT 1.0，并且可能没有非常优化）。与许多廉价办公计算机，电话等相比，您的服务器可能具有更强大的CPU。

没有理由为什么不应该像在服务器端那样直接扩展以及生成HTML。与PHP相比，也没有太多的理由需要持续不断的开销。显然有XSLT> JVM / CLR编译器，我想您甚至可以将其转换为本地代码。

但是，分别传输数据和表示结构的想法本身是不错的。
它可以节省大量带宽，甚至可以节省服务器性能。但是pomeL提到了许多要点。

为了获得浏览器的适当支持，xslt.js可能会有所帮助。

就个人而言，我不喜欢XML，所以我会改用JSON和JS模板引擎，这些引擎将在浏览器中执行。或某种模板引擎，它将模板标记转换为服务器端的可执行js，用于在客户端渲染。
JavaScript是相当快的，几乎可以在任何地方使用。JSON和JS比XML和XSLT更紧凑。

发送紧凑的XML并在客户端上缓存XSLT甚至可以节省带宽。

您省去了所有不支持XSLT的浏览器，例如智能手机。但是无论如何，您都应该为这些创建专用版本。

以前的主要问题是只有很少的浏览器很好地支持了这一点，因此从根本上创建一个新的支持平台并不麻烦。另外，较旧版本的IE并不能很好地支持这一功能，如果我没记错的话，至少一个IE使用另一种XSLT语言，会带来各种有趣的问题。