2017前端性能优化清单

2017前端性能优化清单

你开始使用渐进启动了么？是否是已经使用过React和Angular中tree-shaking和code-splitting两个工具？有没有用过Brotli、Zofli和HPACK这几种压缩技术，或者OCSP协议（在线证书状态协议）？知不知道资源提醒，客户端提醒和CSS containment一类的技术？了解IPv6，HTTP/2和Service Worker这些协议吗？

回想那些年，你们每每在完成了产品以后才会去考虑性能。经常把与性能相关的事情拖到项目的最后来作，所作的也不过是对服务器上的config文件进行一些微调、串联、优化以及部分特别小的调整。而如今，技术已经有了翻天覆地的变化。

一个项目的性能是很是重要的，除了要在技术层面上注意，更要在项目的设计之初就开始考虑，这样才可使性能的各类隐形需求完美的整合到项目中，随着项目一块儿推动。性能最好具备可量化、可监测以及可改动的特性。网络愈来愈复杂，对网络的监控也变得愈来愈难，由于监测的过程会受到包括设备、浏览器、协议、网络类型以及其余技术（CDN，ISP，缓存，代理服务器，防火墙，负载均衡器和服务器对性能的影响都很大）的很大影响。

下文是一份2017年的前端性能优化清单，阐述了做为前端开发人员，为了确保反馈速度以及浏览器兼容性咱们须要考虑的问题。

（你也能够下载checklist PDF或者check in Apple Pages。优化万岁！）

正文

微优化是保持性能最好的办法，可是又不能有太过明确的优化目标，由于过于明确的目标会影响在项目中作的每个决定。如下是一些不一样的模型，请按照本身舒服的顺序阅读。

请准备好而后定下目标！

1. 比你最强的竞争对手快20%

根据一个心理学研究，你的网站最少在速度上比别人快20%，才能让用户感受到你的网站比别人的更快。这个速度说的不是整个页面的加载时间，而是开始加载渲染的时间，首次有效渲染时间（例如页面须要加载主要内容的时间），或者交互时间（指的是页面或者应用中主要的页面加载完成，并主备好与用户进行交互的时间）。

在Moto G（一个中端三星设备）和Nexus 4（比较主流的设备）上衡量开始渲染时间（用WebPagetest）以及首页有效渲染时间（用Lighthouse），最好是在一个开放的实验室中，使用规范的3G，4G和Wi-Fi连接。

Lighthouse，一个Google开发的新的性能审查工具

你能够经过你的分析报告看看你的用户处在哪一个阶段，选取其中前90%的用户体验来作测试。接着收集数据，建一个表格，筛去20%的数据并预设一个目标（如：性能预算）。如今你能够将上述两个值进行对比检测。若是你始终维持着你的目标而且经过一点一点改变脚本去加快交互时间，那么上述方法就是合理可行的。

由Brad Frost建立的性能分析

和你的同事分享这份清单。首先要确保团队中的每一个人都熟悉这份清单。项目中每个决定都会影响性能，若是前端工程师们都在积极的参与项目概念，UX以及视觉设计的决定，这将会给整个项目带来巨大收益。地图设计的决定违背了性能理念，因此他在这份清单内的顺序有待考虑。

2. 反应时间为100毫秒，帧数是每秒60帧

RAIL性能模型会为你提供一个优秀的目标，既尽最大的努力在用户初始操做后的100毫秒内提供反馈。为了达到这个目标，页面须要放弃权限，并将权限在50毫秒内交回给主线程。对于像动画同样的高压点，最好的方法就是什么都不作，由于你永远没法达到最小绝对值。
同理，动画的每一帧都须要在16毫秒内完成，这样才能保证每秒60帧（一秒/60=16.6毫秒），若是能够的话最好能在10毫秒内完成。由于浏览器须要必定的时间去在屏幕上渲染新的帧，并且你的代码须要在16.6毫秒内完成执行。要注意，上述目标应用于衡量项目的运行性能，而非加载性能。

