前端优化方案

时间 2019-11-24

标签前端优化方案繁體版

原文原文链接

1 优化css

1.1 避免使用CSS表达式

用CSS表达式动态设置CSS属性，是一种强大又危险的方式。从IE5开始支持，但从IE8起就不推荐使用了。例如，能够用CSS表达式把背景颜色设置成按小时交替的javascript

尽可能减小标签选择器的使用
尽量少使用id选择器，多使用样式选择器(通用性强)
减小选择器前缀，例如.headerBox .nav .left a{} 选择器是从右向左查询的
避免使用css表达式

background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );
复制代码

1.2 减小页面中的冗余代码

尽量提升方法的重复使用率：“低耦合高内聚”php

1.3 选择舍弃@import

前面提到了一个最佳实践：为了实现逐步渲染，CSS应该放在顶部。在IE中用@import与在底部用<link>效果同样，因此最好不要用它。css

1.4 避免使用滤镜

IE专有的AlphaImageLoader滤镜能够用来修复IE7以前的版本中半透明PNG图片的问题。在图片加载过程当中，这个滤镜会阻塞渲染，卡住浏览器，还会增长内存消耗并且是被应用到每一个元素的，而不是每一个图片，因此会存在一大堆问题。
最好的方法是干脆不要用AlphaImageLoader，而优雅地降级到用在IE中支持性很好的PNG8图片来代替。若是非要用AlphaImageLoader，应该用下划线hack：_filter来避免影响IE7及更高版本的用户。html

1.5 把样式表放在顶部

把样式表放到文档的HEAD部分能让页面看起来加载地更快。这是由于把样式表放在head里能让页面逐步渲染。
关注性能的前端工程师想让页面逐步渲染。也就是说，咱们想让浏览器尽快显示已有内容，这在页面上有一大堆内容或者用户网速很慢时显得尤其重要。给用户显示反馈（好比进度指标）的重要性已经被普遍研究过，而且被记录下来了。在咱们的例子中，HTML页面就是进度指标！当浏览器逐渐加载页面头部，导航条，顶部logo等等内容的时候，这些都被正在等待页面加载的用户看成反馈，可以提升总体用户体验。前端

1.6 压缩 css

使用在线网站进行压缩
使用html-minifier 对html 中的css 进行压缩
使用clean-css 对css进行压缩
webpack,gulp打包工具

2 优化图片

2.1 图片格式

尝试把GIF格式转换成PNG格式，看看是否节省空间。在全部的PNG图片上运行pngcrush（或者其它PNG优化工具）
vue

2.2 优化CSS Sprite

采用css雪碧图(css sprit/css 图片精灵)技术，吧一些小图合并在一张大图上面，使用的时候，经过北京图片定位，定位到具体的某一张小图上java

在Sprite图片中横向排列通常都比纵向排列的最终文件小
组合Sprite图片中的类似颜色能够保持低色数，最理想的是256色如下PNG8格式
“对移动端友好”，不要在Sprite图片中留下太大的空隙。虽然不会在很大程度上影响图片文件的大小，但这样作能够节省用户代理把图片解压成像素映射时消耗的内存。100×100的图片是1万个像素，而1000×1000的图片就是100万个像素了。

.pubBg{
	background:url('../img/sprit.png') no-repeat;
  background-size:x y; // 和原图的大小保持一致
}

.box{
	background-position:x y; // 经过背景定位，定位到具体的位置，展现不一样的图片极客
}
复制代码

页面中无法送一次http请求，都须要完成请求+响应这个完整的http事务，会消耗一些时间，也可能会致使http连接通道的堵塞,为了提升页面的加载速度和运行的性能，咱们应该减小http的请求次数和减小请求内容的大小。webpack

2.3 图像映射

能够把多张图片合并成单张图片，总大小是同样的，但减小了请求数并加速了页面加载。图片映射只有在图像在页面中连续的时候才有用，好比导航条。给image map设置坐标的过程既无聊又容易出错，用image map来作导航也不容易，因此不推荐用这种方式。ios

