web前端工程师都需要学习什么？

Web前端开发工程师现在的发展是一个很新颖的职业，简单的说在国内或是在国际上真正开始受到重视的时间不到10年。Web前端开发是从网页制作演变而来的，名称上有很明显的时代特征。北京北大青鸟发现在互联网的演化进程中，网页制作是Web10时代的产物，那时网站的主要内容都是静态的，用户使用网站的行为也以浏览为主

要成为web前端工程师都需要学习什么

第一，必须掌握基本的Web前端开发技术，其中包括：CSS、HTML、SEO、DOM、BOM、Ajax、JavaScript等，在掌握这些技术的同时，还要清楚地了解它们在不同浏览器上的兼容情况、渲染原理和存在的Bug。第二，在一名合格的前端工程师的知识结构中，网站性能优化、SEO和服务器端的基础知识也是必须掌握的。第三，必须学会运用各种工具进行辅助开发。第四，除了要掌握技术层面的知识，还要掌握理论层面的知识，包括代码的可维护性、组件的易用性、分层语义模板和浏览器分级支持，等等。可见，看似简单的网页制作，如果要做得更好、更专业，真的是不简单。这就是前端开发的特点，也是让很多人困惑的原因。如此繁杂的知识体系让新手学习起来无从下手，对于老手来说，也时常不知道下一步该学什么。代码质量是前端开发中应该重点考虑的问题之一。例如，实现一个网站界面可能会有无数种方案，但有些方案的维护成本会比较高，有些方案会存在性能问题，而有些方案则更易于维护，而且性能也比较好。这里的关键影响因素就是代码质量。CSS、HTML、JavaScript这三种前端开发语言的特点是不同的，对代码质量的要求也不同，但它们之间又有着千丝万缕的联系。

在web前端工程师之前，我们是需要学习、实操，掌握静态网页的制作，能够灵活的使用html+css语言和Div+css的布局来制作优良的静态页面。

能够使用JavaScript语言制作精良的动态效果和用户体验，并且深入浅出的对于JavaScript的函数框架制作与使用。

能够使用Html5来制作精美网页效果以及移动APP开发和混合APP的开发与制作。

如何才能成为一个好的web前端工程师

一位好的Web前端开发工程师在知识体系上既要有广度，又要有深度，所以很多大公司即使出高薪也很难招聘到理想的前端开发工程师。现在说的重点不在于讲解技术，而是更侧重于对技巧的讲解。技术非黑即白，只有对和错，而技巧则见仁见智。以前会Photoshop和Dreamweaver就可以制作网页，现在只掌握这些已经远远不够了。无论是开发难度上，还是开发方式上，现在的网页制作都更接近传统的网站后台开发，所以现在不再叫网页制作，而是叫Web前端开发。Web前端开发在产品开发环节中的作用变得越来越重要，而且需要专业的前端工程师才能做好，这方面的专业人才近两年来备受青睐。Web前端开发是一项很特殊的工作，涵盖的知识面非常广，既有具体的技术，又有抽象的理念。简单地说，它的主要职能就是把网站的界面更好地呈现给用户。所以一名优秀的前端开发工程师，不单单需要掌握前端必须的各种技术，同时还要掌握其它技术，需要掌握一点后台的知识，同时也要对网站构架有一定的了解，同时还要掌握一定的SEO网站优化技术，这样才可以称之为一个“优秀的web前端开发工程师”。除了技术以外，还需要一定的时间来沉淀自己。一名资深的优秀web前端开发工程师，是每个大型企业都渴望的人才。业内人士表示，宁可高薪招人，险企也不愿自己培养相关的技术人才

前端与后端最初的渲染方式是后端模板渲染，就是由后端使用模板引擎渲染好 html 后，返回给前端，前端再用 js 去操作 dom 或者渲染其他动态的部分。这个过程大致分成以下几个步骤：

前端请求一个地址 url

后端接收到这个请求，然后根据请求信息，从数据库或者其他地方获取相应的数据

使用模板引擎（如 java > jsp、php > smarty）将这些数据渲染成 html

