# 性能

> 让 Shoplazza 应用达到 Lighthouse 基准：后台页面加载快、OAuth 流程精简、注入店铺前台的脚本保持轻量。

应用性能从两头影响商家：后台界面慢，商家不愿意用你的应用；注入店面的脚本慢，直接损失商家的转化率。本文按应用触达的每个界面，介绍对应的性能实践。

## 达到 Lighthouse 基准

要在 Shoplazza 应用商店上架，你的应用使店铺 [Lighthouse](https://developers.google.com/web/tools/lighthouse) 性能分的降幅不能超过 10%。这一项在应用审核时测量——测试方法见[应用性能要求](/docs/app/publish-and-operate/app-requirements/performance)。每次提交前自己先测：在开发店铺上分别于安装前后跑一次 Lighthouse，对比分数。

## 保持应用页面快速加载

应用自己的页面——无论嵌入后台还是独立打开——遵循标准的 Web 性能实践：

- **压缩产物。** 压缩 JavaScript 和 CSS、删除无用代码；原生浏览器能力和现代 DOM API 能满足时，避免引入大型框架或工具库。
- **非关键资源按需加载。** 用户没打开某个功能，就不要提前加载、解析、执行它的代码。
- **静态资源走 CDN**，并配置长效缓存响应头。
- **避免布局偏移，展示加载进度。** 给异步加载的内容预留空间、清晰地提示进度——界面稳定、反馈及时的应用，即使加载耗时相同，也会被感知为更快。
- **内联脚本放在远程样式表之前。** 浏览器会等前面的样式表加载完才执行内联脚本，样式表在前会拖慢你的脚本。

## 优化 OAuth 授权流程

[授权](/docs/app/building-blocks/authentication/oauth-flow)是商家与你应用的第一次交互，要让它快：

- **回调快速响应。** OAuth 回调里只做必要的事——验证请求、用 code 换取 Access Token、建立会话——然后立刻重定向（`302`）进入应用。
- **重活移出关键路径。** 初始数据同步、注册 webhook、开通资源这类工作放到重定向之后用后台任务执行。先让商家看到应用界面，初始化异步完成，需要时在界面上展示进度。
- **缩短跳转链路。** 授权到应用首屏之间每多一跳都在增加延迟，在商家看来就像出了故障。

## 注入脚本保持精简

应用注入店面或结账页的脚本运行在商家的收入关键页面上，预算比你自己的后台页面紧得多：

- **结账页：每个扩展 gzip 后不超过 30 KB。** 结账页性能直接影响转化率。
- **绝不阻塞渲染。** 脚本用 `defer`（保持顺序）或 `async`（顺序无关）加载，让浏览器持续解析页面：

  ```html
  <script src="https://cdn.example.com/app-code.js" defer></script>
  ```

- **避免重型依赖。** 不要把 React、Vue、jQuery 或面向过时浏览器的 polyfill 打进别人的店面；多个应用重复加载同一框架会成倍放大伤害。
- **能用 CSS 就不用 JavaScript** 实现视觉效果和简单交互——CSS 的解析和渲染快得多。
- **用被动模式代替轮询。** 优先 `IntersectionObserver`、事件监听或一次性 `setTimeout`，不用高频定时器。
- **收敛全局变量。** 把代码包进 [IIFE](https://developer.mozilla.org/en-US/docs/Glossary/IIFE)，避免变量与主题或其他应用在全局命名空间冲突。