网页前端优化

网站前端优化

主要是给学生介绍了这几个规则。

第一:减少HTTP请求

1: 将超链接关联到图片上,例如在导航栏按钮中。如果是以这种形式关联多个带有超链接的图片,使用图片地图这种方式既能减少HTTP请求,有无需改变页面外观感受。图片地图允许在一个图片上关联多个URL.

2: CSS Sprites

和图片地图一样,CSS Sprites也可以合并图片,但是更加灵活,可以将多个图片合并到一个单独的图片中。

3:合并脚本和样式表

我们在使用Javascript和CSS时,到底是进行“内联”(也就是将其嵌套在HTML文档中)还是将其放在外部的脚本和样式表文件中。一般来说,使用外部脚本和样式表对性能更加有利(后面会说到)。但是,如果将代码分割到过多的小文件中,会降低性能,因为每个文件都会导致一个额外的HTTP请求。为了清晰,不建议将脚本和样式表合并在一起。但是多个

脚本应该合并为一个脚本,多个样式表也应该合并为一个样式表。到底页面上应该有多少个脚本文件和CSS文件需要花一定的时间分析页面。

第二:使用内容发布网络

网站最初通常将其所有的服务器放在同一个地方。当用户群增加时,公司就必须面对服务器放置地点不再使用的事实,有必要再多个地理位置不同的服务器上部署内容。

CDN的通俗理解就是网站加速,CPU均衡负载,可以解决跨运营商,跨地区,服务器负载能力过低,带宽过少等带来的网站打开速度慢等问题。

比如:

1.一个企业的网站服务器在北京,运营商是电信,在广东的联通用户访问企业网站时,因为跨地区,跨运营商的原因,网站打开速度就会比北京当地的电信客户访问速度慢很多,很容易造成这个企业的客户流失

2.一个网站的服务器性能比较差,承载能力有限,有时面临突发流量,招架不住,直接导致服务器崩溃,网站打不开,尤其是电商网站在节日期间,因为这种情况网站打不开,销售额白白流失的占比都高涨至60%

3.再比如一些中小企业租用的虚拟主机,因为跟好几个网站共用一台服务器,每个网站所分带宽有限,带宽过小经常导致流量稍微一多,网站打开速度就很慢,甚至打不开。

国内较为有名的CDN服务商有蓝汛、网宿科技,世纪互联,帝联科技等

第三:添加Expires

今天的WEB页面包含了大量的组件,并且其数量在不断增长,页面的初次访问者会进行很多HTTP请求,但通过一个长久的Expires头,使这些组件可以被缓存。这回在后续的页面浏览中避免不必要的HTTP请求。长久的Expires头最常用于图片,但是应该将其用在所有的组件上,包括脚本,样式表等。在HTTP1.1引入了Cache-Control头来克服Expires头的限制。因为Expires头使用一个特定的时间,它要求服务器和客户端的时钟严格同步。

使用带有max-age的Cache-Control可以消除Expires的限制(我推荐尽量使用Cache-Control)。如果两者同时出现,HTTP规定max-age指令将重写Expires头。

可以在IIS管理器为静态内容设置Cache-Control:max-age.

还可以在web.config文件里应用该设置.如下所示:

<configuration>

…………..

<system.webServer>

……………………..

<staticContent>

<clientCache cacheControlMode=”UseMaxAge” cacheControlMaxAge= ‘365.00 :00 :00 ’ >

</staticContent>

</system.webServer>

</configuration>

前面的<staticContent>节名字暗示这种方式只针对静态内容。对于动态内容,需要设置客户端缓存过期时间,可以在aspx文件中设置。

<%@ Page ……%>

<%@ OutputCache Duration=”86400” Location=”Client” VaryByParam=”None”%>

该指令告诉运行时生成的HTTP头,让浏览器缓存该内容1天(86400秒)。

第四:减少ViewState的大小。

有些控件,比如GridView,会很容易地产生数K字节的ViewState.因为浏览器会将ViewState作为HTTP POST的一部分发送回服务器,所以如果它大,会对页面的加载时间有不利的影响。所以应该关闭ViewState,代码如下

<%@ Page Title="" Language="C#" EnableViewState="false" AutoEventWireup="true" CodeBehind="View.aspx.cs" Inherits=" View" %>

第五:压缩组件

通过减小HTTP响应的大小来减少响应时间。如果HTTP请求产生的响应包很小,传输时间就会减少,因为只需要将很小的包从服务器传递到客户端。这一效果对速度较慢的带宽尤其明显。最主要的方式是通过gzip编码来压缩HTTP响应包,并由此减少网络响应时间。这是减小页面大小的最简单的技术,但影响是最大的。还有很多方式可以减小HTML文档的页面大小(例如删除注释和额外的空格,移除没有使用的CSS,移除没有使用的JAVASCRIPT,检查并移除冗余标签,移除没有内容的标签,移除<meta refresh>标签:页面自动刷新乍一看有时很动人,但是考虑到这样的情况,用户离开了电脑,或者正在看浏览器的另外一个选项卡,那么这只会浪费客户端和服务器的资源)。