3. 首次有效渲染时间要低于1.25秒，速度指数要低于1000

纵使这个目标实现起来很是困难，你的最终目标也应该是让开始渲染时间低于1秒且速度指数低于1000（在网速快的地方）。对于首次有效渲染时间，上限最好是1250毫秒。对于移动端，3G下移动设备首次渲染时间低于3秒都是能够接受的。稍微高一点也不要紧，但千万别高太多。

定义你所须要的环境

4. 选择和安装你的开发环境

不要过多的关注当下最流行的工具，坚持选择适合本身开发环境的工具，例如Grunt、Gulp、Webpack、PostCSS，或者组合起来的工具。只要这个工具运行的速度够快，并且没有给你的维护带来太大问题，这就够了。

5. 渐进加强（progressive enhancement）

在构建前端结构的时候，应始终将渐进加强做为你的指导原则。首先设计而且构建核心体验，随后再完善那些为高性能浏览器设计的高级特性的相关体验，建立弹性体验。若是你的网页能够在使用低速网络、老旧显示器的很慢的电脑上运行飞快，那么在光纤高配电脑上它只会运行的更快。

6. Angular，React，Ember等

最好使用那些支持服务器端渲染的框架。在使用某个框架钱，先记录服务器和客户端的引导时间，记得要在移动设备上测试，最终才能使用某个框架（由于面对的是性能问题，若是在使用某个框架后，再作修改是很是困难的）。若是你使用JavaScript框架，要保证你的选择是被普遍使用而且通过考验的。不一样框架对性能有着不一样程度的影响，同时对应着不一样的优化策略，因此最好能够清楚的了解你要用的框架的每一个方面。在写网页应用时能够先看看PRPL pattern和application shell architecture。

本图描述了PRPL pattern

上图是application shell，是一个小型的、由HTML,CSS和JavaScript构成的用户界面

7. AMP仍是Instant Articles？

根据你总体组织结构的优先顺序和策略，你能够考虑使用Google的AMP或Facebook的Instant Articles。要知道没有这些你也能够达到不错的性能，可是AMP能够提供一个性能不错的免费的内容分发网络框架（CDN），Instant Articles能够在Facebook上促进你的性能。你也能够创建progressive web AMP。

8. 选择适合你的CDN

根据你的动态数据量，能够将一部份内容外包给静态网站生成工具，将它置于CDN上，从中生成一个静态版本，从而避免那些数据库的请求。也能够选择基于CDN的静态主机平台，经过交互组件丰富你的页面（JAMStack）。

注意CDN是否能够很好的处理（或分流）动态内容。不必单纯的将你的CDN限制为静态。反复检查CDN是否执行了内容的压缩和转化，检查智能HTTP/2传输和缓存服务器（ESI），注意哪些静态或动态的部分处在CDN的边缘（最接近用户的服务器）。

开始优化

9. 直接肯定优化顺序

首先应该弄清楚你想解决的问题是什么。检查一遍你全部的文件（JavaScript，图片，字体，第三方script文件以及页面中重要的模块，例如轮播，复杂信息图标和多媒体内容），并将他们分类。
列一个表格。明确浏览器上应该有的基础核心内容，哪些部分属于为高性能浏览器设计的升级体验，哪些是附加内容（那些没必要要或者能够被延时加载的部分，例如字体，没必要要的样式，轮播组件，播放器，社交网站入口，很大的图片）。更详细的细节请参考文章”Improving Smashing Magazine’s Performance‘’。

10. 使用符合标准的技术

使用符合标准的技术向过期的浏览器提供核心体验，向老式浏览器提供加强体验, 同时对所加载的内容要有严格的把控。即首要加载核心体验部分，将加强部分放在DomContentLoaded，把额外内容发在load事件中。

之前咱们能够经过浏览器的版本推断出设备的性能，但如今咱们已经没法推测了。由于如今市场上不少廉价的安卓手机都不考虑内存限制和CPU性能，直接使用高版本的Chrome浏览器。必定要注意，在咱们没有其余选择的时候，咱们选择的技术同时可能成为咱们的限制。

