Web性能优化的常用手段
因为最近在学习前段的过程中,接触到了对应的前端web性能等相关领域的知识,为了更全面的了解前端领域的同时,也是为了更好地学习前端,更具我所了解到的知识,于是写下了这篇Blog:
学习不仅仅是学习,因此在了解到Web性能优化之前我问了自己以下几个问题:
- 为什么要了解Web性能优化:
- Web性能优化有几个常见措施:
- Web性能优化的重要性:
01|为什么要了解Web性能优化:
Web性能优化之所以为什么要了解,不仅仅是学习,也是因为对前端世界的好奇,因为为什么会有Web性能优化的概念,也是为了解决一些问题而被提出的,这是毋庸置疑的,但是与我们刚学习的前端小白来说Web性能优化会不会太遥远了,Web性能优化具体来讲,我们应该如何看待呢?
其实我个人的看法是这样的,既然说有Web性能优化的概念的提出,那么应该追溯到前端领域的发展史,准确来说应该是Web领域发展史,为什么这么说呢?因为现在的前端和以前的前端大有不同了,关于性能优化的提出应该也是针对性能不足的问题而提出来的,那么为什么以前没有这种问题,反倒是现在这种概念一直被人(软件工程师)悉知,因为以前的互联网相对来讲比较落后,Web上面的用户体验和应用场景现在那么丰富,当时的Web页面还是比较简陋的,不像现在这样非常注重用户体验! 加上互联网的蓬勃发展,对Web要求越来越高,因此在现在高速发展的互联网环境下面,Web性能是比较重要的一环,这是以前从未遇到过的情况!
作为一名前端工程师,在作好本职工作的同时,更要站在不同的角度去看到Web不论是用户还是开发者本身,都是为了方便人们更好地享受互联网所带来的便利,为了更好地提升用户体验,因此Web性能优化这一环是值得我们深入了解和实践的!
02|Web性能优化的常见几个措施:
上面讲到了为什么要了解Web性能优化,那么这一环节,将介绍如何深入实践Web性能优化,并且以常用的几种优化方式来服务大众,在此之前,为了更全面的了解Web性能优化的实践方式和主要方法,看了一些资料,以雅虎前端优化35条规则为前提下,介绍了常用几种,因为前面的35条并不适用于所有的开发环境!
01|使用 CDN
CDN其实是
[Content distribution network]内容分发网络 的简称,用户请求资源如果说距离服务器太远的话会增加服务器的响应时间,但是如果说使用了CDN的话,利用最靠近每位用户的服务器,更快更可靠地将静态资源或者是应用程序及其他文件发送给用户,来提高性能,可拓展性以及低成本的网络内容传递给用户!因为距离会影响服务器的响应时间,通过CDN分发资源给最近的用户来达到良好的用户体验!
02|使用 Cache-Control
cache-control MDN 通用消息投资端被用于在HTTP请求和响应中通过指定指令来实现缓存机制!
其中的cache-control头部帮助浏览器进行有条件的请求.
一般来讲页面越丰富的话,那么对应的脚本文件,样式,图片文件会越来越多,通过缓存的方式缓解服务器的压力! 提升用户的上网体验!
03|使用 Etag
实体标记Entity tag,是服务器和浏览器之间判断浏览器缓存中某个组件是否匹配服务器端元组件的一种机制,ETag被当做验证实体的比最后更改日期更高效的机制,服务器设置ETag的方式:
HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
ETag: "10c24bc-4ab-457e1c1f"
Content-Length: 12195
如果浏览器要验证组件的话,它使用了If-None-Match头部来传Etag给服务器,如果Etag匹配的话,服务器则返回304:
GET /i/yahoo.gif HTTP/1.1
Host: us.yimg.com
If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
If-None-Match: "10c24bc-4ab-457e1c1f"
HTTP/1.1 304 Not Modified
04|使用 Gzip
传输的时候使用Gzip等压缩组件
从Http/1.1开始,客户端通过http请求中的Accept-Encoding偷不来提示支持的压缩:
Accept-encoding:gzip,deflate
如果服务器看到了这个头部的话,他可能会选用列表中的某个方法压缩响应,服务器通过CONTENT-enCoding头部提示客户端
Content-Encoding:gzip
gzip一般的话可以减小响应的70%,尽可能Gzip文本类型的文件.
05|合并文件（CSS、JS、图片）
到终端用户的响应时间80%花在前端：大部分用于下载组件（js/css/image/flash等等）。减少组件数就是减少渲染页面所需的http请求数。这是更快页面的关键。
减少组件数的一个方法就是简化页面设计。保持富内容的页面且能减少http请求，有以下几个技术：
- Combined files。合并文件，如合并js，合并css都能减少请求数。如果页面间脚本和样式差异很大，合并会更具挑战性。
- CSS Sprites。雪碧图可以合并多个背景图片，通过
background-image和background-position来显示不同部分。 - Image maps。合并多个图片到一个图片，一般用于如导航条。由于定义坐标的枯燥和易错，一般不推荐。
- Inline images。使用
data:url scheme来內连图片。
减少请求数是为第一次访问页面的用户提高性能的最重要的指导。
06|调整 CSS 和 JS 的位置
CSS
把样式放在顶部。
研究雅虎网页性能时发现把样式表移到
<head>里会让页面更快。这是因为把样式表移到<head>里允许页面逐步渲染。关注性能的前端工程师希望页面被逐步渲染，这时因为，我们希望浏览器尽早渲染获取到的任何内容。这对大页面和网速慢的用户很重要。给用户视觉反馈，比如进度条的重要性已经被大量研究和记录。在我们的情况中，
HTML页面就是进度条。当浏览器逐步加载页面头部，导航条，logo等等，这些都是给等待页面的用户的视觉反馈。这优化了整体用户体验。把样式表放在文档底部的问题是它阻止了许多浏览器的逐步渲染，包括IE。这些浏览器阻止渲染来避免在样式更改时需要重绘页面元素。所以用户会卡在白屏。
HTML规范清楚表明样式应该在
<head>里。
JavaScript
把脚本放到底部。
脚本引起的问题是它们阻塞了并行下载。HTTP1.1规范建议浏览器每个域名下不要一次下载超过2个组件。如果你的图片分散在不同服务器，那么你能并行下载多个图片。但当脚本在下载，浏览器不会再下载其它组件，即使在不同域名下。
有些情况下把脚本移动到底部并不简单。比如，脚本中用了
document.write来插入内容，它就不能被移动到底部。另外有可能有作用域问题。但大多数情况，有方法可以解决这些问题。一个替代建议是使用异步脚本。
defer属性表明脚本不包含document.write，是提示浏览器继续渲染的线索。不幸的是，Firefox不支持。如果脚本能异步，那么也就可以移动到底部。
07|减少DNS的查询次数
因为在我们刚开始输入网址的时候,就是通过DNS查询得到真实网址的ip地址,DNS查询北缓存来提高性能,缓存可能发生在特定的缓存服务器中,大多数浏览器有自己的缓存,独立与操作系统的缓存,如果说浏览器缓存了某条DNS记录的话,那么就不会向操作系统发送DNS解析请求操作!
IE默认缓存30分钟,FireFox默认缓存1分钟. 如果说当客户的缓存为空的话,nameDNS查询次数等于页面中的唯一域名数!
减少DNS请求数可能会减少并行下载数。避免DNS查找减少响应时间，但减少并行下载数可能会增加响应时间。指导原则是组件可以分散在至少2个但不多于4个的不同域名。这是两者的妥协。
08|增加域名以并行下载资源
把组件分散到不同的域名。
把组件分散到不同的域名允许你最大化并行下载数。由于DNS查询的副作用，最佳的不同域名数是2-4。
03|Web性能优化的重要性:
Web性能优化的重要性,体现在产品上,用户的体验上面,当然同时也鞭策着程序员能够遵循对应的优化原则写出更符合要求的代码做出更好的产品! 如果想成为一名出色的Web工程是那么这个环节将是你必不可少的一个环节!
结尾
写在最后,有一些Web性能优化的常见措施没有讲到,因此只说到我比较熟悉的几个措施,如果你对本文有什么建议或者意见的话可以联系我 ProbeDream
网友评论