来源：得物技术

目前软广自营+商投渠道，每个季度的消耗都不少，并且在不停地铺开多媒体平台，软广的重要性不言而喻。运营人员对于编辑器的编辑概念已经弱化（软广运营创建会场的频率不高），目前都是通过固定几个外投链接，然后通过在投放链接拼接上增长算法侧的捞月 ID 参数，来创建很多的外投广告计划。

所以针对业务的变化，运营侧迫切希望目前软广外投的页面打开速度得到优化，以及解决会场失效等一些高频问题，同时与现有的投放广告系统做充分的融合，减少中间无意义的 Gap。

这里我们选取技术指标 FCP_Rate FCP 的数值小于 1 秒内的数值占总 PV 的比例，用于衡量我们这次新版落地页的性能收益。

Lighthouse 跑分对比：慢速的情况下从之前的 56 分提高到 79 分，网速较快的情况下，从之前的 87 分 提高到 98 分。

真实数据收益：老版的 FCP_Rate 平均在 35% 左右，新版上线以来，FCP_Rate 平均在 80% 左右。提高了 45pp 左右。

在做技术选型之前，我们仔细分析了目前现有外投软广的 C 端页面，其中流量 top3 就是九宫格、单品图、商品流（如下图所示）。整个外投软广的流量高峰期能够达到 100多万PV 以上，而这 3 个模板的流量几乎占据了 90% 以上，所以对高频软广页面优化的业务价值非常大。

左右滑动查看外投软广的C端页面

目前外投模板都是采用 SSR 去做服务端渲染的，但是 SSR 渲染的整个流程如下图所示：

SSR 把数据拉取放到了服务端，因为离数据源比较近，数据拉取的速度会快一点。但这也不是完全没有副作用，因为需要在服务端等待数据就绪，TTFB(Time to First Byte) 相比 CSR 会长一点。

SSR 只是给我们准备好了初始的数据和 HTML，实际上和 CSR 一样，我们还是需要加载完整的客户端程序，然后在浏览器端重新渲染一遍(更专业的说是 Hydration  水合/注水)，才能让 DOM 有交互能力。

也就是说，FCP(First Contentful Paint) 相比 CSR 提前了，但是 TTI(Time to Interactive) 并没有太多差别。只是用户可以更快地看到内容了。

我们生成环境 SSR  生成的 HTML 资源会被 CDN 缓存，也就是说当 CDN 有缓存的，上述图片中的流程是不会再走一遍的。

为什么选择 SSG 作为得物外投渲染的技术方案？

通过分析了目前得物外投的 C 端页面，有下列几点：

• 重玩法和体验，而且本身就是投在短视频平台上的广告，大部分都是拉新，所以对于站外新用户可能就点击一次，后续再也不会点了，所以优化第一次的秒开体验还是很有必要的。

• 运营对于模板配置的改动频率较低，不是高频操作。如果模板是高频改动，那么 SSG 的技术方案可能就不是特别适合。因为模板需要一直重新构建，这时候不如采用 SSR，保持新鲜度。

• 外投页面对于接口请求的依赖十分弱。

根据这三点判断外投软广十分符合 SSG 的技术体系，可以节约第一次服务端拉取数据的时间，其实这部分的时间，反正也是生成 HTML，返回给客户端。其实在运营投出广告之前，模板已经构建完成了，而在构建的时候就直接生成好了所谓的静态外投模板页面。这种方式其实就做 SSG (静态生成)。

看下面这张图或许你就能明白 SSG 和 SSR 的区别：

从图中能明显看出来 HTML 是在构建的时候生成的，而不是在访问这个 HTML，服务器在动态生成。这就是两者之间的差距。所以对于第一次访问的，可以看下面这张图：

SSG 等待服务响应的时间是明显低于 SSR 的。看下面视频就可以明显感觉到差距。

SSG 和 SPA 预渲染骨架的区别在哪里？

SPA 预渲染骨架：是指在服务端对 CSR 页面进行预先渲染，在页面启动时直接返回已经渲染好的 HTML 文件给客户端，避免了客户端一开始加载页面就要进行 JavaScript 的解析和运行，这样能够提升页面的访问速度和用户体验。预渲染技术使用工具（如 Puppeteer）对 CSR 网页进行自动化爬取、渲染、生成 HTML 文件的操作。