11. 考虑微优化和渐进启动

在一些应用中，能够在渲染页面前先初始化应用。最好先显示框架，而不是一个进度条或指示器。使用能够加速初始渲染时间的模块或技术（例如tree-shaking和code-splitting），由于大部分性能问题来自于应用引导程序的初始分析时间。还能够在服务器上提早编译，从而减轻部分客户端的渲染过程，从而快速输出结果。最后，考虑使用Optimize.js来加快初始加载速度，它的原理是包装优先级高的调用函数（虽然如今已经没什么必要了）。

渐进启动指的是使用服务器端渲染，从而快速获得首次有效渲染，这个渲染过程也包括小部分的JavaScript文件，目的是使交互时间尽量的接近首次有效渲染时间。

到底采用客户端渲染仍是服务器端渲染？不论哪一种作法，咱们的目标都是创建渐进启动：使用服务器端渲染能够获得很短的首次有效渲染时间，这个渲染过程也包括小部分的JavaScript文件，目的是使交互时间尽量的接近首次有效渲染时间。接下来，尽量的增长一些应用的非必要功能。不幸的是，正如Paul Lewis所说，框架基本上对开发者是没有优先级的概念的，所以渐进启动在不少库和框架上是很难实施的。若是你有时间的话，仍是考虑使用策略去优化你的性能吧。

12. HTTP的缓存头使用的合理吗？

仔细检查一下例如expires，cache-control，max-age以及其余HTTP缓存头是否被正确的使用。通常来讲，资源不论在短期（若是它会被频繁改动）仍是不肯定的时间内（若是它是静态的）都是可缓存的——你大可在须要的时候在URL中成改版本。

若是可能，使用为指纹静态资源设计的Cache-control:immutable，从而避免二次验证（2016年12月，只有FireFox在https://处理中支持）。你可使用，Heroku的primer on HTTP caching headers，Jake Archibald的 ”Caching Best Practices”，还有IIya Grigorik的HTTP caching primer做为指导。

13. 减小使用第三方库，加载JavaScript异步操做

当用户请求页面时，浏览器会抓取HTML同时生成DOM，而后抓取CSS并创建CSS对象模型，最后经过匹配DOM和CSS对象生成渲染树。在须要处理的JavaScript文件被解决以前，浏览器不会开始对页面进行渲染。做为开发者，咱们要明确的告诉浏览器不要等待，直接开始渲染。具体方法是使用HTML中的defer和async两个属性。

事实上，defer更好一些（由于对于IE9及如下用户对于IE9及如下用户，颇有可能会中断脚本）。同时，减小第三方库和脚本的使用，尤为是社交网站的分享按键和<iframe>嵌入（好比地图）。你可使用静态的社交网站分享按键（例如SSBG的）和指向交互地图的静态连接去代替他们。

14. 图片是否被正确优化？

尽量的使用带有srcset，sizes还有<picture>元素的响应式图片。你也能够利用<picture>元素的WebP格式，用JPEG格式做为替补（参见Andreas Bovens的code snippet）或是使用内容协商（使用接受头）。Sketch本来就支持WebP，WebP图片能够直接被Photoshop的WebP plugin导出。固然也有不少其余方法。

响应图片段点生成器可自动处理图片

你也可使用客户端提示，如今浏览器也能够作到。在用来生成响应图片的源文件过少时，使用响应图片段点生成器或相似Cloudinary的服务自动的优化图片。在不少案例中，单独使用sreset和sizes都带来了很大的收益。在本网站上，咱们给文件添加-opt后缀——例如brotli-compression-opt.png；这样团队的每个人就知道这些带着后最的图片是被优化过的。

15. 图片的进一步优化

