对埃里克·波蒂斯（Eric Portis）非常有用的文章的回应：View Transitions Break incremental rendering。

问题

• 增量HTML渲染很棒
• 查看过渡和递增渲染不能很好地一起工作
• 因此，一个痛苦的权衡。
• 我们该怎么办？

谁打破了递增渲染？

首先，让我们检查一下文章的标题和前提 - 增量渲染是（1）伟大，（2）通过视图过渡打破。谁真正打破了逐步渲染，在构想观看过渡之前？

水疗中心

增量渲染确实很好且凉爽，并有助于更快地渲染主要内容。从网络的黎明开始是正确的。

然而，对于更好和更糟糕的是，当今的网络充满了水疗中心 - 单页应用程序，其中默认行为被替换并用自定义的JavaScript行为进行调整，通常由诸如react/vue/vue/...的框架管理。这种构建Web应用程序的诱人素质是，开发人员构建它可以控制其加载序列，而不是将其放在浏览器中可能不同的启发式方法上。

这里的一个手术单词是“应用程序”。多年来，已经有各种各样的网站正在寻求“像经验”的“应用程序”。没有对这是否也很酷/好的判断，事实是这非常受欢迎。

其他JS技术

不管通常控制同一应用程序页面之间的加载顺序的水疗中心，还有其他技术可以打破增量渲染：

• 在文档完全解析后到达的渲染障碍方式和脚本。
• 使用服务工作者人为地延迟此类资源，直到达到某种就绪状态为止。
• 最初，使用opacity: 0或display: none加载页面，然后在准备就绪时将其更改为opacity: 1或display: block，也许是动画。

后者是“类似”类别的网页中的一种非常流行的技术，用于其初始页面负载。当页面需要一些JavaScript来布局本身时，它也是想要的技术，以避免使用丑陋的flash of unstyled content和由此产生的不良CLS。尽管有速度，但很快就会呈现破裂的布局并没有帮助用户体验。

浏览器

（AB？）使用Web API来打破增量渲染，浏览器还具有自己的启发式方法。例如，Chrome实现了paint holding：一种减少相同原始导航中白色闪光的机制。 Safari＆Firefox具有自己的机制和启发式方法，可以减少闪光灯。

中期结论

查看过渡没有破坏增量渲染。您做到了，网络开发人员。我们，浏览器开发人员做到了。用户，我们所有人都通过选择“类似应用”的体验来做到。
更确切地说，平滑度和速度之间的平衡不是一个简单的任务。这也是埃里克（Eric）文章的语气，所以我认为我们实际上是在同一页面上

脚步谬论

设计Web API（和其他技术）时，一种常见的话语是 - 这可能会成为脚踏式的 - 就像人们一样，人们会以错误的方式使用它，而造成的弊大于利。引用这篇文章：我担心，给开发人员的工具明确阻止渲染 - 将使您的网络变得更糟。这也是关于问题的讨论中的一般氛围。

这确实经常发生，减轻脚枪的机会是API设计过程的重要组成部分。

我们应该小心在讨论脚枪和陷阱时不要错过大局。我们想要启用的经验今天以各种复杂的方式实现。专注于它的滥用和脚枪方面，最终可能会产生一种比所需的更复杂的解决方案，并可能使用其自身的复杂陷阱。

工具越强大，以错误的方式使用时可以造成的损坏越多。
格兰特斯，剪刀，演练，药物 - 所有这些都在错误的方式使用时可能会造成伤害。这不是不拥有它们的理由，当然，当我们可以提供以这种方式更安全的替代方案时，这当然很棒。

例如，Web API，服务工作人员是一整个脚枪。但是它们有足够的用处使它值得。

我建议有时候处理可以成为脚步的电动工具的最佳方法是使其看起来像枪一样，给它一个看起来像触发器的单个大扳机，并放上警告标签 - 射击前瞄准。

在这种特殊情况下，例如，如果我们人为地范围文档使阻塞只能查看过渡，那么人们就有一种风险，即人们会创建人为的0-持续视图过渡，仅仅是为了渲染阻止效果。这是由人工限制产生的脚枪的形状 - 微妙，难以检测，向后弯曲。

重申：脚枪对话非常重要和有价值。但是有时结论应该更简单，即使更简单也意味着更强大。让我们通过将它们放在朴素的视线中来防止脚枪。

返回过渡

在MPA内部过渡时（或换句话说，执行相同的原始导航）时，开发人员应该能够找到适合于速度和平稳性之间的平衡。这是UX选择。从定义上讲，平滑的动画比直接跳到下一个状态的动画要慢 - 这使此始终是一个权衡。

埃里克的文章以更快/更快的速度来谈论这一点。我宁愿从艺术指导无缝的应用内导航方面看它。

跨文档视图过渡的艺术方向

以这种方式考虑（相同原始）导航过程：

延迟提交

在准备新文档时，请继续显示旧页面的实时版本。在此期间

短冻结

捕获旧页面的最后一帧，并继续显示一小段时间，直到新页面准备渲染或直到系统定义非常短的超时为止。

退缩过渡

如果一切准备就绪，请显示您可以的最好的动画。否则（如果到达超时），请根据文档准备了多少文档，显示一个后备动画或根本没有动画。

让开发人员在新文档被视为已准备就绪的条件下定义，允许基于这些条件进行简短的冻结阶段，并可选地继续显示现场版本旧页面短暂（延迟提交），我们可以使那些想从事类似应用程序的导航体验并做出自己的设计选择，而无需强迫他们求助于水疗中心和 - 一切都是JS。当然，这些系统定义的超时必须很短，以防止在冻结阶段产生震撼的用户体验。所有这些都是替代涂料的替代方法 - 在此中，冰冻/渲染障碍物是一个短（但必要的）阶段。

仅向MPA范围

也许中间立场是将渲染阻滞限制在同一原始导航中？这将支持MPA导航平稳的用例，而不会对冷初始负载产生任何不利影响。

保持冻结时间很短

最需要冻结阶段，这确实很棘手，就像在太长时间显示旧页面的冻结图像是一种令人震惊的体验。这里的关键是要保持此阶段非常短，同时还可以实现其他缓解措施（延迟提交，后备过渡），从而创造了这种刺激效应。

结论

增量渲染确实很棒，尤其是对于网页的冷启动。
但是，人们今天已经以各种方式在类似应用程序的体验方面覆盖它，这是采用水疗体系结构的主要方式，将导航体验留给了文档JS框架，该框架随身携带了自己的脚踏库。
在一个感知到的类似应用的体验的世界中，在速度和平稳性之间取得了平衡，需要简单而强大的工具，可以清楚其预期用法，以帮助实现无缝导航体验的艺术方向。

冻结旧文档的捕获（for a very short duration），而新文档正在定居是该公用设施带的必要工具。
我们当然可以并且应该以这样的方式对其进行调整并设计它，以使其预期的用法很明显，并且滥用它会提供明确的反馈。