Web客户端可以通过HTTP请求中的Accept-Encoding头来标示对压缩的支持。

Accept-Encoding:gzip,deflate

如果Web服务器看到请求中有这个头,就会使用客户端列出来的方法中的一种来压缩响应。Web服务器通过响应中的Content-Encoding头来通知Web客户端

Content-Encoding:gzip

Gzip是目前最流行和有效地压缩方法,你能看到的另一种压缩方式为deflate,但是效果不如gzip,并且也不太流行,支持deflate的浏览器也支持gzip,但是很多浏览器支持gzip却不支持deflate,因此gzip是最理想的压缩方法。很多网站会压缩其HTML文档,压缩脚本和CSS样式表也是很重要的,图片不应该压缩,因为可以在上传时进行压缩,试图对它们进行压缩

只会浪费CPU资源。当然压缩也是有成本的,服务端会额外花费CPU周期来完成压缩,客户端需要对压缩文件进行解压缩。要检测收益是否大于开销,需要考虑响应的大小,链接的带宽和客户端与服务器之间的Internet距离,这些信息是很难得到的,根据经验通常对于大于1KB或2KB的文件进行压缩。

可以在IIS中配置文件的压缩,具体步骤可以参考微软的MSDN

http://msdn.microsoft.com/zh-cn/ff695514.aspx

压缩分为静态压缩和动态压缩,我建议在这里启用静态压缩,而不要启用动态压缩。对于一个活跃的网站,启用压缩通常会增加大概3%~5%的CUP使用率。对于大多数网站,这种取舍通常是值得的。

这里需要考虑代理缓存的情况,有兴趣的同学可以查一下资料。

第六:将样式表放在顶部(使用Link标签将样式表放在HEAD标签中)

我们希望浏览器能够尽快显示内容,这对于有很多内容的页面以及Internet链接很慢的用户来说很重要。将样式表放在文档底部会导致在浏览器中阻止内容逐步呈现。该规则对于加载页面所需要的时间没有什么太大的影响。在浏览器和用户等待位于底部的样式表时,浏览器会延迟显示任何的可视化的内容,我们称之为”白屏”

大家可以自己测试一下。

为了避免白屏,请将样式表放在文档顶部的Head中。在Head中导入外部样式可以使用Link,和@import,我更喜欢使用Link,因为性能要好一些,并且@import有时候可能会导致白屏的出现,甚至放在文档的Head标签中。

第七:将脚本放在底部

在使用样式表时,页面逐步呈现会被阻止,直到所有的样式表下载完成。这就是最好将样式表移到文档的HEAD的原因,这样就能首先下载它们而不会阻止页面呈现。使用脚本时,对于所有位于脚本以下的内容,逐步呈现都被阻塞了。将脚本放在页面越靠下的地方,意味着越多的内容能够逐步呈现。

并行下载组件的优点是很明显的。然而在下载脚本文件时并行下载实际上是被禁用的,其中的一个原因是,脚本可能使用了document.write来修改页面内容,因此浏览器会等待,以确保能够恰当的布局。

另外一个原因是为了保证脚本能够按照正确的顺序执行。所以脚本会阻塞对其后面内容的呈现。如果将脚本放在页面顶部,页面中的所有的内容都位于脚本之后,整个页面的呈现和下载都会被阻塞,直到脚本加载完毕。由于整个页面的呈现被阻塞了,因此也会出现白屏的现象。

第八:使用外部的CSSJavascript

使用外部的CSS和Javascript的原因是这些文件有机会被浏览器缓存起来。

如果你的网站中的每个页面都使用了相同的CSS和Javascript,使用外部文件可以提高这些组件的重用率。在这些情况下使用外部文件更加具有优势,因为当用户在页面间导航时,Javascript和CSS组件已经位于浏览器的缓存中了。相反的情况时,如果没有任何两个页面共享相同的JAVASCRIPT和CSS,重用率就会降低。当然解决这个问题,没有什么好的办法,我认为可以采用一个折中的办法,就是将你网站的页面划分成几种页面类型,然后为每种类型创建单独的脚本和样式表,这样的话对于给定的任意界面都只需要下载很少的多余的CSS和JAVASCRIPT文件。当然,你的CSS和JAVASCRIPT有很高的重用度,则部署在外部文件中更有优势,但是如果重用度很低,还是内联更有意义一些。

第九:减少DNS的查找

