vue-cli 是一个官方发布 vue.js 项目脚手架，使用 vue-cli 可以快速创建 vue 项目，GitHub地址是: https://github.com/vuejs/vue-cli

一、 安装 node

首先需要安装node环境，可以直接到官网https://nodejs.org/en/下载安装包。

（中文官网http://nodejs.cn/）

安装完成后，可以命令行工具中输入node -v和npm -v，如果能显示出版本号，就说明安装成功。

二、安装 vue-cli

安装好了 node，我们可以直接全局安装 vue-cli：

1

npm install -g vue-cli

但是这种安装方式比较慢，推荐使用国内镜像来安装，所以我们先设置 cnpm：

1

npm install -g cnpm --registry=https://registry.npm.taobao.org

如果安装失败，可以使用npm cache clean清理缓存，然后再重新安装。后面的安装过程中，如有安装失败的情况，也需要先清理缓存

同样可以使用cnpm -v查看是否安装成功

然后使用 cnpm 安装 vue-cli 和 webpack

1

cnpm install -g vue-cli

最新的 vue 项目模板中，都带有 webpack 插件，所以这里可以不安装 webpack

安装完成后，可以使用vue -V（注意 V 大写）查看是否安装成功。

如果提示“无法识别 ‘vue’ ” ，有可能是 npm 版本过低，可以使用 npm install -g npm 来更新版本

三、生成项目

首先需要在命令行中进入到项目目录，然后输入：

1

vue init webpack vue_project

其中 webpack 是模板名称，可以到 vue.js 的 GitHub 上查看更多的模板https://github.com/vuejs-templates

vue_project是自定义的项目名称，命令执行之后，会在当前目录生成一个以该名称命名的项目文件夹

配置完成后，可以看到目录下多出了一个项目文件夹，里面就是 vue-cli 创建的一个基于 webpack 的 vue.js 项目

然后进入项目目录（cd vue_project），使用 cnpm 安装依赖

1

cnpm install

然后启动项目

1

npm run dev

如果浏览器打开之后，没有加载出页面，有可能是本地的 8080 端口被占用，需要修改一下配置文件config>index.js

建议将端口号改为不常用的端口。另外我还将 build 的路径前缀修改为 ‘ ./ ‘（原本为 ‘ / ‘），是因为打包之后，外部引入 js 和 css 文件时，如果路径以 ‘ / ‘ 开头，在本地是无法找到对应文件的（服务器上没问题）。所以如果需要在本地打开打包后的文件，就得修改文件路径。

四、打包上线

自己的项目文件都需要放到 src 文件夹下

项目开发完成之后，可以输入 npm run build 来进行打包工作

1

npm run build

打包完成后，会生成 dist 文件夹，如果已经修改了文件路径，可以直接打开本地文件查看

项目上线时，只需要将 dist 文件夹放到服务器就行了。

首先要说的，typeof 并不是一个方法，所以没必要写成 typeof() 的形式。
typeof 是一个操作符，typeof 操作符返回一个字符串,指示未经计算的操作数的类型。

接下来我要问的是，你知道 typeof 可能的返回值有哪些？

例子

常规用法

// Numbers
typeof 37 === 'number';
typeof 3.14 === 'number';
typeof Math.LN2 === 'number';
typeof Infinity === 'number';
typeof NaN === 'number'; // 尽管NaN是"Not-A-Number"的缩写
typeof Number(1) === 'number'; // 但不要使用这种形式!

// Strings
typeof "" === 'string';
typeof "bla" === 'string';
typeof (typeof 1) === 'string'; // typeof总是返回一个字符串
typeof String("abc") === 'string'; // 但不要使用这种形式!

// Booleans
typeof true === 'boolean';
typeof false === 'boolean';
typeof Boolean(true) === 'boolean'; // 但不要使用这种形式!

// Symbols
typeof Symbol() === 'symbol';
typeof Symbol('foo') === 'symbol';
typeof Symbol.iterator === 'symbol';

// Undefined
typeof undefined === 'undefined';
typeof declaredButUndefinedVariable === 'undefined';
typeof undeclaredVariable === 'undefined'; 

// Objects
typeof {a:1} === 'object';

// 使用Array.isArray 或者 Object.prototype.toString.call
// 区分数组,普通对象
typeof [1, 2, 4] === 'object';

typeof new Date() === 'object';

// 下面的容易令人迷惑，不要使用！
typeof new Boolean(true) === 'object';
typeof new Number(1) ==== 'object';
typeof new String("abc") === 'object';

// 函数
typeof function(){} === 'function';
typeof Math.sin === 'function';

null

// 从一开始出现JavaScript就是这样的
typeof null === 'object';

哈哈，我们都知道 typeof null 返回 ‘object’，但是为什么呢？原来，在 JavaScript 最初的实现中，JavaScript 中的值是由一个表示类型的标签和实际数据值表示的。对象的类型标签是0。由于 null 代表的是空指针(大多数平台下值为0x00)，因此，null的类型标签也成为了0，typeof null就错误的返回了’object’.

正则表达式

//对正则表达式字面量的类型判断在某些浏览器中不符合标准：
typeof /s/ === 'function'; // Chrome 1-12 , 不符合 ECMAScript 5.1
typeof /s/ === 'object'; // Firefox 5+ , 符合 ECMAScript 5.1

//我目前版本的Chrome(60.0.3112.90)
typeof /s/ === 'object';

番外：IE 宿主对象是对象而不是函数

//在 IE 6, 7 和 8 中，大多数的宿主对象是对象，而不是函数
typeof alert === 'object'

总结 如下表 （ from MDN ）

over

首先必须要说的是，this的指向在函数定义的时候是确定不了的，只有函数执行的时候才能确定this到底指向谁，实际上this的最终指向的是那个调用它的对象（这句话有些问题，后面会解释为什么会有问题，虽然网上大部分的文章都是这样说的，虽然在很多情况下那样去理解不会出什么问题，但是实际上那样理解是不准确的，所以在你理解this的时候会有种琢磨不透的感觉），那么接下来我会深入的探讨这个问题。

为什么要学习this？如果你学过函数式编程，面向对象编程，那你肯定知道干什么用的，如果你没有学过，那么暂时可以不用看这篇文章，当然如果你有兴趣也可以看看，毕竟这是js中必须要掌握的东西。

例子1：

1
2
3
4
5
6

function a() {
  var user = "马里奥";
  console.log(this.user);  //undefined
  console.log(this);  //Window
}
a();

按照我们上面说的this最终指向的是调用它的对象，这里的函数a实际是被Window对象所点出来的，下面的代码就可以证明。

1
2
3
4
5
6

function a() {
  var user = "马里奥";
  console.log(this.user);  //undefined
  console.log(this);      //Window
}
window.a();

和上面代码一样吧，其实alert也是window的一个属性，也是window点出来的。

例子2：

1
2
3
4
5
6
7

var o = {
  user: "马里奥",
  fn: function() {
    console.log(this.user);  // 马里奥
  }
}
o.fn();

这里的this指向的是对象o，因为你调用这个fn是通过o.fn()执行的，那自然指向就是对象o，这里再次强调一点，this的指向在函数创建的时候是决定不了的，在调用的时候才能决定，谁调用的就指向谁，一定要搞清楚这个。

其实例子1和例子2说的并不够准确，下面这个例子就可以推翻上面的理论。

如果要彻底的搞懂this必须看接下来的几个例子

例子3：

1
2
3
4
5
6
7

var o = {
  user: "马里奥",
  fn: function() {
    console.log(this.user);  // 马里奥
  }
}
window.o.fn();

