<script>放</body>前是最小代价的性能修复，因其直接切断浏览器解析HTML时遇到<script>暂停DOM构建、下载执行再继续的阻塞链，避免首屏卡顿，且不依赖defer/async限制或内联JS风险。
为什么<script>放</body>前是最小代价的性能修复
浏览器解析HTML时，遇到<script>默认会暂停DOM构建，去下载、执行脚本，再继续——首屏卡顿80%出在这里。把<script>挪到</body>前，不是“最佳实践”，而是最直接切断阻塞链的方式。
- 不依赖
defer或async：它们只对外部脚本有效，且async执行时机不可控，可能早于DOMContentLoaded - 避免内联大JS：比如把Vue/React初始化逻辑塞进
<script>标签里，一旦它依赖未就绪的DOM节点，就会报Cannot read property 'xxx' of null - 服务端渲染（SSR）场景下，这个位置仍是安全的：HTML已完整输出，JS只需补交互，不参与首屏渲染
<link rel="preload">和<link rel="preconnect">什么时候该删
这两个标签不是“加了就快”，而是“加错就拖慢”。浏览器会为它们提前分配连接、带宽和解析资源，但若目标资源根本不用，或加载顺序不合理，反而挤占关键路径。
-
<link rel="preload" href="/font.woff2" as="font">只对首屏必现字体有效；若字体只用于h2以下文本，预加载反而抢占HTTP/2优先级 -
<link rel="preconnect" href="https://cdn.example.com">对跨域CDN有用，但别对fonts.googleapis.com、analytics.js、adservice.google.com全加上——实测多加3个，TTFB平均增加120ms - 所有
preload必须配as属性，否则浏览器按fetch处理，可能触发重复请求
嵌套超过5层<div>为什么让低端机首屏慢50ms
浏览器构建DOM树是同步单线程过程，每层嵌套都意味着一次节点创建+样式计算+布局重排。这不是理论值，是真实设备上可复现的延迟。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 检查方式：用Chrome DevTools的Elements面板看渲染后DOM，不是源码——组件框架（如Vue）可能自动包裹一层
<div>，你没写，但它在 - 替代方案：用
<header>、<nav>、<main>等语义化标签，它们本身不增加嵌套深度；CSS中用display: contents跳过盒模型，但注意IE全系不支持、影响可访问性 - Flex/Grid容器内子元素不继承
width: 100%，<main>区域若没显式设宽，文字溢出后触发重排，等于白优化
<meta charset>位置错位会导致页面闪动
这不是兼容性问题，是HTML规范强制要求：<meta charset="utf-8">必须出现在前1024字节内。否则浏览器先按latin1解析一部分，发现编码不对再重载，用户看到的是乱码→闪白→正常，整个过程不可跳过。
立即学习“前端免费学习笔记（深入）”；
- 放在
<head>最开头，紧贴<title>之前，不要被<meta name="viewport">或其他meta挤到后面 - 服务端模板中容易漏：比如EJS里
<% if (env === 'prod') { %><script>...</script><% } %>写在<meta charset>前面，就违规 - Webpack/Vite构建时，如果HTML插件配置了
inject: false，手动插入<meta>务必确认位置
<script>位置、删两个preconnect、扁平一层<div>、校准<meta charset>位置——这些改动不需要重构，但效果立竿见影。 
