导语
前端目前来说越来越庞大，对前端有了一种新的定义–大前端，PHP和node等一些弱类型的脚本辅助语言也逐渐归类为大前端的一部分。对于一个完整的，可持续优化的项目，前端的优化必不可少。
除了以上这些最基础的性能优化方案，随着5G的普及，短视频的道路会越走越远。来看一组数据：
由此可见，5G的到来，会促进前端性能优化的大进发。
SSR? CSR? NSR!
CSR（客户端渲染）
在当今SPA框架，Vue，React，Angular大行天下的时候，前后端分离开发异常可见。客户端渲染简单理解就是浏览器发送页面请求，服务器返回的是一个模板页面，浏览器从上至下解析过程中需要发送ajax请求获取数据，最后再调用模板引擎（art-template等）渲染HTML结构，并把渲染后的结果添加到页面指定容器中。
客户端渲染因为数据是异步获取，所以在展示完整页面的过程中最少发起两次请求，数据是动态的添加到页面中，因此，非常不利于SEO，便于前后端分离开发。现如今前端采用Vue等框架开发非常多见，因此为了解决纯客户端渲染面临的问题，很多类似Vue中使用SSR和前后端同构的思想也非常常见。
SSR（服务端渲染）
简单理解就是浏览器发送请求后，服务器把客户端网页和数据在后台渲染解析，之后把渲染后的结果返回客户端。
客户端拿到的是渲染后的结果，可以直接展示。服务器端渲染的页面在网络中传输的时候，传输的是一个真实的页面。因此，爬虫客户端当爬到我们的页面后，会分析我们给他提供的这个页面，此时，我们页面中的关键数据就会被爬虫给收录了。服务端渲染可以解决首页白屏时间过久，但是也容易导致服务器压力大，因此，可以使用服务器端的页面缓存技术，减轻服务器的渲染压力。
思考： 如果SSR是解决web性能问题的最优手段，它能对齐Native的性能吗？
NSR（Native渲染）
顾名思义，NSR即是通过WebView内核的机制进行的提前渲染，web，h5加载页面的时候，先去读取Core MemiryCache搜寻数据，如果有数据，直接渲染，这个是理论上的最短渲染路径，相比SSR，CSR发请求，拉取数据来说，这个是最快的渲染方式。MemoryCache没有数据拦截IO请求，读取离线资源，解释如下图所示：
上图的内核缓存首先是基于已经存在的PreFetch，通过内核请求获取到的数据，缓存在内核Core MemoryCache中：
NSR存在一个命中率的问题，如果内核没有缓存数据的时候，需要从离线资源缓存或者是http缓存获取数据，这个流程用CSR替代，这些缓存都没有数据的时候需要发起网络请求的时候，服务端返回的数据改用SSR返回已经渲染好的结果。这也就是三端同构，此时的性能更进一步。
pure-jsx
一个没有Vdom的但保留最小组件周期的React实现（只有1KB）。