从生成的内容来说都是 HTML，这一点没什么区别。但是从投放的业务来说，我们要静态化的页面较多，所以我们需要一个专门的服务帮我们根据模板 ID 生成各种静态 HTML。

在静态资源更新上，假设这么一个场景，线上预渲染的 HTML 有问题我们需要更新，如果 1-2 个页面没啥问题，我们可以重新构建一下，更新 HTML 缓存，如果有几千或者是上万个，SPA 预渲染估计也不太适合。而且频繁的发版、构建对于线上的稳定性也是一个不小的挑战。

在增量更新上，SPA 预渲染骨架是没法支持的，目前社区的一些插件实现原理都类似，都是根据特定 SPA 指定的路由通过 WebPack 或者是 Vite 去进行预构建然后生成对应的 HTML，还需要在nginx上配置特定路由转发， 不然走index.html 不够纯粹，这一点也 pass 掉。

基于上面的一些原因，选择了 Next 去做 SSG 框架支持。生态完善又可以持续更新，可以简化一部分开发工作。

那么 SSG 就没有什么缺点吗？

优点的话不用多说，相比 SSR，因为不需要服务端运行时进行数据拉取，TTFB/FCP 等都会提前。

在实际过程中还遇到下面几个问题：

• 针对模板更新的时候，如何去进行静态页面缓存更新？

• 对于没有静态生成的页面，我们还能访问吗？

针对上述问题我们在技术方案里引入 ISR (增量静态生成)。

如下图所示：

ISR 是 SSG 的升级版，解决 SSG 内容变更的问题。

ISR 依旧会在构建时预渲染页面，但是这里多出了一个服务端运行时，运行时会按照一定的过期/刷新策略(通常会使用 stale-while-revalidate )来重新生成页面。

关于这部分内容，本篇文章不做详细介绍，只是引出关键概念，看到这里如果觉得写的不错的，可以给作者点个赞哟！

其实光做 SSG 在页面体感上其实已经可以达到比之前的快了，但是光做这个是不够的。因为在 CDN 有缓存的情况下，SSG 和 SSR 的 HTML 都缓存在 CDN 上，这里的话其实两者区别不是特别大。

关于性能优化市面上有很多文章，这里不做过多叙述，本篇文章只针对得物外投广告业务，探索符合外投广告优化的性能最佳实践。

自定义文档行为，主要是修改 next.js 默认的文档行为，只需要在页面新增一个_document.tsx  _app.tsx 如下图所示：

这里我们做的第一个行为就是 CSS 内联  通过继承 Head 组件，重对应的子方法。

class InlineStylesHead extends Head {  getScripts(files: any) {    return null  }
  getPolyfillScripts(): JSX.Element[] {    return this.context.buildManifest.polyfillFiles.map((file) => {      return <script defer={true} noModule src={`${ASSETPREFIX[SENV]}/_next/${encodeURI(file)}`}></script>    })  }
  getCssLinks(files: any) {    const cssFiles = files.allFiles.filter((f) => f.endsWith('.css'))    return this.__getInlineStyles(cssFiles)  }  __getInlineStyles(files: string[]) {    const { assetPrefix } = this.context    if (!files || files.length === 0) return null    return files      .filter((file) => /\.css$/.test(file))      .map((file) => (        <style          key={file}          data-href={`${assetPrefix}/_next/${file}`}          dangerouslySetInnerHTML={{            __html: readFileSync(join(process.cwd(), '.next', file), 'utf-8'),          }}        />      ))  }}#因为doucment 文件是在 node 侧执行的， 所以当生成静态的html 的时候， 这个时候静态资源 webpack 打包已经生成好了， 我可以通过读写文件名，找到对应的文件内容。如图所示：build 的时候，这里的值会内联首屏需要的css，不在首屏的css 不会内联进去。

