前端优化不完全指南

本文主要从工作效率、速度性能、稳定性、响应式、兼容性、搜索SEO、信息无障碍等方面进行讲解。

前端优化是一个让人技术提升的point，希望你也能从这里学到一些东西。

1 工作效率

你是否经常处于这样的场景：从早上忙到晚上八九点，一会与产品经理沟通，一会在部门群聊一下新奇的东西，一会被设计美眉纠缠住拖不了身，有时还开不了部门的会议因为页面急着上线，然后继续加班~~~

怎么提高我们的工作效率？下面从四个方面讲解：

• 时间管理

• 利用工具

• 经验和阅历

• 使用新技术

1.1 时间管理

凡是时间管理，都会联想到计划这个词。我们先看看别人家的月计划表和周计划表，之所以周计划表为空，是希望你能把它下载并打印出来，行动从计划开始：

月计划表：

周计划表：

当然计划不要做得过于琐碎，且不要占用自己太多时间。做好计划之余，在执行过程中需要注意几点：

• 正确的时间点做正确的事，比如早上比较精神，可选择比较难的项目开展，可容易达到高效率。

• 专注一件事情，尽量不要被琐碎或其他事情影响，而且不要频繁地去看计划表，最好是做完一件再去看，否则容易焦虑导致无法专心。

1.2 利用工具

第一样工具，比如程序员杯子：

利用工具有什么好处呢？

• 减少重复性工作。

• 减少繁琐工作流程，一键式化。

1.2.1 编辑器

选择好一个前端编辑器是比较重要的。目前sublime、webstorm和vim是比较常见的，建议不使用Dreamweaver。

sublime目前还是不错的选择，可以安装插件，比如BracketHighlighter 高亮显示、JsFormat、Emmet html/CSS快速编辑以及DocBlockr插件，快速输入jsDoc注释等，还可以自定义代码段snippets。

无论你使用哪种编辑器，你需要的是熟悉这个编辑器并熟练它的快捷键。

1.2.2 浏览器开发者工具

作为前端人员，首选的浏览器当然是chrome。推荐阅读Chrome开发者工具不完全指南一系列文章，它从一些基础的功能开始到它的一些高级性能分析器（Timeline、Profiles），熟悉chrome对我们的开发工作有很大的作用。

1.2.3 其他常用工具

切图工具：photoshop cc切图之智能切图、 cutterman

量色、测距工具：FastStone Capture、马克鳗 - 设计稿标注

图片压缩：tinypng、智图

生成雪碧图：spritebox、CSS Sprite Generator、cssgaga

调试工具：Fiddler 、weinre 、微信调试工具；

1.2.4 前端工程化

凡是重复的，必须使用工具自动完成。

工具众多，我们就有一种想法，能不能有一种工具能帮我们自动生成雪碧图、 css压缩、图片压缩等等，然后就出现了前端工程化。前端工程化一般可分为五个步骤：

（1） 初始，生成基础目录结构和样式库。

（2） 开发，实时预览、预编译。

（3） 构建，预编译、合并、压缩。

（4） 发布，将构建后静态文件发布上线。

（5） 打包，资源路径转换，源码打包 。

这里推荐一个工具fis，解决前端开发中自动化工具、性能优化、模块化框架、开发规范、代码部署、开发流程等问题。还有凹凸实验室研发的athena，O2Team构建项目流程工具，可以生成相应目录和代码，同时对项目进行编译， 一次安装，到处运行。

1.3 阅历和经验

我所理解的程序员兼并聪明以及“懒惰”精神，推崇懒惰式开发，即把问题理解清楚，确保将要写的代码能真正的解决问题，这将会避免之后写出大量无用的代码，正所谓“懒”出效率。

我们的阅历和经验可以大大提高开发效率，思考代码的时间增加从而选出最优方案，因此写代码速度更快以及代码长度更短，对问题的透彻理解使调试代码的速度也更快。

