首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Web前端性能优化教程03:网站样式和脚本&减少DNS查找、避免重定向

Web前端性能优化教程03:网站样式和脚本&减少DNS查找、避免重定向

作者头像
逸鹏
发布2018-04-11 11:53:54
3.1K0
发布2018-04-11 11:53:54
举报
文章被收录于专栏:逸鹏说道逸鹏说道

一、将样式表放在顶部

可视性回馈的重要性

进度指示器有三个主要优势——它们让用户知道系统没有崩溃,只是正在为他或她解决问题;它们指出了用户大概还需要等多久,以便用户能够在漫长的等待中做些其他事情;最后,它们能给用户提供一些可以看的东西,使得等待不再是那么无聊。最后一点优势不可低估,这也是为什么推荐使用图形进度条而不是仅仅以数字形式显示预期的剩余时间。在Web的世界里,Html页面的逐步呈现就是很好的进度指示器。

将没有立即使用的css放在底部是错误的做法

通常组件的下载是按照文档中出现的顺序下载的,所以将不需要立即使用到的组件css(比如需要用户点击登录弹出框需要用到的样式)放在底部,可以得到一个加载很快的页面。然而这个推论其实是错误的,IE8以下(包括IE8)的工作方式是如果css表仍在加载,构建呈现树就是一种浪费,因为在所有样式表加载并解析完毕之前无需绘制任何东西,这时整个浏览器显示都是空白,直到css加载完毕,这就失去了提供可视化回馈的机会,让用户感觉到缓慢。

不过,更高级版本的IE和其他浏览器已经克服了“白屏”问题,所以这种情况已经不复存在。

无样式内容的闪烁

这里将讨论另外一种出现的情况,当我们将css放在底部,页面可以正常逐步呈现,但在css下载并解析完毕之后,已经呈现的文字和图片就要用新的样式重绘了,这就是“无样式内容的闪烁”,这将是一种不好的用户体验。

CSS的最佳摆放位置

使用LINK标签将样式表放在文档HEAD中。

二、将脚本放在底部

并行下载

浏览器下载组件的时候并不是每次只下载一个组件,而是实现了并行下载的机制。HTTP规范1.1建议浏览器从每个主机名并行地下载两个组件。既假如页面的所有组件都来自于一个主机名,则每次只能同时下载两个组件。如果组件使用了两个主机名,而且组件的主机名分配均匀,则每次并行下载的数量变成了2*2=4。不过,当代的浏览器普遍实现都超过了2个并行下载,不同的浏览器设置都有所不同。

脚本阻塞下载

并行下载组件能加快页面的加载速度,然而,在下载脚本的时候并行下载实际上是被禁用的,即使其他组件使用了不同的主机名,浏览器也不会启动其他的下载。原因如下:1. 脚本可能使用了document.write来修改页面内容,因此浏览器会等待,以确保能够恰当地布局;2. 为了保证脚本能够按照正确的顺序执行,如果并行下载多个组件,就无法保证响应是按照特定顺序到达浏览器的。

所以,脚本放在越靠近顶部的地方将越延迟用户的可视化反馈,这不是一种良好的用户体验,会让用户感觉到缓慢。

最佳做法

放置脚本的最好地方是页面的底部,这不会阻止页面内容的呈现,而且页面的可视化组件可以尽早下载。以博客园为例,博客园就把google流量分析的js放在底部,同时把下载Blog新闻和Blog侧边栏的js执行函数放在了底部。

三、使用外部javascript和css

基础知识

页面浏览量(PV):用户对页面请求访问次数总和。

内联 VS 外置

对于两个相同大小的页面,一个使用了内联,只有html需要下载,一个使用了外置,包括一个js和一个css,在用户不带缓存访问页面的时候,内联所有的js和css的效率更快,原因是外置js和css带来额外的http请求开销,1个http请求相对于3个http请求要更快一些。尽管如此,现实中还是使用外部文件会产生较快的访问速度,这是由于外部js和css有机会被浏览器缓存起来,当再次请求相同的js或css的时候,浏览器将不会发出http请求,而是使用缓存的组件,减少了总体需要下载文件的大小。

综合来讲,我们一般推荐使用外置的js和css,不过这也要根据自身web的访问场景以及PV做出最优选择。

如何划分组件?

当我们决定使用外置js和css的时候,这时怎样划分js和css并打包到外部文件中成为一个首要考虑的问题。在典型情况下,页面之间的js和css的重用既不可能100%重叠,也不可能100%无关。

一种极端的做法是创建一个单独的,联合了所有js的文件,再创建一个包含了所有css的文件。这只要求用户生成一个Http请求,但它增加了用户不带缓存访问的情况下的数据量,同时我们必须清楚:缓存有时会失效,这将带来更多额外的开销。而且,在任何一块独立的js或css改变后,都需要更新文件,并发布新的版本号,这将使所有客户端的旧版本缓存失效。

另一种极端的做法是为每个页面提供一组分离的外部文件,这种方式真正做到按需下载,但缺点在于每个页面都产生令响应时间变慢的HTTP请求。

对于大多数web应用来说,我们需要一种折中的方案!将页面划分为几种页面类型,然后为每种类型创建单独的js和css。以css为例,我们可以创建一个所有页面都通用的global.css,再针对不同类型的页面,创建对应的css。

一、减少DNS查找

基础知识

DNS(Domain Name System): 负责将域名URL转化为服务器主机IP。

DNS查找流程:首先查看浏览器缓存是否存在,不存在则访问本机DNS缓存,再不存在则访问本地DNS服务器。所以DNS也是开销,通常浏览器查找一个给定URL的IP地址要花费20-120ms,在DNS查找完成前,浏览器不能从host那里下载任何东西。

