核心回答首屏白屏优化的本质就是让首屏首帧依赖的东西更少、更早、更快。1. 先把问题拆开白屏到底卡在哪里可以把首屏过程理解成HTML 到达 ↓ HTML 解析 ↓ 发现 CSS / JS / 图片 / 字体 ↓ 资源下载 ↓ CSSOM / DOM ↓ 执行 JS ↓ 生成渲染树 ↓ Layout ↓ Paint ↓ 首帧所以“白屏严重”至少可能卡在四类问题网络慢 ↓ 资源下载慢 解析阻塞 ↓ CSS / JS 阻塞解析或渲染 执行慢 ↓ JS 长任务占满主线程 渲染慢 ↓ Layout / Paint / 图片解码 / 字体等耗时2. 关键渲染路径到底“关键”在哪关键渲染路径不是某一个 API而是浏览器从拿到 HTML到真正把第一帧内容画到屏幕上的必经过程。其中最重要的是HTML ↓ DOM ─────────┐ ├→ Render Tree → Layout → Paint CSS → CSSOM ─┘这里有两个非常重要的阻塞关系。CSS 为什么会影响首屏因为浏览器需要 CSSOM 来确定怎么渲染页面。linkrelstylesheethref/app.css如果首屏依赖的 CSS 还没准备好浏览器通常不会贸然把页面按最终样式绘制出来。所以CSS 越大 ↓ 下载 解析越慢 ↓ 越晚形成 CSSOM ↓ 首屏越晚JS 为什么会影响 HTML 解析传统同步脚本scriptsrc/app.js/script浏览器解析到这里后通常需要暂停 HTML 解析下载并执行 JS。因为 JS 可能document.body.innerHTML...;document.write(...);document.querySelector(...);所以浏览器不能假设“这个 JS 不会修改 DOM”。3. CSS 和 JS 怎么优化① 首屏关键 CSS直接内联例如headstyle.header{height:64px;}.hero{min-height:500px;}.skeleton{display:block;}/stylelinkrelstylesheethref/app.css/head核心思想首屏必须的 CSS ↓ 直接放 HTML ↓ 减少一次关键网络请求 ↓ 更快形成首屏样式但不是把整个 CSS 都塞进 HTML。应该关键 CSS ↓ 内联 非关键 CSS ↓ 异步/延后加载否则 HTML 自己变得很大反而得不偿失。4. 非关键 CSS 怎么处理可以使用linkrelpreloadhref/other.cssasstyleonloadthis.onloadnull;this.relstylesheet或者根据场景使用medialinkrelstylesheethref/print.cssmediaprint核心不是死记某个写法而是首屏必须的 CSS 走关键路径不重要的 CSS 不要堵在关键路径上。5. JS 为什么推荐defer例如scriptsrc/app.jsdefer/script它和普通scriptsrc/app.js/script最大的区别是普通 script HTML解析 ↓ 发现JS ↓ 暂停HTML解析 ↓ 下载JS ↓ 执行JS ↓ 继续解析HTML而deferHTML解析 ─────────────→ 完成 ↘ JS下载 ↓ DOM解析完成 ↓ 按顺序执行JS所以defer的核心价值就是让 JS 下载和 HTML 解析并行同时不因为脚本下载而卡住 HTML 解析。6.typemodule呢例如scripttypemodulesrc/main.js/script模块脚本默认具有类似defer的非阻塞解析行为。所以现代前端通常可以scripttypemodulesrc/main.js/script而不是body...scriptsrc/main.js/script/body但这里有一个容易被面试官抓住的点不是说“放到底部”一定错误。底部脚本确实可以避免阻塞前面的 HTML 解析但它的问题是浏览器很晚才能发现 JS ↓ JS 下载启动得晚 ↓ JS 执行也可能更晚如果这个 JS 是首屏真正需要的关键脚本就可能白白损失启动时间。所以更准确的说法是关键 JS 应该尽早被发现和下载同时不要阻塞 HTML 解析。7. 资源优先级怎么控制这里非常容易出现一个错误不是“重要资源全部 preload”。而应该做资源分层当前页面马上需要 ↓ Preload 关键域名 ↓ Preconnect 当前页面暂时不用 ↓ 不急着下载 下一个页面可能需要 ↓ Prefetchpreconnect例如linkrelpreconnecthrefhttps://cdn.example.com它解决的是DNS ↓ TCP ↓ TLS提前建立连接。适合CDN API 字体服务器等真正关键的跨域来源。preload例如首屏 LCP 图片linkrelpreloadasimagehref/hero.webp告诉浏览器这个资源当前页面马上就要用别等解析到img才发现它。特别适合首屏 LCP 图片首屏关键 CSS关键字体关键脚本/模块资源但一定要克制。8. 为什么 Preload 太多反而可能变慢因为浏览器带宽不是无限的。假设Preload A Preload B Preload C Preload D Preload E全部抢带宽。真正的 LCP 图片LCP ↓ 也在抢带宽结果可能变成Preload 越多 ↓ 关键资源之间互相竞争 ↓ 真正的关键资源反而变慢所以preload的原则是只提前加载“当前页面很快就一定会用”的关键资源。9.prefetch和preload不要混简单记preload → 我现在就要 prefetch → 我后面可能要例如用户现在在首页而你判断用户很可能马上进入商品详情页可以考虑linkrelprefetchhref/product-detail.js它属于提前准备未来资源而不是抢当前首屏的资源。10.fetchpriority是干什么的例如imgsrc/hero.webpfetchpriorityhighalt它是在告诉浏览器这个资源对当前页面更重要优先级可以高一些。首屏 LCP 图片经常是典型场景。反过来非关键图片可以imgsrc/image.webploadinglazyfetchprioritylowalt但也不要把所有东西都设置成high。如果什么都是高优先级就等于没有优先级。11. 为什么 Preload 了 LCP 图片还是最后加载这是非常好的追问。常见原因有几个① Preload 太多CSS preload JS preload 字体 preload 图片 preload ...互相竞争带宽。②as写错比如linkrelpreloadhref/hero.webpasimage应该正确声明资源类型。③ 实际 URL 不一致比如preload: https://cdn.com/a.webp img: https://cdn.com/a.webp?v1浏览器可能无法按预期复用。④ 图片本身太大Preload 只能让下载开始得更早不能让10MB → 100KB所以还要WebP / AVIF响应式图片合适尺寸CDN 图片处理压缩12. 下载完资源了为什么还是白屏这时候就不能再只盯着网络。核心要判断资源下载完成 ↓ JS 执行慢 ↓ 接口没回来 ↓ Render 慢 ↓ 图片解码慢 ↓ 字体阻塞 ↓ 代码报错13. 怎么系统定位第一层Network看资源瀑布DNS ↓ TCP ↓ TLS ↓ Request ↓ TTFB ↓ Download可以用 Resource Timingconstresourcesperformance.getEntriesByType(resource);console.log(resources);重点关注DNS 连接建立 TTFB 下载时间 资源之间是否存在瀑布依赖第二层Performance重点看Main Thread ↓ Long Task ↓ JS 执行 ↓ Layout ↓ Paint ↓ Frames例如JS执行 500ms ████████████████████████ 浏览器没机会及时渲染 ↓ 用户看到白屏这时候继续压 CDN 基本没用了。14. JS 长任务怎么优化比如constresulthugeCalculation(data);render(result);如果hugeCalculation()跑了 500ms主线程 ████████████████████ 500ms 浏览器没法及时处理渲染可以考虑拆任务setTimeout((){doPart1();},0);或者requestIdleCallback((){doNonCriticalWork();});CPU 密集型计算放Web Worker例如constworkernewWorker(/worker.js);worker.postMessage(data);worker.onmessage(event){render(event.data);};核心就是首屏阶段主线程只做必须做的事情非关键计算能晚就晚CPU 密集型计算能丢 Worker 就丢 Worker。15. 接口瀑布也是常见白屏原因比如HTML ↓ JS下载 ↓ JS执行 ↓ 请求接口 ↓ 接口返回 ↓ React渲染 ↓ 首屏出现这里接口请求启动得太晚。如果是首屏真正需要的数据可以尽量提前HTML ↓ 尽早发现并发起接口请求 ↓ JS下载 ↓ JS执行 ↓ 接口已经在路上更进一步可以使用SSR直接把首屏需要的 HTML 内容返回给浏览器。16. SSR 为什么能改善白屏传统 CSRHTML ↓ 下载 JS ↓ 执行 JS ↓ 请求接口 ↓ 拿数据 ↓ 渲染 ↓ 用户看到内容SSR服务端 ↓ 获取数据 ↓ 生成 HTML ↓ 浏览器收到 HTML ↓ 直接看到内容 ↓ 再 Hydration所以 SSR 的核心优势之一就是把原来必须等客户端 JS 执行才能出现的内容提前变成 HTML 返回。但 SSR 不是万能的。如果服务端本身慢查询 接口瀑布 模板渲染慢一样会导致首屏慢。17. 图片也可能卡住首屏尤其是大图下载 ↓ 解码 ↓ Layout / Paint所以除了imgsrc/hero.webpdecodingasync还应该从根上解决原图 5MB ↓ 压缩 ↓ WebP / AVIF ↓ 合适尺寸 ↓ 响应式图片例如imgsrc/hero-800.webpsrcset/hero-800.webp 800w, /hero-1600.webp 1600wsizes100vwalt18. 字体为什么会导致首屏问题如果首屏文字依赖自定义字体HTML ↓ 发现字体 ↓ 下载字体 ↓ 字体加载/应用 ↓ 文字最终显示字体过大可能造成文字显示延迟甚至产生布局变化。常见方案font-face{font-family:AppFont;src:url(/app.woff2)format(woff2);font-display:swap;}再配合字体子集化 ↓ 只保留首屏需要的字符 ↓ 减少字体体积19. 骨架屏到底解决什么骨架屏解决的不是真实加载速度而是用户感知例如接口还没回来 ┌──────────────┐ │ ████████████ │ │ ██████ │ │ ██████████ │ └──────────────┘用户看到的是页面已经“有东西”而不是一片白所以骨架屏属于感知性能优化不能替代真正的网络、执行和渲染优化。20. 最终应该怎么做成一套优化方案可以按照这个顺序排查首屏白屏 │ ┌───────────┼───────────┐ ↓ ↓ ↓ 网络 执行 渲染 │ │ │ TTFB/下载 JS长任务 Layout/Paint │ │ │ CDN/缓存/压缩 拆任务/Worker 图片/字体 │ │ │ └───────────┼───────────┘ ↓ 关键渲染路径 ↓ ┌─────────┴─────────┐ ↓ ↓ 减少关键资源 提高关键资源优先级 ↓ ↓ Critical CSS Preconnect defer/module Preload SSR fetchpriority ↓ ↓ 首屏首帧更早出现21. 面试官追问链追问 1关键渲染路径到底关键在哪因为它就是浏览器从拿到 HTML 到真正画出第一帧的必经过程里面任何一个关键环节变慢都会直接推迟首屏。追问 2CSS 为什么会阻塞渲染因为浏览器需要 CSSOM 来确定页面怎么画关键 CSS 没准备好就不能按最终样式正常渲染。追问 3JS 为什么会阻塞 HTML 解析因为同步 JS 可能修改 DOM所以浏览器遇到它时不能继续放心解析后面的 HTML。追问 4defer和普通 script 最大区别defer让 JS 下载和 HTML 解析并行等 DOM 解析完成后再执行。追问 5async呢async也是并行下载但下载完成就执行可能打断 HTML 解析而且多个脚本不保证执行顺序所以更适合互相独立的脚本。追问 6为什么不能全部 preload因为 preload 会提前抢带宽太多关键资源互相竞争反而可能拖慢真正重要的资源。追问 7Preload 和 Prefetch 区别Preload 是当前页面马上要用Prefetch 是为未来可能用的资源提前准备。追问 8Preconnect 做了什么提前建立关键跨域连接把 DNS、TCP、TLS 这些连接成本前置。追问 9fetchpriorityhigh和 preload 一样吗不一样。Preload 是让资源更早被发现并开始加载fetchpriority 是调整资源在加载过程中的优先级两者可以配合但不是一回事。追问 10Preload 了 LCP 图片为什么还是慢先看是不是 preload 太多导致抢带宽再检查 URL、as、缓存复用和图片体积Preload 只能让它更早下载不能解决图片本身太大。追问 11资源都下载完了还是白屏怎么办这时候转向运行时排查看 JS 长任务、接口瀑布、渲染耗时、图片解码、字体和运行时错误。追问 12怎么判断是不是 JS 长任务用 Performance 看 Main Thread如果首屏阶段存在明显 Long Task就说明主线程被 JS 长时间占住了。追问 13JS 长任务怎么解决首屏只执行必要逻辑非关键任务拆开延后CPU 密集型计算可以放 Web Worker。追问 14接口瀑布怎么解决核心是让首屏接口尽早发起避免等 JS 层层执行完才开始请求条件允许可以通过 SSR 直接把首屏数据变成 HTML。追问 15怎么证明优化真的有效不能只看 Lighthouse 分数要结合真实用户的 FCP、LCP、INP 等指标看 P75 等分位数优化前后的变化。最终背诵版首屏白屏的核心不是简单压缩资源而是首屏真正需要的内容被关键路径上的网络、解析、执行或渲染环节卡住了。优化就是缩短关键渲染路径同时把有限的带宽和主线程时间优先给首屏内容。具体上关键 CSS 尽量内联非关键 CSS 延后关键 JS 用defer或模块脚本避免阻塞 HTML 解析资源优先级上用preconnect、preload、prefetch和fetchpriority分层不能什么都抢高优先级。如果资源已经下载完还白屏就继续查运行时用 Performance 看 JS 长任务和渲染用 Resource Timing 看网络用 RUM 看真实用户的 FCP、LCP、INP针对接口瀑布、JS 执行、图片解码、字体等具体瓶颈优化。