2.4 行内图片（Base64编码）

用data: URL模式来把图片嵌入页面。这样会增长HTML文件的大小，把行内图片放在（缓存的）样式表中是个好办法，并且成功避免了页面变“重”。但目前主流浏览器并不能很好地支持行内图片。
减小页面的HTTP请求数是个起点，这是提高站点首次访问速度的重要指导原则。css3

2.5 不要用HTML缩放图片

不要由于在HTML中能够设置宽高而使用本不须要的大图。若是须要

<img width="100" height="100" src="mycat.jpg" alt="My Cat" />
复制代码

那么图片自己（mycat.jpg）应该是100x100px的，而不是去缩小500x500px的图片。

2.6 用小的可缓存的favicon.ico（P.S. 收藏夹图标）

favicon.ico是放在服务器根目录的图片，它会带来一堆麻烦，由于即使你无论它，浏览器也会自动请求它，因此最好不要给一个404 Not Found响应。并且只要在同一个服务器上，每次请求它时都会发送cookie，此外这个图片还会干扰下载顺序，例如在IE中，当你在onload中请求额外组件时，将会先下载favicon。
因此为了缓解favicon.ico的缺点，应该确保：

足够小，最好在1K如下
设置合适的有效期HTTP头（之后若是想换的话就不能重命名了），把有效期设置为几个月后通常比较安全，能够经过检查当前favicon.ico的最后修改日期来确保变动能让浏览器知道。

2.7 压缩image

使用雪花图
- 使用雪花图 www.spritecow.com/
使用矢量图
- 使用矢量图字体 fontawesome.dashgame.com/
- 使用阿里矢量图库 www.iconfont.cn/
- 使用矢量图转成字体 icomoon.io/
使用base64转换
使用网站压缩
- 使用无损压缩 tinypng.com/
- png转换webp zhitu.isux.us/
合理使用格式图片
- jpg有损压缩，压缩率搞，不支持透明
- png支持透明，浏览器兼容好
- webp压缩程度更好，在ios webview有兼容性问题
- svg矢量图，代码内嵌，相对于较小，图片样式相对简单的场景

在使用webp的过程当中，会产生一些浏览器兼容问题

function checkWebp() {

    try{

        return (document.createElement('canvas').toDataURL('image/webp').indexOf('data:image/webp') == 0);

       }catch(err) {

        return false;

       }

}



$(document).ready(function() {

        var webp_good = checkWebp();

        if(webp_good == false) {

            $('img').each(function() {

            var src = $(this).attr('src');

            if(typeof src != 'undefined') {

                src = src.replace('/format,webp', '/format,jpg'); //将webp格式转换成jpg格式

                $(this).attr('src', src);

            }

            var original = $(this).attr('original');        //针对用了懒加载的状况

            if(typeof original != 'undefined') {

                original = original.replace('/format,webp', '/format,jpg'); //将webp格式转换成jpg格式

                $(this).attr('original', original);

            }

        })

    }

})
复制代码

2.8 图片懒加载

采用图片懒加载技术，在页面开始加载时候，不请求真实的图片地址，而是默认图占位，当页面加载完成后，在根据相关的条件依次加载真实的图片(减小页面首次加载http请求的次数)
真实项目中，咱们开始图片都不加载，页面首次加载完成，先把第一屏幕中看见的图片进行加载，随着页面的滚动，在下面区域中可以呈现出来的图片进行加载

根据图片懒加载技术，咱们还能够扩充出，数据懒加载

开始加载页面的时候，咱们只把首屏或者前两屏的数据从服务器进行请求(有些网站首屏数据是后台渲染好，总体返回给客户端呈现的)