当你在编写登录界面的时候，发现页面上的图片加载的特别快，这时你须要确认一下JPEG格式文件是否已经经过mozJPEG（它能够操做扫描等级从而提升渲染时间）优化和压缩，PNG格式对应Pingo，GIF须要用到Lossy GIF，SVG要使用SVGOMG。对图片不重要的部分进行模糊处理（使用高斯模糊过滤器处理他们），从而减小文件大小，最后你可能还要去彩色化使图片变成黑白，从而减小更多的容量。对于背景图片，使用Photoshop保持0到10%的质量输出是绝对能够接受的。

若是你还以为不够，那你能够经过多重背景图片技术来提升图片的感知性能。

16. 网页字体优化了吗？

你用来修饰网页字体的服务颇有可能毫无用处，包括字形和额外的特性。若是你在使用开源的字体，尝试用字体库中某一个小的子集或是本身归类一个小的子集从而压缩文件大小（例如经过一些特殊的注音符号引用Latin）。WOFF2 support是个很是不错的选择，若是浏览器不支持，那你能够将WOFF和OTF做为备用。你也能够从Zach Leatherman的“Comprehensive Guide to Font-Loading Strategies”一文中选择一个合适的策略，而后使用服务器来缓存字体。若是想要快速入门，Pixel Ambacht的教程与案例会让你的字体变得尽然有序。

Zach Leatherman的“Comprehensive Guide to Font-Loading Strategies”提供了一打可让字体传输变得更好的选项

若是你用的是第三方服务器主机，没办法本身在服务器上对字体进行操做，必定看看Web Font Loader。FOUT is better than FOIT中提到，在备选状况下当即渲染文本，而且异步加载字体——你也可使用loadCSS实现这个。你可能也会避免本地OS上安装字体。

17. 快速执行关键部分的CSS

为了确保浏览器尽量快的渲染你的页面，先收集页面首次可见部分的CSS文件（也叫决定性CSS或上半版CSS）进行渲染，而后将它加入页面的<head>部分，从而避免重复操做。由于慢启动阶段对交换包大小的限制，你关键CSS文件的大小也被限制在14KB左右。若是高于这个值，浏览器须要重复一些步骤来获取更多的样式。关键CSS是容许你这样作的。可能对每一个模板都须要这个操做。若是可能，考虑一下用Fiament Group用的条件内敛方法。

经过HTTP/2，关键CSS能够单独存为CSS文件，经过服务器传输，并且能够避免HTML膨胀。服务器传输缺少连续支持，而且存在一些超高速缓存的问题（Hooman Beheshti演示的前144页）。事实上，这样会致使网络缓冲区膨胀。由于TCP的慢启动，服务器传输在稳定的链接下会更有效率。因此你可能须要创建带有缓存的HTTP/2服务器传输机制。但请记住，新的cache-digest规则会否认手动创建的须要缓存的服务器的请求。

18. 经过tree-shaking和code-splitting减小净负载

Tree-shaking是经过保留那些在项目过程当中真正须要的代码从而清理你的构建过程的一种方式。你能够用Webpack 2来提出那些没用的住配置文件，用UnCSS或Helium从CSS中取出不须要的样式。同理，也能够考虑学习一下如何编写高效的CSS选择器，以及如何避免膨胀和高费的样式。

Code-splitting是另外一个Webpack特性，它能够根据按需加载的块将你的代码分开。只要你在代码中定义了分离点，Webpack便会处理好相关的输出文件。它基本上能保证你初始下载的内容很小，并且在需求被添加时按需请求代码。

Rollup所展现的结果要比Browserify配置文件所显示的好得多。因此当咱们想使用相似工具的时候，或许应该看看Rollupify，它将ECMAScript2015模块变成了一个更大的CommonJS模块——由于小模块没准有出乎意料的高性能成本，这源自于你对打包工具模块系统的选择。

19. 提高渲染性能

使用相似CSS containment的方法对高消耗组建进行隔离，从而限制浏览器样式的范围，能够做用在为无canvas的浏览工做的布局和装饰工做中，或是用在第三方工具上。要确保页面滚动和出现动画效果时没有延迟，别忘了以前提到过的每秒60帧的原则。若是没办法作到，那就尽量保证每秒帧数的大体范围在15到60帧。使用CSS中的will-change通知浏览器哪些元素和属性发生了变化。

