现在病毒肆虐,政府号召大家呆在家里不要出门。特殊时期就该特殊对待,就算口罩成为有钱也买不到的稀缺品,日子还是要继续过下去。但一直宅在家里,屁股都坐麻了,看剧玩游戏也不是办法(老妈不让)。所以我把博客翻了个底朝天,顺便学习Z酱,写一篇网站日志。Weekly太短,就叫Mikusa Yearly Issue吧!(一年能有一篇日志已经是极限了!)

图片压缩

图片一直是本站的重点关注对象。除了大量与文章无关的封面图片外,还有不少文章插图。

首页
首页

起先为了给读者带来清晰的视觉体验,本站所有图片均无压缩原图显示。我一直对此沾沾自喜,虽然超大的图片拖累了网站加载速度。

可坏处说来就来。原本「又拍云」可以自动压缩,适时输出WebP格式的图片。可最近访问量越来越大,CDN 流量也越来越大,眼瞅着就快承担不起了。

又拍云账单
又拍云账单

与其等着被榨干钱包,不如我自己了断。我决定压缩图片,放弃又拍云,转战腾讯云。我制定了「图片压缩&迁移」计划,每张图片都经过我亲手压缩,保证质量的同时,顺便处理掉一些多余的图片。手动整理大概花了我一周时间。

图片压缩计划
图片压缩计划

但文章实在是多,我又顺便删掉了部分水文。

更换图片存储商

「CDN 流量」和 「HTTPS 请求数」是又拍云计费里的大头,于是我的代金券早早的就用光了。好在腾讯云还有免费的对象存储,免费的 10G CDN流量,不用白不用。而且对象存储客户端 COSBrowser 还挺好用。

COSBrowser
COSBrowser

于是我删光了又拍云上的图片,全部存到腾讯云。

WebP 改造

整理过程中,我发现一个问题:

压缩不动的图片怎么办?

有些图片牺牲质量才能减少体积,否则就纹丝不动。我想过把pngjpg格式的图片全部压缩成WebP格式,不仅保证质量,容量也可以尽可能的小。可这样又产生了新的问题:

Apple 用户怎么办?

WebP是由 Google 开发并推广的图片格式,其特点是体积小,同等压缩率下质量比jpgpng高。举个例子,下面是两张原图1.1M,经过80%压缩后的样图。

样图 | jpg,161KB
样图 | jpg,161KB

样图 | WebP,67.9KB
样图 | WebP,67.9KB

几乎看不出来区别,这就是WebP吸引我的地方。市面上大部分浏览器均支持WebP,唯独 Apple 旗下的 Safari 浏览器不支持WebP。也就是 Safari 用户看不见WebP格式的图片。为了解决这个问题,我咨询了资深 Apple 用户,VELAS 电波站的站长 Zeee

Z酱建议我放弃使用 CDN。那怎么能行,CDN、云存储都是要钱的,我已经买了流量包了。

那到底该如何有效地解决这个问题呢?

Mikusa 的解决方案

既不能放弃 Apple 用户,毕竟认识的大佬们都在用苹果产品;又不能不压缩图片,再这样下去我的钱包就要被榨干了。于是我想了两个「部分放弃 Apple 用户体验」折中的方法:

  1. 从源头判断访客类型。比如这篇文章,是为了告诉 Android 用户有这么一个应用,IOS 用户看了也没用,所以全文图片WebP化。
  2. 从图片体积判断是否需要压缩。比如这篇文章,照片原图 60M,WebP压缩后 9M,不仅省流量,还省空间。

因此,如果 Apple 用户哪天看到本站某一篇文章图片全裂,除了站长跑路,还有一种可能,是文章图片格式是 Safari 不支持显示的。

要怪就怪 Apple 不愿意适配WebP吧。🙃

Zeee 的解决方案

资深 Apple 用户 Z 酱建议我上传jpgWebP两种格式的图片,再写个判断,确定客户端类型输出WebP,我不会写,Z 酱决定帮我写。

她指出,为了解决「WebP 难题」,要针对全站「WebP 改造」的难点、重点入手,从根源做好「VOID」的修改工作。

Z 酱为此做了以下变更:

  1. 为 VOID 添加 WebP兼容算法,需要确保「JPG图片相同位置下存在一张同名的 WebP 图片」,浏览器兼容 WebP 就会自动启用这张 WebP 图片
  2. 修改 VOID 附带的懒加载效果,原理是「当图片滚动到视野内,判断浏览器是否兼容 WebP。兼容就尝试请求对应的 WebP 图片,请求成功就直接加载,请求失败就加载非 WebP图片」,即在懒加载前增加一个「请求 WebP」的步骤
  3. 修改 VOID 的灯箱,让灯箱直接显示 WebP 图片

最后的成果就是这篇文章的效果。

成果
成果

想要和我一同白嫖 Z 酱的劳动成果,就快去 VOID HACK 下载主题测试下吧!

文章整理

既然要把图片都轮一遍,为何不把文章也顺便整理一下呢?

过去的一年都是仔细斟酌才把文章发出来,而前年的文章水得真是叫一个惨不忍睹。于是整理过程中把所有能看的不能看的水文都删掉了。

整理前
整理前

整理后
整理后

人都是有黑历史的,不给看。😜

文章链接格式

本站的文章路径,在 2017 年搭建博客时确定使用/archives/{slug}.html以保证链接的简洁美观,可有一点不足。

Typecho 的slug默认使用cid,而添加图片、新增草稿同样占用cid,文章slug就不会连续。随着文章、图片、草稿越来越多,slug会越来越大,到最后「文章没几篇,slug已上万」。

虽然这并不是什么大问题,但我看着很是难受。为此我做了两次变更。第一次是在 2018 年,我决定用连续的数字代替cid,把所有文章重新排了序。这一行为导致本站的百度索引丢了个精光,很长一段时间里再起不能。

过了半年,数字越来越大。我发现以我的记性,根本无法把数字与对应文章绑定。于是在 2019 年初,文章排序达到60的时候,我决定使用文章标题的英文翻译作为slug以替代单纯数字排序。

这样,就解决了上面提到的「数字越来越多」和「无法靠链接得知文章内容」两个问题。完美!😝

图片链接格式

最后,就是确定图片链接的格式了。

之前都是直接上传到 Typecho,经过时间戳转换后变成/uploads/年/月/文件时间戳这样的格式,可手动上传就不成了。我想过参考Z酱的图片格式/images/post/年-月-日-文件名,但这样图片命名会很麻烦,还要加上年月日。

我想到我在电脑上使用 Typora 水文, Typora 可以直接拖动图片到文章里,不用上传到腾讯云里获取图片链接,想改就改,很方便。而我在使用图片时又有给图片按年份分类的习惯。

经过这番考量,我决定化繁为简,直接使用/年/文章名/文件名,也就是本文正在使用的图片链接格式。

未来?

之所以要这么大费周折,一是为了省钱,二是为以后静态化或是跑路做准备。先从图片这种麻烦的地方下手,以后搬家换地方也不怕。接下来就是慢慢写文章了,每篇文章都好好打磨。再三斟酌后再发布到博客,避免未来某一天看了尴尬再去删除。我还有好多天坑不想填呢!

不会鸽
不会鸽

2020年确实有点不太正常,开年就遇上这么档子事儿。特殊时期,虽然不能出门,不能玩,但只要我们好好听从安排,不要擅自外出行动,一定会挺过这次的疫情。提前祝大家元宵节快乐,出去的话不要忘记戴口罩哦!