这段代码和上面的那段代码几乎是一样的，但是这里的this为什么不是指向window，如果按照上面的理论，最终this指向的是调用它的对象，这里先说个题外话，window是js中的全局对象，我们创建的变量实际上是给window添加属性，所以这里可以用window点o对象。

这里先不解释为什么上面的那段代码this为什么没有指向window，我们再来看一段代码。

1
2
3
4
5
6
7
8
9
10

var o = {
  a: 10,
  b: {
    a: 12,
    fn: function() {
      console.log(this.a);  // 12
    }
  }
}
o.b.fn();

这里同样也是对象o点出来的，但是同样this并没有执行它，那你肯定会说我一开始说的那些不就都是错误的吗？其实也不是，只是一开始说的不准确，接下来我将补充一句话，我相信你就可以彻底的理解this的指向的问题。

情况1：如果一个函数中有this，但是它没有被上一级的对象所调用，那么this指向的就是window，这里需要说明的是在js的严格版中this指向的不是window，但是我们这里不探讨严格版的问题，你想了解可以自行上网查找。

情况2：如果一个函数中有this，这个函数有被上一级的对象所调用，那么this指向的就是上一级的对象。

情况3：如果一个函数中有this，这个函数中包含多个对象，尽管这个函数是被最外层的对象所调用，this指向的也只是它上一级的对象，例子3可以证明，如果不相信，那么接下来我们继续看几个例子。

1
2
3
4
5
6
7
8
9
10

var o = {
  a: 10,
  b: {
    // a: 12,
    fn: function() {
      console.log(this.a);  //undefined
    }
  }
}
o.b.fn();

尽管对象b中没有属性a，这个this指向的也是对象b，因为this只会指向它的上一级对象，不管这个对象中有没有this要的东西。

还有一种比较特殊的情况，例子4：

1
2
3
4
5
6
7
8
9
10
11
12

var o = {
  a: 10,
  b: {
    a: 12,
    fn: function(){
      console.log(this.a);  // undefined
      console.log(this);  // window
    }
  }
}
var j = o.b.fn;
j();

这里this指向的是window，是不是有些蒙了？其实是因为你没有理解一句话，这句话同样至关重要。

this永远指向的是最后调用它的对象，也就是看它执行的时候是谁调用的，例子4中虽然函数fn是被对象b所引用，但是在将fn赋值给变量j的时候并没有执行所以最终指向的是window，这和例子3是不一样的，例子3是直接执行了fn。

this讲来讲去其实就是那么一回事，只不过在不同的情况下指向的会有些不同，上面的总结每个地方都有些小错误，也不能说是错误，而是在不同环境下情况就会有不同，所以我也没有办法一次解释清楚，只能你慢慢地的去体会。

构造函数版this：

1
2
3
4
5

function Fn() {
  this.user = "马里奥";
}
var a = new Fn();
console.log(a.user); // 马里奥

这里之所以对象a可以点出函数Fn里面的user是因为new关键字可以改变this的指向，将这个this指向对象a，为什么我说a是对象，因为用了new关键字就是创建一个对象实例，理解这句话可以想想我们的例子3，我们这里用变量a创建了一个Fn的实例（相当于复制了一份Fn到对象a里面），此时仅仅只是创建，并没有执行，而调用这个函数Fn的是对象a，那么this指向的自然是对象a，那么为什么对象Fn中会有user，因为你已经复制了一份Fn函数到对象a中，用了new关键字就等同于复制了一份。

除了上面的这些以外，我们还可以自行改变this的指向，关于自行改变this的指向请参考JavaScript中的call,apply,bind方法。

更新一个小问题当this碰到return时

1
2
3
4
5
6

function fn () {
  this.user = '马里奥';
  return {};
}
var a = new fn;
console.log(a.user);  //undefined

再看一个

1
2
3
4
5
6

function fn () {
  this.user = '马里奥';
  return function(){};
}
var a = new fn;
console.log(a.user);  //undefined

再来

1
2
3
4
5
6
7
8
9
10
11
12

function fn() {
  this.user = '马里奥';
  return 1;
}
var a = new fn;
console.log(a.user);  //马里奥
function fn() {
  this.user = '马里奥';
  return undefined;
}
var a = new fn;
console.log(a.user);  //马里奥

什么意思呢？

如果返回值是一个对象，那么this指向的就是那个返回的对象，如果返回值不是一个对象那么this还是指向函数的实例。

1
2
3
4
5
6

function fn() {
  this.user = '马里奥';
  return undefined;
}
var a = new fn;
console.log(a); // fn {user: "马里奥"}

还有一点就是虽然null也是对象，但是在这里this还是指向那个函数的实例，因为null比较特殊。

1
2
3
4
5
6

function fn() {
  this.user = '马里奥';
  return null;
}
var a = new fn;
console.log(a.user);  // 马里奥

知识点补充：

1. 在严格版中的默认的this不再是window，而是undefined。
2. new操作符会改变函数this的指向问题，虽然我们上面讲解过了，但是并没有深入的讨论这个问题，网上也很少说，所以在这里有必要说一下。

1
2
3
4
5

function fn() {
    this.num = 1;
}
var a = new fn();
console.log(a.num);  //1

为什么this会指向a？首先new关键字会创建一个空的对象，然后会自动调用一个函数apply方法，将this指向这个空对象，这样的话函数内部的this就会被这个空的对象替代。

1. 定义局部变量

当一个变量被引用的时候，JavaScript将在作用域链中的不同成员中查找这个变量。作用域链指的是当前作用于下可用变量的集合，它在各种主流浏览器中至少包含两个部分：局部变量的集合和全局变量的集合。

简单地说，如果JavaScript引擎在作用域链中搜索的深度越大，那么操作也就会消耗更多的时间。引擎首先从 this 开始查找局部变量，然后是函数参数、本地定义的变量，最后遍历所有的全局变量。

因为局部变量在这条链的起端，所以查找局部变量总是比查找全局变量要块。所以当你想要不止一次地使用一个全局变量的时候，你应该将它定义成局部变量，就像这样：

1
2

var blah = document.getElementById('myID')，
blah2 = document.getElementById('myID2');

改写成

1
2
3

var doc = document，
blah = doc.getElementById('myID')，
blah2 = doc.getElementById('myID2');

2. 不要使用 with() 语句

这是因为 with() 语句将会在作用域链的开始添加额外的变量。额外的变量意味着，当任何变量需要被访问的时候，JavaScript引擎都需要先扫描with()语句产生的变量，然后才是局部变量，最后是全局变量。 So with() essentially gives local variables all the performance drawbacks of global ones, and in turn derails Javascript optimization. 因此with()语句同时给局部变量和全局变量的性能带来负面影响，最终使我们优化JavaScript性能的计划破产。

3. 小心使用闭包

虽然你可能还不知道“闭包”，但你可能在不经意间经常使用这项技术。闭包基本上被认为是JavaScript中的new，当我们定义一个即时函数的时候，我们就使用了闭包，比如：

1

document.getElementById('foo').onclick = function(ev) { };

闭包的问题在于：根据定义，在它们的作用域链中至少有三个对象：闭包变量、局部变量和全局变量。这些额外的对象将会导致第1和第2个建议中提到的性能问题。

但是我认为Nicholas并不是要我们因噎废食，闭包对于提高代码可读性等方面还是非常有用的，只是不要滥用它们（尤其在循环中）。

4. 对象属性和数组元素的速度都比变量慢

谈到JavaScript的数据，一般来说有4种访问方式：数值、变量、对象属性和数组元素。在考虑优化时，数值和变量的性能差不多，并且速度显著优于对象属性和数组元素。

因此当你多次引用一个对象属性或者数组元素的时候，你可以通过定义一个变量来获得性能提升。（这一条在读、写数据时都有效）

