HTML5性能优化关键在合理使用：正确设置viewport、避免强制同步布局、慎用will-change/translateZ(0)、用Web Workers处理耗时计算且不操作DOM。
HTML5 本身不直接“提升性能”，真正起作用的是你如何用它——特别是避开渲染阻塞、减少重排重绘、合理使用新 API，以及针对移动端硬件特性做取舍。
viewport 设置不对，再好的 HTML5 也白搭
很多页面在手机上缩放错乱、字体忽大忽小、点击区域不准，根源常出在 配置上。它不是可选项，而是移动端渲染的起点。
- 必须显式声明：
-
user-scalable=no要谨慎：禁用缩放会影响可访问性，仅在游戏、全屏交互类场景考虑；普通内容页建议保留 - 避免
width=320或固定值——这会让高 DPR 设备（如 iPhone 14）强行缩放渲染，导致模糊和额外重绘 - 如果用 rem/vw 布局，
initial-scale=1.0是前提，否则 JS 动态计算根字体大小会失效
避免强制同步布局（Forced Synchronous Layout）
这是移动端卡顿最隐蔽的元凶之一。只要你在 JS 中读取某些样式后立刻修改样式（比如 offsetTop → classList.add），浏览器就不得不提前触发回流（reflow）来返回准确值。
- 常见触发属性：
offsetTop、clientWidth、getComputedStyle()、scrollHeight - 写法示例（错误）：
element.style.height = element.scrollHeight + 'px'; // 强制回流
- 优化方式：批量读、批量写；或改用
requestAnimationFrame延迟到下一帧：requestAnimationFrame(() => { const h = element.scrollHeight; element.style.height = h + 'px'; }); - 工具辅助：Chrome DevTools → Rendering → ✅ “Layout Shift Regions” 和 “FPS Meter”，能直观看到强制同步布局发生的帧
用 will-change 和 transform: translateZ(0) 要懂边界
这两个 CSS 技巧确实能触发 GPU 加速，但滥用反而拖慢首屏、增加内存占用，尤其在低端安卓机上表现明显。
立即学习“前端免费学习笔记（深入）”；
-
will-change: transform不是“开启加速开关”，而是向浏览器“预告”——浏览器会提前分配图层，但若预告过多（比如给 50 个列表项都加），会导致图层爆炸、内存飙升 - 只对真正需要频繁动画的元素用，且动画结束后建议移除：
element.style.willChange = 'transform'; // 动画结束回调中 element.style.willChange = 'auto';
-
transform: translateZ(0)在 iOS Safari 15.4+ 已基本失效（自动优化），在 Android Chrome 中可能引发意外的滚动条消失或 input 失焦，慎用 - 更稳妥的替代：用
transform: translateY(0)+opacity: 0.999组合，兼容性好、副作用小
Web Workers 处理耗时 JS，但别碰 DOM
移动端 JS 主线程一旦被占满，UI 就冻结。把计算密集型任务（如解析大 JSON、图像处理、加密）丢进 Web Worker 是有效解法，但必须注意通信成本和 DOM 访问限制。
- Worker 里不能访问
document、window、localStorage等主线程专属对象 - 数据传递靠
postMessage()，传大对象时用transferable（如ArrayBuffer），避免拷贝开销：// 主线程 const buffer = new ArrayBuffer(1024 * 1024); worker.postMessage(buffer, [buffer]); // 第二个参数表示转移所有权
- 不要为简单循环（如
for (let i = 0; i ）开 Worker——启动和通信成本远超收益 - 适合场景：前端 Excel 解析、实时滤镜、离线地图瓦片解码、大量表单校验预处理
真正影响 HTML5 移动端体验的，从来不是用了多少新标签，而是你有没有在 touchstart 触发前就准备好状态、有没有让 scroll 事件节流到 requestAnimationFrame、有没有在用户看不见的地方悄悄释放掉不用的 Canvas 上下文——这些细节，比任何“优化技巧清单”都更难被注意到，也更容易被忽略。
