只考虑两个问题
1 、明显，如果服务器端解析，如果服务器性能不行会有延迟（并发情况下会明显不过一般遇不到），客户端解析，则是看客户端性能。
2 、如果你打算写一套内容系统，可能存数据库会好点（推荐 sqlite 主要好迁移），如果只是单纯的博客，写文件会好点，以后想从动态改静态也可以直接用。

核心，还是你想用 php 实现什么功能，说到底无论是静态生成博客还是动态的 php 博客都有很多成熟的解决方案。
真的想折腾，静态资源上 CDN ，打开速度会快不少。

附上，我的博客 https://saltfish.vip/ 。
最开始使用的 Hexo 部署在 github Page 上。
后面自己用 Nodejs 进行了一些改造 ，买的服务器配置也和你的差不多，5mb 的带宽，不过我备案了。
其中也做了你现在想做的部分，编辑器,pjax ，文件预览，在线热更，预渲染，动态渲染（存数据库和文件也试过），live2d 之类的小插件。
然后服务器到期了，换了现在用的 Typecho ，部署在自己家里的迷你主机里，通过通道服务解析域名。
结论就是，如果只是想写博客，现成的方案会好一些。如果想顺便学点东西，什么想法都试下，会比较直观。

@Cesign
有时间我会关注一下..不过我对 Python 不是很熟悉，准备先进行研究。
话说，我刚看了一眼开发文档..
为什么不考虑在开发模式的镜像中直接挂载代码？
就是做镜像的时候不复制代码，做完时候把路径挂进去..
这样容器内代码是实时的，再配合 watchdog 就可以方便热更新了。
嘛，也是提升开发体验的小点，这块我可能可以先弄弄

@cesign
昨天装了个试了下，今天简单的看了下结构，的确是挺有意思的，我简单提提我的想法，你可以感受下有没有必要。
感觉上 kubespider 做了链接解析和调度。
下载部分虽是单独的模块，但为了便于使用和简单部署，实际最好是部署在同一台机子上。

有兴趣其实可以拆成两部分，解析的部分，也就是现在的“本体”，解析的结果不是直接去调下载模块，而是搞个消息队列（比如用 sqlite 模拟一个），下载模块通过消息队列与“本体”通信，根据类型去消费。
在这个模式下，下载模块可以不需要对外暴露端口（ pt 下载的另算）

单机模式下，这样的好处是便于控制，有的时候希望把下载的内容先加进去，晚些时候再下，也能比较容易的做下载记录的展示，可以减少暴露的端口（收缩关注的点）。

同时提供了多机的可能，本体可以做为注册中心，下载可以分在别的机子上，有需要的话也能做同步功能，增加应用场景。

坏处则是会增加不少复杂度，最后还是看有没有必要吧，这种架构层面的变更往往吃力不讨好。

现在在用 obsidian 学习成本其实不高，我之前也捣鼓过很多笔记软件，相对来说，更喜欢 obsidian

推荐，电子琴或者当钢琴弹，不怎么扰民，实在不行可以带耳机，而且打代码的情况下，手指一般都灵活
性质上可能和电吉他类似，但电吉他没有音箱的话效果差很多
尤克里里感觉..看风格吧
能做的事情，相对前两者会少些

看起来挺有意思的，先装起来试试。
看了下，解析和下载应该是分开的吧？
能否支持类似，先把解析的东西存起来，等下载的电脑开起来了，再推送下载类似这样的功能？
就是，解析，下载，以及 Jellyfin 之类的，不在同一台电脑下这样的场景？能否通过某种方式组织起来？

很难说有什么感想，建议 OP 换位思考，如果你是你父亲，你儿子这么想会是什么感受。
至于，房和车，货车耶，生产力工具，买房也可以看作，不想拖累子女，没直接找来要钱，其实已经不错了。

读了好几遍也没弄明白这个场景为啥要用 base64..用 oss 上 cdn 吧，不行的话，前端手动实现一个缓存？感觉好像也没啥用..后端，把 base64 写成文件，提供 url 让前端用，作用估计也有限..主要不知道这里的，吃不消体现在哪里，页面卡？还是接口返回慢？ 4mb 说大不大，页面我觉得很少会因为这个卡的..

个人感觉，锻炼好身体，技术上个人感觉很难说跳出场景有个什么样的提高，找自己的喜欢的方向做储备，没有就是英语数学，且苟且看

J1900 的性能太差了，性价比也不高，买个稍微好点的工控主机吧（笔记本低压 U 的那种，600 ～ 1000 块），我和你有同样的需求，之前研究过一下，一言以蔽之，免费的话还是用 CloudFlared Tunnel 吧，自己租房子，动态解析啥的太麻烦了。
可以参考下我之前记得，我这个博客就是跑在工控机上用 Tunnel 服务代理出来的。

https://saltfish.vip/index.php/archives/34/

只有当知识能够帮助你做实际决策的时候，它才是你的知识。

其实还是个视角问题，看看偏远山区，高考这种分地域来竞争的几乎是他们离开所处环境最好的路径了，你让他们和教育发达的地方做完全平等的竞争，不可能在一个数量级上。但是你能说他们能力差么？只是没有对应的资源罢了，河北高考这么卷的一个方面也是侧面反映该地的教育资源，在当前这种模式下非常发达，好不好两说，公平不公平，大抵还是公平的，因为你竞争的对象和你处于同一环境下

@Citrus 有没有可能是系统自动更新？我有遇到类似的情在笔记本上，自己装了个 m2 固态散热不行，如果系统自动更新涉及到大量 I/o 就会出现这种类型的卡顿，一般也就几秒，没啥规律，随时偶发，发生的时候如果正好有任务管理器开着，可以看到 windwos 自动更新占了大量的硬盘读写或者 cpu

我在想固态的坏道是个什么概念...

随着年龄增长，这些下降是不可避免的，过几年会更明显，感兴趣是一方面，用不用的上是另一方面。
我想想一年左右，主要做修补工作，想通过跳槽涨薪的话。
自己从脚手架开始构建一个项目吧，vue 也行，react 也行，最不济也得知道从头开始大概是怎么一回事（参考成熟框架）。
可以尝试复刻自己正在修补的项目的主要部分，或者平时接触不到的非业务的部分（如果是后台，比如登录，鉴权，一些复杂的业务模块，或者绘图组件之类的），这是一个方向。
另一个方向则是，总结自己手中项目的业务流程，以及前端在其中的位置，有什么亮点（技术上的，业务上的与前端相关的）。
最后就是一些面试题准备吧，根据上面的方向，选一块深入，也可以参考看别人怎么做的。

一个可视区内为例，3000 张一个可视区，用 base64 大概是，先等所有图片下载完再展示（我就当你是嵌在 html 里了）
相对路径则是先展示轮廓再展示，浏览器并发，不同浏览器不一样通常是 6 ～ 8 个，所以 3000 张同屏怎么也会有先后顺序
你要全部加载完哪个更快？主要看设备，通常来说，一个大文件会比 3000 个小文件快，取决于大小差异和实际使用的 http 协议，用 http3.0 的话，小文件估计会快一点，1.0 大文件会快一点。
个人建议，用相对路径，需要一次性展示的话自己控制图片的加载完再展示，而不是使用 base64 这样完全不可控。
一个可视区放不下的情况，比如滚动加载，就别 base64 了，没啥意义。