虽然这条规则在绝大多数情况下是正确的，但是Firefox在优化数组索引上做了一些有意思的工作，能够让它的实际性能优于变量。但是考虑到数组元素在其他浏览器上的性能弊端，还是应该尽量避免数组查找，除非你真的只针对于火狐浏览器的性能而进行开发。

5. 不要在数组中挖得太深

另外，程序员应该避免在数组中挖得太深，因为进入的层数越多，操作速度就越慢。

简单地说，在嵌套很多层的数组中操作很慢是因为数组元素的查找速度很慢。试想如果操作嵌套三层的数组元素，就要执行三次数组元素查找，而不是一次。

因此如果你不断地引用 foo.bar， 你可以通过定义 var bar = foo.bar 来提高性能。

6. 避免 for-in 循环（和基于函数的迭代）

这是另一条非常教条的建议：不要使用for-in循环。

这背后的逻辑非常直接：要遍历一个集合内的元素，你可以使用诸如for循环、或者do-while循环来替代for-in循环，for-in循环不仅仅可能需要遍历额外的数组项，还需要更多的时间。

为了遍历这些元素，JavaScript需要为每一个元素建立一个函数，这种基于函数的迭代带来了一系列性能问题：额外的函数引入了函数对象被创建和销毁的上下文，将会在作用域链的顶端增加额外的元素。

7. 在循环时将控制条件和控制变量合并起来

提到性能，在循环中需要避免的工作一直是个热门话题，因为循环会被重复执行很多次。所以如果有性能优化的需求，先对循环开刀有可能会获得最明显的性能提升。

一种优化循环的方法是在定义循环的时候，将控制条件和控制变量合并起来，下面是一个没有将他们合并起来的例子：

1
2

for ( var x = 0; x < 10; x++ ) {
};

当我们要添加什么东西到这个循环之前，我们发现有几个操作在每次迭代都会出现。JavaScript引擎需要：

1：检查 x 是否存在

2：检查 x 是否小于 0 （译者注：我猜这里是作者的笔误）

3：使 x 增加 1

然而如果你只是迭代元素中的一些元素，那么你可以使用while循环进行轮转来替代上面这种操作：

1
2

var x = 9;
do { } while( x-- );

如果你想更深入地了解循环的性能，Zakas提供了一种高级的循环优化技巧，使用异步进行循环（相当可以！）

8. 为HTML集合对象定义数组

JavaScript使用了大量的HTML集合对象，比如 document.forms，document.images 等等。通常他们被诸如 getElementsByTagName、getElementByClassName 等方法调用。

由于大量的DOM selection操作，HTML集合对象相当的慢，而且还会带来很多额外的问题。正如DOM标准中所定义的那样：“HTML集合是一个虚拟存在，意味着当底层文档被改变时，它们将自动更新。”这太可怕了！

尽管集合对象看起来跟数组很像，他们在某些地方却区别很大，比如对于特定查询的结果。当对象被访问进行读写时，查询需要重新执行来更新所有与对象相关的组分，比如 length。

HTML集合对象也非常的慢，Nicholas说好像在看球的时候对一个小动作进行60倍速慢放。另外，集合对象也有可能造成死循环，比如下面的例子：

1
2
3
4
5
6

var divs = document.getElementsByTagName('div');

for (var i=0; i < divs.length; i++ ) {
    var div = document.createElement("div"); 
    document.appendChild(div);
}

这段代码造成了死循环，因为 divs 表示一个实时的HTML集合，并不是你所期望的数组。这种实时的集合在添加

解决这个问题的方法是将这些元素定义成数组，相比只设置 var divs = document.getElementsByTagName(‘div’) 稍微有点麻烦，下面是Zakas提供的强制使用数组的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

function array(items) {
    try {
        return Array.prototype.concat.call(items);
    } catch (ex) {

        var i = 0,
            len = items.length,
            result = Array(len);

        while (i < len) {
            result[i] = items[i];
            i++;
        }

            return result;
    }  
}

var divs = array( document.getElementsByTagName('div') );

for (var i=0l i < divs.length; i++ ) {
    var div = document.createElement("div"); 
    document.appendChild(div);
}

9. 不要碰DOM！

不使用DOM是JavaScript优化中另一个很大的话题。经典的例子是添加一系列的列表项：如果你把每个列表项分别加到DOM中，肯定会比一次性加入所有列表项到DOM中要慢。这是因为DOM操作开销很大。

Zakas对这个进行了细致的讲解，解释了由于回流（reflow）的存在，DOM操作是非常消耗资源的。回流通常被理解为浏览器重新选渲染DOM树的处理过程。比如说，如果你用JavaScript语句改变了一个div的宽度，浏览器需要重绘页面来适应变化。

任何时候只要有元素被添加到DOM树或者从DOM树移除，都会引发回流。使用一个非常方便的JavaScript对象可以解决这个问题——documentFragment，我并没有使用过，但是在Steve Souders也表示同意这种做法之后我感觉更加肯定了。

DocumentFragment 基本上是一种浏览器以非可视方式实现的类似文档的片段，非可视化的表现形式带来了很多优点，最主要的是你可以在 documentFragment 中添加任何结点而不会引起浏览器回流。

10. 修改CSS类，而不是样式

你也许听说过：修改CSS类必直接修改样式会更高效。这归结于回流带来的另一个问题：当布局样式发生改变时，会引发回流。

布局样式意味着任何影响改变布局的变化都会强制引起浏览器回流。比如宽度、高度、字号、浮动等。

但是别误会我的意思，CSS类并不会避免回流，但是可以将它的影响最小化。相比每次修改样式都会引起回流，使用CSS类一次修改多个样式，只需要承担一次回流带来的消耗。

因此在修改多个布局样式的时候，使用CSS类来优化性能是明智的选择。另外如果你需要在运行时定义很多歌CSS类，在DOM上添加样式结点也是不错的选择。

JavaScript的延迟加载是那些在web上，能让你想抓狂地去寻找解决方案的问题之一。

很多人说那就用”defer”或”async”，甚至有些人说“那就将你的javascript代码放在页面代码底部”。

上述方法都不能解决在web页面完全加载后，再加载外部js的问题。上述方法也会偶尔让你收到Google页面速度测试工具的“延迟加载javascript”警告。所以这里的解决方案将是来自Google帮助页面的推荐方案。

如何延迟加载JavaScript

下面是Google推荐的代码。这些代码应被放置在</body>标签前(接近HTML文件底部)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

<script type="text/javascript">
  function downloadJSAtOnload() {
      var element = document.createElement("script");
      element.src = "defer.js";
      document.body.appendChild(element);
  }
  if(window.addEventListener) {
      window.addEventListener("load", downloadJSAtOnload, false);
  } else if(window.attachEvent) {
      window.attachEvent("onload", downloadJSAtOnload);
  } else {
      window.onload = downloadJSAtOnload;
  } 
</script>

这里做了什么？

这段代码意思是等到整个文档加载完后，再加载外部文件“defer.js”。

具体说明

1. 复制上面代码

2. 粘贴代码到HTML的标签前 (靠近HTML文件底部)

3. 修改“defer.js”为你的外部JS文件名

4. 确保你文件路径是正确的。例如：如果你仅输入“defer.js”，那么“defer.js”文件一定与HTML文件在同一文件夹下。

这段代码能用在哪里(和哪里不能用)

这段代码直到文档加载完才会加载指定的外部JS文件。因此，不应该把那些页面正常加载需要依赖的javascript代码放在这里。而应该将JavaScript代码分成两组。一组是因页面需要而立即加载的javascript代码，另外一组是在页面加载后进行操作的javascript代码(例如添加click事件或其他东西)。这些需等到页面加载后再执行的JavaScript代码，应放在一个外部文件，然后再引进来。