将 html 文本返回给前端

在这个过程中，前端的 html 代码需要嵌入到后端代码中（如 java、php），并且在很多情况下，前端源代码和后端源代码是在一个工程里的。

所以，不难看出，这种方式的有这样的几个不足：

前后端杂揉在一起，不方便本地开发、本地模拟调试，也不方便自动化测试

前端被约束在后端开发的模式中，不能充分使用前端的构建生态，开发效率低下

项目难以管理和维护，也可能会有前后端职责不清的问题

尽管如此，但因为这种方式是最早出现的方式，并且这种渲染方式有一个好处，就是前端能够快速呈现服务器端渲染好的页面，而不用等客户端渲染，这能够提供很好的用户体验与 SEO 友好，所以当下很多比较早的网站或者需要快速响应的展示性网站仍然是使用这种方式。

jQuery的诸多局限性导致前端工程师的发展受到了很多的限制，只能做一些表面性的工作，并不能实现前后端分离开发。

而近期出现的Vue，它给前端带来了无限的可能和改变。

改变一：真正意义上的前端工程师

之前开发都是前端做静态页面，把页面给到后台程序员改成jsp、php、asp等等一顿乱改，一顿塞变量，做完以后页面样式乱七八糟，最后你再调整css。说白了你会html，css就行了，基本没什么门槛，可以这么说。

有了Vue和Node的前端工程化以后，前端工程师能做的事情越来越多，后台人员只需要抛过来一个Api，剩下的就可以都交给前端了。

改变二：服务端渲染VS客户端渲染

传统的jsp、php或是模板渲染也好，都是服务端渲染，就是客户端一个请求，服务器直接把整个页面返回给你，简单粗暴。（Spring Boot是通过模板引擎，由服务端完成的渲染工作）

但是vue开发是前后端分离开发，通过api进行交互，客户端请求服务器返回json数据，由客户端进行渲染。

不仅减轻了服务器的压力速度更快而且渲染更加优雅，代码更容易维护。

改变三：渲染优雅，代码易维护

jQuery是通过DOM来控制数据，不仅笨重而且渲染数据特别麻烦，而 Vue是通过数据来控制状态，通过控制数据来控制渲染，变量可以直接写在标签中，渲染更加优雅。

因为前端代码和后台代码都是分开的，所以项目更容易维护，开发效率更高。

改变四：项目工程化，结合npm直接安装第三方库

Vue让前端项目更加工程化，同时也规范了前端工程师的代码，而node和npm的加入才是vue能蓬勃发展的重要原因。

Node为Vue提供了本地server和模块化开发的思路，npm更能安装Vue项目需要的模块，配合Vue使用，比如Momentjs Element ui vuex等等，这些第三方库让Vue有了无限的可能。

敲黑板（补充下）：传统开发jQuery是命令式编程，现代框架开发是函数式编程。现代框架开发，可以使用Webpack（当然使用jQuery也可以使用Webpack），可以使用人家提供的现成的脚手架，比方说create-react-app，vue-cli。极大提高了开发的效率，并且可以使用最新的ES6、ES7语法进行开发，在编码体验上，就提高了一个档次。

总结

知其然，知其所以然，没有最好的框架，只有最合适的框架！

首先了解一下URL的组成：

从上面的URL可以看出，一个完整的URL包括以下几部分：

1、协议部分：该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符

2、域名部分：该URL的域名部分为“wwwbaiducom”。一个URL中，也可以使用IP地址作为域名使用

3、端口部分：跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口80

4、虚拟目录部分：从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”

5、文件名部分：从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。本例中的文件名是“indexasp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名

6、锚部分：从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分

7、参数部分：从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。

很多大公司面试喜欢问这样一道面试题， 输入URL到看见页面发生了什么？ ,今天我们来总结一下。 简单来说，共有以下几个过程

下面我们来看看具体的细节