也记得要衡量渲染执行中的性能（能够用DevTools）。能够参照Udacity上Paul Lewis的免费课程——浏览器渲染优化，做为入门。还有一篇Sergey Chikuyonok的文章讲了如何正确的用GPU动画。

20. 预热网络链接，加快传输速度

使用页面框架，对高消耗组建延迟加载（字体，JS文件，循环播放，视频和内嵌框架）。使用资源提示来节省在dns-prefetch（指的是在后台执行DNS检索），preconnect（指要求浏览器在后台进行握手连接（DNS，TCP，TLS）），prerender（指要求浏览器在后台对特定页面进行渲染），preload（指的是提早取出暂不执行的源文件）。根据你浏览器的支持状况，尽可能使用preconnect来代替dns-prefetch，并且在使用prefetch和prerender要特别当心——后者（prerender）只有在你很是确信用户下一步操做的状况下再去使用（好比购买流程中）。

HTTP/2

21. 准备好使用HTTP/2

Google开始向着更安全网页的方向努力，而且将全部Chrome上的HTTP网页定义为“不安全”时，你或许应该考虑是继续使用HTTP/1.1，仍是将目光转向HTTP/2环境。虽然初期投入比较大，可是使用HTTP/是大趋势，并且在熟练掌握以后，你可使用service worker和服务器推送技术让行性能再提高一大截。

如今，Google计划把全部HTTP页面标记为不安全，而且将HTTP安全指示器设置为与Chrome用来拦截HTTPS的红色三角相同的图标。

使用HTTP/2的环境的缺点在于你要转移到HTTPS上，而且根据你HTTP/1.1用户的数量（主要指使用过期操做系统和过期浏览器的用户），你须要适应不一样的建构过程，才能发送不一样的建构。注意：不管是迁移仍是新的构建过程均可能很是棘手并且耗时不少。

22. 适当部署HTTP/2

重申，使用HTTP/2协议以前，你须要完全排查目前为止你所使用协议的状况。你须要在打包组建和同时加载不少小组间之间找到平衡。

一方面，你可能想要避免将不少资源链式连接，与其将你所有的界面分割成许多小模块，不如将他们压缩使之成为建构过程的一部分，以后给它们赋予可检索的信息并加载它们。这样的话，对一个文件将再也不须要从新下载整个样式清单或JavaScript文件。

另外一方面，封装是颇有必要的，由于一次向浏览器发送太多JavaScript文件会出问题。首先，压缩会形成损坏。得益于dictionary reuse，压缩大文件不会对文件形成损害，压缩小文件则否则。确实有方法能够解决这个问题，但这不是本文讨论的范畴。其次，浏览器还没有优化到能够对相似工做流进行优化。例如，Chrome会引起进程间通讯（IPCs），这些通讯的数量与资源的数量成正比，而这成百上千个资源将会消耗大量的浏览器的执行时间。

Chrome的Jake Archibald建议，为了用HTTP/2达到最好的效果，考虑一下逐步加载CSS文件

固然你能够考虑逐步加载CSS文件。很显然，你这样作对HTTP/1.1的用户很是不利，因此你可能须要根据不一样的浏览器创建多个版原本应对你的调度过程，这样就会使过程略微复杂。你也能够避免HTTP/2链接的合并，同时受益于HTTP/2来使用域名碎片，可是实现起来有些困难。

咱们到底应该作什么呢？若是你粗略的用过HTTP/2，彷佛成功的发送过10个左右的包（在总是浏览器上运行的也不错）。那你就能着手开始试验而且为你的网站找到平衡点。

23. 确保服务器安全可靠

全部的浏览器都支持HTTP/2而且使用TLS，这是有你可能想要避免安全警告，并删除页面上没用的元素。好好检查你的安全头部是否设置正确，排除已知的缺陷并检查证书。

