我终于理解了什么是静态站点

使用客户端渲染，做 openflomo

刚接触 AI Coding 的时候，我想把 flomo 笔记做一个公开版，在 Claude 的操作下，动作是这样的：

1. 下载源笔记，flomo 官方提供的是 html 版

从仅公开的角度，将这个版本直接作为静态页面托管起来就可以。但我非得作死，要重构一下，改为与 flomo 主页类似的页面。

2. 雕花

这里面的区别在于：1. 笔记卡片种的「标签」，不支持高亮 + 筛选；2. 缺少左侧的标签列表。

一番折腾后，他长下面这样。我开心的不得了，立马丢到了 Github Page。

3. 问题，加载速度慢

我共有 2k + 笔记数量，html 源文件大概 700 kb，js 和 css 文件都有 600 多行。当打开页面时，运行过程是这样的：

1. 先加载 index，这时候引入源文件、js，按需引入 css
2. 根据 js 的的逻辑循环处理源文件，包含标签识别、格式化、列表页、url 等特征的格式化
3. 引入 css 渲染完毕

因为我不懂代码，一直盯着 LCP 的性能优化截图丢给 Claude 让他搞，上了很多招也有了改善。但我的直觉告诉我，这样的方法怪怪的。

看到了 HackerNews 和 Buzz

我刚刚开始刷 HackerNews，很纳闷为什么他的界面这么落后。一番考究后发现，他的用户们认为：

• 仅有必要的 html+css，几乎没有 js，这样就算网络极差也可以访问
• 高信息密度
• 无大量 css 的干扰元素，容易沉浸

然后我刷到了 owen 的重构 buzz 的文章，https://www.owenyoung.com/blog/new-buzzing ，我才意识到，针对上述 openflomo 的场景，应该通过服务端渲染、构建静态站点，再通过 GithubPage 托管静态站点。

客户端渲染及服务端渲染

最基础的网页可以只有一个 html 文件，css 给了样式，js 给了逻辑。如果没有 js，他本就是一个完整的页面。

但更常见的情况，已有的数据资源到网页结构中间，还需要一个过程。比如 blog 页面，我使用 md 写了文章，需要通过一系列脚本将 md 格式转换为 html ，才能够成为一个网页。

这个过程就是「Build」构建。

那么托管这个网站，最常见的就有 3 个构建时机：

1. 本地 Build，然后将编译后的文件托管
2. 托管资源文件时 Build，仅在服务端构建一次，客户端访问时获取的就是编译后的文件
3. 客户端拉取所有资源文件，临时进行 Build，这时候必然会导致加载及渲染的速度较慢

使用 Astro 重构

在 Cursor 的操作下，我使用 Astro 重构了项目。现在的流程是这样的：

1. 引入新的 flomo 笔记资源
2. 提交并推送代码，服务端运行 Build 脚本，处理标签、列表、样式等问题，生成最终的静态站点资源
3. 客户端访问，直接拉取静态站点

看到这个加载项时，第一次感受到合作过开发同事们，写出漂亮代码的兴奋感。