Reading Notes
把玻璃拟态博客打磨到可长期阅读:速度、结构与体验实战
这是一篇完整的示例长文,用来验证目录、图文混排、代码块、表格、任务清单与长文阅读体验。
2024年03月25日
14 min
话题animationnextjstypescript
把玻璃拟态博客打磨到可长期阅读
当一个博客从“能看”走向“耐读”,真正起作用的往往不是一两个炫目的动效,而是加载反馈、结构层级、滚动节奏与信息密度的整体配合。
为什么先做性能,再做观感
很多站点的问题不是没有设计,而是设计与响应速度脱节。用户点击后两秒没有反馈,再精致的玻璃卡片也会失去说服力。
阅读体验从来不只是排版问题,它首先是“能不能无阻力到达内容”的问题。
本次优化关注的三个层面
- 页面切换要有即时反馈
- 列表页只传必要数据
- 详情页把正文放在最优先级
结构设计:像正常博客一样组织阅读
一个成熟的文章页通常至少包含这些区域:
| 区域 | 作用 | 必要性 |
|---|---|---|
| 标题区 | 建立内容预期 | 高 |
| 摘要 | 快速理解文章价值 | 高 |
| TOC | 长文导航 | 中高 |
| 正文主列 | 真正的阅读区 | 最高 |
| 上一篇/下一篇 | 阅读延续 | 中 |
推荐的阅读区宽度
正文最好控制在 65ch ~ 72ch 之间。
太宽会让用户一行读太久,太窄会让页面显得拥挤。
不要把所有信息都塞进正文上方
下面这些信息建议保留但压低噪声:
- 发布时间
- 阅读时长
- 标签
- 返回列表入口
一个简单的任务清单示例
- 给文章页增加阅读进度条
- 给 H2/H3 自动生成目录
- 给代码块增加复制按钮
- 为移动端补一个简化 TOC 入口
内容渲染:同时兼容 Markdown 与 HTML
如果历史文章已经是 Markdown,而新的文章编辑器输出 HTML,那么渲染链路要允许两者并存。
推荐策略
- 检测内容是否包含明显 HTML 标签
- 若包含 HTML,则按 HTML 渲染
- 否则走 Markdown 渲染
- 两条链路都要统一 heading id 与 TOC 提取逻辑
伪代码
ts
function renderContent(input: string) {
if (looksLikeHtml(input)) {
return renderHtml(input);
}
return renderMarkdown(input);
}一个简单的缓存封装
ts
import { cache } from 'react';
export const getPostBySlug = cache(async (slug: string) => {
return db.post.findUnique({ where: { slug } });
});