html评分是lighthouse生成的静态分数，不影响星星组件运行时性能；真正影响性能的是事件绑定方式、dom更新策略和动画节流机制。
HTML评分本身不会拖慢星星组件
页面里跑 document.querySelectorAll 或 getElementsByClassName 这类 DOM 查询，和 Lighthouse 里的「HTML 评分」完全无关。HTML 评分是 Lighthouse 在审计完成后算出的一个**静态分数**，它不参与运行时逻辑，也不会注入任何脚本、监听器或重绘逻辑。星星组件（比如用 input[type="range"]、svg 或纯 CSS 实现的评分控件）的响应速度，只取决于它自己的事件绑定、DOM 更新方式和渲染复杂度。
但「为提 HTML 分数而改写的星星组件」可能变慢
常见踩坑场景：有人看到 Lighthouse 报「使用语义化 HTML」或「避免内联样式」，就强行把原本轻量的星星组件改成一堆 fieldset+legend+label+input[type="radio"] 嵌套结构，还配上大量 ARIA 属性和 JS 初始化逻辑。结果：
- DOM 节点数从 7 个涨到 30+，首次渲染耗时上升
- 每个星星点击都要触发多次
change+focus+ 自定义事件派发 - 为满足「无障碍」要求加了
aria-live区域，导致每次评分更新都触发屏幕阅读器重读 - CSS 选择器变成
.rating > fieldset > div > label > input + span::before，重排重绘开销翻倍
真正影响星星组件性能的 3 个关键点
别盯着 HTML 分数看，盯这三处：
-
事件委托没做：给每个星星单独绑
click，而不是在父容器上用event.target.matches('.star')判断 —— 10 颗星就是 10 个监听器 -
状态同步靠 innerHTML 重写：每次评分都
el.innerHTML = generateStarsHtml(score)，触发整块 DOM 替换，而非仅切换class或style -
用了 requestAnimationFrame 却没节流：鼠标移入星星区域时，每帧都调用
updatePreview(score)，但实际用户根本感知不到 60fps 下的细微变化
Lighthouse HTML 分数低，但星星组件很流畅 —— 这很正常
比如你用 div 模拟星星，加了 role="img" 和 aria-label，CSS 用伪元素画星形，JS 只监听父级 click 并更新一个 data-score 属性 —— 这种写法通常 HTML 分数只有 70–80（因缺少 form 关联、未用 input 原生控件），但交互响应能压到 3ms 内。Lighthouse 的 HTML 类别主要查结构合理性与基础可访问性，不测运行时性能。别为了把那个分数从 83 拉到 92，给星星组件加一层 React 封装再配 Formik。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
