Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

首屏慢在哪儿?

  Web 页面的首屏加载速度是一个关键的性能指标,也是最难优化的一个部分。比起内页切换,首屏总是要慢得多。因为首屏没有任何缓存可以用,所有东西都必须从服务器上加载。虽然我们可以对程序做优化,对架构做调整,但好像无论怎么做,首屏依然很慢。
  我以前一直无视 DNS 解析的速度,觉得它应该是很快的。后来换了几个奇怪的 DNS 服务器之后才体会到 DNS 服务器的慢。比如 8.8.8.8 就会慢城狗,偶尔还会被墙。首屏加载几乎没法做 DNS 解析优化,只有在首屏以后我们才可以对其它域名做一些预解析、缓存等操作。当然,如果页面是从自家的 App 中打开的话,DNS 解析是可以在 App 做一次预解析的。
  DNS 解析之后就是请求页面服务器。如果服务器的延迟很高那就呵呵了。光是建立 TCP 连接大概就需要三倍延迟的耗时,如果使用 https 的话七倍延迟的耗时就更是慢成狗。对于前后端分离的单页应用而言,入口页面文件大小是很容易优化的,这里就不考虑了。页面文件的加载主要耗在连接上,这部分也是几乎没法优化的。
  加载页面以后还要加载页面上的 js/css。虽然我们会使用 keep-alive 来共用连接,但对这些资源的请求未必会和入口页面的请求共用连接。html 文件是流,它是传输过程解析的。也就是说对 js/css 文件的请求是在入口页面文件的传输过程中发起的,在 http 1.1 上没法与之共用。于是这里还有建立新的连接,这又会耗费大堆时间。而且如果 js/css 的资源是放在独立域名的 CDN 上,此处还需要一个 DNS 解析。另外,比起 html 页面,js/css 要大得多,此处还需要考虑传输的耗时。
  资源请求完成后浏览器执行 js。这个步骤可能也会耗时,特别是在一些前端框架中。但在前端程序的方面是很容易优化的,所以这里也不考虑它。接着前端程序主动向服务器请求数据,这时候确实可能有闲置的连接了,如果请求的是与页面相同的域名就不用重新建立连接了。这一步得看后端对 API 的优化做得如何。如果命中后端缓存就可以很快获取到内容,否则要查数据库的话可能也会慢成狗。总之无论这一步有多快,它至少都是一次网络通信的耗时。
  那么首屏加载到底慢在哪儿呢?哪儿都慢啊!对于前后端分离的项目,就算程序已经优化到极致,使用 https 把一个页面加载出来理论上至少需要十八倍网络延迟的耗时。于是呢?提高服务器网络质量才是关键。或者有些特殊请求也可以考虑抛弃前后端分离,直接从后端渲染。又或者,我们可以偷天换日地绕过首屏。比如让自家的 App 内置一份 Web 页面来避免从服务器加载首屏。
网名:
3.80.55.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^