转换后的页面可以像手工构建的页面一样快——也可以明显更慢，这取决于转换期间和转换后做出的一些选择。
优先使用原生小部件，而非 HTML 块
最大的一个因素。一个被放入单个大型 HTML 小部件中的页面会携带其整个原始样式表，包括针对页面上并不存在的元素的规则。原生组件模式会生成真正的小部件，其样式由 Elementor 按页面生成并缓存，因此你会少输出很多未使用的 CSS——而且作为额外好处，你还能得到一个可编辑的页面。
决定如何处理原始样式表
在转换期间保留内联样式很有用，因为它能让基于类的样式被正确测量。但是，一旦小部件携带了自身设置，页面顶部剩余的 CSS 块往往就是多余的。尝试移除它并检查布局——如果没有任何位移，你就刚刚删除了一块无用负担。
图片最值得关注
- 将真实图片上传到媒体库，而不是嵌入 data URL。Base64 图片无法被缩放、单独缓存或懒加载，而且它还会膨胀页面 HTML 本身。
- 让 WordPress 提供响应式尺寸，而不是在所有地方强制使用同一种大尺寸。
“优化 Base64 图片”选项实际做什么
这个选项的作用比它的名称所暗示的更有限，了解其边界可以避免你对它不会做的事情抱有期望。
它只在高保真模式下运行，且只处理大于约 135KB 的 Base64 数据图片——PNG、JPEG 或 WebP。这些图片会被解码、缩小，使其最长边不超过 2560px，然后重新编码。结果视图会报告处理了多少张以及节省了多少。
它不会做的事情：它不会处理通过 URL 引用的图片，因为那些是服务器上的文件，这个工具无权重写。而且在原生组件模式下它根本不会运行——那里的 Base64 图片会变成带说明文字的空占位框，供你从媒体库补上，这本来就是更好的结果。
因此，诚实的总结是：这个选项只解决一种特定情况——对一个所有图片都已内联的页面进行高保真导入，而这种页面通常由 AI 工具生成。如果你的图片是正常的 URL，那么这个选项就无关紧要，真正的优化发生在它该发生的地方——在你的媒体库中，由 WordPress 生成响应式尺寸。
注意嵌套深度
过深的容器树不仅难以编辑——每一层都是额外的 DOM 节点和另一组生成的 CSS 规则。如果结构映射显示层级达到七层或八层，请简化源内容，或在树中把复制根节点设得更深。更扁平的输出既更快，也更容易维护。
字体
转换后的页面会声明源页面所使用的字体。如果这些字体不是你的网站已经在加载的字体，请正确注册它们，或改用“继承目标站全局字体”，让页面使用你的网站已经在加载的字体。你要避免的是为一个导入的区块加载第二种字体家族。
以原生方式重新添加行为
脚本会在转换期间被剥离，这对性能和安全性都是好事。当你重新搭建轮播、选项卡或计数器时，请使用 Elementor 自带的小部件，而不是粘贴第三方脚本回去——它们已经是你正在加载的资源包的一部分。
为什么转换后的页面不会自动变得臃肿
有一种合理的担心：自动转换会把页面埋在一堆设置中，而所有这些设置都会变成 CSS。有两件事可以防止这种情况发生。
首先，响应式值只在它们与桌面端不同的地方写入。一个在各宽度下内边距都相同的容器只会得到一个内边距值，而不是三个。在有六十个小部件的页面上，这就是精简样式表和携带三分之二冗余规则的样式表之间的区别。
其次，可以证明不起任何作用的包裹元素会被移除，而不是被转换。每个保留下来的容器都是一个真正的 <div>，带有自己生成的规则，因此丢弃没有样式效果的容器会同时移除一个 DOM 节点及其 CSS。
这些措施都无法修复的是本来就很深的源标记。转换器会镜像你的 HTML，而不是重新设计它。即使每一层都被仔细处理，七层的源内容仍会产生一个沉重的页面，这就是为什么在源头上进行扁平化比任何导入后的整理都更有价值。
先测量，再整理
在清理前后分别对页面进行速度测试。通常收益来自三个方面：移除多余的样式表块、替换过大的图片，以及扁平化嵌套过深的树。这些都不需要太长时间，而且它们通常能解释大部分差异。
关注正确的指标。页面总大小和 Largest Contentful Paint（LCP，最大内容绘制）会随图片方面的优化而改善。Cumulative Layout Shift（CLS，累积布局偏移）则取决于图片是否有明确的尺寸——你从媒体库填充的占位图具有这些尺寸，而 Base64 图片通常没有。而 DOM 节点数，这个大多数报告都会显示、但大多数人会跳过的指标，才是告诉你嵌套是否得到控制的指标。