例如，在这页面我使用上述文件进行延迟加载 - Google analytics，Viglink (我怎么赚钱)，和显示在底部的Google+徽章(我的社交媒体)。这对于我来说，没有理由在初始页面加载时加载这些文件，因为初始阶段都没必要加载上述无关紧要的内容。也许在你的页面中也有同样性质的文件。那你难道想让用户在看到网页内容之前，还要等待这些文件加载吗？

为什么不使用其它方法呢？

直接插入代码、将脚本放置在底部和使用“defer”或“async”，这几种方法都不能达到先加载页面后加载JS的目的，而且它们肯定不能在各个浏览器上表现一致。

它为什么重要？

它的重要性是由于Google将页面速度作为排名因素之一而且用户也希望能快速加载页面。另外对于移动搜索引擎优化也是非常重要的。Google根据页面最初加载时间来衡量页面速度。这意味着你必须尽可能快地得到页面的load事件。页面最初加载时间是Google用来评价你的web页面质量(而且别忘记用户在等待页面的加载)。Google积极推进和推荐将上述的无关紧要的内容按重要性排列，让所有资源(js,css,images等)脱离关键的渲染路径，而且这样做是值得去努力的。如果这样能取悦用户，且让Google开心，你很应该这样做。

关键点

压倒一切的首要任务应该是尽可能快地交付内容给用户。而我们一直没想着如何对待我们的javascript代码。但用户不应该为一些无关紧要的脚本，而被迫地为内容而作出等待。无论你的页脚多酷，都没理由让一个可能从不滚动到页脚的用户，去加载那些让页脚变酷的javascript文件。

Yahoo!的Exceptional Performance团队为改善Web性能带来最佳实践。他们为此进行了 一系列的实验、开发了各种工具、写了大量的文章和博客并在各种会议上参与探讨。最佳实践的核心就是旨在提高网站性能。

Excetional Performance 团队总结出了一系列可以提高网站速度的方法。可以分为 7 大类 34 条。包括内容、服务器、cookie、CSS、JavaScript、图片、移动应用等七部分。

本文为CSS和Javascript部分：

除此之外，JavaScript 和 CSS 也是我们页面中经常用到的内容，对它们的优化也提高网 站性能的重要方面：

CSS

1. 把样式表置于顶部

2. 避免使用CSS表达式（Expression）

3. 使用外部JavaScript和CSS

4. 削减JavaScript和CSS

5. 用代替@import

6. 避免使用滤镜

JavaScript

1. 把脚本置于页面底部

2. 使用外部JavaScript和CSS

削减JavaScript和CSS 和 剔除重复脚本（参考3、4）

1. 减少DOM访问

2. 开发智能事件处理程序

最佳实践

1.把样式表置于顶部

在研究Yahoo!的性能表现时，我们发现把样式表放到文档的<head />内部似乎会加快页 面的下载速度。这是因为把样式表放到<head />内会使页面有步骤的加载显示。

注重性能的前端服务器往往希望页面有秩序地加载。同时，我们也希望浏览器把已经接收到内容尽可能显示出来。这对于拥有较多内容的页面和网速较慢的用户来说特别重要。

向用户返回可视化的反馈，比如进程指针，已经有了较好的研究并形成了正式文档。在我们的研究中HTML页面就是进程指针。当浏览器有序地加载文件头、导航栏、顶部的logo等对于等待页面加载的用户来说都可以作为可视化的反馈。这从整体上改善了用户体验。

把样式表放在文档底部的问题是在包括Internet Explorer在内的很多浏览器中这会中 止内容的有序呈现。浏览器中止呈现是为了避免样式改变引起的页面元素重绘。用户不 得不面对一个空白页面。

HTML规范清楚指出样式表要放包含在页面的<head />区域内：”和<a />不同，<link /> 只能出现在文档的<head />区域内，尽管它可以多次使用它”。无论是引起白屏还是出 现没有样式化的内容都不值得去尝试。最好的方案就是按照HTML规范在文档<head />内加载你的样式表。

2.避免使用CSS表达式（Expression）

CSS表达式是动态设置CSS属性的强大（但危险）方法。Internet Explorer从第5个版 本开始支持CSS表达式。下面的例子中，使用CSS表达式可以实现隔一个小时切换一次背景颜色：

1

background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00″ );

如上所示，expression中使用了JavaScript表达式。CSS属性根据JavaScript表达式的 计算结果来设置。expression方法在其它浏览器中不起作用，因此在跨浏览器的设计中

单独针对Internet Explorer设置时会比较有用。 表达式的问题就在于它的计算频率要比我们想象的多。不仅仅是在页面显示和缩放时，就是在页面滚动、乃至移动鼠标时都会要重新计算一次。给CSS表达式增加一个计数器可以跟踪表达式的计算频率。在页面中随便移动鼠标都可以轻松达到 10000 次以上的计算量。

一个减少CSS表达式计算次数的方法就是使用一次性的表达式，它在第一次运行时将结 果赋给指定的样式属性，并用这个属性来代替CSS表达式。如果样式属性必须在页面周 期内动态地改变，使用事件句柄来代替CSS表达式是一个可行办法。如果必须使用CSS表达式，一定要记住它们要计算成千上万次并且可能会对你页面的性能产生影响。

3.使用外部JavaScript和CSS

很多性能规则都是关于如何处理外部文件的。但是，在你采取这些措施前你可能会问到 一个更基本的问题：JavaScript和CSS是应该放在外部文件中呢还是把它们放在页面本 身之内呢？

在实际应用中使用外部文件可以提高页面速度，因为JavaScript和CSS文件都能在浏览 器中产生缓存。内置在HTML文档中的JavaScript和CSS则会在每次请求中随HTML文档重 新下载。这虽然减少了HTTP请求的次数，却增加了HTML文档的大小。从另一方面来说， 如果外部文件中的JavaScript和CSS被浏览器缓存，在没有增加HTTP请求次数的同时可 以减少HTML文档的大小。

关键问题是，外部JavaScript和CSS文件缓存的频率和请求HTML文档的次数有关。虽然 有一定的难度，但是仍然有一些指标可以一测量它。如果一个会话中用户会浏览你网站 中的多个页面，并且这些页面中会重复使用相同的脚本和样式表，缓存外部文件就会带 来更大的益处。

许多网站没有功能建立这些指标。对于这些网站来说，最好的坚决方法就是把 JavaScript和CSS作为外部文件引用。比较适合使用内置代码的例外就是网站的主页， 如Yahoo!主页和My Yahoo!。主页在一次会话中拥有较少（可能只有一次）的浏览量，你可以发现内置JavaScript和CSS对于终端用户来说会加快响应时间。

对于拥有较大浏览量的首页来说，有一种技术可以平衡内置代码带来的HTTP请求减少与 通过使用外部文件进行缓存带来的好处。其中一个就是在首页中内置JavaScript和CSS， 但是在页面下载完成后动态下载外部文件，在子页面中使用到这些文件时，它们已经缓存到浏览器了。

4.削减JavaScript和CSS

精简是指从去除代码不必要的字符减少文件大小从而节省下载时间。消减代码时，所有 的注释、不需要的空白字符（空格、换行、tab缩进）等都要去掉。在JavaScript中， 由于需要下载的文件体积变小了从而节省了响应时间。精简JavaScript中目前用到的最 广泛的两个工具是JSMin和YUI Compressor。YUI Compressor还可用于精简CSS。

