HTML评分是Lighthouse生成的静态分数，不影响星星组件运行时性能；真正影响性能的是事件绑定方式、DOM更新策略和动画节流机制。
HTML评分本身不会拖慢星星组件
先明确一个核心概念：你在页面里运行的那些 document.querySelectorAll 或者 getElementsByClassName 操作，跟 Lighthouse 报告里的 “HTML 评分” 压根不是一回事。这个分数，其实是 Lighthouse 完成所有审计项之后，根据一系列规则计算出来的一个静态数字。它更像一份事后的“体检报告”，本身并不会参与到页面的运行时逻辑中。也就是说，它既不会往你的页面里注入额外的脚本，也不会添加任何事件监听器，更不会触发重绘或重排。
那么，星星组件的响应速度究竟取决于什么呢？答案在于组件自身的设计：它的事件绑定机制是否高效、状态更新时如何操作DOM，以及视觉渲染的复杂度有多高。这才是问题的关键。
但「为提 HTML 分数而改写的星星组件」可能变慢
这里有个常见的误区，很多人踩过坑。看到 Lighthouse 提示“要使用语义化 HTML”或者“避免内联样式”，就下定决心对星星组件进行一场“外科手术式”的改造。原本可能只用几个 div 或 span 就能轻巧实现的交互，被硬生生改造成了一套庞大的结构：外层套上 fieldset 和 legend，里面再嵌套一堆 label 和 input[type="radio"]，生怕不够“语义化”。
这还没完，为了拿到更高的无障碍（A11y）分数，还得加上各种 ARIA 属性，并编写复杂的 Ja vaScript 来初始化和维护状态。结果通常是这样的：
- DOM 节点爆炸：星星数量没变，但节点数可能从不到10个激增到30个以上，首次渲染时间肉眼可见地变长。
- 事件流臃肿：每点击一颗星，都可能触发一连串的
change、focus事件，再加上开发者自己派发的自定义事件，执行链路变得又长又重。 - 过度无障碍反馈：为了即时告知屏幕阅读器评分已更新，添加了
aria-live区域。这导致每次评分变化，都会强制屏幕阅读器重读内容，反而干扰了正常体验。 - CSS 选择器变深：样式选择器不得不写成
.rating > fieldset > div > label > input + span::before这样的长链，查询和渲染的计算开销成倍增加。
你看，出发点是为了优化，结果却南辕北辙，让一个轻量组件变得笨重不堪。
真正影响星星组件性能的 3 个关键点
所以，别再紧盯着那个 HTML 分数不放了。真正值得你投入精力的，是下面这三个直接影响性能的环节：
- 事件绑定策略不当：最常见的问题是给每一颗星星都单独绑定
click事件监听器。10颗星就是10个监听器，这不仅是内存的浪费，也增加了事件管理的复杂度。高效的做法是采用事件委托：只在父容器上绑一个监听器，通过判断event.target.matches(‘.star‘)来定位具体被点击的星星。 - DOM 更新方式粗暴：每次评分变化，都直接使用
el.innerHTML = generateStarsHtml(score)来重写整个星星区域的HTML。这相当于每次都把这一小块DOM拆除重建，触发完整的重排与重绘。更好的方式是只更新状态变化的部分，比如切换特定星星的active类名，或者修改其style属性。 - 动画与交互缺乏节流：为了实现鼠标滑过时的预览效果，在
mousemove事件中调用updatePreview函数，并且每一帧（通过requestAnimationFrame）都执行。但实际上，用户的手指或鼠标移动速度，根本感知不到60fps下每一帧的细微变化。这里就需要合理的节流（throttle）策略，减少不必要的函数执行次数。
Lighthouse HTML 分数低，但星星组件很流畅 —— 这很正常
举个典型的例子：你用一组 div 元素来模拟星星，为了基本的可访问性，你加上了 role="img" 和 aria-label 来说明其功能。星星图形用CSS伪元素绘制，交互逻辑则只在父容器上监听一个 click 事件，然后更新一个 data-score 属性来驱动视图变化。
这种实现方案，在Lighthouse的HTML审计项下，分数可能只有70到80分。因为它没有使用原生的 form 关联控件，也没有用 input 来承载状态。但是，它的交互响应速度可以轻松控制在几毫秒之内，用户体验极其流畅。
道理很简单：Lighthouse的HTML类别审计，主要考察的是文档结构的合理性、语义的准确性以及基础的可用性规范，它并不直接测量运行时的性能。因此，千万别为了把那个分数从83分硬拉到92分，而给一个原本高效的星星组件套上沉重的框架封装（比如React + Formik），那才是真正的得不偿失。
立即学习“前端免费学习笔记（深入）”；
