兰州网站seo优化,济南网站建设,做磁力搜索网站违法吗,常州企业家坠楼公司发讣告后删除前端“智能”静态资源管理 模块化/组件化开发#xff0c;仅仅描述了一种开发理念#xff0c;也可以认为是一种开发规范#xff0c;倘若你认可这规范#xff0c;对它的分治策略产生了共鸣#xff0c;那我们就可以继续聊聊它的具体实现了。 很明显#xff0c;模块化/组件化…前端“智能”静态资源管理 模块化/组件化开发仅仅描述了一种开发理念也可以认为是一种开发规范倘若你认可这规范对它的分治策略产生了共鸣那我们就可以继续聊聊它的具体实现了。 很明显模块化/组件化开发之后我们最终要解决的就是模块/组件加载的技术问题。然而前端与客户端GUI软件有一个很大的不同 前端是一种远程部署运行时增量下载的GUI软件 前端应用没有安装过程其所需程序资源都部署在远程服务器用户使用浏览器访问不同的页面来加载不同的资源随着页面访问的增加渐进式的将整个程序下载到本地运行“增量下载”是前端在工程上有别于客户端GUI软件的根本原因。 上图展示了一款界面繁多功能丰富的应用如果采用Web实现相信也是不小的体量如果用户第一次访问页面就强制其加载全站静态资源再展示相信会有很多用户因为失去耐心而流失。根据“增量”的原则我们应该精心规划每个页面的资源加载策略使得用户无论访问哪个页面都能按需加载页面所需资源没访问过的无需加载访问过的可以缓存复用最终带来流畅的应用体验。 这正是Web应用“免安装”的魅力所在。 由“增量”原则引申出的前端优化技巧几乎成为了性能优化的核心有加载相关的按需加载、延迟加载、预加载、请求合并等策略有缓存相关的浏览器缓存利用缓存更新、缓存共享、非覆盖式发布等方案还有复杂的BigRender、BigPipe、Quickling、PageCache等技术。这些优化方案无不围绕着如何将增量原则做到极致而展开。
所以我觉得 前端开发最迫切需要做好的就是在基础架构中贯彻增量原则。 相信这种贯彻不会随着时间的推移而改变在可预见的未来无论在HTTP1.x还是HTTP2.0时代无论在ES5亦或者ES6/7时代无论是AMD/CommonJS/UMD亦或者ES6 module时代无论端内技术如何变迁我们都有足够充分的理由要做好前端程序资源的增量加载。 我觉得是在其基础架构中缺少这样一种“智能”的资源加载方案。没有这样的方案很难将前端应用的规模发展到第四阶段很难实现落地前面介绍的那种组件化开发方案也很难让多方合作高效率的完成一项大型应用的开发并保证其最终运行性能良好。在第四阶段我们需要强大的工程化手段来管理”玩具般简单“的前端开发。 在我的印象中Facebook是这方面探索的伟大先驱之一早在2010年的Velocity China大会上来自Facebook的David Wei博士就为业界展示了他们令人惊艳的静态网页资源管理和优化技术。
David Wei博士在当年的交流会上提到过一些关于Facebook的一些产品数据 Facebook整站有10000个静态资源 每个静态资源都有可能被翻译成超过100种语言版本 每种资源又会针对浏览器生成3种不同的版本 要针对不同带宽的用户做5种不同的打包方法 有3、4个不同的用户组用于小批次体验新的产品功能 还要考虑不同的送达方法可以直接送达或者通过iframe的方式提升资源并行加载的速度 静态资源的压缩和非压缩状态可切换用于调试和定位线上问题 这是一个状态爆炸的问题将所有状态乘起来整个网站的资源组合方式会达到几百万种之多去重之后统计大概有300万种组合方式。支撑这么大规模前端项目运行的底层架构正是魏博士在那次演讲中分享的Static Resource Management System(静态资源管理系统)用以解决Facebook项目中有关前端工程的3D问题DevelopmentDeploymentDebugging。 那段时间 FIS 项目正好遇到瓶颈当时的FIS还是一个用php写的task-based构建工具那时候对于前端工程的认知度很低觉得前端构建不就是几个压缩优化校验打包任务的组合吗写好流程调度就针对不同需求写插件呗看似非常简单。但当我们支撑越来越多的业务团队接触到各种不同的业务场景时我们深刻的感受到task-based工具的粗糙团队每天疲于根据各种业务场景编写各种打包插件构建逻辑异常复杂隐隐看到不可控的迹象。 我们很快意识到把基础架构放到构建工具中实现是一件很愚蠢的事试图依靠构建工具实现各种优化策略使得构建变成了一个巨大的黑盒一旦发生问题定位起来非常困难而且每种业务场景都有不同的优化需求构建工具只能通过静态分析来优化加载具有很大的局限性单页面/多页面/PC端/移动端/前端渲染/后端渲染/多语言/多皮肤/高级优化等等资源加载问题总不能给每个都写一套工具吧更何况这些问题彼此之间还可以有多种组合应用工具根本写不过来。 Facebook的做法无疑为我们亮起了一盏明灯不过可惜它并不开源不是技术封锁而是这个系统依赖FB体系中的其他方面通用性不强开源意义不大我们只能尝试挖掘相关信息网上对它的完整介绍还是非常非常少分析facebook的前端代码也没有太多收获后来无意中发现了facebook使用的项目管理工具phabricator中的一个静态管理方案Celerity以及相关的说明看它的描述很像是Facebook静态资源管理系统的一个mini版 简单看过整个系统之后发现原理并不复杂小而美的典范它是通过一个小工具扫描所有静态资源生成一张资源表然后有一个PHP实现的资源管理框架Celerity提供了资源加载接口替代了传统的script/link等静态的资源加载标签最终通过查表来加载资源。
虽然没有真正看过FB的那套系统但眼前的这个小小的框架给了当时的我们足够多的启示 静态资源管理系统 资源表 资源加载框架 多么优雅的实现啊 资源表是一份数据文件比如JSON是项目中所有静态资源主要是JS和CSS的构建信息记录通过构建工具扫描项目源码生成是一种k-v结构的数据以每个资源的id为key记录了资源的类别、部署路径、依赖关系、打包合并等内容比如
{
a.js: {
url: /static/js/a.5f100fa.js,
dep: [ b.js, a.css ]
},
a.css: {
url: /static/css/a.63cf374.css,
dep: [ button.css ]
},
b.js: {
url: /static/js/b.97193bf.js
},
button.css: {
url: /static/css/button.de33108.js
}
} 而资源加载框架则提供一些资源引用的API让开发者根据id来引用资源替代静态的script/link标签来收集、去重、按需加载资源。调用这些接口时框架通过查表来查找资源的各项信息并递归查找其依赖的资源的信息然后我们可以在这个过程中实现各种性能优化算法来“智能”加载资源。 根据业务场景的不同加载框架可以在浏览器中用JS实现也可以是后端模板引擎中用服务端语言实现甚至二者的组合不一而足。 这种设计很快被验证具有足够的灵活性能够完美支撑不同团队不同技术规范下的性能优化需求前面提到的按需加载、延迟加载、预加载、请求合并、文件指纹、CDN部署、Bigpipe、Quickling、BigRender、首屏CSS内嵌、HTTP 2.0服务端推送等等性能优化手段都可以很容易的在这种架构上实现甚至可以根据性能日志自动进行优化Facebook已实现。 因为有了资源表我们可以很方便的控制资源加载通过各种手段在运行时计算页面的资源使用情况从而获得最佳加载性能。无论是前端渲染的单页面应用还是后端渲染的多页面应用这种方法都同样适用。 此外它还很巧妙的约束了构建工具的职责——只生成资源表。资源表是非常通用的数据结构无论什么业务场景其业务代码最终都可以被扫描为相同结构的表数据并标记资源间的依赖关系有了表之后我们只需根据不同的业务场景定制不同的资源加载框架就行了从此彻底告别一个团队维护一套工具的时代 恩如你所见虽然彻底告别了一个团队一套工具的时代但似乎又进入了一个团队一套框架的时代。其实还是有差别的因为框架具有很大的灵活性而且不那么黑盒采用框架实现资源管理相比构建更容易调试、定位和升级变更。 深耕静态资源加载框架可以带来许多收益而且有足够的灵活性和健壮性面向未来的技术变革这个我们留作后话。 本文来自http://github.com/fouber/blog,著作权属于原作者前端农名工。