这里的话由于背景图是默认静态生成的时候已经是内联了，这时候是没有 Webp 的，如果通过 React State 去控制背景图的 Webp 展示的话，会导致页面闪一下，用户体验不好，但我们又想优化背景图的体积，于是我们在自定义 Doucument 里面加了一个原生 Dom 操作如图所示，支持 Webp 的优化成 Webp，不支持的优化成 jpeg 格式。

 <script          dangerouslySetInnerHTML={{            __html: `          var el = document.getElementById('nineRoot');          if(el) {            if(window.isSupportWebp) {              el.style.backgroundImage = 'url(${global.nineImg || defaultUrl}?x-oss-process=image/format,webp)';            } else {              el.style.backgroundImage = 'url(${global.nineImg || defaultUrl}?x-oss-process=image/format,jpeg)';            }          }        `,          }}        />

优化过后的体积大小对比：

足足差了 100KB 左右。

Nezha 是采用 Next 12 版本系列，我们新的轻量级落地页采用 Next 13，有一个很重要的特点使用了 SWC 而不是 Babel。

我们选择使用 SWC 进行开发有以下几个原因：

• 可扩展性：使用 SWC 可以作为 Next.js 中的 Crate，而不必分叉库或绕过设计限制。

• 性能：通过切换到 SWC，我们在 Next.js 中实现了大约 3 倍更快的快速刷新和 5 倍更快的构建速度，还有更多的优化空间正在进行中。

• WebAssembly：Rust 对 WASM 的支持对于支持所有可能的平台并将 Next.js 开发带到任何地方至关重要。

• 社区：Rust 的社区和生态系统是惊人的，而且还在不断壮大。

• 这里还有一个很重要的原因就是后续我们会新增 ISR，也就是服务端不存在的静态模板 ID 资源的时候，我们通过接口触发 Node 层进行构建，构建的速度越快，用户等待的时间也越少。所以更换语法转换还是有很有必要的，对于后期 ISR 是非常有必要的。

具体了解 SWC 可以看这个网站：https://swc.rs/

