我目前正在尝试调整公司Web应用程序的UI。该应用程序只能由工作人员访问，因此服务器和客户端之间的连接速度将始终远远高于互联网上的连接速度。
我一直在使用绩效审核工具，例如Y Slow！和Google Chrome的分析工具，可以尝试突出显示值得调查的区域。但是，这些工具是在考虑互联网的情况下编写的。例如，谷歌Chrome浏览器对该应用程序的审核建议如下：
网络利用率
网页效果
鉴于连接速度和使用模式，这些建议中的任何一个都是完全冗余的吗？用户将在一天中频繁使用该应用程序，因此无论初始命中是否很大（当他们第一次访问页面并构建其缓存时），只要在将来的页面查看中完成最少量的工作就没关系
例如，是否值得合并我们所有的CSS和JavaScript文件？它可能会加快初始页面视图的速度，但在整个工作日的后续页面浏览量中它会产生多大的差异？
我已经尝试过搜索这个，但我不断提出的是标准的面向互联网的性能建议。关于在本场景中如何关注我的绩效调整工作或其他审计工具建议的任何建议都将不胜感激。
答案 0 :(得分：3)
一种尺寸不适合这些东西;立即跳出作为具有重大影响的项目是“利用浏览器缓存”。这显然减少了带宽使用，但也告诉浏览器它不需要重新解析你缓存的任何内容。即使您有足够的带宽，您下载的每个文件都需要来自浏览器的资源 - 管理下载，解析文件，管理内存等的线程。减少这些将使应用感觉更快。
GZIP压缩可能是多余的，如果你确实拥有无限带宽，它甚至可能有害 - 它会消耗服务器和客户端上的资源来压缩数据。并不多，我从来没有能够衡量 - 但理论上它可能会有所作为。
代理缓存也可能有所帮助 - 具体取决于您公司的网络基础架构。
减少cookie大小可能有所帮助 - 不仅仅是因为带宽问题，而且再次管理cookie会消耗客户端上的资源;这也解释了为什么从无cookie域提供静态资产有帮助。
但是，如果您要优化UI的性能，您真的需要了解减速的位置。 Y！慢和Chrome专注于常见问题，其中许多问题与带宽和浏览器的行为有关。他们不知道JS的某个特定部分是否很慢，或者服务器是否正在努力处理特定的动态页面请求。
像Firebug这样的工具有助于此 - 查看网络发生的情况，以及任何资产是否需要比预期更长的时间。使用JavaScript分析器查看您花费最多时间的位置。
答案 1 :(得分：1)
这些工具中的大多数都提供一次性检查的步骤或建议。但是，它解决了一些问题，但它没有告诉您用户如何体验您的网站。始终真实的用户监控是衡量实时用户表现的正确解决方案。您可以使用Navigation Timing API来衡量页面加载时间和资源计时。
如果您想查找服务，可以尝试https://www.atatus.com/，它提供真实用户监控，Ajax监控，事务监控和JavaScript错误跟踪。
答案 2 :(得分：0)
以下是可用于测试网站速度的其他服务列表： http://sixrevisions.com/tools/free-website-speed-testing/