前端性能优化

时间  2019-11-10 标签 前端 性能 优化

 

图中已经对前端性能作了一些归纳。javascript

从三个方面就前端性能进行总结：网络方面、DOM操做及渲染方面、数据方面。php

网络方面

web应用，老是会有一部分的时间浪费在网络链接和资源下载方面。每每创建一次网络链接是须要时间成本的。并且浏览器同一时间所发送的网络请求数是有限的。因此，这个层面的优化能够从「减小请求数目」开始：css

  1. 减小http请求：在YUI35规则中也有提到，主要是优化js、css和图片资源三个方面，由于html是没有办法避免的。所以，咱们能够作一下的几项操做：html

    • 合并js文件
    • 合并css文件
    • 雪碧图的使用(css sprite)
    • 使用base64表示简单的图片

    上述四个方法，前面二者咱们可使用webpack之类的打包工具进行打包；雪碧图的话，也有专门的制做工具；图片的编码是使用base64的，因此，对于一些简单的图片，例如空白图等，可使用base64直接写入html中。前端

回到以前网络层面的问题，除了减小请求数量来加快网络加载速度，每每整个资源的体积也是，平时咱们会关注的方面。java

  1. 减少资源体积：能够经过如下几个方面进行实施：android

    • gzip压缩
    • js混淆
    • css压缩
    • 图片压缩

    gzip压缩主要是针对html文件来讲的，它能够将html中重复的部分进行一个打包，屡次复用的过程。js的混淆能够有简单的压缩(将空白字符删除)、丑化(丑化的方法，就是将一些变量缩小)、或者可使用php对js进行混淆加密。css压缩，就是进行简单的压缩。图片的压缩，主要也是减少体积，在不影响观感的前提下，尽可能压缩图片，使用png等图片格式，减小矢量图、高清图等的使用。这样子的作法不只能够加快网页显示，也能减小流量的损耗。webpack

除了以上两部分的操做以外，在网络层面咱们还须要作好缓存工做。真正的性能优化来讲，缓存是效率最高的一种，每每缩短的加载时间也是最大的。ios

  1. 缓存：能够经过如下几个方面来描述：程序员

    • DNS缓存
    • CDN部署与缓存
    • http缓存

    因为浏览器会在DNS解析步骤中消耗必定的时间，因此，对于一些高访问量网站来讲，作好DNS的缓存工做，就会必定程度上提高网站效率。CDN缓存，CDN做为静态资源文件的分发网络，自己就已经提高了，网站静态资源的获取速度，加快网站的加载速度，同时也给静态资源作好缓存工做，有效的利用已缓存的静态资源，加快获取速度。http缓存，也是给资源设定缓存时间，防止在有效的缓存时间内对资源进行重复的下载，从而提高总体网页的加载速度。

其实，网络层面的优化还有不少，特别是针对于移动端页面来讲。众所周知，移动端对于网络的敏感度更加的高，除了目前的4G和WIFI以外，其余的移动端网络至关于弱网环境，在这种环境下，资源的缓存利用是至关重要的。并且，减小http的请求次数，也是相当重要的，移动端弱网环境下，对于http请求的时间也会增长。因此，咱们能够看一下咱们在移动端网络方面能够作的优化：

  1. 移动端优化：使用如下几种方式来加快移动端网络方面的优化：

    • 使用长cache，减小重定向
    • 首屏优化，保证首屏加载数据小于14kb
    • 不滥用web字体

    「使用长cache」，可使得移动端的部分资源设定长期缓存，这样能够保证资源不用向服务器发送请求，来比较资源是否更新，从而避免304的状况。304重定向，在PC端或许并不会影响网页的加载速度，可是，在移动端网络不稳定的前提下，多一次请求，就多了一部分加载时间。「首屏优化」，对于移动端来讲是相当重要的。2s时间是用户的最佳体验，一旦超出这个时间，将会致使用户的流失。因此，针对移动端的网络状况，不可能在这么短期内加载完成全部的网页资源，因此咱们必须保证首屏中的内容被优先显示出来，并且基于TCP的慢启动和拥塞控制，第一个14kb的数据是很是重要的，因此须要保证首部加载数据可以小于14kb。「不滥用web字体」，web字体的好处就是，能够代替某些图片资源，可是，在移动端过多的web字体的使用，会致使页面资源加载的繁重，因此，慎用web字体

渲染和DOM操做方面