TTL(Time To Live):表示查找返回的DNS记录包含的一个存活时间,过期则这个DNS记录将被抛弃。

影响DNS缓存的因素

1. 服务器可以设置TTL值表示DNS记录的存活时间。本机DNS缓存将根据这个TTL值判断DNS记录什么时候被抛弃,这个TTL值一般都不会设置很大,主要是考虑到快速故障转移的问题。

2. 浏览器DNS缓存也有自己的过期时间,这个时间是独立于本机DNS缓存的,相对也比较短,例如chrome只有1分钟左右。

3. 浏览器DNS记录的数量也有限制,如果短时间内访问了大量不同域名的网站,则较早的DNS记录将被抛弃,必须重新查找。不过即使浏览器丢弃了DNS记录,操作系统的DNS缓存也有很大机率保留着该记录,这样可以避免通过网络查询而带来的延迟。

最佳实践

当客户端的DNS缓存为空时,DNS查找的数量与Web页面中唯一主机名的数量相等。所以减少唯一主机名的数量就可以减少DNS查找的数量。

然而减少唯一主机名的数量会潜在地减少页面中并行下载的数量,避免DNS查找降低了响应时间,但减少并行下载可能会增加响应时间。当页面的组件量比较多的时候,可以考虑将组件分别放到至少2-4个主机名,已获得最大收益。

延伸阅读:

  • CloudXNS免费DNS服务:线路细分 宕机监控等
  • http://www.chinaz.com/web/2015/0318/390930.shtml
  • 减少域名DNS解析时间将网页加载速度提升新层次
  • http://www.chinaz.com/web/2015/0316/390234.shtml
  • 盘点十大免费DNS域名解析服务:稳定、可靠
  • http://www.chinaz.com/web/2015/0122/380042.shtml
  • 国内免费DNS服务使用评测:360DNS、ZnDNS等
  • http://www.chinaz.com/web/2015/0122/380039.shtml

二、避免重定向

什么是重定向?

重定向用于将用户从一个URL重新路由到另一个URL。

常用重定向的类型

301:永久重定向,主要用于当网站的域名发生变更之后,告诉搜索引擎域名已经变更了,应该把旧域名的的数据和链接数转移到新域名下,从而不会让网站的排名因域名变更而受到影响。

302:临时重定向,主要实现post请求后告知浏览器转移到新的URL。

304:Not Modified,主要用于当浏览器在其缓存中保留了组件的一个副本,同时组件已经过期了,这是浏览器就会生成一个条件GET请求,如果服务器的组件并没有修改过,则会返回304状态码,同时不携带主体,告知浏览器可以重用这个副本,减少响应大小。

重定向如何损伤性能?

当页面发生了重定向,就会延迟整个HTML文档的传输。在HTML文档到达之前,页面中不会呈现任何东西,也没有任何组件会被下载。

来看一个实际例子:对于ASP.NET webform开发来说,对于新手很容易犯一个错误,就是把页面的连接写成服务器控件后台代码里,例如用一个Button控件,在它的后台click事件中写上:Response.Redirect("");然而这个Button的作用只是转移URL,这是非常低效的做法,因为点击Button后,先发送一个Post请求给服务器,服务器处理Response.Redirect("")后就发送一个302响应给浏览器,浏览器再根据响应的URL发送GET请求。正确的做法应该是在html页面直接使用a标签做链接,这样就避免了多余的post和重定向。

重定向的应用场景

1. 跟踪内部流量

当拥有一个门户主页的时候,同时想对用户离开主页后的流量进行跟踪,这时可以使用重定向。以yahoo.com为例,主页新闻的链接主机名是http://hsrd.yahoo.com/,后面跟着识别的参数,点击后再产生一个301重定向,这样就记录了离开门户主页后的流量去向。  

我们知道重定向是如何损伤性能的,为了实现更好的效率,可以使用Referer日志来跟踪内部流量去向。每个HTTP请求都有一个Referer表示原始请求页(除了从书签打开或直接键入URL等操作),记录下每个请求的Referer,就避免了向用户发送重定向,从而改善了响应时间。

2. 跟踪出站流量

有时链接可能将用户带离你的网站,在这种情况下,使用Referer就不太现实了。

同样也可以使用重定向来解决跟踪出站流量问题。以百度搜索为例,百度通过将每个链接包装到一个302重定向来解决跟踪的问题,例如搜索关键字“跟踪出站流量”,搜索结果的第一个URL为http://www.baidu.com/link?url=后面跟着一连串字符,即使搜索结果并没有变,但这个字符串是动态改变的,我认为这里的搜索连接URL好像没有改变的需要,不知道这里起到怎样的作用?

除了重定向外,我们还可以选择使用信标(beacon)——一个HTTP请求,其URL中包含有跟踪信息。跟踪信息可以从信标Web服务器的访问日记中提取出来,信标通常是一个1px*1px的透明图片,不过204响应更优秀,因为它更小,从来不被缓存,而且绝不会改变浏览器的状态。

延伸阅读:

  • 301跳转常见问题汇总
  • http://www.chinaz.com/web/2014/1029/372287.shtml
  • 写给新手站长:301重定向完整解析
  • http://www.chinaz.com/web/2013/1212/330808.shtml
  • 再谈Canonical标签:与301有何区别?
  • http://www.chinaz.com/web/2015/0409/397350.shtml
本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-12-01,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 我为Net狂 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 延伸阅读:
  • 延伸阅读:
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档