HTML结构直接影响首屏渲染性能：未压缩HTML、同步脚本、内联样式、DOM节点过多、px单位滥用等均导致延迟与掉帧；需压缩HTML、移除阻塞资源、用虚拟滚动/Canvas、vh/vw单位及动态rem适配，并从HTML顶部埋点监控。
HTML结构本身就会拖慢首屏渲染
HTML不是“写完就能跑”的静态文档——浏览器解析它时会逐字节构建DOM树，遇到同步脚本就暂停，遇到内联样式就触发重排。一个没压缩的、含大量空格和注释的HTML文件，哪怕只有10KB，也可能让domInteractive延迟80ms以上。
常见错误现象：navigationStart到domInteractive间隔超200ms；Lighthouse提示“Eliminate render-blocking resources”，但检查后发现根本没外链JS，问题出在<script>标签位置或document.write()调用。
- 把所有
<script>移到</body>前，禁用document.write() - 服务端开启Gzip/Brotli压缩，HTML响应体控制在30KB以内（含内联CSS/JS）
- 避免在
<head>里用<link rel="stylesheet">加载非关键CSS；改用media="print" onload="this.media='all'"懒加载
DOM节点数超标直接触发掉帧
监控大屏或数据看板页面常因DOM节点爆炸式增长而卡顿：500个<div>嵌套+每秒更新3次，Chrome主线程每帧要重排重绘上千次，60fps立刻崩到20fps以下。
使用场景：实时拓扑图、设备状态列表、滚动日志面板——这些地方最容易堆DOM。
立即学习“前端免费学习笔记（深入）”；
- 用
document.createDocumentFragment()批量插入节点，而非多次appendChild() - 超过100个同类型项（如服务器列表），改用
<canvas>或虚拟滚动（只渲染视口内节点） - 用
console.dir(document.body)查childNodes.length，超过200就该拆分或懒加载
性能监控必须从HTML加载起点埋点
只在window.onload之后上报性能数据，等于放弃首屏最关键的2秒——此时用户已经看到白屏或骨架屏，但你还没开始采集。
容易踩的坑：performance.timing在某些安卓WebView里不可靠；第三方SDK注入晚于fetchStart，导致DNS耗时漏报。
- 在
<head>最顶部加<script async defer>加载监控脚本，并确保它不依赖document对象 - 用
PerformanceObserver监听navigation类型，捕获responseStart前的DNS/TCP阶段 - 卸载前用
navigator.sendBeacon()发走performance.getEntriesByType('navigation')[0]，避免跳转丢失数据
布局单位写死px是响应式大屏的隐形杀手
很多监控大屏上线后在4K屏上文字小得看不见、图表错位、滚动条消失——问题不在CSS媒体查询，而在HTML里写了width="1920"或style="height: 1080px"。
性能影响比想象中更直接：浏览器为每个px单位做浮点计算，配合transform缩放时还会触发额外合成层，GPU内存占用翻倍。
- 所有宽高优先用
vh/vw，或clamp(300px, 50vw, 1200px) - 栅格布局弃用
<table>或多层<div class="row"><div class="col">，改用display: grid+minmax(0, 1fr) - 字体大小不用
px，统一用rem或em，根字号通过document.documentElement.style.fontSize动态适配分辨率
<!DOCTYPE html>第一行开始，就要决定这个页面能不能扛住300人同时刷、能不能在i5旧笔记本上稳住40fps。 