混淆是另外一种可用于源代码优化的方法。这种方法要比精简复杂一些并且在混淆的过 程更易产生问题。在对美国前 10 大网站的调查中发现，精简也可以缩小原来代码体积 的 21%，而混淆可以达到 25%。尽管混淆法可以更好地缩减代码，但是对于JavaScript 来说精简的风险更小。

除消减外部的脚本和样式表文件外，<script>和<style>代码块也可以并且应该进行消 减。即使你用Gzip压缩过脚本和样式表，精简这些文件仍然可以节省 5%以上的空间。由于JavaScript和CSS的功能和体积的增加，消减代码将会获得益处。

5.用<link>代替@import

前面的最佳实现中提到 CSS 应该放置在顶端以利于有序加载呈现。

在 IE 中，页面底部@import 和使用<link>作用是一样的，因此最好不要使用它。

6.避免使用滤镜

IE 独有属性 AlphaImageLoader 用于修正 7.0 以下版本中显示 PNG 图片的半透明效果。 这个滤镜的问题在于浏览器加载图片时它会终止内容的呈现并且冻结浏览器。在每一个 元素（不仅仅是图片）它都会运算一次，增加了内存开支，因此它的问题是多方面的。 完全避免使用 AlphaImageLoader 的最好方法就是使用 PNG8 格式来代替，这种格式能在 IE 中很好地工作。如果你确实需要使用 AlphaImageLoader，请使用下划线_filter 又使之对 IE7 以上版本的用户无效。

7.把脚本置于页面底部

脚本带来的问题就是它阻止了页面的平行下载。HTTP/1.1 规范建议，浏览器每个主机 名的并行下载内容不超过两个。如果你的图片放在多个主机名上，你可以在每个并行下 载中同时下载 2 个以上的文件。但是当下载脚本时，浏览器就不会同时下载其它文件了， 即便是主机名不相同。

在某些情况下把脚本移到页面底部可能不太容易。比如说，如果脚本中使用了 document.write来插入页面内容，它就不能被往下移动了。这里可能还会有作用域的问 题。很多情况下，都会遇到这方面的问题。 一个经常用到的替代方法就是使用延迟脚本。DEFER属性表明脚本中没有包含 document.write，它告诉浏览器继续显示。不幸的是，Firefox并不支持DEFER属性。在 Internet Explorer中，脚本可能会被延迟但效果也不会像我们所期望的那样。如果脚

本可以被延迟，那么它就可以移到页面的底部。这会让你的页面加载的快一点。

8.剔除重复脚本

在同一个页面中重复引用 JavaScript 文件会影响页面的性能。你可能会认为这种情况

并不多见。对于美国前 10 大网站的调查显示其中有两家存在重复引用脚本的情况。有 两种主要因素导致一个脚本被重复引用的奇怪现象发生：团队规模和脚本数量。如果真 的存在这种情况，重复脚本会引起不必要的 HTTP 请求和无用的 JavaScript 运算，这降 低了网站性能。

在 Internet Explorer 中会产生不必要的 HTTP 请求，而在 Firefox 却不会。在 Internet Explorer 中，如果一个脚本被引用两次而且它又不可缓存，它就会在页面加载过程中产 生两次 HTTP 请求。即时脚本可以缓存，当用户重载页面时也会产生额外的 HTTP 请求。

除增加额外的 HTTP 请求外，多次运算脚本也会浪费时间。在 Internet Explorer 和 Firefox 中不管脚本是否可缓存，它们都存在重复运算 JavaScript 的问题。 一个避免偶尔发生的两次引用同一脚本的方法是在模板中使用脚本管理模块引用脚本。 在 HTML 页面中使用<script />标签引用脚本的最常见方法就是：

1

<script type="text/javascript" src="menu_1.0.17.js"></script>

在 PHP 中可以通过创建名为 insertScript 的方法来替代：

1

<?php insertScript("menu.js") ?>

为了防止多次重复引用脚本，这个方法中还应该使用其它机制来处理脚本，如检查所属 目录和为脚本文件名中增加版本号以用于 Expire 文件头等。

9.减少 DOM 访问

使用 JavaScript 访问 DOM 元素比较慢，因此为了获得更多的应该页面，应该做到：

• 缓存已经访问过的有关元素

• 线下更新完节点之后再将它们添加到文档树中

• 避免使用 JavaScript 来修改页面布局

10.开发智能事件处理程序

有时候我们会感觉到页面反应迟钝，这是因为DOM树元素中附加了过多的事件句柄并且 些事件句病被频繁地触发。这就是为什么说使用event delegation（事件代理）是一种 好方法了。如果你在一个div中有 10 个按钮，你只需要在div上附加一次事件句柄就可 以了，而不用去为每一个按钮增加一个句柄。事件冒泡时你可以捕捉到事件并判断出是 哪个事件发出的。

你同样也不用为了操作DOM树而等待onload事件的发生。你需要做的就是等待树结构中 你要访问的元素出现。你也不用等待所有图像都加载完毕。 你可能会希望用DOMContentLoaded事件来代替onload，但是在所有浏览器都支持它之前 你可使用YUI 事件应用程序中的onAvailable方法。

前端性能优化策略总结

一、PC浏览器前端优化策略

PC端优化的策略很多，如 YSlow（YSlow 是 Yahoo 发布的一款 Firefox 插件，现 Chrome 也可安装，可以对网站的页面性能进行分析，提出对该页面性能优化的建议）原则，或者 Chrome 自带的 Audits 等，总结起来主要包括网络加载类、页面渲染类、CSS 优化类、JavaScript 执行类、缓存类、图片类、架构协议类等几类，下面逐一介绍。

网络加载类

1．减少 HTTP 资源请求次数

在前端页面中，通常建议尽可能合并静态资源图片、JavaScript 或 CSS 代码，减少页面请求数和资源请求消耗，这样可以缩短页面首次访问的用户等待时间。通过构建工具合并雪碧图、CSS、JavaScript 文件等都是为了减少 HTTP 资源请求次数。另外也要尽量避免重复的资源，防止增加多余请求。

2．减小 HTTP 请求大小

除了减少 HTTP 资源请求次数，也要尽量减小每个 HTTP 请求的大小。如减少没必要的图片、JavaScript、CSS 及 HTML 代码，对文件进行压缩优化，或者使用 gzip 压缩传输内容等都可以用来减小文件大小，缩短网络传输等待时延。前面我们使用构建工具来压缩静态图片资源以及移除代码中的注释并压缩，目的都是为了减小 HTTP 请求的大小。

3．将 CSS 或 JavaScript 放到外部文件中，避免使用 <script> 或 <style> 标签直接引入

在 HTML 文件中引用外部资源可以有效利用浏览器的静态资源缓存，但有时候在移动端页面 CSS 或 JavaScript 比较简单的情况下为了减少请求，也会将 CSS 或 JavaScript 直接写到 HTML 里面，具体要根据 CSS 或 JavaScript 文件的大小和业务的场景来分析。如果 CSS 或 JavaScript 文件内容较多，业务逻辑较复杂，建议放到外部文件引入。

1
2
3

<link rel="stylesheet" href="//cdn.domain.com/path/main.css" >
...
<script src="//cdn.domain.com/path/main.js"></script>

4．避免页面中空的 href 和 src

当<link>标签的 href 属性为空，或<script>、<img>、<iframe>标签的 src 属性为空时，浏览器在渲染的过程中仍会将 href 属性或 src 属性中的空内容进行加载，直至加载失败，这样就阻塞了页面中其他资源的下载进程，而且最终加载到的内容是无效的，因此要尽量避免。

1
2
3

<!--不推荐-->
<img src="" alt="photo" >
<a href="">点击链接</a>

