最近重新整理个人网站时,我给自己定了一个很小的目标:打开一篇文章之后,读者应当可以直接开始阅读,而不是先等待页面准备好。
这听起来理所当然,但我们很容易把“功能已经能用”误认为“体验已经完成”。导航能点、图片能显示、动画能播放,并不意味着页面适合阅读。
先观察,再动手
我通常先打开浏览器的网络面板,模拟较慢的网络,然后刷新页面。此时不要急着关注某个分数,而是观察:标题何时出现?正文出现后是否跳动?必须等哪些请求完成,读者才能开始读?
这些观察会把抽象的“网站有点慢”,变成具体的问题。
| 观察到的现象 | 可能的原因 | 第一步尝试 |
|---|---|---|
| 标题迟迟不出现 | 字体或脚本阻塞 | 使用系统字体,减少首屏脚本 |
| 图片加载后正文下移 | 没有预留尺寸 | 明确图片宽高 |
| 点击后没有反馈 | 客户端工作过重 | 减少不必要的交互代码 |
让静态内容保持简单
对于博客,标题、日期和正文在发布时就已经确定。把这些工作放在构建阶段,通常比每次访问时重新计算更合适。

export default function PostsPage() {
const posts = getPublishedPosts();
return (
<ul>
{posts.map((post) => (
<li key={post.slug}>{post.title}</li>
))}
</ul>
);
}这段示意代码的重点是:文章数据在服务端读取。浏览器只需要接收已经生成好的内容,无须为了展示一个标题再发起一次数据请求。
图片也是布局的一部分
给图片设置宽高,不只是为了优化某个指标。它告诉浏览器提前留下多少空间,也让正在阅读的人不会突然丢失位置。
如果图片不在首屏,就让它延迟加载;如果只是装饰,则先判断它是否真的值得存在。删除一张没有信息价值的图片,往往比寻找更复杂的压缩参数更有效。
优化的终点是读者
我会保留一份优化前的记录,再在同样的网络和设备条件下重复测试。只改变一个因素,才更容易知道是哪一步带来了改善。
下一次感觉页面迟缓时,可以先问一个具体的问题:为了让这段文字出现,我们究竟要求浏览器做了多少事?
—— Xavier,写于
谢谢你读到这里。
文章评论
给想法留一个回声。
正在读取留言…