简单聊聊网页的资源加载优化_html/css_WEB-ITnose

移动开发中很重要的一块是资源的加载优化。移动开发由于网速低带宽，高延迟，移动设备小内存，低处理器性能的原因，因此很多时候不得不通过优化前端页面的性能来满足用户对网页加载的预期。

前段时间做了相关方面的优化，发现网上的中文教程比较少，都是照着chrome开发者网站上一步一步看下来，找问题来解决，因此将部分有用的网页整理翻译了一下。

一、查看网页加载速度

网页加载时长受到网速影响，一般采用浏览器模拟一个特定网速进行测试，这样优化前与优化后的结果会有一个较准确的对比。

方法：打开调试面板—选择网速，一般我们移动测试用的是regular 3g.然后刷新页面，开始查看页面加载时间。

资源加载顺序与耗时就会依次显示出来，红线表示DOM加载的时间。

二、资源加载的顺序与说明

资源请求的生命周期如下：

重定向 - 应用程序缓存 - DNS - TCP - 请求 - 响应

对于某一个资源，点击资源加载进度条可以看到具体每一阶段的加载时间。或者可以在console面板中，通过timing api获取。

performance.getEntriesByType('resource').filter(item => item.name.includes("style.css"))

具体解释如下：

• Queueing（排队）：浏览器有连接限制，当网页资源很多时就会出现排队的现象，排队的资源要等到上一个资源加载完毕释放后才能开始请求。比关键资源（如javascript与css）低优先级的请求会被浏览器推迟，一般推迟的都是图片。在许多资源同时发起请求时浏览器默认先加载css,然后javascript，最后才是图片。

• Stalled(阻塞)：请求在发送前的时间被成为阻塞。阻塞的原因有很多种，导致排队的原因或是Proxy Negotiation都能造成阻塞。

• DNS Lookup（DNS查询）：DNS查找的时间，网页资源中请求每一个新域都需要做一次完整的DNS查询。

• Initial Connection（初次连接）：初次建立连接需要花费的时间。

• Request Sent(请求发送时间)：网络请求发送的时间。

• Waiting(TFFB)(等待时间)：等待服务器初始响应的时间。

• Content Downloading（下载时间）:资源下载的时间。

三、诊断原因与解决方案

通过chrome网络面板调试，经常会看到每次加载的时间都不太相同，造成加载慢会有许多原因。前端需要优化，但很多时候是后台或者网络的问题。

1. 排队问题

最长见的问题就是资源排队问题。在HTTP1.0/1.1连接中，chrome最多允许对同一host一次有6个连接，如果网页种有12个资源，那后面的6个就需要排队，直到前面的下载完毕，才能按次序发起请求。解决这个问题，首先要减少网页的请求，例如css sprite、js/css压缩、采用缓存、按需加载等等。

还有一种方法，将资源放在不同的子域名下，比如将图片资源与静态资源分开可以大大加速网页加载时间，但这个方法对HTTP2的连接不适用。

2. TFFB时间慢

TFFB时间通常建议在200ms以下，如果超过推荐值，会引起队列中其他资源下载都跟着变慢。TFFB高主要有两个原因：一是客户端和服务器之前网络情况比较差；二是服务器应用响应比较慢。首先排除网络因素，在本地环境看一下是否仍旧存在TFFB情况，如果有，需要优化应用程序的响应时间，例如优化数据库查询、实现资源缓、修改web服务器配置等等。如果是由于网络引起的，那服务器与客户端的每一个节点都有可能引起这个问题，最简单的方法是把应用迁移至其他服务器看看是不是存在这个问题，然后一个节点一个节点查明原因。

3. 下载时间过久

如果大量的时间花在下载上，那提高服务器响应也没用，还是应该将文件进行压缩。

最后

前端优化路漫漫，敌人是毫秒，却需要十八般武艺才能攻克。且行且思考吧。

参考资料： https://developers.google.com/web/tools/chrome-devtools/profile/network-performance/understanding-resource-timing#diagnosing-network-issues