深度优化是从浏览器解析html第一行开始掐住节奏：script放错位置会阻塞渲染，需用async/defer；dom层级过深加剧重排，应语义化标签并减少嵌套；图片须设宽高防抖动；流式html渲染可提升首屏速度。
HTML 本身不执行逻辑，但写法一错，整个页面就卡在解析阶段——所谓“深度优化”，不是堆技巧，而是从浏览器解析 DOM 的第一行开始，掐住它每一步的节奏。
为什么 <script></script> 放错位置会让首屏白屏两秒
浏览器遇到未加修饰的 <script></script> 标签，默认暂停 HTML 解析，同步下载、编译、执行脚本后才继续。这意味着：哪怕只是 <script>console.log(1)</script> 写在 里，也会阻塞后续所有标签（包括 <img>、<div>）的解析和渲染。
<ul>
<li>必须用 <code>async 或 defer：非关键 JS 加 async；依赖 DOM 结构或需按序执行的加 defer
<script></script> 放 defer 可控（比如无法保证执行顺序）<script>...</script>）永远阻塞，除非你确认它只做极轻量初始化（如设置 window.__INIT__）DOM 层级深到 8 层以上，重排成本会指数级上升
浏览器构建渲染树时，每个节点都要计算样式、布局、绘制。嵌套越深，CSS 选择器匹配路径越长，getBoundingClientRect() 这类读取操作越容易触发强制同步布局（forced reflow）。
- 用
<main></main>、<section></section>、<article></article>替代无意义的<div> 嵌套，语义化本身就能压平结构 <li>Flexbox/Grid 能实现的布局，别用三层 <code><div class="wrapper"><div class="inner"><div class="content"> <li>Chrome DevTools 的 “Layers” 面板可直观看到哪些元素被拆成独立合成层——过度切分（如每个卡片都加 <code>transform: translateZ(0)）反而加重 GPU 负担 - 必须为所有
<img>显式声明width和height（可用 CSS aspect-ratio 替代，但兼容性要查） -
decoding="async"应与loading="lazy"同时使用，避免解码阻塞主线程 - SVG 图标建议内联（
<svg>...</svg>），既免请求又可控尺寸，比<img src="icon.svg">更稳 - 需要后端框架支持（如 Spring Boot 的
StreamingResponseBody、Node.js 的res.write()） - 前端不能依赖
DOMContentLoaded——因为 DOM 是渐进式到达的，需监听document的增量变化（如用MutationObserver处理动态插入的模块） - 注意缓存代理（如 Nginx）可能缓冲 chunk，需配
proxy_buffering off和chunked_transfer_encoding on
loading="lazy" 不是万能的，图片没设 width/height 会引发布局抖动
懒加载只控制资源何时下载，但若图片缺失尺寸属性，浏览器无法预留空间，加载完成瞬间会触发重排，造成文字上跳、按钮位移等肉眼可见的抖动。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
流式 HTML 渲染（chunked transfer）是服务端最被低估的优化点
传统 SSR 是等整个 HTML 字符串拼完才发响应，用户得等全部模板渲染结束才能看到任何内容。而启用分块传输（Transfer-Encoding: chunked），可以让服务端一边生成、一边推送，首屏区块（如 header + 导航）几毫秒内就能出现在用户屏幕上。
真正的深度优化，往往藏在你删掉的那三行 <div>、改掉的两个 <code>top: 20px、以及服务端多写的那一行 res.write("<header>...</header>") 里——它不炫技，但用户刷进去那一刻，就是快。