输入 wwwgooglecom 网址后，首先在本地的域名服务器中查找，没找到去根域名服务器查找，没有再去 com 顶级域名服务器查找，，如此的类推下去，直到找到IP地址，然后把它记录在本地，供下次使用。大致过程就是 -> com -> googlecom -> wwwgooglecom 。 (你可能觉得我多写 ，并木有，这个对应的就是根域名服务器，默认情况下所有的网址的最后一位都是，既然是默认情况下，为了方便用户，通常都会省略，浏览器在请求DNS的时候会自动加上)

既然已经懂得了解析的具体过程，我们可以看到上述一共经过了N个过程，每个过程有一定的消耗和时间的等待，因此我们得想办法解决一下这个问题！

DNS存在着多级缓存，从离浏览器的距离排序的话，有以下几种: 浏览器缓存，系统缓存，路由器缓存，IPS服务器缓存，根域名服务器缓存，顶级域名服务器缓存，主域名服务器缓存。

在你的chrome浏览器中输入:chrome://dns/，你可以看到chrome浏览器的DNS缓存。

系统缓存主要存在/etc/hosts(Linux系统)中

检查浏览器是否有缓存

通过 Cache-Control 和 Expires 来检查是否命中强缓存，命中则直接取本地磁盘的html（状态码为200 from disk(or memory) cache，内存or磁盘）；

如果没有命中强缓存，则会向服务器发起请求（先进行下一步的TCP连接），服务器通过 Etag 和 Last-Modify 来与服务器确认返回的响应是否被更改（协商缓存），若无更改则返回状态码（304 Not Modified）,浏览器取本地缓存；

若强缓存和协商缓存都没有命中则返回请求结果。

不知道你们有没有注意这样一件事，你访问http://baiducom的时候，每次响应的并非是同一个服务器（IP地址不同），一般大公司都有成百上千台服务器来支撑访问，假设只有一个服务器，那它的性能和存储量要多大才能支撑这样大量的访问呢？DNS可以返回一个合适的机器的IP给用户，例如可以根据每台机器的负载量，该机器离用户地理位置的距离等等，这种过程就是DNS负载均衡

TCP 协议通过三次握手建立连接。

翻译成大白话就是：

为什么是3次？ ：避免 历史 连接，确认客户端发来的请求是这次通信的人。

为什么不是4次？ ：3次够了第四次浪费

建立连接的过程是利用客户服务器模式，假设主机A为客户端，主机B为服务器端。

采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，主机A又重新向主机B发送连接请求，且建立成功，顺序完成数据传输。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发回确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。

采用两次握手不行，原因就是上面说的失效的连接请求的特殊情况。而在三次握手中， client和server都有一个发syn和收ack的过程， 双方都是发后能收， 表明通信则准备工作OK

为什么不是四次握手呢？ 大家应该知道通信中著名的蓝军红军约定， 这个例子说明， 通信不可能100%可靠， 而上面的三次握手已经做好了通信的准备工作， 再增加握手， 并不能显著提高可靠性， 而且也没有必要。

第一次握手 ：

客户端发送syn包(Seq=x)到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手：

服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（Seq=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：

客户端收到服务器的SYN ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

要先申请CA证书，并安装在服务器上（一个文件，配置nginx支持监听443端口开启ssl并设置证书路径）

浏览器发送请求；

网站从浏览器发过来的加密规则中选一组自身也支持的加密算法和hash算法，并向浏览器发送带有公钥的证书，当然证书还包含了很多信息，如网站地址、证书的颁发机构、过期时间等。

浏览器解析证书。

验证证书的合法性。如颁发机构是否合法、证书中的网站地址是否与访问的地址一致，若不合法，则浏览器提示证书不受信任，若合法，浏览器会显示一个小锁头。

若合法，或用户接受了不合法的证书，浏览器会生成一串随机数的密码（即密钥），并用证书中提供的公钥加密。

使用约定好的hash计算握手消息，并使用生成的随机数（即密钥）对消息进行加密，最后将之前生成的所有消息一并发送给网站服务器。