5．为 HTML 指定 Cache-Control 或 Expires

为 HTML 内容设置 Cache-Control 或 Expires 可以将 HTML 内容缓存起来，避免频繁向服务器端发送请求。前面讲到，在页面 Cache-Control 或 Expires 头部有效时，浏览器将直接从缓存中读取内容，不向服务器端发送请求。

1
2

<meta http-equiv="Cache-Control" content="max-age=7200">
<meta http-equiv="Expires" content="Sun,10Jul201610:00:00GMT">

6．合理设置 Etag 和 Last-Modified

合理设置 Etag 和 Last-Modified 使用浏览器缓存，对于未修改的文件，静态资源服务器会向浏览器端返回304，让浏览器从缓存中读取文件，减少 Web 资源下载的带宽消耗并降低服务器负载。

1

<meta http-equiv="last-modified" content="Sun,10 Jul 2016 11:20:17 GMT">

7．减少页面重定向

页面每次重定向都会延长页面内容返回的等待延时，一次重定向大约需要200毫秒不等的时间开销（无缓存），为了保证用户尽快看到页面内容，要尽量避免页面重定向。

8．使用静态资源分域存放来增加下载并行数

浏览器在同一时刻向同一个域名请求文件的并行下载数是有限的，因此可以利用多个域名的主机来存放不同的静态资源，增大页面加载时资源的并行下载数，缩短页面资源加载的时间。通常根据多个域名来分别存储 JavaScript、CSS 和图片文件。

1
2
3

<link rel="stylesheet" href="//cdn1.domain.com/path/main.css" >
...
<script src="//cdn2.domain.com/path/main.js"></script>

9．使用静态资源 CDN 来存储文件

如果条件允许，可以利用 CDN 网络加快同一个地理区域内重复静态资源文件的响应下载速度，缩短资源请求时间。

10．使用 CDN Combo 下载传输内容

CDN Combo 是在 CDN 服务器端将多个文件请求打包成一个文件的形式来返回的技术，这样可以实现 HTTP 连接传输的一次性复用，减少浏览器的 HTTP 请求数，加快资源下载速度。例如同一个域名 CDN 服务器上的 a.js，b.js，c.js 就可以按如下方式在一个请求中下载。

1

<script src="//cdn.domain.com/path/a.js,b.js,c.js"></script>

11．使用可缓存的 AJAX

对于返回内容相同的请求，没必要每次都直接从服务端拉取，合理使用 AJAX 缓存能加快 AJAX 响应速度并减轻服务器压力。

1
2
3
4
5
6
7
8