首先，简单的聊一下优化渲染的重要性。在网页初步加载时，获取到HTML文件以后，最初的工做是构建DOM和构建CSSOM两个树，以后将他们合并造成渲染树，最后对其进行打印。咱们能够经过图片来看一下，简单的过程：

 
DOM渲染

这里整个过程拉出来写，具体能够再写一篇文章，恕我偷下懒，推荐一篇比较好的文章给你们吧。浏览器渲染过程与性能优化

继续咱们的话题，咱们能够如何去缩短这个过程呢？能够从如下几个操做进行优化。

  1. 优化网页渲染：

    • css的文件放在头部，js文件放在尾部或者异步
    • 尽可能避免內联样式

    css文件放在「头部加载」，能够保证解析DOM的同时，解析css文件。由于，CSS（外链或内联）会阻塞整个DOM的渲染，然而DOM解析会正常进行，因此将css文件放在头部进行解析，能够加快网页的构建速度。假设将其放在尾部，那时DOM树几乎构建，这时就得等到CSSOM树构建完成，才可以继续下面的步骤。「js放在尾部」：js文件不一样，将js文件放在尾部或者异步加载的缘由是JS（外链或内联）会阻塞后续DOM的解析，后续DOM的渲染也将被阻塞，并且一旦js中遇到DOM元素的操做，极可能会影响。这方面能够推荐一篇文章——异步脚本载入提升页面性能。「避免使用内联样式」，能够有效的减小html的体积，通常考虑内联样式的时候，每每是样式自己体积比较小，每每加载网络资源的时间会大于它的时候。

除了页面渲染层面的优化，固然最重要的就是DOM操做方面的优化，这部分的优化应该是最多的，并且也是平时开发能够注意的地方。若是开发前期明白这些原理，同时付诸实践的话，就能够在后期的性能完善上面少下不少功夫。那么，接下来咱们能够来看一下具体的操做：

  1. DOM操做优化：

    • 避免在document上直接进行频繁的DOM操做
    • 使用classname代替大量的内联样式修改
    • 对于复杂的UI元素，设置position为absolute或fixed
    • 尽可能使用css动画
    • 使用requestAnimationFrame代替setInterval操做
    • 适当使用canvas
    • 尽可能减小css表达式的使用
    • 使用事件代理

    前面三个操做，其实都是但愿『减小回流和重绘』。其实，进行一次DOM操做的代价是很是之大的，之前能够经过网页操做是否卡顿来进行判断，可是，现代浏览器的进步已经大大减小了这方面的影响。可是，咱们仍是须要清楚，如何去减小回流和重绘的问题。由于这里不想细说这方面的知识，想要了解的话，能够看这篇文章——回流与重绘：CSS性能让JavaScript变慢？。这但是张鑫旭大大的一篇文章呦(^.^)。「尽可能使用css动画」，是由于自己css动画比较简单，并且相较于js的复杂动画，浏览器自己对其进行了优化，使用上面不会出现卡顿等问题。「使用requestAnimationFrame代替setInterval操做」，相信你们都有所耳闻，setInterval定时器会有必定的延时，对于变更性高的动画来讲，会出现卡顿现象。而requestAnimationFrame正好解决的整个问题。「适当使用canvas」，不得不说canvas是前端的一个进步，出现了它以后，前端界面的复杂性也随之提高了。一些难以完成的动画，均可以使用canvas进行辅助完成。可是，canvas使用频繁的话，会加剧浏览器渲染的压力，同时致使性能的降低。因此，适当时候使用canvas是一个不错的建议。「尽可能减小css表达式的使用」，这个在YUI规则中也被提到过，每每css的表达式在设计之初都是美好的，但在使用过程当中，因为其频繁触发的特性，会拖累网页的性能，出现卡顿。所以在使用过程当中尽可能减小css表达式的使用，能够改换成js进行操做。「使用事件代理」：每每对于具有冒泡性质的事件来讲，使用事件代理不失为一种好的方法。举个例子：一段列表都须要设定点击事件，这时若是你给列表中的每一项设定监听，每每会致使总体的性能降低，可是若是你给整个列表设置一个事件，而后经过点击定位目标来触发相应的操做，每每性能就会获得改善。

