Web组件样式运行时性能影响：Foo与Bar实例对比分析

先看两种自定义元素的实现代码：

window.customElements.define('my-foo', class Foo extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({mode: 'open'});
  }
  
  connectedCallback() {
    this.shadowRoot.innerHTML = `
      <style>
         p {
           color: red;
         }
         /* more styles go here */
      </style>
      <p>Foo</p>
    `;
  }
});

window.customElements.define('my-bar', class Bar extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({mode: 'open'});
  }
  
  connectedCallback() {
    this.shadowRoot.innerHTML = `
      <link rel="stylesheet" href="path/to/my/cdn/bar.css">
      <p>Bar</p>
    `;
  }
});

你的推测完全正确，下面详细分析两种方案在大量实例场景下的浏览器行为和性能表现：

一、浏览器行为差异 #

1. my-foo（内嵌样式方案） #

• 每个<my-foo>实例触发connectedCallback时，都会将包含<style>的HTML片段插入到自身的Shadow DOM中
• 浏览器会为每个实例的Shadow DOM单独解析内嵌的CSS规则，哪怕样式内容完全一致，也会重复执行解析、构建样式表的流程
• 全程无网络请求，所有样式逻辑都在本地完成

2. my-bar（外部样式表方案） #

• 第一个<my-bar>实例插入<link>标签时，浏览器会发起网络请求加载bar.css（若资源未在浏览器缓存中）
• 资源加载完成后，浏览器仅解析一次CSS并构建样式表，后续所有<my-bar>实例的<link>标签会直接复用已缓存的样式表，不会重复发起请求或重复解析
• 每个实例的Shadow DOM都会关联这份共享的样式表，不会创建独立的样式表副本

二、性能优劣对比 #

my-foo方案 #

• 优点：
  • 无网络依赖，不会因CSS加载阻塞组件渲染，组件能快速呈现
  • 样式与组件逻辑完全内聚，无需额外维护外部CSS文件，代码更紧凑
• 缺点：
  • 大量实例场景下，重复解析相同样式会消耗额外CPU资源，导致组件整体初始化时间变长
  • 每个实例都会持有独立的样式表副本，内存占用会随实例数量线性增长，样式内容越多，内存开销越大

my-bar方案 #

• 优点：
  • 样式表仅加载、解析一次，大量实例时能显著降低CPU和内存开销，初始化性能更优
  • 外部CSS可单独进行缓存、压缩优化，也能被其他组件复用，便于样式的统一维护和迭代
• 缺点：
  • 首次渲染依赖网络请求，若CSS加载较慢，会出现组件内容先无样式展示的情况（FOUC），需要额外处理加载状态
  • 样式与组件逻辑分离，增加了文件维护的复杂度，比如需要确保CSS路径正确、版本同步

优化方向 #

如果想兼顾两者的优势，可以考虑：

• 将my-foo的内嵌样式提取为类的静态属性，提前定义好样式字符串，减少每个实例的字符串拼接开销（虽仍会重复解析，但能降低部分初始化成本）
• 使用Constructable Stylesheets API：提前创建全局样式表，然后将其挂载到每个<my-foo>的Shadow DOM中，这样既无需外部网络请求，又能实现样式表的共享复用，彻底避免重复解析

内容的提问来源于stack exchange，提问作者Meise2000