L.Plog.v1 超出预期的浏览体验

2 天前 · 昆明

· Picture by ChatGPT· Picture by ChatGPT

断断续续忙乎了两周,个性化图志系统 L.Plog 已完成后端和后台的制作,前端的功能部分也在昨日成型,只剩样式。

这两天,用了好几年的虚拟主机到期,遂对博客做了迁移,考虑到之后会使用 L.Plog 替换 Typecho 系统,顺便也对数据做了重建。由于 L.Plog 使用了独立的数据存储方式,不依赖数据库,所以,需要将博客现有的 Typecho 数据,重新构建为符合格式要求的数据文件,这是一个不断烧脑,不停抓狂的过程,折腾了一天,总算是分毫不差、准确无误的导出了所有所需数据。

比如,将 contents.text![描述][标记] + [标记]: 链接 替换为 ![描述](链接) 标准图像格式,且图像文件名需要重新编码,同时,文件夹 uploads 内对应的图像文件名也需要更名为相同的编码后的文件名。

比如,每张图像需要获取所在文章的标签,存储到记录着每张图像元数据的文件中,因为,在 L.Plog 中,需要使用这些特征标签进行管理,让图像具有通用性,可以便捷的在不同场景中复用,不再局限于某篇文章中。

L.Plog 的不少功能使用了一些可以提升性能的方案,在测试中,竟也是惊喜连连。

比如,前端加载数据时,参考了轮播方式,在浏览当前内容时,会在浏览器空闲时,预加载下一项内容,包括文本包括图像,且做了缓存,那么,在切换到下一项内容时,或者返回上一项内容时,平滑的程度可以说是毫秒级的,甚至是无感的。

另外,在预加载临近项的图像,当数量较多时,如果一次性加载,会适得其反,需要做限制:只加载适当数量的图像,确保切换后,首屏的图像是处于加载完成的状态,直接显示,内容中之后的图像沿用延迟加载逻辑。

比如,后台三千多张图像,在不使用分页的情况下,DOM 节点数量多的吓人,页面更是卡得不行,在使用虚拟滚动,搭配图像延迟加载,还有自动生成缩略图后,也能流畅浏览。

L.Plog 将不会迎合搜索引擎的规范而添加对自己来说是冗余的功能,也会对博客做调整,回归「写而为己」的初始状态。

  1. 想起各种相册系统的感觉了。

    1. @acevs

      这么一说,以前有一款 Flash 网页相册程序也是很酷炫。

  2. 你这个是完全重构了一个博客系统啊

    1. @老何

      尝试做个简单的后台内容管理加前台单页应用。

16 金沙江白鹤滩右岸挂壁小道
1677967200
金沙江白鹤滩右岸挂壁小道
2 云南潞江小粒咖啡
1458295200
云南潞江小粒咖啡
37,立秋
1565226000
37,立秋
2 今日放映
1578790800
今日放映
9 一季山河:四川篇(下)
1637370000
一季山河:四川篇(下)
有声:7466次的乡亲们
1726966800
有声:7466次的乡亲们
44,小寒
1767585600
44,小寒