网站服务器解析消息。用已有的私钥将密钥解密出来，然后用密钥解密发过来的握手消息，并验证是否跟浏览器传过来的一致。然后再用密钥加密一段握手消息，发送给浏览器。

浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据，为后续真正数据的传输做一次测试。

发送HTTP请求

首先科补一个小知识，HTTP的端口为80/8080，而HTTPS的端口为443

发送HTTP请求的过程就是构建HTTP请求报文并通过TCP协议中发送到服务器指定端口 请求报文由 请求行 ， 请求抱头 ， 请求正文 组成。

请求行

请求行的格式为 Method Request-URL HTTP-Version CRLF eg: GET indexhtml HTTP/11 常用的方法有: GET , POST , PUT , DELETE , OPTIONS , HEAD 。

常见的请求方法区别

这里主要展示 POST 和 GET 的区别

常见的区别

注意一点你也可以在GET里面藏body，POST里面带参数

重点区别

GET 会产生一个 TCP 数据包，而 POST 会产生两个 TCP 数据包。

详细的说就是：

注意一点，并不是所有的浏览器都会发送两次数据包，Firefox就发送一次

请求报头

请求报头允许客户端向服务器传递请求的附加信息和客户端自身的信息。

从图中可以看出，请求报头中使用了Accept, Accept-Encoding, Accept-Language, Cache-Control, Connection, Cookie等字段。Accept用于指定客户端用于接受哪些类型的信息，Accept-Encoding与Accept类似，它用于指定接受的编码方式。Connection设置为Keep-alive用于告诉客户端本次HTTP请求结束之后并不需要关闭TCP连接，这样可以使下次HTTP请求使用相同的TCP通道，节省TCP连接建立的时间。

请求正文

当使用POST, PUT等方法时，通常需要客户端向服务器传递数据。这些数据就储存在请求正文中。在请求包头中有一些与请求正文相关的信息，例如: 现在的Web应用通常采用Rest架构，请求的数据格式一般为json。这时就需要设置 Content-Type: application/json 。

更重要的事情-HTTP缓存

HTTP属于客户端缓存，我们常认为浏览器有一个缓存数据库，用来保存一些静态文件，下面我们分为以下几个方面来简单介绍HTTP缓存

缓存的规则

缓存规则分为 强制缓存 和 协商缓存

强制缓存

当缓存数据库中有客户端需要的数据，客户端直接将数据从其中拿出来使用（如果数据未失效），当缓存服务器没有需要的数据时，客户端才会向服务端请求。

又称对比缓存。客户端会先从缓存数据库拿到一个缓存的标识，然后向服务端验证标识是否失效，如果没有失效服务端会返回304，这样客户端可以直接去缓存数据库拿出数据，如果失效，服务端会返回新的数据

强制缓存

对于强制缓存，服务器响应的header中会用两个字段来表明——Expires和Cache-Control。

Expires

Exprires的值为服务端返回的数据到期时间。当再次请求时的请求时间小于返回的此时间，则直接使用缓存数据。但由于服务端时间和客户端时间可能有误差，这也将导致缓存命中的误差，另一方面，Expires是HTTP10的产物，故现在大多数使用Cache-Control替代。

Cache-Control

Cache-Control有很多属性，不同的属性代表的意义也不同。

协商缓存

协商缓存需要进行对比判断是否可以使用缓存。浏览器第一次请求数据时，服务器会将缓存标识与数据一起响应给客户端，客户端将它们备份至缓存中。再次请求时，客户端会将缓存中的标识发送给服务器，服务器根据此标识判断。若未失效，返回304状态码，浏览器拿到此状态码就可以直接使用缓存数据了。

对于协商缓存来说，缓存标识我们需要着重理解一下，下面我们将着重介绍它的两种缓存方案。

Last-Modified

Last-Modified：服务器在响应请求时，会告诉浏览器资源的最后修改时间。

从字面上看，就是说：从某个时间节点算起，是否文件被修改了

这两个的区别是一个是修改了才下载一个是没修改才下载。

