绝大多数HTML开发工作无需独立显卡，document.getElementById()等逻辑运行在CPU上，集成显卡仅负责最终渲染；真正调用GPU的是WebGL、WebGPU、Canvas 2D硬件加速或CSS合成层等主动启用的机制。
够用，绝大多数 HTML 相关开发工作根本不需要独立显卡——你写的 document.getElementById()、fetch()、addEventListener() 全部跑在 CPU 上，集成显卡只负责最后把渲染结果“画出来”，不参与逻辑执行。
哪些“HTML函数”真会用到 GPU
所谓“用到 GPU”，其实是浏览器调用 WebGL、WebGPU、Canvas 2D 硬件加速路径或 CSS 合成层时触发的。这些不是 HTML 自身功能，而是 JS 或 CSS 主动启用的加速机制：
-
getContext("webgl")或getContext("webgpu")初始化失败 → 很可能不是显卡不行，而是驱动未更新、浏览器没开硬件加速、或电源计划被设为“节能” -
canvas.getContext("2d", { willReadFrequently: true })像素读取变慢 → 集成显卡支持该 flag，但若系统未绑定高性能 GPU（如 Intel Iris Xe 在 Win11 下默认走核显），性能会打折扣 - CSS 中大量使用
transform+opacity触发合成层 → 集成显卡能处理，但若页面有上百个同时动画的元素，帧率可能从 60fps 掉到 40fps，人眼可察觉卡顿
集成显卡下容易被误判的卡顿来源
页面变慢，90% 情况和显卡无关，而是代码写法触发了低效路径：
- 频繁调用
offsetHeight/getBoundingClientRect()→ 强制同步布局计算，主线程阻塞 - 在
resize或scroll事件里直接操作 DOM → 未加debounce或requestAnimationFrame节流，重排重绘爆炸 - 用
innerHTML替换大段结构，且未用DocumentFragment批量插入 → 每次都触发完整重排 - 大量
console.log()输出对象（尤其带循环引用的）→ DevTools 序列化开销远超预期，旧笔记本上明显卡顿
必须手动干预的三个关键设置
即使核显足够，Windows + Chrome/Edge 组合下仍需主动配置，否则 GPU 加速通道默认关闭：
立即学习“前端免费学习笔记（深入）”；
- 电源计划必须设为【高性能】——“平衡”模式会锁死 GPU 频率，
requestAnimationFrame动画掉帧、ctx.drawImage批量绘制延迟升高 - 在 Windows 图形设置中，为
chrome.exe显式指定“高性能 GPU”——否则浏览器进程可能被调度到核显，导致getContext("webgl")返回null - 浏览器设置里确认已开启【硬件加速】（chrome://settings/system → 开启“使用硬件加速模式”）——这是软件开关，不开则所有 GPU 路径都被禁用
真正卡住你的，从来不是那块 Intel Iris Xe 或 AMD Radeon Graphics，而是没意识到 will-change: transform 写在 200 个元素上会创建 200 个合成层，吃光显存；也不是核显不支持 WebGL，而是忘了在 chrome://flags 里启用 #enable-webgpu-developer-features（WebGPU 开发阶段需要手动开）。
