我可能会记错，但我觉得对于那些切换可见性的部分，当我们使用这种方法切换它们时，我们得到了更好的性能。@joaomoreno 我相信这是其中的一部分。

好的点，对于经常切换的组件，如侧边栏，应该优化速度。但对于可能仍然处于禁用状态的部分，我会删除DOM节点。
顺便说一下，这个观点来自于研究慢速窗口调整性能：由于div仍在DOM中，即使启用了原生标题，仍会应用导致窗口控制容器变慢的CSS规则。

@bpasero这是否意味着即使规则存在，但不适用于现有元素，它也会变慢？

我并没有确认这一点，但人们表示即使拥有本地头衔，perf也运行缓慢，所以这是一个怀疑。

@sbatten 我只能确认在 env(titlebar-area-*) 的情况下，即使在原生标题栏场景中存在 window-controls-container,也会导致相同的过度重新计算样式，所以它似乎有效果。我不能为其他情况说话，需要进行测量：)

我认为这里最大的问题是标题栏部分在原生情况下渲染，它永远不会显示。其他可以切换但不太可能的部分也可以进行优化，但我将重点关注原生标题栏情况，其中许多逻辑和DOM渲染仍在发挥作用。由于布局代码，我可能会实现一个NativeTitlebarPart来提供ITitleService接口和一个非常便宜的可序列化视图。