阿里妹导读：Web应用在实际体验上和Native应用仍然存在非常明显的差距，那么如何低成本地把一个现有的网站改造成类Native的体验呢？本文分享一种让网站低成本渐进式实现Native化体验的方式——同屏渲染。文末推荐：阿里云线上峰会。
Web端体验
在有了PWA（Progressivewebapps）之后，WebApplication也具备了添加到桌面和离线访问等能力，但是实际体验上却总是和Native应用存在非常明显的差距。
我们可以看一下Alibaba的M站和iOS应用的录屏（左边为WEB，右边为iOSAPP）：
我们可以看到，对于WebApplicaiton来说，在页面中来回跳转时访问的总是割裂的，从上一个页面到下一个页面需要等loading，返回时很多内存状态又都不在了，导致无法正确定位回之前的列表位置（这一点其实和不同的浏览器以及列表本身的实现方式有关，也有一些方案可以规避这个问题，在这里只是其中一个case）。
这样对于用户的体验伤害非常明显，他能明确感觉到自己在用的并非一个Application而是一个Website，而且在进行复杂的操作时整个链路也非常容易被中断。
而其实这种体验差异的根源，在于B/S（Browser/Server）和C/S（Client/Server）的差异。ServiceWorker虽然提供了一些方案（例如AppShell）让我们较低成本的增强原有的体验，但仍然难以解决页面之间的割裂问题，很多相同的代码在不同页面间重复执行，每一次访问内存状态就会丢失。
渲染性能
当我们在说体验的时候会显得有点主观，性能相比之下就容易衡量的多，而页面割裂带来的最为直观的体验差距其实就来自于渲染性能的差异。
在Web端一个典型的CSR（ClientSideRendering）要经过的流程大致如下：
这其中有很多不符合我们预期的地方：
HTML/JS都等到点击后才开始加载（这点可以通过预加载的手段解决，其中HTML的预加载可以通过ServiceWorker进行）。
framework等JS在不同页面间总是重复执行的。
加载API的时机非常晚，而加载API一般是耗时很长而且可以并行的部分，理论上加载时机越早越好。
所以理想中的渲染流程应该是下图这样：
其实对于Native应用也是如此，用户点击时基本就会开始加载API并且执行下个页面的逻辑。其实一个优化的比较好（做了preload等）的SPA也是类似的效果，我们提前加载好下个页面的vendor，点击时直接只执行下个页面的逻辑即可。
然而实际上对于一个较大的现存站点来说（例如m.alibaba.
联系电话：