DOM操做的优化，还有不少，固然也包括移动端的。这个会在以后移动端优化部分被说起，此处先卖个关子。上面咱们概述了开始渲染的时候和DOM操做的时候的一些注意事项。接下来要讲的是一些小细节的注意，这些细节可能对于页面影响不大，可是一旦堆积多了，性能也会有所影响。

  1. 操做细节注意：

    • 避免图片或者frame使用空src
    • 在css属性为0时，去掉单位
    • 禁止图像缩放
    • 正确的css前缀的使用
    • 移除空的css规则
    • 对于css中可继承的属性，如font-size，尽可能使用继承，少一点设置
    • 缩短css选择器，多使用伪元素等帮助定位

    上述的一些操做细节，是平时在开发中被要求的，更能够理解为开发规范。(基本操做，坐下^_^)

列举完基本操做以后，咱们再来聊一下移动端在DOM操做方面的一些优化。

  1. 移动端优化：

    • 长列表滚动优化
    • 函数防抖和函数节流
    • 使用touchstart、touchend代替click
    • HTML的viewport设置
    • 开启GPU渲染加速

    首先，长列表滚动问题，是移动端须要面对的，IOS尽可能使用局部滚动，android尽可能使用全局滚动。同时，须要给body添加上-webkit-overflow-scrolling: touch来优化移动段的滚动。若是有兴趣的同窗，能够去了解一下ios和android滚动操做上的区别以及优化。「防抖和节流」，设计到滚动等会被频繁触发的DOM事件，须要作好防抖和节流的工做。它们都是为了限制函数的执行频次，以优化函数触发频率太高致使的响应速度跟不上触发频率，出现延迟，假死或卡顿的现象。

    介绍：函数防抖，当调用动做过n毫秒后，才会执行该动做，若在这n毫秒内又调用此动做则将从新计算执行时间；函数节流，预先设定一个执行周期，当调用动做的时刻大于等于执行周期则执行该动做，而后进入下一个新周期。

    「touchstart、touchend代替click」，也是移动端比较经常使用的操做。click在移动端会有300ms延时，这应该是一个常识呗。(不知道的小伙伴该收藏一下呦)。这种方法会影响用户的体验。因此作优化时，最简单的方法就是使用touchstart或者touchend代替click。由于它们事件执行顺序是touchstart->touchmove->touchend->click。或者，使用fastclick或者zepto的tap事件代替click事件。「HTML的viewport设置」，能够防止页面的缩放，来优化性能。「开启GPU渲染加速」，小伙伴们必定听过CPU吧，可是这里的GPU不能和CPU混为一谈呦。GPU的全名是Graphics Processing Unit，是一种硬件加速方式。通常的css渲染，浏览器的渲染引擎都不会使用到它。可是，在3D渲染时，计算量较大，繁重，浏览器会开启显卡的硬件加速来帮助完成这些操做。因此，咱们这里可使用css中的translateZ设定，来欺骗浏览器，让其帮忙开启GPU加速，加快渲染进程。

DOM部分的优化，更多的是习惯。须要本身强制要求本身在开发过程当中去注意这些规范。因此，这部分的内容能够多关注一下，才可以慢慢了解。同时，本人对于上述几点的描述是归纳性的。并无对其进行详细的展开。所以，也要求你去细细的查阅Google呦。

数据方面

数据，也能够说是前端优化方面比较重要的一块内容。页面与用户的交互响应，每每伴随着数据交互，处理，以及ajax的异步请求等内容。因此，咱们也能够来聊聊这一块的知识。首先是对于图片数据的处理：

  1. 图片加载处理：

    • 图片预加载
    • 图片懒加载
    • 首屏加载时进度条的显示

    「图片预加载」，预加载的寓意就是提早加载内容。而图片的预加载每每会被用在图片资源比较大，即时加载时会致使很长的等待过程时，才会被使用的。常见场景：图片漫画展现时。每每会预加载一张到两张的图片。「图片懒加载」，懒加载或许你是第一次据说，可是，这种方式在开发中会被常用。首先，咱们须要明白一个道理：每每只有看到的资源是必须的，其余资源是能够随着用户的滚动，随即显示的。因此，特别是对于图片资源特别多的网站来讲，作好图片的懒加载是能够大大提高网页的载入速度的。

    常见的图片懒加载的方式就是：在最初给图片的src设置一个比较简单的图片，而后将图片的真实地址设置给自定义的属性，作一个占位，而后给图片设置监听事件，一旦图片到达视口范围，从图片的自定义属性中获取出真是地址，而后赋值给src，让其进行加载。

    「首屏进度条的显示」：每每对于首屏优化后的数据量并不满意的话，同时也不能进一步缩短首屏包的长度了，就可使用进度条的方式，来提醒用户进行等待。