若是尚未迁移到HTTP， 你那能够先看看HTTPS准则（The HTTPS-Only Standard）。确保全部外部插件和监视脚本都能被HTTPS正确加载，确保没有跨站脚本出现，HTTP脚本传输的安全头和内容安全头也都设置正确。

24. 你的服务器和CDN支持HTTP/2吗？

不一样服务器和CDN对HTTP/2的兼容性不一样，你可使用TLS够快吗？一文来查看你有什么选择。

Is TLS Fast Yet？让你能看看你的服务器和CDN在使用HTTP/2的时候你能使用的工具

25. Brotli和Zopfli两种压缩算法还在用吗？

2015年，Google介绍了Brotli，一个新的开源无损数据格式，它已经被Chrome，Firefox和Opera很好的兼容了。具体使用时，Brotli所显示出的效率要远高于Gzip和Deflate。它根据不一样的配置可能压缩的时候会比较慢，可是压缩速度慢最后会让压缩效率提升。并且解压起来很是快。由于这个算法来自Google，因此浏览器只在用户经过HTTPS访问网页的时候使用它，这个事情就不奇怪了。Brotli的隐患是它没办法在目前大部分服务器上预设，并且若是没有NGINX或者Ubuntu，部署起来仍是有难度的。但其实你是能够在不支持它的CDN上使用Brotli（经过service worker）。

你能够看看Zopfli压缩算法做为备选，它将数据编码为Deflate，Gzip和Zlib格式。任何规范的Gzip压缩资源都受益于Zopfli改进了Deflate编码，由于文件会比Zlib压缩的最大文件小3%-8%。问题在于文件会消耗大概80倍的时间去压缩。这就是为何在不怎么会变得资源上使用Zopfli是不错的选择，这样的文件通常都压缩一次，下载屡次。

26. OCSP装订是否可使用？

让服务器使用OCSP装订，能够提高你TLS握手的速度。线证书状态协议（OCSP）是做为证书废置列表协议的代替品被创造出来的。两个协议均可以用来检测SSL证书是否被取消。然而，OCSP不须要浏览器花时间下载和扫描证书信息的列表，因此它能够减小握手时间。

27. 你是否开始使用IPv6？

由于咱们已经没什么IPv4的地址可用了，并且移动网络大都开始使用IPv6（美国已经有50%的入口采用IPv6），将你的DNS升级到IPv6为之后做打算是个不错的选择。要确保通网络能够支持双栈协议——它须要容许IPv6和IPv4同时运行。毕竟IPv6不仅是作为后备计划的。并且研究显示，伴随邻居发现（NDP）和路由优化，使用IPv6的网站要比普通网站快10%到15%。

28. 是否使用HPACK？

若是你在使用HTTP/2，看看你的服务器有没有执行HPACK对HTTP的响应头进行压缩，来减小没必要要的消耗。由于HTTP/2服务器相对较新，因此有些像HPACK这样的规格目前尚未被支持。咱们能够用H2spec来检查HPACK是否在工做。

H2spec的截图

29. service workers是否为超高速缓存和网络提供预设机制？

没有通过优化的网络能够比用户机器的本地缓存跑得更快。若是你的网站在HTTPS上运行，你能够参考“实用主义者的service workers手册”，而后把静态资源存在service worker的缓存中，把离线预设（甚至离线页面）存在用户机器方便检索，这样比屡次进行网络链接更有效。你还能够参考Jake的离线使用手册和免费的Udactiy课程“离线网络应用”。若是浏览器支持，那就再好不过了，预设就能在任何地方代替网络了。

测试与监听

30. 监听混合内容中的警告

若是你近期完成了HTTP到HTTPS的迁移，你能够利用相似Report-URI.io一类的对主动和被动的混合内容警告都进行监听。也能够利用混合内容扫描器来对你使用HTTPS的网页进行扫描。

31. 你的开发流程是否使用Devtools进行了优化？

选一个调试工具来对每个按钮进行检查。确保本身明白如何分析渲染性能和控制台输出、明白如何调试JavaScript以及编辑CSS样式。Umar Hansa最近有一个关于使用DevTools调试和测试的分享，主要包括一些不经常使用的技巧和技术。

