首帧加载时间（FCP）超1.8秒主因是HTML结构问题而非CDN或服务器：嵌套div、未defer/script、错用lazy loading、内联style等拖慢解析；需精简语义化标签、规范图片属性、分层加载脚本、精准预加载与内联CSS。
首帧加载时间（FCP）压不进 1.8 秒，大概率不是 CDN 或服务器慢，而是 HTML 结构本身在拖后腿——尤其对大流量新闻站，每次发布新文章都带一堆冗余 <div>、未收敛的 <script>、错位的 loading="lazy"，这些细节在 UV 百万级时会被指数级放大。
为什么新闻页首屏 HTML 解析总卡在 300ms 以上
浏览器解析 HTML 是单线程同步行为，而新闻页常见结构里埋着多个隐性阻塞点：
- 嵌套过深的
<div>容器（比如<div class="wrapper"><div class="inner"><div class="content">...），导致 DOM 构建耗时翻倍 -
<script>标签没加defer或async，且放在<head>里，直接中断 HTML 流式解析 - 首屏图片用了
loading="lazy"却没设width/height，触发 layout shift 后浏览器反复重排 - 大量内联
style块或@import语句，让 CSSOM 构建延迟，进而阻塞渲染
新闻正文区域的 HTML 必须满足的三个硬约束
不是“越语义化越好”，而是要兼顾解析速度、SEO 和无障碍——尤其对高频更新的新闻正文：
- 用
<article>包裹整篇内容，但禁止内部再套<section>或<div>做布局，改用 CSS Grid / Flex 控制流式 - 段落必须用
<p>，禁用<br>换行；小标题统一用<h2>～<h4>，跳过<h1>（留给页面主标题） - 所有图片必须带
width和height属性，且优先用srcset+sizes适配多端，避免 JS 动态计算尺寸
如何让 <script> 不吃掉首帧时间
新闻页脚本分三类：广告、分享组件、评论框——它们的加载方式必须严格区分：
立即学习“前端免费学习笔记（深入）”；
- 第三方广告脚本一律用
async，且通过<script type="text/plain">+ 自定义属性（如data-src）延迟初始化，等DOMContentLoaded后再替换 - 分享按钮等轻量交互脚本，用
defer放在</body>前，确保 DOM 就绪后再执行 - 评论区这类重资源，必须用
<iframe src="about:blank">占位，滚动进入视口后才用IntersectionObserver注入真实src，彻底隔离阻塞 - 绝对禁用
document.write()—— 新闻页常有老广告 SDK 仍依赖它，会清空整个文档流，本地调试时就可能白屏
预加载与内联 CSS 的边界在哪
新闻页首屏关键资源非常明确：主图、标题、前两段正文、顶部导航栏。其他全是可延迟项：
- 只对主图用
<link rel="preload" as="image" href="hero.jpg">，别 preload 字体或次要图标——实测多 preload 一个非关键资源，FCP 平均增加 80ms - 内联 CSS 严格控制在 12KB 内（gzip 后），只含
<article>、<h2>、<p>、<img>的基础样式，连 hover 状态都不放 - 暗色模式切换用
<link rel="stylesheet" media="(prefers-color-scheme: dark)">，而不是靠 JS 动态换 CSS 文件——后者必然引入额外 RTT
真正卡住新闻页 FCP 的，从来不是「要不要优化」，而是「哪一行 HTML 正在悄悄拖慢解析」。上线前用 Chrome DevTools 的 Network 面板看 HTML 的 Content Download 时间线，再切到 Performance 面板展开 Parse HTML 事件，一眼就能定位是哪个 <div> 或 <script> 在吃时间——别信经验，只信 waterfall 图。