当页面下拉，滚动到哪一个区域，在把这个区域须要的数据进行请求(请求回来数据绑定以及图片延迟加载等)
分页展现技术采用的也是数据懒加载思想实现的:若是咱们开始请求获取的数据是不少的数据，咱们最好分批请求，开始只请求第一页的数据，当页面点击第二页(微博是下拉到必定距离后，再请求第二页数据)的时候请求第二页数据。

3 优化js

3.1 去除重复脚本

页面含有重复的脚本文件会影响性能，这可能和你想象的不同。在对美国前10大web站点的评审中，发现只有2个站点含有重复脚本。两个主要缘由增长了在单一页面中出现重复脚本的概率：团队大小和脚本数量。在这种状况下，重复脚本会建立没必要要的HTTP请求，执行无用的JavaScript代码，而影响页面性能。
IE会产生没必要要的HTTP请求，而Firefox不会。在IE中，若是一个不可缓存的外部脚本被页面引入了两次，它会在页面加载时产生两个HTTP请求。即便脚本是可缓存的，在用户从新加载页面时也会产生额外的HTTP请求。
除了产生没有意义的HTTP请求以外，屡次对脚本求值也会浪费时间。由于不管脚本是否可缓存，在Firefox和IE中都会执行冗余的JavaScript代码。
避免不当心把相同脚本引入两次的一种方法就是在模版系统中实现脚本管理模块。典型的脚本引入方法就是在HTML页面中用SCRIPT标签：

<script type="text/javascript" src="menu_1.0.17.js"></script>
复制代码

3.2 尽可能减小DOM访问

一个复杂的页面意味着要下载更多的字节，并且用JavaScript访问DOM也会更慢。举个例子，想要添加一个事件处理器的时候，循环遍历页面上的500个DOM元素和5000个DOM元素是有区别的。
操做dom的弊端

dom存在映射在机制(js中的dom元素对象和页面中dom结构是存在映射机制的，一改则都改)，这种映射机制，是浏览器安卓w3c标准完成对js语言的构建和dom的构建(其实就是构建一个监听机制)，操做dom是同事修改两个地址，相对于一些其余的js编程来讲消耗性能的。
页面中的dom结构改变或者样式改变，会触发浏览器的回流(浏览器会把dom结构从新进行计算，这个操做很耗性能)和重绘(吧一个元素的样式从新渲染)

在作dom事件绑定的时候，尽可能避免一个个的事件绑定，二采用性能更高的事件委托来实现

事件委托(事件代理) 把时间板顶给外层容器，当里面的后代元素相关行为被处罚，外层容器绑定的方法也会被触发执行(冒泡传播机制致使)，经过的事件源是谁，咱们作不一样的操做便可

用JavaScript访问DOM元素是很慢的，因此，为了让页面反应更迅速，应该：

缓存已访问过的元素的索引
先“离线”更新节点，再把它们添到DOM树上
避免用JavaScript修复布局问题

DOM元素的数量很容易测试，只须要在控制台里输入

document.getElementsByTagName('*').length
复制代码

3.3 用智能的事件处理器

有时候感受页面反映不够灵敏，是由于有太多频繁执行的事件处理器被添加到了DOM树的不一样元素上，这就是推荐使用事件委托的缘由。若是一个div里面有10个按钮，应该只给div容器添加一个事件处理器，而不是给每一个按钮都添加一个。事件可以冒泡，因此能够捕获事件并得知哪一个按钮是事件源。

3.4 更多异步操做编译

同步编程会致使:上面东西完不成，下面任务也作不了，咱们开发的时候，能够把某一个区域模块都设置为异步编程，这样只要模块之间没有必然的前后顺序，均可以独立进行加载，不会受到上面模块的堵塞影响(用的很少)
尤为是ajax数据请求，咱们通常都要使用异步编程，最好是基于promise设计模式进行管理(项目中常用fetch、vue、axios)等插件进行ajax请求处理，由于这些插件中就是基于promise设计模式对ajax进行了封装处理
在真实的项目中，咱们尽量避免一次性循环过多数据(由于循环操做是同步编程)，尤为是要避免while致使的死循环操做

