简单聊聊网页的资源加载优化

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

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

1、查看网页加载速度

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

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

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

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

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

重定向 - 应用程序缓存 - 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（下载时间）:资源下载的时间。

3、诊断缘由与解决方案

经过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