跳到主要内容

性能

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

达到 Lighthouse 基准​

要在 Shoplazza 应用商店上架，你的应用使店铺 Lighthouse 性能分的降幅不能超过 10%。这一项在应用审核时测量——测试方法见应用性能要求。每次提交前自己先测：在开发店铺上分别于安装前后跑一次 Lighthouse，对比分数。

保持应用页面快速加载​

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

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

优化 OAuth 授权流程​

授权是商家与你应用的第一次交互，要让它快：

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

注入脚本保持精简​

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

  • 结账页：每个扩展 gzip 后不超过 30 KB。 结账页性能直接影响转化率。

  • 绝不阻塞渲染。 脚本用 defer（保持顺序）或 async（顺序无关）加载，让浏览器持续解析页面：

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

  • 避免重型依赖。 不要把 React、Vue、jQuery 或面向过时浏览器的 polyfill 打进别人的店面；多个应用重复加载同一框架会成倍放大伤害。

  • 能用 CSS 就不用 JavaScript 实现视觉效果和简单交互——CSS 的解析和渲染快得多。

  • 用被动模式代替轮询。 优先 IntersectionObserver、事件监听或一次性 setTimeout，不用高频定时器。

  • 收敛全局变量。 把代码包进 IIFE，避免变量与主题或其他应用在全局命名空间冲突。