Internet是通过IP地址来查找服务器的,由于IP地址比较难记,通常使用包含主机名的URL来代替(域名),但是当浏览器发出请求时,IP地址仍然是必须的,这就需要DNS将主机名称映射到IP地址上,你在浏览器上键入 :www.baidu.com时,连接到浏览器的DNS解析器会返回服务器的IP地址。DNS也是有开销的,通常情况下浏览器查找一个给定的主机名的IP地址需要花费20~120毫秒,在DNS查找完成之前,浏览器是不能从主机名那里下载到任何东西的。响应的时间依赖于DNS解析器,它所承担的请求的压力,你与它之间的距离和你的带宽。当然DNS也是可以被缓存起来的,但是浏览器对缓存的DNS记录的数量也有限制,而不管缓存记录的时间。如果用户在短时间内访问了很多具有不同域名的网站,较早的DNS记录将被丢弃,必须重新查找该域名。

减少DNS查找,我的建议是将CSS,图片,脚本等这些组件分别放在至少2个,但不要超过4个主机域名下。这是在减少DNS查找和允许高度并行下载之间做出的很好的权衡。

第十:精简JavaScript

精简是从代码中移除不必要的字符以减小其大小,进而改善加载时间,在代码被精简以后,所有的注释以及不必要的空白字符(空格,换行等)都被移除。对于Javascript而言,这可以改善响应时间效率,因为需要下载的文件大小减小了。说到精简,简单提一下混淆。

混淆是可以应用在源码上的另外一种优化方式,和精简一样,它也会移除注释空白,同时它还会改写代码。作为改写的一部分,函数和变量的名字将被变的更短,但是也更难阅读。通常这样做的目的主要是为了增加对代码进行反向工程的难度。当然对提高性能也有帮助,因为这比精简更能减小代码的大小。缺点就是,更加复杂,而且很难阅读与调试。

精简JavaScript代码的工具可以使用JSMin.

我们在前面说过,可以对Javascript外部文件使用gzip来完成压缩,当前gzip压缩比精简更能减少文件的大小,那么如果已经启用了压缩,是否还要在进行精简呢?

是有必要的,因为gzip虽然压缩产生的影响更大,但是精简能够进一步的减小文件的大小。

精简CSS能够带来的节省要小于精简JAVASCRIPT,因为CSS中的空白和注释一般情况下要比JAVASCRIPT的少,所以CSS主要是合并相同的类,移除不用的类等。

十一:移除重复的脚本

重复脚本损伤性能的方式主要有两种情况,不必要的HTTP请求和执行JavaScript所浪费的时间。这种错误看似简单但是却是经常发生的,例如在母版页中引用了一个脚本文件,在具体的内容页面中又引用了一次。有可能有人认为,现在脚本文件已经被缓存了,不会再发新的请求了,但是如果单击浏览器的刷新按钮时,还是会产生两个HTTP请求(这种情况存在IE中)。同时,对脚本进行多次求值也会浪费时间。

十二:注意图片的优化

1:减少页面上的图片的数量

图片通常比HTML占用更多的网站带宽,所以图片优化的第一步应该是考虑一下是否需要页面上所有的图片。

2:可以使用CSS来代替翻转图片的效果。

3:优化背景图片

优化背景图片,一定要利用浏览器可以通过平铺重复单个图片的功能。例如将图片是1像素宽的渐变图片平铺。

4:选择正确的图片格式

5:压缩缩小图片尺寸。

6:使用图片切片

7:如果您的网站存在大量的图片读写操作,我建议您使用图片服务器

时间: 2024-11-08 19:18:21

网页前端优化的相关文章

【转】关于大型网站技术演进的思考(二十一)--网站静态化处理—web前端优化—下【终篇】(13)

本篇继续web前端优化的讨论,开始我先讲个我所知道的一个故事,有家大型的企业顺应时代发展的潮流开始投身于互联网行业了,它们为此专门设立了一个事业部,不过该企业把这个事业部里的人事成本,系统运维成本特别是硬件采购的成本都由总公司来承担,当然互联网业务上的市场营销成本这块还是由该事业部自己承担,可是网站一年运维下来,该公司发现该事业部里最大的成本居然不是市场营销的开销,而是短信业务和宽带使用上的开销,是不是有点让人感到意外呢?下面我来分析下这个场景吧. 短信这块是和通讯运营商有关,很难从根本上解决,

关于大型网站技术演进的思考(二十一)--网站静态化处理—web前端优化—下【终篇】(13)

本篇继续web前端优化的讨论,开始我先讲个我所知道的一个故事,有家大型的企业顺应时代发展的潮流开始投身于互联网行业了,它们为此专门设立了一个事业部,不过该企业把这个事业部里的人事成本,系统运维成本特别是硬件采购的成本都由总公司来承担,当然互联网业务上的市场营销成本这块还是由该事业部自己承担,可是网站一年运维下来,该公司发现该事业部里最大的成本居然不是市场营销的开销,而是短信业务和宽带使用上的开销,是不是有点让人感到意外呢?下面我来分析下这个场景吧. 短信这块是和通讯运营商有关,很难从根本上解决,

