Angular服务端渲染项目预构建页面及初始响应优化咨询

你的场景非常适合使用预构建静态页面方案，这是当前场景下投入产出比最高的优化手段，除此之外也有其他低改造成本的优化方案，具体如下：

方案一：全量预渲染静态页面（最推荐） #

Angular Universal 本身提供开箱即用的预渲染能力，完全匹配你的业务特性：

• 无需改动现有业务代码，只需要在 angular.json 中配置 prerender 规则，指定需要预渲染的路由列表，执行构建命令时会自动将所有路由渲染为完整的静态HTML文件，构建产物直接托管到Nginx即可，无需再运行pm2托管的SSR渲染服务，首包响应耗时可直接降低到百毫秒以内。
• 针对动态路由（比如带参数的详情页），可以提前写脚本从DRF接口拉取所有需要生成的路由参数列表，传给Angular预渲染配置，实现全量动态页的静态化。
• 业务数据每4小时更新的需求，只需要配置一个定时任务，每4小时触发一次预渲染构建，完成后自动替换Nginx托管的静态资源目录即可，全流程可以实现完全自动化。

方案二：SSR页面缓存（改造成本最低） #

如果暂时不想调整现有架构，可以直接在现有请求链路中加页面缓存，效果和静态页接近：

• Nginx层缓存：在反向代理层配置proxy_cache规则，缓存key直接用请求URI，缓存过期时间设为4小时，首次请求转发到SSR服务生成页面后，后续所有同路径请求Nginx直接返回缓存的HTML，无需回源到SSR服务，响应速度和静态页一致。
• 服务层缓存：也可以在Node SSR服务中接入Redis，将渲染完成的HTML存入Redis，过期时间设为4小时，请求进来先查缓存，命中则直接返回，未命中再执行渲染逻辑，比Nginx缓存更灵活，支持主动触发缓存清理。

方案三：现有SSR逻辑优化 #

如果上述两个方案暂时无法落地，可以直接优化现有SSR逻辑降低耗时：

• 剥离SSR阶段非必要的异步请求，将非首屏必须的接口请求移到客户端hydration完成后再触发，直接减少SSR阶段等待DRF接口返回的耗时。
• 开启Angular运行时优化，给首屏组件添加changeDetection: ChangeDetectionStrategy.OnPush配置，减少SSR渲染阶段的变更检测开销，同时调整SSR路由配置为initialNavigation: 'enabledBlocking'，减少不必要的路由等待耗时。
• 给DRF接口添加缓存，使用Django自带的缓存框架搭配Redis，给首屏依赖的接口设置4小时缓存，降低接口响应耗时，间接减少SSR的总等待时间。

内容的提问来源于stack exchange，提问作者Waseem Sabir