预渲染技术通过构建时用无头浏览器生成静态HTML实现“秒开”，适用于内容稳定的页面；App中需配合WebView预加载；资源层面需preload关键资源并缓存；服务端可分层渲染兼顾速度与灵活性。
页面预渲染技术实现“秒开”，核心是把用户看到页面前的大部分工作提前做完，让点击动作几乎只触发显示，不触发加载和计算。
预渲染在构建时就生成完整HTML
它不是等用户点开再跑JS、请求API、拼DOM，而是在项目打包阶段，用无头浏览器（比如Puppeteer）模拟访问首页，把模板+初始数据一次性渲染成静态HTML字符串，直接输出给用户。用户打开时，浏览器拿到的就是可直接绘制的内容，跳过了整个客户端渲染链路。
适用场景明确：适合内容变化少的页面，比如官网首页、产品介绍页、帮助文档。不适合强个性化或实时态页面（如登录后首页、带定位信息的列表），否则可能渲染出错误内容，还得二次水合，反而更慢。
预渲染 + 预加载WebView双管齐下
在App内嵌H5场景中，仅靠服务端预渲染还不够。客户端也要配合：App启动时就初始化WebView并加载一个空白页（about:blank），完成内核加载、JS引擎初始化、网络栈准备等耗时操作。等用户真正点击跳转时，WebView已就绪，直接载入预渲染好的HTML，省去数百毫秒冷启动时间。
常见做法包括：
- 在Application或Splash页中启动WebView预加载任务
- 预加载期间关闭不必要的调试开关和日志输出
- 复用预加载的WebView实例，避免频繁创建销毁
资源层面做精准预加载与缓存
预渲染HTML只是第一步，配套资源也得跟上。通过 提前声明关键资源（如首屏CSS、核心字体、首屏图片），让浏览器在解析HTML时就发起高优先级请求；对非首屏资源用 prefetch 延迟加载。
同时结合Service Worker或HTTP缓存策略，把预渲染HTML和静态资源长期缓存。用户第二次访问时，甚至能从本地缓存直接读取，做到真正毫秒级呈现。
服务端协同：分层渲染降低压力
大型页面可拆解为静态层、动态层、交互层。导航栏、页脚等不变部分用预渲染固化；商品列表、价格等动态内容仍走API+CSR；搜索、筛选等交互逻辑保留在客户端。这样既享受预渲染的首屏速度，又不牺牲灵活性，还减轻了服务端实时渲染压力。
例如双十一商品页：顶部Banner和分类栏预渲染成HTML片段，加载耗时压到50ms以内；中间商品区通过轻量API拉取JSON，由前端快速挂载。
