这个页面（碎碎念）原本想用 Astro 新搞的 Server Islands 做的，但是后来发现效果不好，所以推倒重做成了传统 SSR + CDN 缓存。

本页面的特点主要有两个：需要从非常非常慢的 Notion API 加载数据，以及所有人看到的内容都是相同的。下面简单总结一下在这个 Use Case 里 Server Islands 的好坏之处：

好处：

• 有很好的 Fallback，用户进来可以看到一个漂亮的 Skeleton，然后慢慢加载出内容；这种效果在传统上（不引入新的库的话）如果不自己写客户端 JS 是做不到的，而 Server Islands 相当于帮你写好了这些；
• 非常快的首次访问，即使服务端没有 Cache，首屏加载也非常快——因为 Notion API 请求这些都是等客户端接收到首个 HTML 之后才开始的。

坏处：

• 难以缓存：Server Islands 的请求都是 POST 请求，一般无法被 CDN 缓存，所以不做骚操作的话是每个用户访问都得加载一次，且不说每个人都要等很久才能看到真正的内容，Notion API 的 Rate Limit 也撑不住；后来我自己加了一个 GET 中间层，让服务端自己请求自己来让 CDN 缓存一些东西，但是这样依旧每个人访问都要跑一遍服务端渲染，只是省下了访问 Notion API 的时间；
• 成本高：其实是上一点的副作用，每个人都要跑服务器渲染，Serverless Function 的免费配额感觉会不够用……
• 很大的布局偏移：一开始的 Skeleton 大小不可能和 Note 大小一样，这样布局偏移直接上天了

总结来看，我不适合用 Server Islands 的主要原因就是因为所有人访问的页面内容都是相同的，不需要“定制”，所以传统的服务端渲染 + CDN 缓存就够了，而这样传统方案的坏处就是第一次访问（没 Cache）的时候，会慢到爆炸（至少 5 - 6 秒）才能出结果，虽然 Astro 对于异步组件可以流式传输 HTML 不至于真的白屏那么久，但是也是很让人抓狂的，而解决方法也就只能是吧 Cache 的 s-maxage 和 stale-while-revalidate 设置的大一点了，代价是 Notion 中的内容需要很久才能同步过去。

不知不觉写了这么多，说不定之后会加上我使用 Server Islands 的感受写一篇文章吧，感觉应该是个还不错的话题