3.5 JS中避免使用eval

性能消耗大
代码压缩后，容易出现代码执行错乱问题

3.6 JS中尽可能减小闭包的使用

闭包会造成一个不销毁的栈内存，过多的栈内存累积影响页面的性能
还会容易致使内存的泄露
闭包也有本身的优点:保存和保护，咱们只能尽可能减小，可是没法避免

3.7 尽可能使用css3动替代js动画

css3的动画或者变形都开启了硬件加速，性能比js动画好

3.8 缓存作处理

对于不常常更新的数据，最好采用浏览器的304缓存作处理
例如:
第一次请求css和js下拉，浏览器会把请求的内容缓存起来，若是作了304处理，用户再次请求css和js直接从缓存中读取，不须要再去服务器获取了(减小了http请求次数)
当用户强制刷新页面(ctrl+f5)或者当前缓存的css或者js发生了变更，都会重新从服务器端拉取
对于客户端来说，咱们还能够基于localStronge来作一些本地存储，例如:第一次请求的数据或者不常常更新的css和js，咱们均可以吧内容存储在本地，下一次页面加载，咱们从本地中获取便可，咱们设定必定的期限或者一些标识，能够控制在某个阶段从新从服务器获取

3.9 设计模式

编写js代码的时候尽量使用设计模式来构建体系，方便后期的维护，也提升了扩充性等

3.10 把脚本放在底部

脚本会阻塞并行下载，HTTP/1.1官方文档建议浏览器每一个主机名下并行下载的组件数不要超过两个，若是图片来自多个主机名，并行下载的数量就能够超过两个。若是脚本正在下载，浏览器就不开始任何其它下载任务，即便是在不一样主机名下的。
有时候，并不容易把脚本移动到底部。举个例子，若是脚本是用document.write插入到页面内容中的，就没办法再往下移了。还可能存在做用域问题，在多数状况下，这些问题都是能够解决的。
一个常见的建议是用推迟（deferred）脚本，有DEFER属性的脚本意味着不能含有document.write，而且提示浏览器告诉他们能够继续渲染。不幸的是，Firefox不支持DEFER属性。在IE中，脚本可能被推迟，但不尽如人意。若是脚本能够推迟，咱们就能够把它放到页面底部，页面就能够更快地载入。

3.11 压缩js

使用在线网站进行压缩
使用html-minifier 对html 中的css 进行压缩
使用uglifjs2对js进行压缩
webpack,gulp打包工具

4 优化html

4.1 audio或者video标签

若是当页面中出现audio或者video标签，咱们最好设置它们的preload=:页面加载的时候，音视频资源不进行加载，播放的时候再开始加载(减小页面首次加载http请求的次数)

preload=auto 页面首次加载的时候就把音频资源进行加载
preload=metadata 页面首次加载的时候只能音视资源的头部信息进行加载

4.2 尽可能少用iframe

用iframe能够把一个HTML文档插入到父文档里，重要的是明白iframe是如何工做的并高效地使用它。
<iframe>的优势：

引入缓慢的第三方内容，好比标志和广告
安全沙箱
并行下载脚本

<iframe>的缺点：

代价高昂，即便是空白的iframe
阻塞页面加载
非语义

4.3 杜绝404

HTTP请求代价高昂，彻底没有必要用一个HTTP请求去获取一个无用的响应（好比404 Not Found），只会拖慢用户体验而没有任何好处。
有些站点用的是有帮助的404——“你的意思是xxx？”，这样作有利于用户体验，，但也浪费了服务器资源（好比数据库等等）。最糟糕的是连接到的外部JavaScript有错误并且结果是404。首先，这种下载将阻塞并行下载。其次，浏览器会试图解析404响应体，由于它是JavaScript代码，须要找出其中可用的部分。

5 移动端

