首屏时间是指用户从打开小程序看到第一屏主要内容的时间，首屏时间太长会导致用户长时间看到的都是白屏，影响使用体验。 优化首屏时间，可以分为以下几种情况： 首屏渲染的内容较多，需要集合多份数据进行渲染。这种情况需要开发者把内容分优先级，把优先级高的内容做优先展示，缩短白屏时间；首屏内容依赖的数据从服务端请求的时间太长。开发者需要从服务端侧具体分析服务端数据返回的时间长的原因；一次性渲染数据太大或依赖的计算过于复杂。减少渲染的数据量、优化渲染相关数据的算法可以解决这类问题。这里想问下，第一屏指的具体是什么呢？是指 initial data 被渲染的那一刻吗？还是指 DOM 元素铺满屏幕那一刻呢？

小程序给出了 setUpdatePerformanceListener api 用来获取更新性能统计信息。 [图片] 这个说明有点不够具体，毕竟对于开发者所谓的更新队列机制都是黑盒。有以下几个疑问： updateProcessId 是否是页面内自增的，不论是基本更新还是子更新，发生一个更新就自增？初始 data 算第一个 updateProcessId 么？parentUpdateProcessId 是否可以理解为某个 setData 导致的一些列同步 setData 更新，比如 observer 内部的 setData，其父更新就是导致 Observer 执行的 setData？还有其他场景么？isMergedUpdate 这个有场景示例么？pendingStartTimestamp 代表的是什么时刻：执行 setData 的那一刻，data 传递到渲染层那一刻还是指的其他时刻？updateStartTImestamp 代表的是什么时刻：DOM diff 开始那一刻？DOM diff 是在逻辑层还是渲染层呢？updateEndTImestamp 代表的是什么时刻：DOM diff 完成那一刻，还是 DOM render 那一刻？烦请官方能够解答一下，也辛苦新出一个 api 以后，希望能从开发者的角度去丰富文档和示例，这样有助于这个 api 真正的落地和服务开发者，非常感谢。 ps: 既然出一个 api，应该是有场景驱动才对，想请问下官方推荐的使用场景是什么呀？

Chrom 85 支持 content-visibility 属性，该属性能够极大优化页面渲染性能，尤其是长列表，微信这边是否考虑从底层予以支持呢？

使用 miniprogram-ci 下载 sourcemap 经常报下述错误： download source map failed: resp body is not a valid json 应该是下载超时导致，但是 ci.getDevSourceMap 并没有提供控制超时时间的选项。 另外，sourcemap 下载时，既下了__FULL__，又下了各个包单独的，但一般情况下用户只会二选一取用。可否提供选项忽略或者指定下载哪些包的 sourcemap。

利用开发者工具跑分优化项目代码时，发现一个问题。我在当前页面操作时是正常的，但是只要跳转下一页，一定会报 ‘存在将未绑定在 WXML 的变量传入 setData’ 且其中列举的都是跳转前页面的操作。开始是怀疑可能是自己代码的问题，但后来发现其他项目也存在。找了个简单的示例如下（WeUI）： 仅在当前页面点击展开表单，不会报上述错误： [图片] 然后我们在运行一遍，展开表单并且点击button，就会报上述错误，将前一个页面对data的操作进行报错： [图片] 烦请微信方面能帮忙看一下~~