根据阅历和经验，或借助其他人的，我们进行整理从而形成自己或团队的规范，这可大大提高我们的写码速度。

1.4 使用新技术

使用新技术如何提高我们的工作效率。一贯我们都使用我们熟悉的技术去开发一个技术处理方案，毕竟学习新技术的时间成本还是存在的。但是还是不能忽略一些新技术的存在，一般新技术包含了一些很棒的新特性，可以更加方便的实现很多复杂的操作，提高开发人员的效率，比如ES6。用你的慧眼去积累新技术，会派上用场的。

2 速度性能

为什么需要前端性能优化？性能优化可以从哪几个方面入手？

遇到一个页面，5秒还没加载完成，那个菊花转啊转，或者页面完全白屏，那简直把人逼疯了。从用户体验的角度看，前端性能优化是非常有必要的。网页最长加载时间一般不能超过3秒。

首先我们需要确定网页的性能指标，可量化的目标以及可持续跟踪的优化数据是性能优化工作得以持续进行的保障，同时也是源动力！比如：

• 首屏加载时长

• DOM加载时长

• 页面白屏时长

我们一般通过三种方式来检验我们的网页性能：

• 通过浏览器开发者工具或浏览器插件、Fiddler、Charles等查看页面加载情况。原理是通过追踪HTTP请求与响应的时间，以图形的方式列出所有资源的下载情况。缺点是人为操作，难以实现批量测试与统计。

• 在页面中引入额外的代码钩子来记录时间等相关数据。缺点是加重了开发者与测试人员的负担，还有可能因为检测代码本身的潜在问题影响页面的性能。如果好一点的话，会接入一个性能数据收集系统，采取并分析数据。

• 使用第三方的工具如Page Speed、YSlow和WebPagetest，能够选择在不同浏览器和不同地域进行测试，并且给出各方面的评分以及提供一些优化建议。但某些服务需要排队等待，并且难以实现批量测试与统计。下面是使用WebPagetest测试京东首页的情况：

持续追踪性能数据，要选择合适的页面性能测量工具或API，一旦选定后，不再更换，以保证历史数据的可参照性。我们还要形成一种意识，达成性能联盟小组，对于重要的业务或者页面，一定要从性能的角度考虑问题，有理有据地拒绝有损于前端性能的业务需求或改动。

人人都知道雅虎军规，那我就来个截图吧！

以下，我们从服务端、网络、客户端三个方面来一一突破速度性能的提升。

2.1 没事少烦我-服务端

2.1.1 使用内容分发网络（Content Delivery Network，CDN）

通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的 cache服务器内，通过DNS负载均衡的技术，判断用户来源就近访问cache服务器取得所需的内容。深圳用户访问遥远的美国服务器，当然不理想了。把静态内容分布到CDN可以减少用户响应时间20%或更多。

2.1.2 静态资源缓存，移动端离线缓存

如果可以减少服务端的负担，在应用离线时可使用资源或加载资源更快，岂不乐哉？

缓存利用可包括：添加 Expires 头，配置 ETag，使 Ajax 可缓存等。其实，恰当的缓存设置可以大大的减少 HTTP请求，也可以节省带宽 。

• 配置 ETag：即If-None-Match: 上次 ETag 的内容。浏览器会发出请求询问服务端，资源是否过期；服务端发现,没有过期，直接返回一个状态码为 304、正文为空的响应，告知浏览器使用本地缓存；如果资源有更新，服务端返回状态码 200、Etag 和正文。这个过程被称之为 HTTP 的协商缓存，通常也叫做弱缓存。

• 添加 Expires 头：服务端通过响应头告诉浏览器，在什么时间之前（Expires）或在多长时间之内（Cache-Control: Max-age=xxx），不要再请求服务器了。这个机制我们通常称之为 HTTP 的强缓存。一般会对 CSS、JS、图片等资源使用强缓存，而入口文件（HTML）一般使用协商缓存或不缓存。