讲完了图片这一块数据资源的处理，每每咱们须要去优化一下异步请求这一部分的内容。由于，异步的数据获取也是前端不可分割的。这一部分咱们也能够作必定的处理：

  1. 异步请求的优化：

    • 使用正常的json数据格式进行交互
    • 部分经常使用数据的缓存
    • 数据埋点和统计

    「JSON交互」，JSON的数据格式轻巧，结构简单，每每能够大大优化先后端的数据通讯。「经常使用数据的缓存」，能够将一些用户的基本信息等经常使用的信息作一个缓存，这样能够保证ajax请求的减小。同时，HTML5新增的storage的内容，也不用怕cookie暴露，引发的信息泄漏问题。「数据埋点和统计」，对于资深的程序员来讲，比较了解。并且目前的大部分公司也会作这方面的处理。有心的小伙伴能够自行查阅。

最后，还有就是大量数据的运算。对于javascript语言来讲，自己的单线程就限制了它并不能计算大量的数据，每每会形成页面的卡顿。而可能业务中有些复杂的UI须要去运行大量的运算，因此，webWorker的使用是相当重要的。或许，前端标准普及的落后，会致使你们对于这些新生事物的短暂缺失吧。

浏览器访问优化

浏览器请求处理流程以下图：

 

一、减小http请求，合理设置 HTTP缓存

        http协议是无状态的应用层协议，意味着每次http请求都须要创建通讯链路、进行数据传输，而在服务器端，每一个http都须要启动独立的线程去处理。这些通讯和服务的开销都很昂贵，减小http请求的数目可有效提升访问性能。

        减小http的主要手段是合并CSS、合并javascript、合并图片。将浏览器一次访问须要的javascript和CSS合并成一个文件，这样浏览器就只须要一次请求。图片也能够合并，多张图片合并成一张，若是每张图片都有不一样的超连接，可经过CSS偏移响应鼠标点击操做，构造不一样的URL。
         缓存的力量是强大的，恰当的缓存设置能够大大的减小 HTTP请求。假设某网站首页，当浏览器没有缓存的时候访问一共会发出 78个请求，共 600多 K数据，而当第二次访问即浏览器已缓存以后访问则仅有 10个请求，共 20多 K数据。 (这里须要说明的是，若是直接 F5刷新页面的话效果是不同的，这种状况下请求数仍是同样，不过被缓存资源的请求服务器是 304响应，只有 Header没有Body，能够节省带宽 )

        怎样才算合理设置 ?原则很简单，能缓存越多越好，能缓存越久越好。例如，不多变化的图片资源能够直接经过 HTTP Header中的Expires设置一个很长的过时头 ;变化不频繁而又可能会变的资源可使用 Last-Modifed来作请求验证。尽量的让资源可以在缓存中待得更久。关于 HTTP缓存的具体设置和原理此处就再也不详述了。

二、使用浏览器缓存

        对一个网站而言，CSS、javascript、logo、图标这些静态资源文件更新的频率都比较低，而这些文件又几乎是每次http请求都须要的，若是将这些文件缓存在浏览器中，能够极好的改善性能。经过设置http头中的cache-control和expires的属性，可设定浏览器缓存，缓存时间能够是数天，甚至是几个月。

        在某些时候，静态资源文件变化须要及时应用到客户端浏览器，这种状况，可经过改变文件名实现，即更新javascript文件并非更新javascript文件内容，而是生成一个新的JS文件并更新HTML文件中的引用。
        使用浏览器缓存策略的网站在更新静态资源时，应采用逐量更新的方法，好比须要更新10个图标文件，不宜把10个文件一次所有更新，而是应该一个文件一个文件逐步更新，并有必定的间隔时间，以避免用户浏览器突然大量缓存失效，集中更新缓存，形成服务器负载骤增、网络堵塞的状况。

三、启用压缩

        在服务器端对文件进行压缩，在浏览器端对文件解压缩，可有效减小通讯传输的数据量。若是能够的话，尽量的将外部的脚本、样式进行合并，多个合为一个。文本文件的压缩效率可达到80%以上，所以HTML、CSS、javascript文件启用GZip压缩可达到较好的效果。可是压缩对服务器和浏览器产生必定的压力，在通讯带宽良好，而服务器资源不足的状况下要权衡考虑。

四、CSS Sprites

合并 CSS图片，减小请求数的又一个好办法。

