FCP慢和TTI长的根本原因是HTML结构与加载策略低效，需内联首屏必需CSS（禁@import/@font-face）、延迟创建非首屏DOM、用defer执行DOM操作脚本、精准preload关键资源，并避免骨架屏掩盖真实阻塞。
首屏绘制（FCP）慢、可交互时间（TTI）长，根本原因往往不在网络或后端，而在 HTML 代码本身的结构与加载策略——它直接决定了浏览器构建 DOM、CSSOM 和渲染树的路径是否高效。
关键 CSS 必须内联，但只内联首屏真正需要的
浏览器遇到 <link rel="stylesheet"> 会暂停 DOM 构建，直到 CSSOM 完成；而 <style> 内联样式能立即参与渲染树构建。但内联整个 main.css 会让 HTML 体积暴涨，在弱网下反而更慢。
- 用工具如
critters或mini-css-extract-plugin+critical自动提取首屏必需样式（如 header、hero 区、按钮基础态） - 内联块里禁止出现
@import或@font-face，它们仍会触发额外阻塞请求 - 若用 CSS-in-JS（如 Emotion），确认 SSR 时已将关键样式序列化进
<style data-emotion>并注入首屏 HTML
非首屏 HTML 结构必须“不创建”，而非“不显示”
display: none 的区块仍参与 DOM 构建和 CSSOM 计算，只是不绘制；真正要的是延迟创建——避免无谓的内存占用和重排开销。
- 轮播图下方的推荐列表、评论区、侧边栏等，改用
<template>标签暂存，滚动进入视口后再动态插入 - tab 类内容初始只保留激活 tab 的 HTML，其余用
data-html属性存字符串，切换时再innerHTML或document.createElement - Chrome DevTools 的 Layers 面板可直观识别首屏区域是否混入大量隐藏节点
defer 与 async 不是互换选项，执行时机错位会导致 DOM 操作失败
defer 脚本按顺序执行，且保证在 DOM 解析完成、DOMContentLoaded 触发前运行；async 则无序加载、加载完立刻执行，可能早于 DOM 构建完成。
立即学习“前端免费学习笔记（深入）”；
- 操作 DOM 的初始化脚本（如初始化菜单、表单校验）必须用
defer，不能用async - 统计 SDK、埋点等独立逻辑可用
async，但禁止内联——否则会阻塞解析 - 现代项目优先用
type="module"，它天然具有defer行为，且支持import按需加载
预加载（preload）只用于浏览器无法自动发现的关键资源
<link rel="preload"> 不是越多越好，滥用会抢占带宽、挤掉真正关键的资源（如首屏 HTML、关键 CSS）。
- 仅预加载首屏强依赖、且浏览器无法静态分析出的资源：比如
<h1>的背景图、跨域 Web 字体（需同时加as="font"和crossorigin） - 不要预加载 JS/CSS 文件本身——浏览器能自动发现
<script src>和<link rel="stylesheet"> - 禁用
@import，它会让 CSS 加载串行化，在 3G 下可能多拖 800ms
HTML 优化最易被忽略的点，是把“让页面看起来快”和“让页面真正快”混为一谈——比如用骨架屏掩盖白屏，却不解决关键渲染路径阻塞；又比如压缩了 HTML 字节数，却让首屏样式仍靠外部 CSS 阻塞渲染。真正的优化，是从浏览器解析第一行 HTML 开始，就确保每一步都在推进首次绘制和可交互状态。