32. 是否使用代理浏览器和过期浏览器测试过？

仅仅使用Chrome和Firefox测试是不够的。还应该看看你的网页在代理浏览器和过期浏览器上运行的怎么样。好比UC浏览器和Opera Min, 它们在亚洲市场的份额很高（高达35%）。在推广时，利用目标客户所在国家的平均网速来进行测试，避免往后出现大的偏差。一样的，不只要在节流网络以及模拟的高数据处理设备上进行测试，还要在真实设备上测试。

33. 有无创建持续监听？

在进行快速、无限制的测试时，最好使用一个我的的WebPageTest实例。创建一个能自动预警的性能预算监听。创建本身的用户时间标记从而测量并监测具体商用的数据。使用SpeedCurve对性能的变化进行监控，同时利用New Relic获取WebPageTest无法提供的数据。SpeedTracker，Lighthouse和Calibre都是不错的选择。

快速入门

这份清单综合性很强，几乎介绍了全部的可用的优化方式。那么，若是你只有一个小时进行优化，你应该干什么呢？让咱们从中总结10个最有用的来。别忘了在你开始优化前和结束优化后，记录你的结果，包括开始渲染时间以及在3G，有限链接下的速度。

1. 有线链接下，你的目标是将开始渲染时间下降至1s一下，而3G的目标是保持在3s一下，SpeedIndex值保持在1000一下。为开始渲染时间和交互时间作优化。

2. 为你主要的模板准备关键CSS文件，将它们放在页面的<head>中（你可使用14KB）。

3. 对于你本身和第三方的脚本文件，尽量的延迟加载它们——尤为是社交网站按钮，播放器和高消耗的JavaScript文件。

4. 使用更快的dns-lookup，preconnect，prefetch，preload和prerender添加资源提示，从而加快传输速度。

5. 将字体一类属性做为子集，异步加载（或者使用系统字体代替）。

6. 优化图片，并考虑在关键页中使用WebP（例如登录页面）。

7. 确保HTTP的缓存头和安全头都被正确的设置。

8. 在服务器上使用Brotli或Zopfli压缩算法。（若是不支持这两个，尝试一下Gzip）

9. 若是HTTP/2可用，使用HPACK压缩算法，并监听混合内容的警告。若是你在使用LTS，就可使用OCSP装订。

10. 若是可能，将相似字体，JavaScript文件以及图片缓存在service worker缓存中——事实上越多越好！

结语

文中提到的一些优化可能超出了你工做的范围，有的可能超出了你的预算，有的甚至对你正在使用的有些过期的代码判了死刑。但不要紧，本文只是一个普通大纲（但愿能作到综合性强），你应该根据本身的工做环境列一份适合本身的清单。最重要的，在开始优化以前，先对项目中存在的问题有一个明确的了解。最后，祝你们2017年优化顺利！

----------------------------------咱们须要的小伙伴------------------------------------

工做职责：

-Web前端的功能设计、开发和优化，开发可重用模块
-实现与视觉稿、交互稿一致的跨平台、浏览器、客户端，兼容性好的移动端页面和PC页面
-前沿技术研究和新技术调研，

职位要求：

-精通JavaScript/HTML5/CSS3等相关前端开发技术，熟悉页面架构和布局，有良好的程序设计和架构能力；
-精通vue或react； 熟悉并熟练使用es6语法，熟悉node.js；
-掌握前端调试、性能优化、工程化等开发等相关技术；
-具备至少一年以上移动端网页开发经验；
-对web技术钻研有强烈兴趣，有良好的学习能力和强烈的进取心，能主动跟进新技术发展动态优先 ；
-学习能力强，强烈的责任心,具备较强的沟通能力及团队合做精神 ；
-有较强的产品理解，能从技术角度推进产品优化；
-思惟缜密、思路清晰，较好的逻辑分析能力；
-了解一门后台语言(php或java)者优先；

有意向的同窗,请发送简历到 xuheng@baidu .com :)