javascript - 审计 Web 应用程序的前端性能

Question

我目前正在尝试对公司 Web 应用程序的 UI 进行性能调整。该应用程序只会被员工访问，因此服务器和客户端之间的连接速度将始终比在互联网上快得多。

我一直在使用 Y Slow 等性能审计工具!和谷歌浏览器的分析工具，尝试突出显示值得调查的目标区域。然而，这些工具是为互联网编写的。例如，当前 Google Chrome 对应用程序的审核建议如下:

网络利用率

• 合并外部 CSS(红色警告)
• 结合外部 JavaScript(红色警告)
• 启用 gzip 压缩(红色警告)
• 利用浏览器缓存(红色警告)
• 利用代理缓存(琥珀色警告)
• 最小化 cookie 大小(琥珀色警告)
• 跨主机名并行下载(琥珀色警告)
• 从无 cookie 域提供静态内容(琥珀色警告)

网页性能

• 删除未使用的 CSS 规则(琥珀色警告)
• 使用普通的 CSS 属性名称而不是 vendor 前缀的名称(琥珀色警告)

考虑到连接速度和使用模式，这些建议是否完全多余？用户将在一整天内频繁使用该应用程序，因此初始点击量是否很大(当他们首次访问页面并构建缓存时)并不重要，只要对 future 的页面 View 进行最少的工作即可.

例如，合并我们所有的 CSS 和 JavaScript 文件是否值得？它可能会加快初始页面浏览速度，但它对整个工作日的后续页面浏览量到底有多大影响？

我已经尝试搜索此内容，但我一直想出的只是面向标准互联网的性能建议。非常感谢任何关于在这种情况下我的性能调整工作的重点或其他审计工具建议的建议。

Answer 1

一种尺寸并不适合所有这些东西；立即跳出的将产生重大影响的元素是“利用浏览器缓存”。显然，这减少了带宽使用，但也告诉浏览器它不需要重新解析您缓存的任何内容。即使你有足够的带宽，你下载的每个文件都需要来自浏览器的资源——一个线程来管理下载、文件解析、管理内存等。减少这将使应用程序感觉更快。

GZIP 压缩可能是多余的，如果您确实拥有无限带宽，甚至可能有害 - 它会消耗服务器和客户端上的资源来压缩数据。不多，而且我从未能够测量 - 但理论上它可能会有所作为。

代理缓存也可能有所帮助 - 取决于您公司的网络基础设施。

减小 cookie 大小可能会有所帮助 - 不仅仅是因为带宽问题，而且管理 cookie 会再次消耗客户端资源；这也解释了为什么从无 cookie 域提供静态 Assets 会有所帮助。

但是，如果您要优化 UI 的性能，您确实需要了解速度变慢的地方。 Y!Slow 和 Chrome 专注于常见问题，其中许多与带宽和浏览器的行为有关。他们不知道 JS 的某个特定部分是否很慢，或者服务器是否正在为特定的动态页面请求而苦苦挣扎。

Firebug 之类的工具对此有帮助 - 查看网络发生的情况，以及是否有任何 Assets 花费的时间比您预期的要长。使用 JavaScript 分析器查看您花费最多时间的地方。