五、LazyLoad Images

        这条策略实际上并不必定能减小 HTTP请求数，可是却能在某些条件下或者页面刚加载时减小 HTTP请求数。对于图片而言，在页面刚加载的时候能够只加载第一屏，当用户继续日后滚屏的时候才加载后续的图片。这样一来，假如用户只对第一屏的内容感兴趣时，那剩余的图片请求就都节省了。

六、CSS放在页面最上部，javascript放在页面最下面

       浏览器会在下载完成所有CSS以后才对整个页面进行渲染，所以最好的作法是将CSS放在页面最上面，让浏览器尽快下载CSS。若是将 CSS放在其余地方好比 BODY中，则浏览器有可能还未下载和解析到 CSS就已经开始渲染页面了，这就致使页面由无 CSS状态跳转到 CSS状态，用户体验比较糟糕，因此能够考虑将CSS放在HEAD中。

        Javascript则相反，浏览器在加载javascript后当即执行，有可能会阻塞整个页面，形成页面显示缓慢，所以javascript最好放在页面最下面。但若是页面解析时就须要用到javascript，这时放到底部就不合适了。

        Lazy Load Javascript（只有在须要加载的时候加载，在通常状况下并不加载信息内容。）随着 Javascript框架的流行，愈来愈多的站点也使用起了框架。不过，一个框架每每包括了不少的功能实现，这些功能并非每个页面都须要的，若是下载了不须要的脚本则算得上是一种资源浪费 -既浪费了带宽又浪费了执行花费的时间。目前的作法大概有两种，一种是为那些流量特别大的页面专门定制一个专用的 mini版框架，另外一种则是 Lazy Load。

七、异步请求Callback（就是将一些行为样式提取出来，慢慢的加载信息的内容）

在某些页面中可能存在这样一种需求，须要使用 script标签来异步的请求数据。相似：

 
<span style="font-size:14px;">/*Callback 函数*/
 
function myCallback(info){
 
//do something here
 
}
 
　HTML:
 
　　Callback返回的内容 :
 
myCallback('Hello world!');
 
</span>

 

像以上这种方式直接在页面上写 <script> 对页面的性能也是有影响的，即增长了页面首次加载的负担，推迟了 DOMLoaded和window.onload 事件的触发时机。若是时效性容许的话，能够考虑在 DOMLoaded事件触发的时候加载，或者使用 setTimeout方式来灵活的控制加载的时机。

八、减小cookie传输

        一方面，cookie包含在每次请求和响应中，太大的cookie会严重影响数据传输，所以哪些数据须要写入cookie须要慎重考虑，尽可能减小cookie中传输的数据量。另外一方面，对于某些静态资源的访问，如CSS、script等，发送cookie没有意义，能够考虑静态资源使用独立域名访问，避免请求静态资源时发送cookie，减小cookie传输次数。

九、Javascript代码优化

(1). DOM　　

a.HTML Collection（HTML收集器，返回的是一个数组内容信息） 
　　在脚本中 document.images、document.forms、getElementsByTagName()返回的都是HTMLCollection类型的集合，在平时使用的时候大多将它做为数组来使用，由于它有 length属性，也可使用索引访问每个元素。不过在访问性能上则比数组要差不少，缘由是这个集合并非一个静态的结果，它表示的仅仅是一个特定的查询，每次访问该集合时都会从新执行这个查询从而更新查询结果。所谓的“访问集合” 包括读取集合的 length属性、访问集合中的元素。 
　　所以，当你须要遍历 HTML Collection的时候，尽可能将它转为数组后再访问，以提升性能。即便不转换为数组，也请尽量少的访问它，例如在遍历的时候能够将 length属性、成员保存到局部变量后再使用局部变量。　　 
b. Reflow & Repaint　　 
　　除了上面一点以外， DOM操做还须要考虑浏览器的Reflow和Repaint ，由于这些都是须要消耗资源的。

(2). 慎用 with　

with(obj){ p = 1}; 代码块的行为其实是修改了代码块中的执行环境 ，将obj放在了其做用域链的最前端，在 with代码块中访问非局部变量是都是先从 obj上开始查找，若是没有再依次按做用域链向上查找，所以使用 with至关于增长了做用域链长度。而每次查找做用域链都是要消耗时间的，过长的做用域链会致使查找性能降低。 
　　所以，除非你能确定在 with代码中只访问 obj中的属性，不然慎用 with，替代的可使用局部变量缓存须要访问的属性。

