序言
讷西县页面的操控性强化，大家可能单厢想起AOL赵雄、2-5-8准则、3五分钟井字分项等准则，这些准则在合作开发过程中不是强制性要求的，但是有时候为了追求页面操控性的完美和体验，就不得不对原有的标识符展开修改和强化。
下面就结合自己三年多的合作开发经验和大量的项目实践，整理出一些常见的操控性强化关键点，与此同时再详列一下AOL赵雄、2-5-8准则、3五分钟井字分项这三个常见准则的关键点。
「D端」：图形界面端页面Desktop End Page「M端」：终端端页面Mobile End Page简述手册
D端强化手段在M端同样适用在M端提出3五分钟图形顺利完成井字分项如前所述第一点，井字读取3秒内顺利完成或采用Loading展开转义如前所述中国联通3G网络平均338kb/s(2.71mb/s)，井字天然资源不应少于1014kbM端因配置原因，除读取外图形速率也是强化重点如前所述第六点，要合理处置标识符增加图形耗损如前所述第一点和第六点，大部份负面影响井字读取和图形的标识符应在处置逻辑中前置读取顺利完成后，使用者可视化采用时也须要操控性「读取强化」
「增加HTTP允诺」：尽可能增加页面的允诺数(「首次读取与此同时允诺数不能少于4个」)，终端设备应用程序与此同时积极响应允诺为4个允诺(「Android全力支持4个，iOS5+全力支持6个」)合并CSS和JS采用CSS恶魔图「内存天然资源」：采用内存可增加向伺服器的允诺数，节约读取天数，大部份动态天然资源都要在服务端增设内存，并且尽可能采用长内存(「采用天数戳更新内存」)内存一切可内存的天然资源采用长内存采用Baug的式样和JAVA「填充标识符」：增加天然资源大小不一可加快页面表明速率，对标识符展开填充，并在服务端增设GZip填充标识符(累赘的对齐、字符和操作符)投入使用Gzip「无堵塞」：颈部H55N的式样和JAVA会堵塞页面的图形，式样放在颈部并采用link形式引入，JAVA放在前部并采用触发器形式读取「井字读取」：井字加速表明可大幅提高使用者对页面速率的可视化，应尽可能针对井字的加速表明做强化「按需加载」：将不负面影响井字的天然资源和当前萤幕不用的天然资源放在使用者需要TNUMBERV12V4读取，可大幅提高表明速率和降低总体流量(「按需读取会导致大量重绘，负面影响图形操控性」)懒读取滚屏读取Media Query读取「预读取」：大型资源页面可采用Loading，天然资源读取顺利完成后再表明页面，但读取天数太长，会造成使用者外流可可视化Loading：进入页面时Loading不可可视化Loading：提前读取下两本「填充影像」：采用影像时选择最合适的文件格式和大小不一，然后采用工具填充，与此同时在标识符中用srcset来按需表明(「过度填充影像大小不一负面影响影像表明效果」)采用TinyJpg和TinyPng填充影像采用CSS3、SVG、IconFont代替影像使用img的srcset按需读取影像选择合适的影像：webp优于jpg，png8优于gif选择合适的大小不一：首次读取不大于1014kb、不宽于640pxPS切图时D端影像保存质量为80，M端影像保存质量为60「增加Cookie」：Cookie会负面影响读取速率，动态天然资源域名不采用Cookie「避免重定向」：重定向会负面影响读取速率，在伺服器正确增设避免重定向「触发器读取第三方天然资源」：第三方天然资源不可控会负面影响页面的读取和表明，要触发器读取第三方天然资源读取过程是最为耗时的过程，可能会占到总耗时的`80%天数(**强化重点**)「执行强化」
「CSS写在颈部，JS写在前部并触发器」「避免img、iframe等的src为空」：空src会重新读取当前页面，负面影响速率和效率「尽可能避免重置影像大小不一」：多次重置影像大小不一会引发影像的多次重绘，负面影响操控性「影像尽可能避免采用DataURL」：DataURL影像没有采用影像的填充算法，文件会变大，并且要解码后再图形，读取慢耗时长执行处置不当会堵塞页面读取和图形「图形强化」
「增设viewport」：HTML的viewport可加速页面的图形<meta name=”viewport” <meta name=“viewport” content=“width=device-width, user-scalable=no, initial-scale=1, minimum-scale=1, maximum-scale=1”>「增加DOM节点」：DOM节点太多负面影响页面的图形，尽可能增加DOM节点「强化动画」尽可能采用CSS3动画合理采用requestAnimationFrame动画代替setTimeout适当采用Canvas动画：5个元素以内采用CSS动画，5个元素以上采用Canvas动画，iOS8+可采用WebGL动画「强化高频事件」：scroll、touchmove等事件可导致多次图形函数节流函数防抖采用requestAnimationFrame监听帧变化：使得在正确的天数展开图形增加积极响应变化的天数间隔：增加重绘次数「GPU加速」：采用某些HTML5标签和CSS3属性会触发GPU图形，请合理采用(「过渡采用会引发手机耗电量增加」)HTML标签：video、canvas、webglCSS属性：opacity、transform、transition「式样强化」
「避免在HTML中书写style」「避免CSS表达式」：CSS表达式的执行需跳出CSS树的图形「移除CSS空准则」：CSS空准则增加了css文件的大小不一，负面影响CSS树的执行「正确采用display」：display会负面影响页面的渲染display:inline后不应该再采用float、margin、padding、width和heightdisplay:inline-block后不应该再采用floatdisplay:block后不应该再采用vertical-aligndisplay:table-*后不应该再采用float和margin「不滥用float」：float在图形时计算量比较大，尽可能增加采用「不滥用Web字体」：Web字体需要下载、解析、重绘当前页面，尽可能增加采用「不声明过多的font-size」：过多的font-size负面影响CSS树的效率「值为0时不需要任何单位」：为了应用程序的兼容性和操控性，值为0时不要带单位「标准化各种应用程序前缀」无前缀属性应放在最后CSS动画属性只用-webkit-、无前缀两种其它前缀为-webkit-、-moz-、-ms-、无前缀四种：Opera改用blink内核，-o-已淘汰「避免让选择符看起来像正则表达式」：高级选择符执行耗时长且不易读懂，避免采用「JAVA强化」
「增加重绘和回流」避免不必要的DOM操作避免采用document.write增加drawImage尽可能改变class而不是style，采用classList代替className「内存DOM选择与计算」：每次DOM选择都要计算和内存「内存.length的值」：每次.length计算用一个变量保存值「尽可能采用事件代理」：避免批量绑定事件「尽可能采用id选择器」：id选择器选择元素是最快的「touch事件强化」：采用tap(touchstart和touchend)代替click(「注意touch积极响应过快，易引发误操作」)常见准则
「AOL赵雄」
AOL团队通过大量实践总结出以下7类35条后端强化准则，准则详情请参考这位兄弟的《AOL后端强化35条准则翻译》。
内容「Make Fewer HTTP Requests」：增加HTTP允诺数「Reduce DNS Lookups」：增加DNS查询「Avoid Redirects」：避免重定向「Make Ajax Cacheable」：内存AJAX允诺「Postload Components」：延迟读取天然资源「Preload Components」：预读取天然资源「Reduce The Number Of DOM Elements」：增加DOM元素数量「Split Components Across Domains」：跨域拆分天然资源「Minimize The Number Of Iframes」：增加iframe数量「No 404s」：消除404错误式样「Put Stylesheets At The Top」：置顶式样「Avoid CSS Expressions」：避免CSS表达式「Choose <link> Over @import」：选择<link>代替@import「Avoid Filters」：避免滤镜JAVA「Put Scripts At The Bottom」：置底JAVA「Make JavaScript And CSS External」：采用外部JS和CSS「Minify JavaScript And CSS」：填充JS和CSS「Remove Duplicate Scripts」：删除重复JAVA「Minimize DOM Access」：增加DOM操作「Develop Smart Event Handlers」：合作开发高效的事件处置影像「Optimize Images」：强化图片「Optimize CSS Sprites」：强化CSS恶魔图「Dont Scale Images In HTML」：不在HTML中缩放图片「Make Favicon.ico Small And Cacheable」：采用小体积可内存的favicon内存「Reduce Cookie Size」：增加Cookie大小不一「Use Cookie-Free Domains For Components」：采用无Cookie域名的天然资源终端端「Keep Components Under 25kb」：保持天然资源小于25kb「Pack Components Into A Multipart Document」：打包天然资源到多部分文档中伺服器「Use A Content Delivery Network」：采用CDN「Add An Expires Or A Cache-Control Header」：积极响应头添加Expires或Cache-Control「Gzip Components」：Gzip天然资源「Configure ETags」：配置ETags「Flush The Buffer Early」：尽早输出缓冲「Use Get For AJAX Requests」：AJAX允诺时采用get「Avoid Empty Image Src」：避免图片空链接「2-5-8准则」
在后端合作开发中，此准则作为一种合作开发指导思路，针对应用程序页面的操控性强化。
使用者在2秒内得到积极响应，会感觉页面的积极响应速率很快 Fast使用者在2~5秒间得到积极响应，会感觉页面的积极响应速率还行 Medium使用者在5~8秒间得到积极响应，会感觉页面的积极响应速率很慢，但还可以接受 Slow使用者在8秒后仍然无法得到积极响应，会感觉页面的积极响应速率垃圾死了(「此时会有以下四种可能」)难道是网速不好，发起第二次允诺 => 刷新页面什么垃圾页面呀，怎么还不打开 => 离开页面，有可能转投竞争对手的网站垃圾程序猿，做的是什么页面啊 => 咒骂合作开发此页面的程序猿断网了 => 网线断了？Wi-Fi断了？信号不好？话费用完了？知道这个准则的数字顺序怎样来的吗，看下键盘右方的数字键盘由下往上排序：2-5-8「3五分钟井字分项」
此准则适用于M端，顾名思义就是打开页面后3五分钟内顺利完成图形并展示内容。
