某次修改 blog 模板的时候,看到了 jsDelivr 下发的一段 CSS ,当时以为是个本地的文件,但遍寻不见。遂请教大佬,得知了 jsDelivr 这个东西。搜索了一波,发现使用 GitHub + jsDelivr 来做个资源分发极好。
理想图床?
看了一圈,发现这个方案用来做一波图床也是极稳的,一方面所有图片都来自自己的 GitHub 库,一方面引用也不用担心失效。 其实也为了加快 blog 的访问速度,避免所有资源都从同一个地方获取
repo 的建立
考虑到 blog 中使用的文件无非是图片和 CSS/JS ,于是顺手新建了一个项目,三种文件分开。图片另外分作封面和文章中的图,而文章中的图片取其 MD5 作为其名称。 这样就避免了名称重复
1 | ├─css |
文章中的应用
在使用这个方案之前,我在文章中插入图片的做法是将图片先转换成 base64 的编码,然后在 Markdown 中作为一个注释插入,然后在文中引用。好处是文章就是完全整体,不管怎么移动位置,图片始终完好。缺点就是一长串的编码扰乱了字数统计系统,给各种维护带来不便。再者,写文章的体验也受到了影响。
jsDelivr 的操作
资源引用
根据 jsDelivr 的规则,对于 repo 的 release ,可以这样访问其中资源,但是对资源有大小限制
1 | https://cdn.jsdelivr.net/gh/{GitHub用户名}/{repo名}@{release版本号}/{repo中的文件路径}/{文件名} |
特别地,可以不指定 {release版本号}
来保持最新。官方不建议用于实际上线的项目中。 实测忽略版本号可能会在短期之内引用上一个版本的同名资源(也就是没有更新的样子) 不过指定一个版本号的范围也是没有问题的,譬如 1.5.x 都可以写作 1.5 。此外,也可以通过 commit 序号来获取资源,只需要将 {release版本号}
改成 {commit序号}
即可。
还有一个我挺喜欢的功能,在 CSS/JS 文件拓展名的后面加上 .min
就能自动生成一个该源文件的压缩版本。
1 | /*ORIGINAL*/ |
1 | /*PROCESSED*/ |
统计信息
jsDelivr 很贴心地给了一个资源引用的统计页面,具体到了每一个资源的次数。通过以下地址可以具体查看。
1 | https://www.jsdelivr.com/package/gh/{GitHub用户名}/{repo名} |
这里附上我的 repo 资源访问总数