Babel 情况下的按需构建我们都是通过安装 babel-plugin-import 通过如下配置：

 [{"libraryName": "antd","libraryDirectory": "lib",   // default: lib"style": true},{"libraryName": "antd-mobile"},]

但是新版本已经内置了这种能力。

可以在 next.config.js 中这样配置，具体的详细配置可以看这个链接：https://nextjs.org/docs/architecture/nextjs-compiler#modularize-imports

 transpilePackages: ['antd-mobile'],  modularizeImports: {    'antd-mobile': {      transform: 'antd-mobile/es/{{ lowerCase member}}',    },  },

对于首屏资源的优化其实是很有必要的，由此提出下面 2 个策略：

• 抽取外投模板通用的组件，比如投放 Banner 五要素、唤端组件。

• 不在首屏资源的组件，延迟加载。

抽取了动态组件，Webpack 打包的时候，对于动态组件相关的资源会打包到一起，不会打包到主 JS 里面，可以很好地提高 CDN 缓存利用率，防止因为一些简单的改动，影响整个 JS 的 Hash。

这里用到了 next/dynamic ，具体的链接可以看这个： https://nextjs.org/docs/app/building-your-application/optimizing/lazy-loading#nextdynamic

import dynamic from 'next/dynamic'
const DynamicDetainmentPopup = dynamic(() => import('./detainmentPopup'), {  loading: () => <div></div>,  ssr: false,})const DynamicToufangBanner = dynamic(() => import('./toufangBanner'), {  loading: () => <div></div>,  ssr: false,})#next/dynamic 是 React.lazy() 和 Suspense 的组合， 其实就是组件懒加载， ssr 为true 表示是服务端渲染  为false 的话表示是客户端渲染， 打包后的路径区别在于  服务端渲染的话也就是ssr 为true 打包生成的chunks 会在 server  目录下，客户端渲染的 打包后的chunk 在 static 目录下  。

但是无论是那种方式，我们线上最终访问的资源都是在 OSS 上的。

所以我们需要在 Webpack 配置下 PublicPath：

     config.output.publicPath = CDN_MAP[process.env.APP_ENV] ||  '//h5static.dewu.com/h5-launch-ssr/'

通过上面这个步骤首屏资源减少几十 KB。

重写 Postcss-Webp 插件，重写的背景原因是由于之前的 OSS 域名改造，静态资源都会更新成 H5static.dewucdn.com。

造成部分图片资源没有应用到 Webp 所以这里重新梳理了这块逻辑，重新封装了。

 "@dw/postcss-webp": "0.1.2"

https://webpack.docschina.org/plugins/split-chunks-plugin/

• 针对 node_modules 资源：

• 可以将 node_modules 模块打包成单独文件(通过 cacheGroups 实现)，防止业务代码的变更影响 NPM 包缓存，同时建议通过 maxSize 设定阈值，防止 Vendor 包体过大。

• 由于我们的资源有专门的静态加速域名且支持 Http2.0，这里将每一个 NPM 包都打包成单独文件。

• 针对业务代码：

• 设置 common 分组，通过 minChunks 配置项将使用率较高的资源合并为 Common 资源。

• 首屏用不上的代码，尽量以异步方式引入，这里上面 Dynamic 已经做了拆包。

• 设置 optimization.runtimeChunk 为 True，将运行时代码拆分为独立资源，这里 Next 也已经内置了。

所以我们的一个优化策略就是将 @du @growth 的 NPM 包进行拆分。

  config.optimization.splitChunks.cacheGroups.dw =  {          name: `@dw`,          test: testPackageName('@dw'),          priority: 500,          enforce: true,         }        config.optimization.splitChunks.cacheGroups.du =  {          name: `@du`,          test: testPackageName('@du'),          priority: 500,          enforce: true,         }        config.optimization.splitChunks.cacheGroups.growth =  {          name: `@growth`,          test: testPackageName('@growth'),          priority: 400,          enforce: true,         }
        config.optimization.splitChunks.cacheGroups.className =  {          name: `classnames`,          test: testPackageName('classnames'),          priority: 400,          enforce: true,         }      }

神策埋点优化：神策实例包体积重复加载优化，减少神策包加载体积 25KB+。

由于唤端 App 和落地页都会进行埋点上报，原有的逻辑是 Call-App 内部也会再去加载神策埋点 JS，但是在外投落地页展示的时候其实已经加载过，导致神策包体积重复加载。

代码如下：

// 如果神策实例 已经加载了 call-app 这里不需要加载  if (window.sensorsDataAnalytic201505) {    sensors = window.sensorsDataAnalytic201505;    return;  }

• 统一请求库：统一去掉 Axios 统一用 Fetch 去做请求，减少了 JS 体积 20KB+。保持项目请求库技术栈统一，这里不需要担心 Fetch 的兼容性问题，Next 13 默认做了 Fecth 的 JS 垫片。

新版落地页上线前，我们做了一轮产品内测，一个是开发视角，以表单问卷的方式进行了做了内测问题收集。

一共收集了如下几个问题：

其中运营侧有一个很强烈的需求，就是强烈要求新版落地转盘速度变快，觉得用户的耐心值比较低，本身就是广告了，点进去运转的慢的话，用户会直接流失。

轻量版本的落地页做出来了，贸然去投外投广告本身是不合适的。所以这里针对同一个外投软广链接，去做 AB 测试，排除用户的群体、包括投放的策略、以及达人的量级等等这些外在因素的影响，去分析 AB 情况下的新版和老版的性能指标。我们验证了新的轻量落地页，无论是在业务还是性能上都有显著提升，那么我们肯定需要大规模灰度，对于线上已经投放的广告，如何进行无缝灰度？针对这一点，运营对我们前端提出的要求很简单，由于线上已经创建了大量的广告计划，运营不可能手动一个个去改链接，工作量很大。所以核心点就是在不改线上链接的前提下，线上用户访问的是我们的新的落地页资源。

通过 ES 灰度验证后，实验效果显著。推全后优化软广外投页面九宫格模板日均 xx 万 PV (占据整个外投的 xx% 的流量)，提高外投模板性能 40pp 左右，提高广告转化率 2pp 左右。

推全之前的外投性能 FCP 平均在 30%，推全之后稳定在 70%，提高了 40pp 左右。

推全之前近一个月的数据平均值，九宫格的 CVR 在 50+，辅助参考指标：真实唤端成功率平均值在 19+。

推全之后的数据：CVR 和真实唤端成功率均显著正向，预计提高 CVR 转换 2pp 左右。

在谈技术方案之前先普及以下概念。

默认的话 CDN 回源只有一个源站，比如 CND-A.com 当回源的时候会直接回源到 A.com。如果你想 CDN-A.com 要回源到 B.com ，那就需要在 CDN 域名管理的 控制配置如下图所示：

结合具体的规则引擎配置比如我们配置的是参数中含有 _launch_ 就会回源到B.dewu.com。

目前条件源站配置好了，线上的所有 CDN-A.com 的链接如何自动的大批量都加上 _launch_ 参数呢？那就需要 ES 登场了。

边缘脚本（EdgeScript，简称 ES）。CDN 节点网关会根据你在控制台上设置的标准配置、边缘脚本规则对请求进行处理。ES 规则的执行位置可以是请求处理开始或者请求处理结尾。所以 ES 的执行配置，可以在请求前，也可以在请求后。这里的配置顺讯会决定条件源站和 ES 的应用顺讯。如下图所示：

结合上面的图，整体的流程已经很明显了，客户端请求先回到 ES ，ES 里面我们会写下灰度匹配脚本。

代码这里就不放了，感兴趣的可以去阿里云 ES 脚本去学习一下。

大体的意思就是匹配 URL 含有某些会场 ID，匹配上了加上 &_launch_=1&esab=1 这两个参数。

然后在经过条件源站，就可以回源到我们新的轻量落地页了。这里解释一下参数上加 Esab 其实主要是一个锁，防止请求在 ES 死循环。

rand_hit(20) 是 ES 语法提供的随机函数，可以进行站外简单的 AB 分流，也就是线上的链接是有概率进入 ES 并且触发条件源站回源。 这里做的比较简单，其实还可以配上 Cooike，达到命中过灰度了，就一直是灰度的链接。站外软广这里不存在登录态，和产品们讨论，问题不是很大。

普及前面的概念，直接捋一下灰度的流程图如下：

流程图上有一块兜底的考虑：万一有配错的会场，回源到 B.com ，我们会进行反向代理，会直接代理到 A.com 确保会场的正确显示。

• 白名单生产测试，ES 脚本匹配 ID 符合上面 7 个模板 ID，然后再加一个白名单测试参数，先真实广告测试唤端对应的场景是否正确。

• 白名单测试完毕之后，去掉白名单测试参数之后 ES 分设备进行灰度，先 iOS 后再安卓（iOS 的流量比安卓的小 ）还是先预发验证，预发验证结束在应用生产正式的 ES。

• 这里灰度的会场 ID 还是逐步灰度观察数据，每一次灰度的会场 ID 都是先 iOS 再安卓进行测试，避免小流量发现不了问题。

测试完毕后：

• DAY1 上午 10 点 iOS 灰度百分比 50%。DAY2 早上灰度当前模板，安卓 10点。

• DAY4 上午 10 点 iOS 灰度 10% ，观察 2 小时有问题随时切走。 DAY4 晚上 9 点灰度 30% 。DAY5 上午 10 点灰度安卓 10%，晚上 9 点灰度 30%。

• Day 6 上午 10 点 iOS 灰度 10%，观察 2 小时有问题随时切走。DAY6 晚上9点灰度30%。DAY7 上午 10 点灰度安卓 10%，晚上 9 点 灰度安卓 30%。

推全的灰度安排就是上面所有会场 ID 不分渠道进行灰度按照 10% 20% 50%  65% 80% 100% 逐渐切入。

敬畏生产。对于一个比较大的技术项目，稳定性的监控十分重要。我们业务的核心指标：唤端成功率，拉新激活率，JS异常。

我们做了下面这几件事：

• SLS 监控告警监控实时唤端成功率，有没有出现同比大幅度下跌。

• 代理失败兜底监控。

• 拉新大盘监控。

• Error 监控报错。