Last-Modified 说好却也不是特别好，因为如果在服务器上，一个资源被修改了，但其实际内容根本没发生改变，会因为Last-Modified时间匹配不上而返回了整个实体给客户端（即使客户端缓存里有个一模一样的资源）。为了解决这个问题，HTTP11推出了Etag。

Etag

Etag：服务器响应请求时，通过此字段告诉浏览器当前资源在服务器生成的唯一标识（生成规则由服务器决定）

但是实际应用中由于Etag的计算是使用算法来得出的，而算法会占用服务端计算的资源，所有服务端的资源都是宝贵的，所以就很少使用Etag了。

缓存的优点

不同刷新的请求执行过程

浏览器地址栏中写入URL，回车

F5

Ctrl+F5

服务器处理请求并返回HTTP报文

它会对TCP连接进行处理，对HTTP协议进行解析，并按照报文格式进一步封装成HTTP Request对象，供上层使用。这一部分工作一般是由Web服务器去进行，我使用过的Web服务器有Tomcat, Nginx和Apache等等 HTTP报文也分成三份， 状态码 ， 响应报头 和 响应报文

状态码

状态码是由3位数组成，第一个数字定义了响应的类别，且有五种可能取值:

平时遇到比较常见的状态码有:200, 204, 301, 302, 304, 400, 401, 403, 404, 422, 500

常见状态码区别

200 成功

请求成功，通常服务器提供了需要的资源。

204 无内容

服务器成功处理了请求，但没有返回任何内容。

301 永久移动

请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。

302 临时移动

服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

304 未修改

自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。

400 错误请求

服务器不理解请求的语法。

401 未授权

请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。

403 禁止

服务器拒绝请求。

404 未找到

服务器找不到请求的网页。

422 无法处理

请求格式正确，但是由于含有语义错误，无法响应

500 服务器内部错误

服务器遇到错误，无法完成请求。

响应报头

常见的响应报头字段有: Server, Connection。

响应报文

你从服务器请求的HTML,CSS,JS文件就放在这里面

就是 Webkit 解析渲染页面的过程。

这个过程涉及两个比较重要的概念 回流 和 重绘 ，DOM结点都是以盒模型形式存在，需要浏览器去计算位置和宽度等，这个过程就是回流。等到页面的宽高，大小，颜色等属性确定下来后，浏览器开始绘制内容，这个过程叫做重绘。浏览器刚打开页面一定要经过这两个过程的，但是这个过程非常非常非常消耗性能，所以我们应该尽量减少页面的回流和重绘

这个过程中可能会有dom操作、ajax发起的http网络请求等。

web-socket、ajax等，这个过程通常是为了获取数据

setTimeout、setInterval、Promise等宏任务、微任务队列

当Render Tree中部分或全部元素的尺寸、结构、或某些属性发生改变时，浏览器重新渲染部分或全部文档的过程称为回流。

会导致回流的操作：

一些常用且会导致回流的属性和方法：

当页面中元素样式的改变并不影响它在文档流中的位置时（例如：color、background-color、visibility等），浏览器会将新样式赋予给元素并重新绘制它，这个过程称为重绘。

JS的解析是由浏览器的JS引擎完成的。由于JavaScript是单线程运行，也就是说一个时间只能干一件事，干这件事情时其他事情都有排队，但是有些人物比较耗时（例如IO操作），所以将任务分为 同步任务 和 异步任务 ，所有的同步任务放在主线程上执行，形成执行栈，而异步任务等待，当执行栈被清空时才去看看异步任务有没有东西要搞，有再提取到主线程执行，这样往复循环（冤冤相报何时了，阿弥陀佛），就形成了Event Loop事件循环，下面来看看大人物

先看一段代码

结果我想大家都应该知道。主要来介绍JavaScript的解析，至于Promise等下一节再说

JavaScript是一门单线程语言，尽管H5中提出了 Web-Worker ，能够模拟实现多线程，但本质上还是单线程，说它是多线程就是扯淡。