• AppCache：

AppCache主要利用manifest 文本文件，告知浏览器被缓存的内容以及不缓存的内容

manifest 文件可分为三个部分：

（1） CACHE MANIFEST - 在此标题下列出的文件将在首次下载后进行缓存，等价于CACHE

（2） NETWORK - 在此标题下列出的文件需要与服务器的连接，且不会被缓存

（3） FALLBACK - 在此标题下列出的文件规定当页面无法访问时的回退页面

使用AppCache方案的步骤：

（1） 整理出需要缓存的静态文件列表，如juqery.js和gb.css。

（2） 配置服务器支持。

（3） 确定内容更新机制和浏览器兼容方案。

LocalStorage：用于持久化的本地存储，除非主动删除数据，否则数据是永远不会过期的。

2.2 省着点用-网络

2.2.1 减少请求数

可通过以下方式减少请求数：

• 小图片合并雪碧图；

• JS、CSS文件选择性合并；

• 避免重复的资源请求。

减少请求数对于速度优化来说最重要最有效的，特别是网络差的用户。一个完整的请求需要经过域名解析以及DNS寻址、与服务器建立连接、发送数据、等待服务器响应、接收数据的过程；每个请求都需要携带数据，因此每个请求都需要占用带宽；浏览器进行并发请求的请求数是有上限的。请求多了的情况，明显增加了网页的响应时间。一个页面由多个模块拼接而成，几个模块中请求了同样的资源时，就会导致资源的重复请求。

2.2.2 减少文件大小（减少请求带宽）

• 压缩CSS、JS、图片；

• 尽可能控制DOM节点数；

• 精简css、 JavaScript，移除注释、空格、重复css和脚本。

• 开启Gzip，Gzip的思想就是把文件先在服务器端进行压缩，且压缩率达到85%，然后再传输，传输完毕后浏览器会 重新对压缩过的内容进行解压缩，并执行。。好处在于Gzip的支持已经很好，且爬虫可识别，压缩率达到66%-85%显著减少了文件传输的大小。另外，gzip对pdf文件的压缩效果不大，而且会浪费CPU。

2.2.3 合理使用静态资源域名

域名的要求是短小且独立。

短小可以减少头部开销，因为域名越短请求头起始行的 URI 就越短。之所以要求独立，因为独立域名不会共享主域的 Cookie，可以有效减小请求头大小，这个策略一般称之为 Cookie-Free Domain；另外一个原因是浏览器对相同域名的并发连接数限制，一般允许同域名并发 6~8 个连接，域名不是越多越好，每个域名的第一个连接都要经历 DNS 查询（DNS Lookup），导致会耗费一定的时间，控制域名使用在2-4个之间。另外注意：同一静态资源在不同页面被散列到不同子域下，会导致无法利用 HTTP 缓存。

2.2.4 使用HTTP 2

HTTP 2 相比 HTTP 1.1 的更新大部分集中于：

多路复用：多路复用很好地解决如何让重要资源尽快加载这个问题。同域名下或者不同域但是同时满足同一个 IP以及使用同一个证书的这两个条件中的所有通信都在单个连接上完成，此连接上同时打开任意数量的双向数据流（ HTTP 1.1 有连接数限制）。使用多域名加上相同的 IP 和证书部署 Web 服务有特殊的意义：让支持 HTTP/2 的终端只建立一个连接，用上 HTTP/2 协议带来的各种好处；而只支持 HTTP/1.1 的终端则会建立多个连接，达到同时更多并发请求的目的。

HEAD 压缩：HTTP/2 将请求和响应数据分割为更小的帧，并对它们采用二进制编码（ Binary Framing ）。在 HTTP/1 中，HTTP 请求和响应都是由「状态行、请求 / 响应头部、消息主体」三部分组成，状态行和头部却没有经过任何压缩，直接以纯文本传输。如下图的比较：

