【问题标题】:Auditing front end performance on web application审核 Web 应用程序的前端性能
【发布时间】:2012-11-05 16:39:28
【问题描述】:

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

我一直在使用 Y Slow 等性能审计工具!和谷歌浏览器的分析工具,用于尝试突出值得调查的区域。但是,这些工具是在考虑 Internet 的情况下编写的。例如,Google Chrome 审核应用程序的当前建议如下:

网络利用率

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

网页性能

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

考虑到连接速度和使用模式,这些建议是否完全多余?用户将在一天中频繁使用该应用程序,因此初始点击量是否很大(当他们第一次访问页面并构建缓存时)并不重要,只要在未来的页面视图上完成最少的工作即可.

例如,合并我们所有的 CSS 和 JavaScript 文件是否值得?它可能会加快初始页面查看速度,但它会对整个工作日的后续页面查看产生多大影响?

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

【问题讨论】:

  • @bwheeler96: 很好。这个网站不仅适合业余爱好者
  • 您需要说明:这是加载时间问题还是应用已加载后的性能问题?
  • Diodeus,这是加载时间问题。应用程序加载后,UI 运行良好。但是,加载可能需要几秒钟。某些页面当前需要 50 多个 GET 请求才能显示,即使在与服务器的快速连接上(甚至在本地运行服务器时)也需要一些时间来加载所有资源。我正在寻找一些关于在调查中值得优先考虑的事项。
  • @bwheeler96,虽然我理解您的观点,但有时业务需求意味着人们最终会在其领域知识领域之外工作。这就是我现在正在做的事情。在 Stack Overflow 上寻求建议,而不是浪费公司时间调整只会带来微不足道的性能提升的领域,这有什么问题?

标签: javascript html css performance


【解决方案1】:

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

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

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

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

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

Firebug 之类的工具可以帮助解决这个问题 - 查看网络正在发生的情况,以及是否有任何资产花费的时间比您预期的要长。使用 JavaScript 分析器查看您花费最多时间的地方。

【讨论】:

  • 谢谢,这真的很有帮助。如果 GZIP 压缩减少了并行下载的数量,在这种情况下会不会有好处?或者只有在带宽有限的情况下并行下载的数量才真正重要?
  • 并行下载通常有助于提高性能 - 如果您巧妙地构建它们。它们允许浏览器同时下载多个文件,并在下载时开始解析它们。如果您不受带宽限制,这意味着浏览器可以同时执行更多操作。 GZIP 压缩与此无关 - 它减少了单个资产的文件大小,因此可以更快地下载它们,但会消耗一些 CPU 和内存来管理客户端上的解压缩...
  • GZIP 压缩对于 Intranet 应用程序来说似乎是完全多余的。下载一个稍大的文件,然后缓存以供以后使用,这比在服务器上压缩它并在客户端解压缩它要痛苦得多。对于其他偶然发现这个 SO 问题的人,我也刚刚发现了这个stackoverflow.com/questions/2707499/…,这可能很有用。
【解决方案2】:

这些工具中的大多数都提供了一次性检查的步骤或建议。然而,它解决了一些问题,它并没有告诉您用户如何体验您的网站。 Always Real 用户监控是衡量实时用户性能的正确解决方案。您可以使用Navigation Timing API 来衡量页面加载时间和资源时间。

如果你想找服务,可以试试https://www.atatus.com/,它提供Real User Monitoring、Ajax Monitoring、Transaction Monitoring和JavaScript error tracking。

【讨论】:

    【解决方案3】:

    以下是可用于测试网站速度的其他服务列表: http://sixrevisions.com/tools/free-website-speed-testing/

    【讨论】:

    • 那些看起来非常面向 INTERnet 应用程序(而不是面向 INTRAnet 应用程序)
    • 谢谢。不幸的是,很多这些工具都需要一个可公开访问的 URL 才能运行。因为这是一个内部应用程序,所以不可能仅仅为了运行审计工具而设置一个面向公众的服务器。除了我在原帖中提到的之外,您对离线工具有什么推荐吗?
    猜你喜欢
    • 2013-05-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-09-26
    • 2011-05-06
    相关资源
    最近更新 更多