hsxfjames
TTFB 也是我目前最蛋疼的地方了，这里的 HTML 全是 PHP 生成的，用的是重型框架 laravel 魔改出来的后台，类似一种 PHP 和 JS 混合的产物。PHP 内部处理差不多 150ms 的内耗，然后辣鸡网络一个请求 大陆→HK→广州→HK→大陆 两次穿墙差不多需要 100ms。
这里原本也有点服务端吐 App Shell 然后前端调接口渲染的机制。作者为了减少一个请求，第一屏的实现是，在 PHP 内部调用帖子数据接口的控制器拿到数据，然后用 json_encode(类似JSON.stringify) 硬编码到 script 标签里面。然后前端再解析这个JSON，渲染出具体的 DOM 节点。也就导致页面整体大小差不多 200KB，gzip 之后也有 30KB...
拿掉了这部分 JSON 输出之后首屏的 HTML 输出降低到了 30KB，gzip 之后 7KB 左右，代价是网页加载完成后得多请求一次接口才能获取到帖子。
然后是 SSR 的可行性。刚刚试了下直接保存渲染好的首页，HTML 部分 100KB左右，gzip 以后刚好是你说的神奇数字14KB。但需要渲染的不仅仅是帖子列表，还有标签节点之类的东西，这些在 Flarum 目前是完全靠前端实现的，前端用的 Mithril.js 这方面支持看起来不太完善，改造的话还扯到PHP的模板和各种插件扩展之类的东西，难度估计非常高。
所以现在觉得还是尽可能减少 HTML 部分首次加载的体积，让它能作为整个 SPA 应用的 App Shell，后台尽可能直接输出，前端用 service worker 缓存起来，整个 SPA 启动起来之后再另外调这个耗时有点长的接口来请求，白屏的时间也短一些🤪