5.1 保证全部组件都小于25K

这个限制是由于iPhone不能缓存大于25K的组件，注意这里指的是未压缩的大小。这就是为何缩减内容自己也很重要，由于单纯的gzip可能不够。

5.2 把组件打包到一个复合文档里

把各个组件打包成一个像有附件的电子邮件同样的复合文档里，能够用一个HTTP请求获取多个组件（记住一点：HTTP请求是代价高昂的）。用这种方式的时候，要先检查用户代理是否支持（iPhone就不支持）。

6 cookie

6.1 给Cookie减肥

使用cookie的缘由有不少，好比受权和个性化。HTTP头中cookie信息在web服务器和浏览器之间交换。重要的是保证cookie尽量的小，以最小化对用户响应时间的影响。

清除没必要要的cookie
保证cookie尽量小，以最小化对用户响应时间的影响
注意给cookie设置合适的域级别，以避免影响其它子域
设置合适的有效期，更早的有效期或者none能够更快的删除cookie，提升用户响应时间

6.2 把组件放在不含cookie的域下

当浏览器发送对静态图像的请求时，cookie也会一块儿发送，而服务器根本不须要这些cookie。因此它们只会形成没有意义的网络通讯量，应该确保对静态组件的请求不含cookie。能够建立一个子域，把全部的静态组件都部署在那儿。
若是域名是www.example.org，能够把静态组件部署到static.example.org。然而，若是已经在顶级域example.org或者www.example.org设置了cookie，那么全部对static.example.org的请求都会含有这些cookie。这时候能够再买一个新域名，把全部的静态组件部署上去，并保持这个新域名不含cookie。Yahoo!用的是yimg.com，YouTube是ytimg.com，Amazon是images-amazon.com等等。
把静态组件部署在不含cookie的域下还有一个好处是有些代理可能会拒绝缓存带cookie的组件。有一点须要注意：若是不知道应该用example.org仍是www.example.org做为主页，能够考虑一下cookie的影响。省略www的话，就只能把cookie写到*.example.org，因此由于性能缘由最好用www子域，而且把cookie写到这个子域下。

7 服务器

7.1 Gzip组件

前端工程师能够想办法明显地缩短经过网络传输HTTP请求和响应的时间。毫无疑问，终端用户的带宽速度，网络服务商，对等交换点的距离等等，都是开发团队所没法控制的。但还有别的可以影响响应时间的因素，压缩能够经过减小HTTP响应的大小来缩短响应时间。
从HTTP/1.1开始，web客户端就有了支持压缩的Accept-Encoding HTTP请求头。

1	`Accept-Encoding: gzip, deflate`

若是web服务器看到这个请求头，它就会用客户端列出的一种方式来压缩响应。web服务器经过Content-Encoding相应头来通知客户端。

1	`Content-Encoding: gzip`

尽量多地用gzip压缩可以给页面减肥，这也是提高用户体验最简单的方法。

7.2 避免图片src属性为空

Image with empty string src属性是空字符串的图片很常见，主要以两种形式出现：

straight HTML
JavaScript
var img = new Image(); img.src = “”;

这两种形式都会引发相同的问题：浏览器会向服务器发送另外一个请求。

7.3 配置ETags

实体标签（ETags），是服务器和浏览器用来决定浏览器缓存中组件与源服务器中的组件是否匹配的一种机制（“实体”也就是组件：图片，脚本，样式表等等）。添加ETags能够提供一种实体验证机制，比最后修改日期更加灵活。一个ETag是一个字符串，做为一个组件某一具体版本的惟一标识符。惟一的格式约束是字符串必须用引号括起来，源服务器用相应头中的ETag来指定组件的ETag：