既然是单线程，每个事件的执行就要有顺序，比如你去银行取钱，前面的人在进行，后面的就得等待，要是前面的人弄个一两个小时，估计后面的人都疯了，因此，浏览器的JS引擎处理JavaScript时分为 同步任务 和 异步任务

这张图我们可以清楚看到

js引擎存在monitoring process进程，会持续不断的检查主线程执行栈是否为空，一旦为空，就会去Event Queue那里检查是否有等待被调用的函数。 估计看完这些你对事件循环有一定的了解，但是事实上我们看对的没这么简单，通常我们会看到Promise，setTimeout，processnextTick（），这个时候你和我就懵逼。

不同任务会进入不同的任务队列来执行。 JS引擎开始工作后，先在宏任务中开始第一次循环（ script里面先执行，不过我喜欢把它拎出来，直接称其进入执行栈 ），当主线程执行栈全部任务被清空后去微任务看看，如果有等待执行的任务，执行全部的微任务（其实将其回调函数推入执行栈来执行），再去宏任务找最先进入队列的任务执行，执行这个任务后再去主线程执行任务（例如执行```consolelog("hello world")这种任务），执行栈被清空后再去微任务，这样往复循环（冤冤相报何时了）

下面来看一段代码

我们看看它的执行情况

具体的执行过程大致就是这样。

PHP查询数据库这部分你已熟悉我就不再展示相关代码，主要是拿到结果后将查到的结果以json格式打包发往前端的代码，如下：

//新建一个空数组名称为$rows 用于保存标准的json格式数据

$rows = array();

//使用循环将数据结果全部写入到$rows数组中,其中的$result为查询到的数据集合

while($row = $result->fetch_assoc()) {

$rows[] = $row;

}

echo json_encode($rows); //将数组转为JSON格式，并返回给前端

前端开发代码优化、可维护性、浏览器兼容性是非常重要的课题。从实际的工程应用角度出发，最常遇见的前端优化问题。前端性能进行优化规则，基本可以涵盖现在前端大部分的性能优化原则了，很多更加geek和精细优化方法都是从这些原则里面延伸出来的。

前端性能进行优化都有哪些规则

减少HTTP请求次数

尽量合并、CSS、JS。比如加载一个页面有5个css文件的话，把这个5个文件合成一个的话，就只需要发出一次http请求，节省网络请求时间，加快页面的加载。

2 使用CDN

网站上静态资源即css、js全都使用cdn分发，包括

3 避免空的src和href

当link标签的href属性为空、script标签的src属性为空的时候，浏览器渲染的时候会把当前页面的URL作为它们的属性值，从而把页面的内容加载进来作为它们的值。所以要避免犯这样的疏忽。

4 为文件头指定Expires

Exipres是用来设置文件的过期时间的，一般对css、js、资源有效。 他可以使内容具有缓存性，这样下回再访问同样的资源时就通过浏览器缓存区读取，不需要再发出http请求。如下例子：

新浪微博的这个css文件的Expires时间是2016-5-04 09:14:14

5 使用gzip压缩内容

gzip能够压缩任何一个文本类型的响应，包括html，xml，json。大大缩小请求返回的数据量。

6 把CSS放到顶部

网页上的资源加载时从上网下顺序加载的，所以css放在页面的顶部能够优先渲染页面，让用户感觉页面加载很快。

7 把JS放到底部

加载js时会对后续的资源造成阻塞，必须得等js加载完才去加载后续的文件 ，所以就把js放在页面底部最后加载。

8 避免使用CSS表达式

举个css表达式的例子

font-color: expression( (new Date())getHours()%3 “#FFFFFF" : “#AAAAAA" );

这个表达式会持续的在页面上计算样式，影响页面的性能。并且css表达式只被IE支持。

9 将CSS和JS放到外部文件中

目的是缓存文件，可以参考原则4。 但有时候为了减少请求，也会直接写到页面里，需根据PV和IP的比例权衡。

10 权衡DNS查找次数

减少主机名可以节省响应时间。但同时，需要注意，减少主机会减少页面中并行下载的数量。

IE浏览器在同一时刻只能从同一域名下载两个文件。当在一个页面显示多张时，IE 用户的下载速度就会受到影响。所以新浪会搞N个二级域名来放。

下面是新浪微博的域名，我们可以看到他有多个域名，这样可以保证这些不同域名能够同时去下载，而不用排队。不过如果当使用的域名过多时，响应时间就会慢，因为不用响应域名时间不一致。

11 精简CSS和JS

这里就涉及到css和js的压缩了。比如下面的新浪的一个css文件，把空格回车全部去掉，减少文件的大小。现在的压缩工具有很多，基本主流的前端构建工具都能进行css和js文件的压缩，如grunt，glup等。

12 避免跳转

有种现象会比较坑爹，看起来没什么差别，其实多次了一次页面跳转。比如当URL本该有斜杠（/）却被忽略掉时。例如，当我们要访问 http:// baiducom 时，实际上返回的是一个包含301代码的跳转，它指向的是 http:// baiducom/ （注意末尾的斜杠）。在nginx服务器可以使用rewrite；Apache服务器中可以使用Alias 或者 mod_rewrite或者the DirectorySlash来避免。

另一种是不用域名之间的跳转， 比如访问 http:// baiducom/bbs 跳转到 http:// bbsbaiducom/ 。那么可以通过使用Alias或者mod_rewirte建立CNAME（保存一个域名和另外一个域名之间关系的DNS记录）来替代。

13 删除重复的JS和CSS

重复调用脚本，除了增加额外的HTTP请求外，多次运算也会浪费时间。在IE和Firefox中不管脚本是否可缓存，它们都存在重复运算JavaScript的问题。

14 配置ETags

它用来判断浏览器缓存里的元素是否和原来服务器上的一致。比last-modified date更具有弹性，例如某个文件在1秒内修改了10次，Etag可以综合Inode(文件的索引节点(inode)数)，MTime(修改时间)和Size来精准的进行判断，避开UNIX记录MTime只能精确到秒的问题。 服务器集群使用，可取后两个参数。使用ETags减少Web应用带宽和负载

15 可缓存的AJAX

异步请求同样的造成用户等待，所以使用ajax请求时，要主动告诉浏览器如果该请求有缓存就去请求缓存内容。如下代码片段, cache:true就是显式的要求如果当前请求有缓存的话，直接使用缓存

$ajax({      url : 'url',      dataType : "json",      cache: true,      success : function(son, status){                  }

16 使用GET来完成AJAX请求

当使用XMLHttpRequest时，浏览器中的POST方法是一个“两步走”的过程：首先发送文件头，然后才发送数据。因此使用GET获取数据时更加有意义。

17 减少DOM元素数量

这是一门大学问，这里可以引申出一堆优化的细节。想要具体研究的可以看后面推荐书籍。总之大原则减少DOM数量，就会减少浏览器的解析负担。

18 避免404

比如外链的css、js文件出现问题返回404时，会破坏浏览器的并行加载。

19 减少Cookie的大小

Cookie里面别塞那么多东西，因为每个请求都得带着他跑。

20 使用无cookie的域

比如CSS、js、等，客户端请求静态文件的时候，减少了 Cookie 的反复传输对主域名的影响。

21 不要使用滤镜

IE独有属性AlphaImageLoader用于修正70以下版本中显示PNG的半透明效果。这个滤镜的问题在于浏览器加载时它会终止内容的呈现并且冻结浏览器。在每一个元素（不仅仅是）它都会运算一次，增加了内存开支，因此它的问题是多方面的。

完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式来代替，这种格式能在IE中很好地工作。如果你确实需要使用AlphaImageLoader，请使用下划线_filter又使之对IE7以上版本的用户无效。

22 不要在HTML中缩放

比如你需要的尺寸是50 50

那就不用用一张500500的大尺寸，影响加载

23 缩小faviconico并缓存

使用vue2服务端渲染的web站点，它的大概流程：

node服务器接受到客户端的请求

然后向其他服务器请求数据

把获取到的数据给vue渲染

把渲染后的东西返回给客户端