Sukka 写前端、网络和基础设施时，习惯先把边界和代价摊开。把「再快一点，再快一点 —— 优化博客白屏时间的实践 | Sukka's Blog」整理成可落地的中文笔记：问题在哪、默认做法会踩什么坑、该怎么选。原站导航和广告已去掉。

确定和分析白屏时间

First Paint 和 First Contentful Paint 是衡量白屏时间的重要指标。Google Chrome 团队提供了专门的库 web-vitals 用于在浏览器中衡量这些指标。直接在本地开发环境中引入该库：

< script type = " module " > import { getFCP , getLCP , getFID } from 'https://unpkg.com/web-vitals@0.2.4/dist/web-vitals.es5.min.js?module' ; // 获取 First Contentful Paint getFCP ( ( { name , value } ) => console . log ( name , value ) ) ; // 获取 Largest Contentful Paint getLCP ( ( { name , value } ) => console . log ( name , value ) ) ; // 获取 First Input Delay getFID ( ( { name , value } ) => console . log ( name , value ) ) ; </ script > 访问在本地运行的 Hexo Ser

分析性能瓶颈

进行性能测试时，模拟移动端的网络和性能是非常重要的。然而，Firefox 的 Dev Tools 至今很遗憾地没有实现这个功能（许多类似的 Feature Request 在 Bugzilla 已经 stall 数个月了）。这也是为什么我钟情于使用 Chromium Based 的浏览器开发的原因。

FCP 1537.4400000000605 LCP 1921.934 FID 3.559999997378327 可以看到，First Contentful Paint 时间在 1.5 秒左右、而 Largest Contentful Paint（最大的可视元素，此时是文章的头图）是 1.9 秒。考虑到这是在本地环境、TTFB 只受模拟的「Fast 3G」限制，不难想象在实际访客体验中白屏时间绝对不止 1.5 秒。

优化白屏时间

肯定了问题的确存在，接下来就需要寻找性能瓶颈了。在「Performance」Tab 中将 CPU 性能修改为「6x slowdown」放大性能瓶颈，然后用「Start profiling and reload page」按钮刷新页面和获取火焰图：

其中，Layout 占据的时间（117.43ms）比 Parse HTML（22.48ms）和 Recalculate Style（20.37ms）都要长得多，基本可以认定这就是性能瓶颈了。接下来判断是页面什么元素导致了 Layout 的性能瓶颈。对博客中其它页面进行 Profiling，并将火焰图进行对比：

尝试新属性

从左往右分别是 「 我就感觉到快 —— zsh 和 oh my zsh 冷启动速度优化 」、首页、「 Hello World 」页面的火焰图和 Layout 用时。

根据火焰图和三个页面的特征，猜测是文章内容部分导致了 Layout 用时过长。为了加以验证，在 CSS 中使用 display: none 将文章内容直接从 DOM 中离线，然后重新生成火焰图。

落地时建议先做的 5 件事

1. 用自己的流量和设备测，不要只抄厂商推荐最小配置。
2. DNS、CDN、代理分流先画清 Fake IP 和 Real IP 的边界。
3. 前端性能看 CLS、白屏和重复渲染，而不是只看打包体积。
4. 基础设施变更走 Git，能复现、能回滚。
5. 结论写成可检查的清单：接口、超时、失败样本、回滚版本。

和智能体产品怎么接

龙虾PRO做 OpenClaw 落地时，网络、DNS 和前端性能笔记最有用的是「边界」：哪一层该加速、哪一层不该假装智能。数字员工调用外部能力前，先把超时和失败路径写死。

本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源