很多系统虽然很老的，但是在扭曲的MVP模式下，还是处于高速迭代的过程中。
这会导致项目架构基本不会发生变化，新特性无法支持，大家还在写ES5...
当然这还是小问题，最大麻烦的还是依赖难以管理，这样会导致很多无用的资源被引用，大家不敢调整顺序，也不敢删，鬼知道资源在什么业务分支下会用到。 如果调整顺序，说不定也会出BUG。
同时还有很大的问题是资源比较分散，很多老系统是基于JSP/PHP/ASP那一套的，很多 include 语法真就是单纯的include，导致页面中间穿插着各种 <script> 和 <link>。
在这种情况下，想去优化首屏渲染就很痛苦了，因为资源实在太乱了又不敢动..但又到了不得不动的时候，可能 <head> 中全是script标签，很多要等加载完才能继续渲染，弱网情况的体验就非常差，首屏会白很久。
还有更更离谱的，因为前后端混写的代码，前端充斥着一堆老模板语法，甚至在script标签中存在一些 <? php 这样的东西，导致连压缩都不能做...
条件就是这个条件了，现在要去做首屏渲染的优化该如何处理。
我想的是一层折中方案，当请求从服务端响应的时候，再加一层，用于处理响应的HTML。
这层处理主要做资源的排布，比如将所有 link 和 script 取出，做资源的合并调度，所有的 link 都放到 <head> 中，所有 script 都放到 </body> 前。
并且可以再这一层将一些小资源合并成适合的资源，比如 10个 3KB的文件合成一个 30KB的文件，并且传OSS。
讲这些处理好后，把 link 和 script 插入到对应的地方，然后响应处理好的HTML，这个时候资源的分布就变得合理，所有样式在上，脚本再下，页面内容会第一时间呈现。
当然这里有点问题，上传资源到OSS是很慢的，所以要再每次发布新版本的时候跑好相关的逻辑，并且做好缓存，那后续就只是单纯替换字符串的工作了。
我做过简单的DEMO，整个资源替换的工作大概在20MS左右，但是页面白屏时间减少了将近一秒，20MS换1000MS是划算的，但是服务成本会变高，毕竟多了一层服务来处理，当然这个处理放在PHP响应前也可以，那这样就不需要新的服务来承担了。
方案的好处是不需要对老架构做大调整，让事情在这一层面变得简单了。 但是坏处也有，不确定所有script被后置后存在什么问题，因为脚本可以会执行document.write这样的操作，就被write到后面了。 所以这个方案是否能落地，还得看当前项目的情况，只能说是一种没办法的解法了...