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，有限衔接下的速率。
有线衔接下，你的目标是将最先衬着时刻下降至1s一下，而3G的目标是对峙在3s一下，SpeedIndex值对峙在1000一下。为最先衬着时刻和交互时刻做优化。
为你主要的模板预备症结CSS文件，将它们放在页面的
<head>中（你能够运用14KB）。关于你本身和第三方的剧本文件，只管的耽误加载它们——尤其是交际网站按钮，播放器和高斲丧的JavaScript文件。
运用更快的
dns-lookup，preconnect，prefetch，preload和prerender增加资本提醒，从而加快传输速率。将字体一类属性作为子集，异步加载（也许运用体系字体替代）。
优化图片，并斟酌在症结页中运用WebP（比方上岸页面）。
确保HTTP的缓存头和平安头都被准确的设置。
在效劳器上运用Brotli或Zopfli紧缩算法。（假如不支撑这两个，尝试一下Gzip）
假如HTTP/2可用，运用HPACK紧缩算法，并监听夹杂内容的正告。假如你在运用LTS，就可以够运用OCSP装订。
假如能够，将相似字体，JavaScript文件以及图片缓存在service worker缓存中——事实上越多越好！
结语
文中提到的一些优化能够超出了你事情的局限，有的能够超出了你的预算，有的以至对你正在运用的有些过期的代码判了极刑。但没紧要，本文只是一个一般纲要（希望能做到综合性强），你应当依据本身的事情环境列一份适宜本身的清单。最主要的，在最先优化之前，先对项目中存在的题目有一个邃晓的相识。末了，祝人人2017年优化顺遂！
———————————-我们须要的小伙伴————————————
事情职责：
-Web前端的功用设想、开辟和优化，开辟可重用模块
-完成与视觉稿、交互稿一致的跨平台、阅读器、客户端，兼容性好的挪动端页面和PC页面
-前沿手艺研讨和新手艺调研，
职位请求：
-通晓JavaScript/HTML5/CSS3等相干前端开辟手艺，熟习页面架构和规划，有优越的顺序设想和架构才能；
-通晓vue或react； 熟习并闇练运用es6语法，熟习node.js；
-控制前端调试、机能优化、工程化等开辟等相干手艺；
-具有最少一年以上挪动端网页开辟履历；
-对web手艺研讨有猛烈兴致，有优越的进修才能和猛烈的进取心，能主动跟进新手艺生长动态优先 ；
-进修才能强，猛烈的责任心,具有较强的沟通才能及团队协作精力 ；
-有较强的产物明白，能从手艺角度推进产物优化；
-头脑周密、思路清晰，较好的逻辑剖析才能；
-相识一门背景言语(php或java)者优先；
有意向的同砚,请发送简历到 xuheng@baidu .com :)
