首屏加载慢90%可借Network面板定位，关键看document请求中DOMContentLoaded与FCP间隔＞300ms即存在CSS/JS阻塞；@import会隐式拖慢300–800ms；file://协议禁用preload等优化，须用本地服务器验证；真机调试不可替代模拟器。
首屏加载慢，90%的问题能靠 Network 面板直接定位，不用猜、不靠经验——关键在看 waterfall 里 document 请求的两个时间点：DOMContentLoaded 和 First Contentful Paint（FCP）的间隔。
怎么看阻塞点在哪？
打开 Chrome DevTools → Network → 刷新页面 → 找到 index.html 这一行。鼠标悬停或点击它，看 Timing 标签页里的两个关键时间：
-
DOMContentLoaded：HTML 解析完、DOM 构建完成的时间 -
First Contentful Paint (FCP)：第一块文字/图片真正渲染出来的时间
如果两者间隔 > 300ms，说明 CSS 或 JS 在阻塞渲染；如果 FCP 比 index.html 的 Finish 时间还晚很多，大概率是首屏 CSS 或 JS 下载/执行太慢。
注意：@import 引入的 CSS 不会单独出现在 Network 列表里，它藏在父 CSS 文件的请求链中，容易被忽略——但实测会多拖 300–800ms。
为什么本地双击打开 HTML 总是慢得离谱？
这不是代码问题，是协议限制：file:// 协议下，浏览器禁用大部分优化机制，比如：
- 不支持
preload、preconnect、loading="eager" - 不触发 gzip/Brotli 压缩（即使服务端配了也没用）
- 某些 CSSOM 构建行为异常，导致 FCP 偏高
必须用本地服务器跑：npx serve、python3 -m http.server 8000 或 Vite/HMR 启动的 dev server。否则所有优化都白搭。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
抓包时最容易误判的三个资源类型
Network 面板里常被当成“已加载完成”的资源，其实根本没生效：
-
：没加crossorigin属性 → 字体不应用，但状态显示 200，容易漏掉 -
-
：如果onload回调没执行（比如 JS 错误或被拦截），样式永远不会生效，Network 显示 200 但页面无样式
验证是否真生效，不能只看 status，要结合 Elements 面板检查 computed styles，或用 Coverage 面板看 CSS 实际使用率。
真机调试时 Network 面板为啥不准？
DevTools 的 Device Mode 是模拟 viewport 和 UA 字符串，但不模拟真实网络栈和渲染引擎。尤其在 iOS 上：
- Safari 真机必须开启「设置 → Safari → 高级 → Web Inspector」并信任开发机证书
- 安卓 WebView 若未启用远程调试，
loading="lazy"可能静默失效，Network 里连请求都不发 - 3G/4G 真实弱网下，
defer脚本的下载时机和执行顺序可能和桌面 Chrome 完全不同
结论：本地 Network 看出问题 ≠ 真机复现，真机看不到 Network 链路 ≠ 没问题——必须用真机 + Web Inspector 抓一次完整 waterfall。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