$.ajax({
    url : url,
    type : 'get',
    cache : true, // 推荐使用缓存
    data : {},
    success (){// ...},
    error (){// ...}
});

12．使用 GET 来完成 AJAX 请求

使用 XMLHttpRequest 时，浏览器中的 POST 方法会发起两次 TCP 数据包传输，首先发送文件头，然后发送 HTTP 正文数据。而使用 GET 时只发送头部，所以在拉取服务端数据时使用 GET 请求效率更高。

1
2
3
4
5
6
7

$.ajax({
    url : url,
    type : 'get', //推荐使用get完成请求
    data : {},
    success (){//...},
    error(){//...}
});

13．减少 Cookie 的大小并进行 Cookie 隔离

HTTP 请求通常默认带上浏览器端的 Cookie 一起发送给服务器，所以在非必要的情况下，要尽量减少 Cookie 来减小 HTTP 请求的大小。对于静态资源，尽量使用不同的域名来存放，因为 Cookie 默认是不能跨域的，这样就做到了不同域名下静态资源请求的 Cookie 隔离。

14．缩小 favicon.ico 并缓存

有利于 favicon.ico 的重复加载，因为一般一个 Web 应用的 favicon.ico 是很少改变的。

15．推荐使用异步 JavaScript 资源

异步的 JavaScript 资源不会阻塞文档解析，所以允许在浏览器中优先渲染页面，延后加载脚本执行。例如 JavaScript 的引用可以如下设置，也可以使用模块化加载机制来实现。

1
2

<script src="main.js" defer></script>
<script src="main.js" async></script>

使用 async 时，加载和渲染后续文档元素的过程和 main.js 的加载与执行是并行的。使用 defer 时，加载后续文档元素的过程和 main.js 的加载是并行的，但是 main.js 的执行要在页面所有元素解析完成之后才开始执行。

16．消除阻塞渲染的 CSS 及 JavaScript

对于页面中加载时间过长的 CSS 或 JavaScript 文件，需要进行合理拆分或延后加载，保证关键路径的资源能快速加载完成。

17．避免使用 CSS import 引用加载 CSS

CSS 中的 ＠import 可以从另一个样式文件中引入样式，但应该避免这种用法，因为这样会增加 CSS 资源加载的关键路径长度，带有 ＠import 的 CSS 样式需要在 CSS 文件串行解析到 @import 时才会加载另外的 CSS 文件，大大延后 CSS 渲染完成的时间。

1
2
3
4
5
6
7

<!--不推荐-->
<style>
    @import "path/main.css";
</style>

<!--推荐-->
<link rel="stylesheet" href="//cdn1.domain.com/path/main.css" >

页面渲染类

1．把 CSS 资源引用放到 HTML 文件顶部

一般推荐将所有 CSS 资源尽早指定在 HTML 文档 <head> 中，这样浏览器可以优先下载 CSS 并尽早完成页面渲染。

2．JavaScript 资源引用放到 HTML 文件底部

JavaScript 资源放到 HTML 文档底部可以防止 JavaScript 的加载和解析执行对页面渲染造成阻塞。由于 JavaScript 资源默认是解析阻塞的，除非被标记为异步或者通过其他的异步方式加载，否则会阻塞 HTML DOM 解析和 CSS 渲染的过程。

3．尽量预先设定图片等大小

在加载大量的图片元素时，尽量预先限定图片的尺寸大小，否则在图片加载过程中会更新图片的排版信息，产生大量的重排

4．不要在 HTML 中直接缩放图片

在 HTML 中直接缩放图片会导致页面内容的重排重绘，此时可能会使页面中的其他操作产生卡顿，因此要尽量减少在页面中直接进行图片缩放。

5．减少 DOM 元素数量和深度

HTML 中标签元素越多，标签的层级越深，浏览器解析 DOM 并绘制到浏览器中所花的时间就越长，所以应尽可能保持 DOM 元素简洁和层级较少。

1
2
3
4
5
6
7
8
9
10
11

<!--不推荐-->
<div>
    <span>
        <a href="javascript:void(0);">
            <img src="./path/photo.jpg" alt="图片">
        </a>
    </span>
</div>

<!--推荐-->
<img src="./path/photo.jpg" alt="图片" >

6．尽量避免在选择器末尾添加通配符

CSS 解析匹配到 渲染树的过程是从右到左的逆向匹配，在选择器末尾添加通配符至少会增加一倍多计算量。

7．减少使用关系型样式表的写法

直接使用唯一的类名即可最大限度的提升渲染引擎绘制渲染树等效率

8．尽量减少使用JS动画

JS 直接操作 DOM 极容易引起页面的重排

9．CSS 动画使用 translate、scale 代替 top、height

尽量使用 CSS3 的 translate、scale 属性代替 top、left 和 height、width，避免大量的重排计算

10．尽量避免使用<table>、<iframe>

<table> 内容的渲染是将 table 的 DOM 渲染树全部生成完并一次性绘制到页面上的，所以在长表格渲染时很耗性能，应该尽量避免使用它，可以考虑使用列表元素 <ul> 代替。尽量使用异步的方式动态添加 iframe，因为 iframe 内资源的下载进程会阻塞父页面静态资源的下载与 CSS 及 HTML DOM 的解析。

11．避免运行耗时的 JavaScript

长时间运行的 JavaScript 会阻塞浏览器构建 DOM 树、DOM 渲染树、渲染页面。所以，任何与页面初次渲染无关的逻辑功能都应该延迟加载执行，这和 JavaScript 资源的异步加载思路是一致的。

12．避免使用 CSS 表达式或 CSS 滤镜

CSS 表达式或 CSS 滤镜的解析渲染速度是比较慢的，在有其他解决方案的情况下应该尽量避免使用。

1
2
3
4

//不推荐
.opacity{
    filter : progid : DXImageTransform.Microsoft.Alpha( opacity = 50 );
}

二、移动端浏览器前端优化策略

相对于桌面端浏览器，移动端 Web 浏览器上有一些较为明显的特点：设备屏幕较小、新特性兼容性较好、支持一些较新的 HTML5 和 CSS3 特性、需要与 Native 应用交互等。但移动端浏览器可用的 CPU 计算资源和网络资源极为有限，因此要做好移动端 Web 上的优化往往需要做更多的事情。首先，在移动端 Web 的前端页面渲染中，桌面浏览器端上的优化规则同样适用，此外针对移动端也要做一些极致的优化来达到更好的效果。需要注意的是，并不是移动端的优化原则在桌面浏览器端就不适用，而是由于兼容性和差异性的原因，一些优化原则在移动端更具代表性。

网络加载类

1．首屏数据请求提前，避免 JavaScript 文件加载后才请求数据

为了进一步提升页面加载速度，可以考虑将页面的数据请求尽可能提前，避免在 JavaScript 加载完成后才去请求数据。通常数据请求是页面内容渲染中关键路径最长的部分，而且不能并行，所以如果能将数据请求提前，可以极大程度上缩短页面内容的渲染完成时间。

2．首屏加载和按需加载，非首屏内容滚屏加载，保证首屏内容最小化

由于移动端网络速度相对较慢，网络资源有限，因此为了尽快完成页面内容的加载，需要保证首屏加载资源最小化，非首屏内容使用滚动的方式异步加载。一般推荐移动端页面首屏数据展示延时最长不超过3秒。目前中国联通 3G 的网络速度为 338KB/s（2.71Mb/s），所以推荐首屏所有资源大小不超过 1014KB，即大约不超过 1MB。

3．模块化资源并行下载

在移动端资源加载中，尽量保证 JavaScript 资源并行加载，主要指的是模块化 JavaScript 资源的异步加载，例如AMD的异步模块，使用并行的加载方式能够缩短多个文件资源的加载时间。

4．inline 首屏必备的 CSS 和 JavaScript

通常为了在 HTML 加载完成时能使浏览器中有基本的样式，需要将页面渲染时必备的 CSS 和 JavaScript 通过 <script> 或 <style> 内联到页面中，避免页面 HTML 载入完成到页面内容展示这段过程中页面出现空白。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<!DOCTYPE html>
<html lang="zh-CN">
    <head>
    <meta charset="UTF-8">
    <title>样例</title>
    <meta name="viewport" content="width=device-width,minimum-scale=1.0,maximum-scale=1.0,user-scalable=no">
    <style>
    /*必备的首屏CSS*/
    html,body{
        margin:0;
        padding:0;
        background-color:#ccc;
    }
    </style>
</head>
<body>
</body>
</html>

5．meta dns prefetch 设置 DNS 预解析

设置文件资源的 DNS 预解析，让浏览器提前解析获取静态资源的主机 IP，避免等到请求时才发起 DNS 解析请求。通常在移动端 HTML 中可以采用如下方式完成。

1
2
3

<!--cdn域名预解析-->
<meta http-equiv="x-dns-prefetch-control" content="on" >
<link rel="dns-prefetch" href="//cdn.domain.com" >

6．资源预加载

对于移动端首屏加载后可能会被使用的资源，需要在首屏完成加载后尽快进行加载，保证在用户需要浏览时已经加载完成，这时候如果再去异步请求就显得很慢。

7．合理利用MTU策略

通常情况下，我们认为 TCP 网络传输的最大传输单元（Maximum Transmission Unit，MTU）为 1500B，即一个RTT（Round-Trip Time，网络请求往返时间）内可以传输的数据量最大为 1500 字节。因此，在前后端分离的开发模式中，尽量保证页面的 HTML 内容在 1KB 以内，这样整个 HTML 的内容请求就可以在一个 RTT 内请求完成，最大限度地提高 HTML 载入速度。

缓存类

1．合理利用浏览器缓存

除了上面说到的使用 Cache-Control、Expires、Etag 和 Last-Modified 来设置 HTTP 缓存外，在移动端还可以使用 localStorage 等来保存 AJAX 返回的数据，或者使用 localStorage 保存 CSS 或 JavaScript 静态资源内容，实现移动端的离线应用，尽可能减少网络请求，保证静态资源内容的快速加载。

2．静态资源离线方案

对于移动端或 Hybrid 应用，可以设置离线文件或离线包机制让静态资源请求从本地读取，加快资源载入速度，并实现离线更新。关于这块内容，我们会在后面的章节中重点讲解。

3．尝试使用 AMP HTML

AMP HTML 可以作为优化前端页面性能的一个解决方案，使用 AMP Component 中的元素来代替原始的页面元素进行直接渲染。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<!--不推荐-->
<video width="400" height="300" src="http://www.domain.com/videos/myvideo.mp4" 
poster="path/poster.jpg">
    <div fallback>
        <p>Your browser doesn’t support HTML5 video</p>
    </div>
    <source type="video/mp4" src="foo.mp4">
    <source type="video/webm" src="foo.webm">
</video>

<!--推荐-->
<amp-video width="400" height="300" src="http://www.domain.com/videos/myvideo.mp4" 
poster="path/poster.jpg">
    <div fallback>
        <p>Your browser doesn’t support HTML5 video</p>
    </div>
    <source type="video/mp4" src="foo.mp4">
    <source type="video/webm" src="foo.webm">
</amp-video>

4．尝试使用 PWA 模式

PWA（Progressive Web Apps）是 Google 提出的用前沿的 Web 技术为网页提供 App 般使用体验的一系列方案。

图片类

1．图片压缩处理

在移动端，通常要保证页面中一切用到的图片都是经过压缩优化处理的，而不是以原图的形式直接使用的，因为那样很消耗流量，而且加载时间更长。

2．使用较小的图片，合理使用 base64 内嵌图片

在页面使用的背景图片不多且较小的情况下，可以将图片转化成 base64 编码嵌入到 HTML 页面或 CSS 文件中，这样可以减少页面的 HTTP 请求数。需要注意的是，要保证图片较小，一般图片大小超过 2KB 就不推荐使用 base64 嵌入显示了。

1
2
3

.class-name{
    background-image : url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAoAAAALCAMAAABxsOwqAAAAYFBMVEWnxwusyQukxQudwQyZvgyhxAyfwgyxzAsUHQGOuA0aJAERGAFIXwSTugyEqgtqhghQZgUwQQIpOQKbuguVtQuKrAuCowp2kQlheghTbQZHWQU7SwVAVgQ6TgQlLwMeKwFOemyQAAAAVElEQVQI1y3JVRaAIAAF0UconXbvf5ei8HfPDIQQhBAAFE10iKig3SLRNN4SP/p+N08VC0YnfIlNWtqIkhg/TPYbCvhqdHAWRXPZSp3g3CWZvVLXC6OJA3ukv0AaAAAAAElFTkSuQmCC');
}

3．使用更高压缩比格式的图片

使用具有较高压缩比格式的图片，如 webp（需要设计降级兼容方案）等。在同等图片画质的情况下，高压缩比格式的图片体积更小，能够更快完成文件传输，节省网络流量。

1

<img src="//cdn.domain.com/path/photo.webp" alt="webp格式图片" >

4．图片懒加载

为了保证页面内容的最小化，加速页面的渲染，尽可能节省移动端网络流量，页面中的图片资源推荐使用懒加载实现，在页面滚动时动态载入图片。

1

<img data-src="//cdn.domain.com/path/photo.jpg" alt="懒加载图片" >

5．使用 MediaQuery 或 srcset 根据不同屏幕加载不同大小图片

在介绍响应式的章节中我们了解到，针对不同的移动端屏幕尺寸和分辨率，输出不同大小的图片或背景图能保证在用户体验不降低的前提下节省网络流量，加快部分机型的图片加载速度，这在移动端非常值得推荐。

6．使用 iconfont 代替图片图标

在页面中尽可能使用 iconfont 来代替图片图标，这样做的好处有以下几个：

使用 iconfont 体积较小，而且是矢量图，因此缩放时不会失真；
可以方便地修改图片大小尺寸和呈现颜色。
但是需要注意的是，iconfont 引用不同 webfont 格式时的兼容性写法，根据经验推荐尽量按照以下顺序书写，否则不容易兼容到所有的浏览器上。

1
2
3
4
5
6
7

@font-face{
    font-family:iconfont;
    src:url("./iconfont.eot");
    src:url("./iconfont.eot?#iefix")  format("eot"),
        url("./iconfont.woff")  format("woff"),
        url("./iconfont.ttf")  format("truetype");
}

7．定义图片大小限制

加载的单张图片一般建议不超过 30KB，避免大图片加载时间长而阻塞页面其他资源的下载，因此推荐在 10KB 以内。如果用户上传的图片过大，建议设置告警系统，帮助我们观察了解整个网站的图片流量情况，做出进一步的改善。

8．强缓存策略

对于一些「永远」不会变的图片可以使用强缓存的方式缓存在用户的浏览器上。

脚本类

1．尽量使用 id

选择器选择页面 DOM 元素时尽量使用 id 选择器，因为 id 选择器速度最快。

2．合理缓存 DOM 对象

对于需要重复使用的 DOM 对象，要优先设置缓存变量，避免每次使用时都要从整个DOM树中重新查找。

1
2
3
4
5
6
7
8

//不推荐
$('#mod.active').remove('active');
$('#mod.not-active').addClass('active');

//推荐
let $mod=$('#mod');
$mod.find('.active').remove('active');
$mod.find('.not-active').addClass('active');

3．页面元素尽量使用事件代理，避免直接事件绑定

使用事件代理可以避免对每个元素都进行绑定，并且可以避免出现内存泄露及需要动态添加元素的事件绑定问题，所以尽量不要直接使用事件绑定。

1
2
3
4
5
6
7
8
9

//不推荐
$('.btn').on('click',function(e){
    console.log(this);
});

//推荐
$('body').on('click','.btn',function(e){
    console.log(this);
});

4．使用 touchstart 代替 click

由于移动端屏幕的设计， touchstart 事件和 click 事件触发时间之间存在 300 毫秒的延时，所以在页面中没有实现 touchmove 滚动处理的情况下，可以使用 touchstart 事件来代替元素的 click 事件，加快页面点击的响应速度，提高用户体验。但同时我们也要注意页面重叠元素 touch 动作的点击穿透问题。

1
2
3
4
5
6
7
8
9

//不推荐
$('body').on('click','.btn',function(e){
    console.log(this);
});

//推荐
$('body').on('touchstart','.btn',function(e){
    console.log(this);
});

5．避免 touchmove、scroll 连续事件处理

需要对 touchmove、scroll 这类可能连续触发回调的事件设置事件节流，例如设置每隔 16ms（60 帧的帧间隔为 16.7ms，因此可以合理地设置为 16ms ）才进行一次事件处理，避免频繁的事件调用导致移动端页面卡顿。

1
2
3
4
5
6
7
8
9
10
11
12

//不推荐
$('.scroller').on('touchmove','.btn',function(e){
    console.log(this);
});

//推荐
$('.scroller').on('touchmove','.btn',function(e){
    let self=this;
    setTimeout(function(){
        console.log(self);
    },16);
});

6．避免使用 eval、with，使用 join 代替连接符＋，推荐使用 ECMAScript6 的字符串模板

这些都是一些基础的安全脚本编写问题，尽可能使用较高效率的特性来完成这些操作，避免不规范或不安全的写法。

7．尽量使用 ECMAScript6＋的特性来编程

ECMAScript6＋ 一定程度上更加安全高效，而且部分特性执行速度更快，也是未来规范的需要，所以推荐使用 ECMAScript6＋ 的新特性来完成后面的开发。

渲染类

1．使用 Viewport 固定屏幕渲染，可以加速页面渲染内容

一般认为，在移动端设置 Viewport 可以加速页面的渲染，同时可以避免缩放导致页面重排重绘。在移动端固定 Viewport 设置的方法如下。

1
2

<!--设置viewport不缩放-->
<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=no">

2．避免各种形式重排重绘

页面的重排重绘很耗性能，所以一定要尽可能减少页面的重排重绘，例如页面图片大小变化、元素位置变化等这些情况都会导致重排重绘。

3．使用 CSS3 动画，开启GPU加速

使用 CSS3 动画时可以设置 transform:translateZ(0) 来开启移动设备浏览器的GPU图形处理加速，让动画过程更加流畅，但需要注意的是，在 Native WebView 下 GPU 加速有几率产生 App Crash。

1
2
3
4

-webkit-transform:translateZ(0);
    -ms-transform:translateZ(0);
     -o-transform:translateZ(0);
        transform:translateZ(0);

4．合理使用 Canvas 和 requestAnimationFrame

选择 Canvas 或 requestAnimationFrame 等更高效的动画实现方式，尽量避免使用 setTimeout、setInterval 等方式来直接处理连续动画。

5．SVG 代替图片

部分情况下可以考虑使用 SVG 代替图片实现动画，因为使用 SVG 格式内容更小，而且 SVG DOM 结构方便调整。

6．不滥用 float

在 DOM 渲染树生成后的布局渲染阶段，使用 float 的元素布局计算比较耗性能，所以尽量减少 float 的使用，推荐使用固定布局或 flex-box 弹性布局的方式来实现页面元素布局。

7．不滥用 web 字体或过多 font-size 声明

过多的 font-size 声明会增加字体的大小计算，而且也没有必要的。

8．做好脚本容错

脚本容错可以避免「非正常环境」的执行错误影响页面的加载和不相关功能的使用

架构协议类

1．尝试使用 SPDY 和 HTTP2

在条件允许的情况下可以考虑使用 SPDY 协议来进行文件资源传输，利用连接复用加快传输过程，缩短资源加载时间。HTTP2 在未来也是可以考虑尝试的。

2．使用后端数据渲染

使用后端数据渲染的方式可以加快页面内容的渲染展示，避免空白页面的出现，同时可以解决移动端页面SEO的问题。如果条件允许，后端数据渲染是一个很不错的实践思路。后面的章节会详细介绍后端数据渲染的相关内容。

3．使用 NativeView 代替 DOM 的性能劣势

可以尝试使用 NativeView 的 MNV＊ 开发模式来避免 HTML DOM 性能慢的问题，目前使用 MNV＊ 的开发模式已经可以将页面内容渲染体验做到接近客户端 Native 应用的体验了。但需要避免 js Framework 和 native Framework 的频繁交互。