ribbon image search rewind fast-forward speech-bubble pie-graph star

Web前端优化的关键词

忽然发现很多人都喜欢用这个问题来问,其实这个问题和 “输入url到网页出现发生了什么”类似,详见知乎上的讨论, 很多人都能回答上来,但是这个问题所能涉及到的知识点却非常多。

那么其实如果我们能够理解输入url都经历了什么,那么我们要做的优化点就是针对这个过程中的每个环节,虽然有些方面并不算前端范畴,但是也需要有所了解。

这个问题有人都已经回到到硬件,用户网络层面这里就忽略吧,我们直接从url解析开始;

DNS查找

输入url会先经理一系列事情,前端不用负责这一块,都是浏览器自己做的,url会先找到对应的ip,如果有DNS缓存就快很多,如果没有呢,就不得不去搜索域名直到找到你的要去的域名。

服务器接受请求

服务器接收到数据请求的时候就需要响应并吐出数据。如果是一个静态页面,它就吐出写好的html代码,如果是服务端语言处理过,那部分还需要服务端工程师参与。所以呢,这个时候你有理由去质疑下是不是服务端工程师那边程序是不是出了问题。不过这个解决的事情也不是我们能够做的咯。

浏览器接受到html内容后

接下来,就是我们的事情咯。自己觉得优化一个字一定不会错(错这个字是相对的,),“变小”。都知道吐出一个400kb的页面和10KB的页面,明显后者快,(在相同物理环境下)。所以变小的过程我们就可以大作文章。

优化其实来源支撑原有体系的每个细节

一个关键字,小。那么一个页面,我们自己写的自然就心里有数。JS + CSS + HTML。如果我们发觉我们把JS CSS都推挤在了html上,html上自然体积就大了。这个时候我们尝试用外链,这样html就会小很多。如果我们再把CSS 和 JS压缩下,是不是请求这些资源的时候又小了很多啊。 这个时候如果我们可以开启GZIP那么,是不是输出内容又压缩不少呢?然后外链的资源,类似图片音频这些,如果在不损害原有设计形象的时候,将资源变小是不是又算优化的一部。尤其图片,我们可以做到响应式更好,在手机上和电脑上响应的去请求不同大小的图片也算是一种提高。再小的话就得看我们的代码本领了,对于html结构,css的写法,JS的实现,可能这个就是看水平高低和经验了,但是至少心里要明白,如果别人可以通过五行实现的我们用了十行,说明还有可以学习或者借鉴的地方。

另一个关键字,少。如果服务器面对高并发的时候就会阻塞,这样有的外链资源就会挂起不响应。这个时候我们就可以努力降低本域名资源请求数目,将一些外链资源放到别的服务器上,比如上到CDN的服务商去。这样他们可以提供高性能的内容访问和缓存控制,也提高我们服务器的可访问性。如果我们适当的将一些小文件的JS或者CSS合并下,是不是又可以减少请求的文件数目了吧。有的时候一个请求,可能请求的内容数据很小,但是相对而言header会占用一定数据量,其实这是一种宽带的浪费。接下来,关于少的事情,我们可以做的更好,比如图片,将小图片进行合并,也就是我们常说的CSS Sprite 。然后我们延迟渲染视角之外的图片,进行惰性加载或者图片预置 。除了可视窗口之外的图片,包括数据也可以进行依赖加载,当用户需要看到的时候再进行渲染出来。

最后一个关键词 缓存 缓存很重要,不敢想象当用户什么时候设置了disable cache这个选项后,我们所面临的困难。无论是静态的html页面还是请求的外部资源,尽可能的设置缓存。这也是CDN网络重要的原因之一,我们可以更好的控制某些资源内容的缓存和更新,而我们的主程序无需去做这些事情。

其实还有很多小细节可以优化,但是我觉得上面所提及的内容,都是来源于我们在起初创建我们的项目每个环节,所以个人的经验也觉得遇到问题,回归到原来的地方,可能思路一下就开阔了。

更多细节

扩展阅读

You Can Speak "Hi" to Me in Those Ways