关于大型网站技术演进的思考(二十)--网站静态化处理—web前端优化—中(12)

Web前端很多优化原则都是从如何提升网络通讯效率的角度提出的,但是这些原则使用的时候还是有很多陷阱在里面,如果我们不能深入理解这些优化原则背后所隐藏的技术原理,很有可能掉进这些陷阱里,最终没有达到最佳的预期效果,今天我在这里分析下浏览器和服务端通讯的一些细节问题,希望通过分析这些细节问题,能给大家一个启迪,能更好的理解这些优化原则背后的隐秘,最终能更好的运用这些原则. 网站的通讯技术是构建在http协议上,http协议底层通讯手段使用的是tcp/ip协议,但是tcp通讯协议在建立连接和断开连接这

【转】yahoo前端优化军规

雅虎给出了前端优化的34条法则(包括Yslow规则22条) 详细说明,下载转发 ponytail 的译文(来自帕兰映像). Minimize HTTP Requests 减少http请求 图片.css.script.flash等等这些都会增加http请求数,减少这些元素的数量就能减少响应时间. 把多个JS.CSS在可能的情况下写进一个文件,页面里直接写入图片也是不好的做法,应该写进CSS里,利用 CSS sprites 将小图拼合后利用background来定位. Use a Content D

Web前端优化最佳实践及工具集锦

前端的性能对于一个Web应用来说非常重要,如果一个Web应用的页面加载速度非常快.对于用户的操作可以及时响应,那么产品的用户体验将会极大地提升.下图显示了页面加载速度对于用户体验的影响. 你的Web页面的速度是否已经足够快了?其实可能还有很多可以提升的地方.Google和雅虎也提出了一些Web应用的前端优化建议,并发布了一些工具,你可以逐一检验你的Web应用,以便达到更高的性能. 这些优化不仅仅可以给用户提供更好的体验,从开发者角度来说,进行优化还可以减少页面的请求数.降低请求所占的带宽.减少资

web 前端优化-戈多编程

大家好,我是戈多,从事web开发工作接近三年了,今天来归纳下web前端优化的解决方案(码农搬砖工,来自各网络汇总) 1.减少Http请求 http请求越多,那么消耗的时间越多,如果在加上网络很糟糕,那么问题就更多了.且如果网页中的图片.css文件.js文件很多甚至有音乐文件时,这势必会造成负担. (1)图片地图 即多个图片排成一行作为链接到其他页面的按钮,我们当然可以使用五福图片,发送5个http请求,但是这是不合适的. 我们可以选择使用图片地图,即只用一张图片,然后使用<map>属性通过控制

高效前端优化工具--Fiddler入门教程

简介: Fiddler是用C#编写的一个免费的HTTP/HTTPS网络调试器.Fiddler是以代理服务器的方式,监听系统的网络数据流动英语中Fiddler是小提琴的意思,Fiddler Web Debugger就像小提琴一样,可以让前端开发变得更加优雅. 它可以做什么? Fiddler是以代理服务器的方式,监听系统的网络数据流动,并在ie, 火狐下都可以安装哦(这个是最好的特点 呵呵) 它能 够记录所有的你电脑和互联网之间的http通讯,Fiddler 可以也可以让你检查所有的http通讯,设

前端优化带来的思考,浅谈前端工程化

重复优化的思考 这段时间对项目做了一次整体的优化,全站有了20%左右的提升(本来载入速度已经1.2S左右了,优化度很低),算一算已经做了四轮的全站性能优化了,回顾几次的优化手段,基本上几个字就能说清楚: 传输层面:减少请求数,降低请求量执行层面:减少重绘&回流 传输层面的从来都是优化的核心点,而这个层面的优化要对浏览器有一个基本的认识,比如: ① 网页自上而下的解析渲染,边解析边渲染,页面内CSS文件会阻塞渲染,异步CSS文件会导致回流 ② 浏览器在document下载结束会检测静态资源,新开线

WEB前端优化一些经验技巧

引言: 1. 慢的页面可能会网站失去更多的用户. 2. 慢500ms意味着20%的用户将放弃访问(google) 3. 慢100ms意味着1%的用户将放弃交易(amazon) 前段时间偶然看到网上的两篇关于前端优化的文章,其中大部分技巧都来自Yahoo的优化原则,这里是对两篇文章的摘抄和总结. 减少Http请求 一般来说,我们从变化性上把数据分成两种类型,变和不变.那么不变的数据可以缓存,变化的数据不能缓存,这是一个常识,也就是说要减少我们的 http请求次数这个目标可以转换成把数据分为变化和不