即使我的DOMContentLoaded事件在约 500 毫秒时触发,但由于布局阶段非常长,第一次绘制发生在 3.5 秒左右。
谁能告诉我为什么会发生这种情况,以及我该如何解决?目前该页面确实有大约 350 个节点,但我看到其他站点具有类似的节点和 50-100 毫秒的布局阶段。
我究竟做错了什么?
PS 这是一个通用的 React 应用程序,我使用 Heroku Standard 1x 和 Fastly CDN 来服务它。
即使我的DOMContentLoaded事件在约 500 毫秒时触发,但由于布局阶段非常长,第一次绘制发生在 3.5 秒左右。
谁能告诉我为什么会发生这种情况,以及我该如何解决?目前该页面确实有大约 350 个节点,但我看到其他站点具有类似的节点和 50-100 毫秒的布局阶段。
我究竟做错了什么?
PS 这是一个通用的 React 应用程序,我使用 Heroku Standard 1x 和 Fastly CDN 来服务它。
使用以下步骤来最小化需要布局的节点数量:
绝对定位的元素完全从文档流中删除。这意味着它们对其父元素或源代码中出现在它们之后的元素完全没有影响。因此,绝对定位的元素将与其他内容重叠,除非您采取措施阻止它。当然,有时这种重叠正是你想要的,但你应该意识到它,以确保你得到你想要的布局!
处理程序根据图像的 offsetTop 值计算每个图像的 left 属性。这会强制浏览器立即执行新布局,以确保它提供正确的值。在每个动画帧期间强制布局是页面上出现动画动画的原因。
作为一般的经验法则,如果您在一帧完成之前要求从 DOM 返回一个几何值,您会发现自己处于“强制同步布局”,如果频繁重复或执行一个大的 DOM 树。
float为:inline-block浮动框之前的当前行中的任何内容都会在浮动另一侧的第一个可用行中重排。
display: flex替代display: table或基于 JavaScript 的布局:新的 flexbox 代码的多通道布局代码路径要少得多。不过,您仍然可以很容易地点击多遍代码路径(例如 flex-align:stretch 通常是 2 遍)。一般来说,在普通情况下它应该快得多,但您可以构建一个同样慢的情况。也就是说,如果你能摆脱它,常规的块布局(非浮动)通常会比新的 flexbox 更快或更快,因为它总是单通道。但是新的 flexbox 应该比使用表格或编写基于 JS 的自定义布局代码更快。
bottom作vertical-align属性的值:内联框根据源内联元素的 'vertical-align' 属性值垂直对齐。如果一个元素的该属性的值为 'top' 或 'bottom',则只有生成的框的高度会影响行框高度的计算;在完全构建线框之前,无法对齐框。请注意,如果行框中的所有框都沿其底部对齐,则行框将恰好是最高框的高度。但是,如果这些框沿公共基线对齐,则行框顶部和底部可能不会接触最高框的顶部和底部。
inline-block对需要垂直定位的大量内联元素使用固定高度:计算行框中每个行内级框的高度。对于替换元素、inline-block 元素和 inline-table 元素,这是它们的边距框的高度;对于内联框,这是它们的“行高”。
shouldComponentUpdate优化渲染:在实践中,任何复杂的东西都可能需要 shouldComponentUpdate 才能获得可接受的性能。编写合理高效的 shouldComponentUpdate 反过来需要可以快速比较的基础数据,因此例如当前对可以通过检查单个引用来测试相等性的不可变数据结构的兴趣。因此,使用 React 进行渲染的选择确实会影响底层数据的存储方式,这会破坏任何关于真正将视图逻辑与业务逻辑分离的主张。
参考