最不卡首屏的位置是：脚本放<head>中并加defer属性，或用async（仅限无DOM依赖的独立脚本）；<body>底部仅为兼容性兜底，非最优解。
script 标签放哪儿最不卡首屏
浏览器解析 HTML 时，遇到 <script> 会立刻暂停 DOM 构建，去下载、执行脚本——哪怕这个脚本只用来统计点击量。首屏白屏时间长，十有八九是 <script> 放错了位置。
正确做法不是“统一丢到 </body> 底部”，而是按依赖关系选属性：
- 完全不依赖 DOM 的脚本（如埋点、广告 SDK）：用
async，下载不阻塞，执行也不保证顺序 - 依赖 DOM 但不依赖其他脚本（如初始化轮播图）：用
defer，下载并行，执行在 DOM 解析完后、DOMContentLoaded前，且按书写顺序 - 必须同步执行、且影响首屏结构的脚本（极少见）：内联 +
type="module"，或确保它体积极小、无网络请求
别再手动把 <script src="xxx"></script> 拖到 </body> 底下——现代构建工具生成的代码里，defer 更可控、更可预测。
loading="lazy" 加了却更慢？检查这三点
loading="lazy" 不是开关一开就提速，用错反而拖累 LCP（最大内容绘制）。常见翻车点：
立即学习“前端免费学习笔记（深入）”；
- 首屏图片加了
loading="lazy"：浏览器直接跳过加载，导致关键图延迟渲染，LCP 暴涨 - 没写
width和height：图片加载时尺寸未知，触发布局重排，造成 CLS（累积布局偏移） - 在 SSR 渲染的页面里对动态插入的
<img>忘记补属性：JS 创建的图片默认loading="eager"，和预期不符
稳妥做法：首屏图片不加 loading 属性（等价于 eager），非首屏图片统一加 loading="lazy"，且所有 <img> 都带明确宽高——哪怕是用 CSS aspect-ratio fallback 兜底。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
为什么内联 CSS 能提前三百毫秒渲染
浏览器只有拿到完整的 CSSOM 才能生成渲染树。外部 CSS 文件会触发「解析暂停 → 请求 CSS → 解析 CSS → 合并 DOM/CSSOM」链条，哪怕文件只有 2KB，网络往返也常耗 100–300ms。
把首屏必需的样式（比如标题字体、按钮颜色、骨架屏结构）内联进 <head> 的 <style>，等于把 CSSOM 构建提前到 HTML 解析阶段完成，跳过一次网络请求。
- 别内联整站 CSS：只取「渲染首屏 DOM 节点所必需」的部分，可用工具如
PurgeCSS或手动生成 critical CSS - 内联后记得压缩：去掉空格、注释、重复规则，避免内联本身增大 HTML 体积
- 配合
media属性做条件加载：比如<style media="(max-width: 768px)">只在小屏生效，大屏不会解析
fetchpriority="high" 真的有用吗
有用，但只在资源竞争激烈时显效。浏览器对每个资源分配默认优先级：link rel="stylesheet" 是 high，<img> 默认是 low，哪怕它是首图。
fetchpriority="high" 不是让下载变快，而是让浏览器把它插队到资源加载队列前面——尤其在弱网、多图、含字体/JS 的页面中，首图开始下载的时间可能提前 200–500ms。
- 仅对关键资源设：首图、关键字体、核心 JS（配合
defer） - 别滥用：给所有图片加
high等于没加，优先级系统会降级处理 - 注意兼容性：Chrome 109+、Edge 109+、Firefox 115+ 支持，Safari 尚未支持，需降级 fallback
真正容易被忽略的是：这些优化都得在 HTML 源码里写死，框架生成的 DOM 往往漏掉 fetchpriority、decoding、enterkeyhint 这类语义化属性——它们不在 React/Vue 的 props 列表里，得手动 patch 或用自定义指令兜底。