(3). 避免使用 eval和 Function

每次 eval 或Function 构造函数做用于字符串表示的源代码时，脚本引擎都须要将源代码转换成可执行代码。这是很消耗资源的操做 —— 一般比简单的函数调用慢 100倍以上。 
　　eval 函数效率特别低，因为事先没法知晓传给 eval 的字符串中的内容，eval在其上下文中解释要处理的代码，也就是说编译器没法优化上下文，所以只能有浏览器在运行时解释代码。这对性能影响很大。 
　　Function 构造函数比 eval略好，由于使用此代码不会影响周围代码 ;但其速度仍很慢。 
　　此外，使用 eval和 Function也不利于Javascript 压缩工具执行压缩。

(4). 减小做用域链查找

前文谈到了做用域链查找问题，这一点在循环中是尤为须要注意的问题。若是在循环中须要访问非本做用域下的变量时请在遍历以前用局部变量缓存该变量，并在遍历结束后再重写那个变量，这一点对全局变量尤为重要，由于全局变量处于做用域链的最顶端，访问时的查找次数是最多的。 
低效率的写法：

 
<span style="font-size:14px;">// 全局变量
 
var globalVar = 1;
 
function myCallback(info){
 
for( var i = 100000; i--;){
 
//每次访问 globalVar 都须要查找到做用域链最顶端，本例中须要访问 100000 次
 
globalVar += i;
 
}
 
}
 
</span>

 

更高效的写法：

 
<span style="font-size:14px;">// 全局变量
 
var globalVar = 1;
 
function myCallback(info){
 
//局部变量缓存全局变量
 
var localVar = globalVar;
 
for( var i = 100000; i--;){
 
//访问局部变量是最快的
 
localVar += i;
 
}
 
//本例中只须要访问 2次全局变量
 
在函数中只须要将 globalVar中内容的值赋给localVar 中
 
globalVar = localVar;
 
}
 
</span>

 

此外，要减小做用域链查找还应该减小闭包的使用。

(5). 数据访问

　　Javascript中的数据访问包括直接量 (字符串、正则表达式 )、变量、对象属性以及数组，其中对直接量和局部变量的访问是最快的，对对象属性以及数组的访问须要更大的开销。当出现如下状况时，建议将数据放入局部变量： 
　　a. 对任何对象属性的访问超过 1次 
　　b. 对任何数组成员的访问次数超过 1次 
　　另外，还应当尽量的减小对对象以及数组深度查找。

(6). 字符串拼接

在 Javascript中使用”+”号来拼接字符串效率是比较低的，由于每次运行都会开辟新的内存并生成新的字符串变量，而后将拼接结果赋值给新变量。与之相比更为高效的作法是使用数组的 join方法，即将须要拼接的字符串放在数组中最后调用其 join方法获得结果。不过因为使用数组也有必定的开销，所以当须要拼接的字符串较多的时候能够考虑用此方法。

十、CSS选择符优化

在大多数人的观念中，都以为浏览器对 CSS选择符的解析式从左往右进行的，例如 
#toc A { color: #444; }这样一个选择符，若是是从右往左解析则效率会很高，由于第一个 ID选择基本上就把查找的范围限定了，但实际上浏览器对选择符的解析是从右往左进行的。如上面的选择符，浏览器必须遍历查找每个 A标签的祖先节点，效率并不像以前想象的那样高。根据浏览器的这一行为特色，在写选择符的时候须要注意不少事项，有兴趣的童鞋能够去了解一下。

CDN加速

CDN（contentdistribute network，内容分发网络）的本质仍然是一个缓存，并且将数据缓存在离用户最近的地方，使用户以最快速度获取数据，即所谓网络访问第一跳，以下图。

 

因为CDN部署在网络运营商的机房，这些运营商又是终端用户的网络服务提供商，所以用户请求路由的第一跳就到达了CDN服务器，当CDN中存在浏览器请求的资源时，从CDN直接返回给浏览器，最短路径返回响应，加快用户访问速度，减小数据中心负载压力。 
CDN缓存的通常是静态资源，如图片、文件、CSS、script脚本、静态网页等，可是这些文件访问频度很高，将其缓存在CDN可极大改善网页的打开速度。

反向代理

传统代理服务器位于浏览器一侧，代理浏览器将http请求发送到互联网上，而反向代理服务器位于网站机房一侧，代理网站web服务器接收http请求。以下图所示：

联系我们 沪ICP备13005482号-10