1 2 3 4	`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传回源服务器。若是ETags匹配成功，会返回一个304状态码，这样就减小了12195个字节的响应体。
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

** **

7.4 对Ajax用GET请求

邮箱团队发现使用XMLHttpRequest时，浏览器的POST请求是经过一个两步的过程来实现的：先发送HTTP头，在发送数据。因此最好用GET请求，它只须要发送一个TCP报文（除非cookie特别多）。IE的URL长度最大值是2K，因此若是要发送的数据超过2K就没法使用GET了。
POST请求的一个有趣的反作用是实际上没有发送任何数据，就像GET请求同样。正如HTTP说明文档中描述的，GET请求是用来检索信息的。因此它的语义只是用GET请求来请求数据，而不是用来发送须要存储到服务器的数据。

7.5 尽早清空缓冲区

当用户请求一个页面时，服务器须要用大约200到500毫秒来组装HTML页面，在这期间，浏览器闲等着数据到达。PHP中有一个flush()函数，容许给浏览器发送一部分已经准备完毕的HTML响应，以便浏览器能够在后台准备剩余部分的同时开始获取组件，好处主要体如今很忙的后台或者很“轻”的前端页面上（P.S. 也就是说，响应时耗主要在后台方面时最能体现优点）。
较理想的清空缓冲区的位置是HEAD后面，由于HTML的HEAD部分一般更容易生成，而且容许引入任何CSS和JavaScript文件，这样就可让浏览器在后台还在处理的时候就开始并行获取组件。
例如：

&emsp;<br />... <!-- css, js --><br />    </head><br />    <?php flush(); ?><br />    <body><br />      ... <!-- content --><br /> 
复制代码

7.6 使用CDN（内容分发网络）

用户与服务器的物理距离对响应时间也有影响。把内容部署在多个地理位置分散的服务器上能让用户更快地载入页面。但具体要怎么作呢？
实现内容在地理位置上分散的第一步是：不要尝试去从新设计你的web应用程序来适应分布式结构。这取决于应用程序，改变结构可能包括一些让人望而生畏的任务，好比同步会话状态和跨服务器复制数据库事务（翻译可能不许确）。缩短用户和内容之间距离的提议可能被推迟，或者根本不可能经过，就是由于这个难题。
记住终端用户80%到90%的响应时间都花在下载页面组件上了：图片，样式，脚本，Flash等等，这是业绩黄金法则。最好先分散静态内容，而不是一开始就从新设计应用程序结构。这不只可以大大减小响应时间，还更容易表现出CDN的功劳。
内容分发网络（CDN）是一组分散在不一样地理位置的web服务器，用来给用户更高效地发送内容。典型地，选择用来发送内容的服务器是基于网络距离的衡量标准的。例如：选跳数（hop）最少的或者响应时间最快的服务器。

7.7 添上Expires或者Cache-Control HTTP头

这条规则有两个方面：

对于静态组件：经过设置一个遥远的未来时间做为Expires来实现永不失效
多余动态组件：用合适的Cache-ControlHTTP头来让浏览器进行条件性的请求

网页设计愈来愈丰富，这意味着页面里有更多的脚本，图片和Flash。站点的新访客可能仍是不得不提交几个HTTP请求，但经过使用有效期能让组件变得可缓存，这避免了在接下来的浏览过程当中没必要要的HTTP请求。有效期HTTP头一般被用在图片上，但它们应该用在全部组件上，包括脚本、样式和Flash组件。
浏览器（和代理）用缓存来减小HTTP请求的数目和大小，让页面可以更快加载。web服务器经过有效期HTTP响应头来告诉客户端，页面的各个组件应该被缓存多久。用一个遥远的未来时间作有效期，告诉浏览器这个响应在2010年4月15日前不会改变。

1	`Expires: Thu, 15 Apr 2010 20:00:00 GMT`

若是你用的是Apache服务器，用ExpiresDefault指令来设置相对于当前日期的有效期。下面的例子设置了从请求时间起10年的有效期：
ExpiresDefault "access plus 10 years"

7.8 减小dns查询

域名系统创建了主机名和IP地址间的映射，就像电话簿上人名和号码的映射同样。当你在浏览器输入www.shanghai70.com的时候，浏览器就会联系DNS解析器返回服务器的IP地址。DNS是有成本的，它须要20到120毫秒去查找给定主机名的IP地址。在DNS查找完成以前，浏览器没法从主机名下载任何东西。
DNS查找被缓存起来更高效，由用户的ISP（网络服务提供商）或者本地网络存在一个特殊的缓存服务器上，但还能够缓存在我的用户的计算机上。DNS信息被保存在操做系统的DNS cache(微软Windows上的”DNS客户端服务”)里。大多数浏览器有独立于操做系统的本身的cache。只要浏览器在本身的cache里还保留着这条记录，它就不会向操做系统查询DNS。
IE默认缓存DNS查找30分钟，写在DnsCacheTimeout注册表设置中。Firefox缓存1分钟，能够用network.dnsCacheExpiration配置项设置。(Fasterfox把缓存时间改为了1小时 P.S. Fasterfox是FF的一个提速插件)
若是客户端的DNS cache是空的（包括浏览器的和操做系统的），DNS查找数等于页面上不一样的主机名数，包括页面URL，图片，脚本文件，样式表，Flash对象等等组件中的主机名，减小不一样的主机名就能够减小DNS查找。
减小不一样主机名的数量同时也减小了页面可以并行下载的组件数量，避免DNS查找削减了响应时间，而减小并行下载数量却增长了响应时间。个人原则是把组件分散在2到4个主机名下，这是同时减小DNS查找和容许高并发下载的折中方案。

7.9 避免重定向

重定向用301和302状态码，下面是一个有301状态码的HTTP头

HTTP/1.1 301 Moved Permanently Location: example.com/newuri Content-Type: text/html

浏览器会自动跳转到Location域指明的URL。重定向须要的全部信息都在HTTP头部，而响应体通常是空的。其实额外的HTTP头，好比Expires和Cache-Control也表示重定向。除此以外还有别的跳转方式：refresh元标签和JavaScript，但若是你必须得作重定向，最好用标准的3xxHTTP状态码，主要是为了让返回按钮能正常使用。
牢记重定向会拖慢用户体验，在用户和HTML文档之间插入重定向会延迟页面上的全部东西，页面没法渲染，组件也没法开始下载，直到HTML文档被送达浏览器。
有一种常见的极其浪费资源的重定向，并且web开发人员通常都意识不到这一点，就是URL尾部缺乏一个斜线的时候。例如，跳转到www.shanghai70.com/a会返回一个重定向到www.shanghai70.com/b的301响应（注意添在尾部的斜线）。在Apache中能够用Alias，mod_rewrite或者DirectorySlash指令来取消没必要要的重定向。
重定向最多见的用途是把旧站点链接到新的站点，还能够链接同一站点的不一样部分，针对用户的不一样状况（浏览器类型，用户账号类型等等）作一些处理。用重定向来链接两个网站是最简单的，只须要少许的额外代码。虽然在这些时候使用重定向减小了开发人员的开发复杂度，但下降了用户体验。一种替代方案是用Alias和mod_rewrite，前提是两个代码路径都在相同的服务器上。若是是由于域名变化而使用了重定向，就能够建立一条CNAME（建立一个指向另外一个域名的DNS记录做为别名）结合Alias或者mod_rewrite指令。

7.10 Json格式传输

在客户端和服务器端进行数据通讯的时候，咱们尽可能采用json格式进行数据传输

json格式的数据，可以清晰明了的展现出数据结构，并且也方便咱们获取的操做
相对于很早之前的xml格式传输，json格式的数据更加轻量级
客户端和服务器端都支持json格式数据的处理，处理起来很是的方便

真实项目中:并非全部的数据都基于json，咱们尽量这样作，可是对于某些特殊的需求(例如文件流的传输或者文档传输)，使用json就不合适了