在 HTTP/2 中，每个数据流都以消息的形式发送，而消息又由一个或多个帧组成。多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装。

请求优先级：服务器可以根据流的优先级，控制资源分配(CPU、内存、带宽)，而在响应数据准备好之后，优先将最高优先级的帧发送给客户端。

服务器推送：启动Server Push，意味着服务端可以在发送页面HTML时主动推送其它资源，有自己独立的URL，可以被浏览器缓存；如果服务端推送的资源已经被浏览器缓存过，浏览器可以通过发送 RST_STREAM 帧来拒收。

2.2 学会持家，让家变得简洁漂亮-客户端

• 使用外链CSS和JS，CSS放头，JS放尾，防止阻塞以减少对并发下载的影响，尽早刷新文档的输出。

• html的代码优化，如：

• 避免空的图片src；

  协议自适应，减少html文件大小，将https://和http://都替换成//。

• css的代码优化，如：

• 建议使用类选择器，访问比较快；

• 不建议使用很长的base64；

• 避免CSS表达式；

• 避免使用Filters。

• js的代码优化，如：

• 避免使用eval和width；

• 减少作用域链查找；

• 减少DOM访问，尽量缓存DOM；

• 充分利用事件委托；

• 减少Repaint（重绘）和Reflow（重排）最好通过批量更新元素减少重排次数，如设置类class统一更新样式，在添加多个li

• 元素将会触发多次页面重排的情况下使用 DOM fargment 在内存中创建完整的 DOM 节点，然后再一次性添加到 DOM 中。

• 图片格式的选择：

• 颜色较为丰富的图片而且文件比较大的（40KB - 200KB）或者有内容的图片优先考虑 jpg；图标等颜色比较简单、文件体积不大、起修饰作用的图片，优先考虑使用 PNG8 格式；图像颜色丰富而且图片文件不太大的（40KB 以下）或有半透明效果的优先考虑 PNG24 格式。

• 条件允许的，使用新格式WEBP和BPG。

• 用SVG和ICONFONT代替简单的图标。

• 用字蛛来代替艺术字体切图，它可剔除没有使用的字符，从而解决中文字体过大的问题，并编码成跨平台兼容的格式。

• 合理分配资源加载时间，按需加载，包括CSS、JS文件以及图片、业务模块等。

根据我们网页最初加载需要的最小内容集推断其他内容延迟加载；无条件提前加载公共内容或根据用户行为推断提前加载某些内容，如根据搜索框输入的文字来判断加载的内容。加载机制如下：

• 预加载

• Dom Ready后加载

• onLoad后加载

• 滚动加载

• 减少DNS 查询：DNS 查询一般需要几毫秒到几百毫秒，移动环境下会更慢。我们可以预先读取DNS，减少用户等待时间。

3 稳定性

稳定性的第一要求是可用。最起码的要求是页面得出来，要不然没法用了。

其次讲究的是页面的可维护性，假如页面挂了，多久可以恢复过来，另外考虑页面挂的期间是否可以采取静态页面处理等方式。

页面的稳定性其实和前端安全挂钩，即使页面可以出来了，但是不能保证不会被黑掉，下文从前端安全的方面讲解。

3.1 常见攻击：

• XSS (Cross Site Script) ，跨站脚本攻击，往Web页面里插入恶意html代码。特点是攻击者的代码必须能获取用户浏览器端的执行权限，要杜绝此类攻击出现可以在入口和出口进行严格的过滤。

三种类型：

（1） 反射型XSS：一次性；将包含注入脚本的恶意链接发送给受害者。

（2） 持久型XSS：用户输入的数据“存储”在服务器端，比如一条包含XSS代码的留言。

（3） DOM XSS：使用一些eval等有输出的语句意味着多了一份被XSS的风险。

应对策略：

• 当恶意代码值被作为某一标签的内容显示：在不需要html输入的地方对html 标签及一些特殊字符( ”