自定义元素本身不提升渲染性能，关键在于通过控制DOM构建时机、减少重排触发、隔离样式作用域来规避性能陷阱；它仅注册类到CustomElementRegistry，不改变渲染流水线，所谓“高性能”源于生命周期钩子与Shadow DOM的主动优化能力。
自定义元素本身不提升渲染性能，但能帮你规避常见性能陷阱——关键在控制 DOM 构建时机、减少重排触发、隔离样式作用域。
为什么直接用 customElements.define() 不会加速渲染
注册自定义元素只是把类挂进 CustomElementRegistry，浏览器不会因此跳过解析、布局或绘制流程。它不改变渲染流水线的任何一环，也不自动启用 GPU 加速或懒加载。所谓“高性能”，实际是你借它的生命周期钩子和 Shadow DOM 能力，主动避开那些拖慢渲染的操作。
常见误判：my-chart 标签写在 HTML 里，但图表数据要等 API 返回才渲染——如果没做控制，constructor 里就调 fetch 或操作 this.innerHTML，会导致 DOM 构建卡顿、首次绘制延迟。
- HTML 中提前写的
<my-chart data-url="/api/stats"></my-chart>，会在解析阶段创建节点，但connectedCallback才是真正适合发起异步加载的时机 - 若在
constructor中直接修改this.style.width或调getBoundingClientRect()，可能强制同步布局计算（Layout Thrashing） - 不加 Shadow DOM 的自定义元素，其内部结构仍参与全局 CSSOM 匹配，深层选择器（如
article div p span）会拖慢样式计算
用 connectedCallback 控制首屏渲染节奏
这个回调在元素被插入文档后触发，且只触发一次。它是你决定“什么时候开始干活”的最可靠入口——比 DOMContentLoaded 更精准，比 requestIdleCallback 更可控。
立即学习“前端免费学习笔记（深入）”；
典型场景：列表页中多个 <product-card> 同时出现在视口内，每个都拉接口、解析图片、计算尺寸，很容易挤占主线程。
- 在
connectedCallback里用IntersectionObserver判断是否真正进入视口，再加载数据和图片 - 避免在回调里直接写
this.innerHTML = template；改用document.createRange().createContextualFragment()或template.content.cloneNode(true)，减少 parser 阻塞 - 如果需要初始化 canvas 或 WebGL 上下文，确保在
connectedCallback中检查this.isConnected，防止 upgrade 过程中重复初始化
Shadow DOM 是减少重排重绘的实际杠杆
不是为了“封装漂亮”，而是因为它让浏览器明确知道：这部分 DOM 的样式计算、布局影响范围被严格限定。没有 Shadow DOM，一个 product-card 里改个 margin，可能触发整页重排；有了它，重排只限于该 shadow root 内部。
注意两个硬约束：
-
attachShadow({ mode: 'open' })必须在constructor中调用，不能拖到connectedCallback—— 否则元素升级（upgrade）时已错过 DOM 构建早期阶段，部分属性（如slot分发）会失效 - 不要在 Shadow DOM 内部再用
<style>标签动态注入样式；改用adoptedStyleSheets（Chrome 73+、Firefox 96+），它复用已解析的 CSSOM，避免重复解析 - 慎用
:host-context(...)：它会让组件样式依赖外部 DOM 结构，破坏样式隔离，也增加 CSSOM 匹配开销
旧浏览器兼容时，polyfill 加载顺序就是性能分水岭
@webcomponents/custom-elements polyfill 不是“多加一行 script 就行”。它必须在任何 customElements.define() 执行前就位，否则注册失败且静默忽略——你看到的“没反应”，其实是元素压根没升级，所有生命周期钩子都不会触发，DOM 就是普通 HTMLElement。
更隐蔽的问题是：polyfill 启动后会遍历已有 DOM，对匹配的未定义标签执行 upgrade。如果页面已有上百个 <my-item>，这个遍历 + 构造函数调用过程会集中占用主线程。
- 把 polyfill 放在
<head>底部，且用defer；确保它在 DOM 解析完成前就下载完毕 - 对非首屏区域的自定义元素，改用
document.createElement('my-item')动态创建，避开初始 upgrade 批量压力 - IE11 下 polyfill 无法支持内置元素扩展（
{ extends: 'button' }），若必须支持，得降级为独立元素 + 模拟属性映射逻辑
最容易被忽略的一点：自定义元素的 attribute 到 property 映射不是自动的。你写了 <my-input value="test"></my-input>，但没在 observedAttributes 和 attributeChangedCallback 里处理 value，那这个值就永远卡在 attribute 层，不会反映到内部 <input> 的 value property 上——后续所有基于 property 的交互（比如表单提交、focus 后编辑）都会出错。
