删掉冗余DOM节点能让首屏快120ms，因节点越多解析、渲染树构建和布局计算开销越大；实测移除3层嵌套div使首屏绘制从1.38s降至1.26s，尤其在低端设备上易触发layout thrashing。
为什么删掉一个 能让首屏快 120ms
DOM 节点越多，浏览器解析、构建渲染树、布局计算的开销越大。尤其在低端手机上，500+ 个节点就可能触发 layout thrashing。我们实测过：某后台管理页移除 3 层嵌套的 <div class="wrapper"><div class="inner"><div class="content">，首屏绘制时间从 1.38s 降到 1.26s。
常见错误现象：用 <div> 套 <div> 实现布局，CSS 里写 .wrapper .inner .content；语义缺失，屏幕阅读器无法识别区域意图；JS 查询时遍历路径变长。
- 能用
<header>、<nav>、<main>、<section> 的地方，别堆 <div>
- Flex/Grid 布局下，90% 的包裹层可直接删——容器本身就能承担布局职责
- 检查 Chrome DevTools 的 Elements 面板，右键节点选 “Break on > attribute modification”，看哪些
<div> 其实只起 class 容器作用
内联 critical CSS 但 HTML 不爆炸的实操边界
直接把全部 CSS 内联进 <head> 是最常见误操作。某电商首页这么做之后，HTML 体积从 18KB 涨到 64KB，TTFB 延迟翻倍，CDN 缓存命中率跌了 37%。
关键不是“要不要内联”，而是“内联多少”和“怎么提取”。critical 工具（如 critical npm 包）默认按 1300px 宽度 + 首屏高度截取样式，但实际要结合设备分布调参。
立即学习“前端免费学习笔记（深入）”；
- 移动端占比超 70%？把提取 viewport 设为
width=375,height=667
- 使用
penthouse 替代默认方案，它支持自定义 Puppeteer 启动参数，能模拟真实用户滚动行为再抓样式
- 内联部分必须用
<style> 标签包裹，且加 media="print" 属性——避免阻塞渲染，等页面加载完再用 JS 切换 media 值
图片懒加载 loading="lazy" 失效的三个隐藏原因
loading="lazy" 看似开箱即用，但上线后发现大量图片仍首屏加载，根本原因是浏览器兼容性与 DOM 插入时机不匹配。
Chrome 76+、Firefox 75+、Safari 15.4+ 才原生支持该属性。更隐蔽的问题是：动态插入的 <img>（比如通过 JS append 或框架 v-for 渲染），如果插入时已位于视口内，浏览器会跳过懒加载逻辑直接请求。
- 服务端渲染（SSR）场景下，确保生成的 HTML 中
<img> 标签已带 loading="lazy"，不要依赖客户端补加
- React/Vue 项目中，避免在
useEffect 或 mounted 里动态设置 src——这会让浏览器当作“新资源”立即加载
- 对轮播图、瀑布流等组件，手动监听
IntersectionObserver 替代纯属性，控制更精准
gzip 压缩后 HTML 还剩 30KB？你可能漏了服务器配置
HTML 压缩工具（如 html-minifier）只能解决代码层面冗余，真正影响传输体积的是服务器是否启用 gzip/brotli，以及压缩等级是否匹配文本特性。
我们遇到过一次线上事故：构建后 HTML 只有 12KB，但 Nginx 返回的响应体却是 28KB。查日志发现 gzip_types 里没配 text/html，导致 HTML 走明文传输。
- Nginx 必须显式声明：
gzip_types text/html application/javascript text/css;
- Node.js（Express）需用
compression 中间件，并设 threshold: 1024（默认 1KB，小文件不压缩反而增大体积）
- Brotli 比 gzip 平均多压 15%，但需要 HTTPS 且客户端支持——用
Accept-Encoding: br 请求头判断是否启用
结构优化不是删代码，是让每个标签都有不可替代的作用；压缩不是越狠越好，是让传输、解析、渲染三阶段都少做无用功。最容易被忽略的，其实是构建流程和服务器配置的联动——工具链输出的 HTML 再干净，没配对的服务器响应头，照样白忙。
DOM 节点越多，浏览器解析、构建渲染树、布局计算的开销越大。尤其在低端手机上，500+ 个节点就可能触发 layout thrashing。我们实测过：某后台管理页移除 3 层嵌套的 <div class="wrapper"><div class="inner"><div class="content">，首屏绘制时间从 1.38s 降到 1.26s。
常见错误现象：用 <div> 套 <div> 实现布局，CSS 里写 .wrapper .inner .content；语义缺失，屏幕阅读器无法识别区域意图；JS 查询时遍历路径变长。
- 能用
<header>、<nav>、<main>、<section>的地方，别堆<div> - Flex/Grid 布局下，90% 的包裹层可直接删——容器本身就能承担布局职责
- 检查 Chrome DevTools 的 Elements 面板，右键节点选 “Break on > attribute modification”，看哪些
<div>其实只起 class 容器作用
内联 critical CSS 但 HTML 不爆炸的实操边界
直接把全部 CSS 内联进 <head> 是最常见误操作。某电商首页这么做之后，HTML 体积从 18KB 涨到 64KB，TTFB 延迟翻倍，CDN 缓存命中率跌了 37%。
关键不是“要不要内联”，而是“内联多少”和“怎么提取”。critical 工具（如 critical npm 包）默认按 1300px 宽度 + 首屏高度截取样式，但实际要结合设备分布调参。
立即学习“前端免费学习笔记（深入）”；
- 移动端占比超 70%？把提取 viewport 设为
width=375,height=667 - 使用
penthouse替代默认方案，它支持自定义 Puppeteer 启动参数，能模拟真实用户滚动行为再抓样式 - 内联部分必须用
<style>标签包裹，且加media="print"属性——避免阻塞渲染，等页面加载完再用 JS 切换 media 值
图片懒加载 loading="lazy" 失效的三个隐藏原因
loading="lazy" 看似开箱即用，但上线后发现大量图片仍首屏加载，根本原因是浏览器兼容性与 DOM 插入时机不匹配。
Chrome 76+、Firefox 75+、Safari 15.4+ 才原生支持该属性。更隐蔽的问题是：动态插入的 <img>（比如通过 JS append 或框架 v-for 渲染），如果插入时已位于视口内，浏览器会跳过懒加载逻辑直接请求。
- 服务端渲染（SSR）场景下，确保生成的 HTML 中
<img>标签已带loading="lazy"，不要依赖客户端补加 - React/Vue 项目中，避免在
useEffect或mounted里动态设置src——这会让浏览器当作“新资源”立即加载 - 对轮播图、瀑布流等组件，手动监听
IntersectionObserver替代纯属性，控制更精准
gzip 压缩后 HTML 还剩 30KB？你可能漏了服务器配置
HTML 压缩工具（如 html-minifier）只能解决代码层面冗余，真正影响传输体积的是服务器是否启用 gzip/brotli，以及压缩等级是否匹配文本特性。
我们遇到过一次线上事故：构建后 HTML 只有 12KB，但 Nginx 返回的响应体却是 28KB。查日志发现 gzip_types 里没配 text/html，导致 HTML 走明文传输。
- Nginx 必须显式声明：
gzip_types text/html application/javascript text/css; - Node.js（Express）需用
compression中间件，并设threshold: 1024（默认 1KB，小文件不压缩反而增大体积） - Brotli 比 gzip 平均多压 15%，但需要 HTTPS 且客户端支持——用
Accept-Encoding: br请求头判断是否启用
结构优化不是删代码，是让每个标签都有不可替代的作用；压缩不是越狠越好，是让传输、解析、渲染三阶段都少做无用功。最容易被忽略的，其实是构建流程和服务器配置的联动——工具链输出的 HTML 再干净，没配对的服务器响应头，照样白忙。
