这篇博客文章起源于一个大型Web应用程序中的性能问题。 每个人都优化Java代码,但似乎没有人尝试优化JavaScript代码。 奇怪,因为在客户端有很多改进的空间。 我会说,甚至比服务器端还要多。 我们将分析可编辑的JSF标准组件(有时称为“旧版”)以及具有丰富JavaScript小部件的现代PrimeFaces组件的性能。 这是中立的分析,不能怪任何图书馆或任何人。 只有事实。
好。 我们要测试什么? 目标是测量PrimeFaces的JS脚本块执行的客户端性能(无后端逻辑)
p:inputText / p:selectOneMenu。 我们想用输入/测试一个可编辑的p:dataTable 选择表单元格中的组件。 该表有25行和16列,表示25 * 16 = 400个单元格。 每个单元格都包含输入或选择组件。 有6个测试用例。 标准的h:inputText和h:selectOneMenu没有JS脚本块,因此有趣的是看看JS小部件有什么影响。
整个测试项目可在GitHub上找到 。 简单克隆或下载它,然后使用内置的Maven Jetty插件运行。 使用新的Navigation Timing JavaScript API测量页面加载速度,以准确地测量Web上的性能。 该API提供了一种获取准确而详细的时序统计信息的简单方法。 比使用JS Date对象更精确。 导航定时JavaScript API在Internet Explorer 9和更高版本(最新版本的Google Chrome和Firefox)中可用。 在GitHub上显示了用于测量从当前响应到达到触发窗口onload事件为止的时间的代码。
JavaScript是单线程的,因此让我们看看顺序脚本块的执行如何会减慢显示网页的速度。 如果我们只测试
h:inputText和p:inputText,区别是微不足道的。 页面加载时间几乎相同。 在Windows 7和Firefox 20.0.1上运行,我只能看到带有p:inputText的表需要ca。 比使用h:inputText的表多200-300 ms。 这是一个很好的结果,这意味着一个p:inputText的JS脚本执行时间不到1毫秒。 真的很好 祝贺PrimeFaces。 使用输入和选择进行的混合测试显示,带有PrimeFaces组件的页面大约需要1.5 sek。 不只是包含标准组件的页面。 添加更多PrimeFaces选择组件会降低页面渲染时间。 极端的情况是只有p:selectOneMenu组件。 这是性能杀手,也是我们的Web应用程序太慢的原因。 Internet Explorer显示众所周知的错误消息“此页面上的脚本导致Internet Explorer运行缓慢”。 看一下页面加载时间本身。
h:selectOneMenu
p:selectOneMenu
如果我们假设组件渲染器花费大约相同的时间来渲染HTML输出,那么我们可以计算单个p:selectOneMenu的JS脚本块执行时间。 这个时间是11.3毫秒。 这太多了。 原因可能是窗口小部件的构造函数中有许多效率低下的jQuery选择器。 我不知道,在这里也没关系。 在装有Ubuntu的笔记本上,我的时差很大。 10瑞典克朗。 具有400个p:selectOneMenu标签的浏览器几乎“冻结”。
h:selectOneMenu
p:selectOneMenu
结论
有人说“ JSF很慢,JSF不是正确的技术”。 错误。 JSF足够快。 这取决于如何使用此框架。 一次编辑所有内容都很好,但是显然不建议使用带有丰富JSF组件的大型可编辑DataTable。 什么是可编辑DataTable的替代方案? 有多种方法,具体取决于个人喜好。 我将尝试提出一些建议。
- 在大型可编辑表中使用标准JSF选择组件。 但是主题是什么? 没问题。 所有现代浏览器(包括IE8和更高版本)都可以设置本机HTML选择元素的样式。 您可以调整边框,背景的颜色,并根据应用的主题让选择看起来或多或少地显得时尚。 当然前提是前提是,您不需要高级功能,例如选定组件中的自定义内容(过滤器功能或其他功能)。
- PrimeFaces中的单元格编辑功能可呈现本机选择元素,并且速度很快。
- PrimeFaces中的行编辑功能可呈现本机选择元素,而且看起来也很快。
- 在一个视图中使用主从方法。 您选择一行并查看要编辑的详细信息。 详细信息可以显示在表格的外部–在右侧或顶部,具体取决于表格的宽度/高度。
- 具有不同视图的主从方法。 您选择一行并切换视图。 您可以在PrimeFaces Extensions的MasterDetail组件中看到详细信息,而不是表格。 您可以从详细信息转到其他级别来创建/编辑更多详细信息,然后最后再次跳至概览表。
翻译自: https://www.javacodegeeks.com/2013/05/jsf-choice-between-legacy-components-and-fashionable-performance-killers.html