网站优化

国内和国外隔着一堵墙,无论如何你都没办法快速绕过它。对于我来说,在域名没有备案的情况下,本站算是差不多已经优化到极限了。

但就在刚刚,我的移动数据流量打开加载十余秒,差不多算是超时了,要彻底解决这个问题,只有备案,无其他路可走。

好在,同之前相比,速度已经有了明显提升,也总算没白费这个折腾劲儿。有一点感受是对网站理解又稍微深刻了些许。

CDN加速

比如,之前在CDN中有CORS(跨域请求)这一项不理解,当然现在也不是很理解,至少知道如果没有正确配置它,会导致类似于字体文件这类资源没办法在浏览器上正常加载。

尽管状态码为200,但资源大小确实零字节,后面设置了后才得以解决。之前没有遇到这个情况,所以也就不知道具体有什么用,反正没设置也能用。

既然谈到了CDN,那么就在谈谈CDN中的回源,源站等问题。比如我的网站主域名为www.tangruiping.com,不带wwwtangruiping.com做301跳转到带www的。

现在我的网站是纯静态站点,原来是托管在Github Pages,但因为访问较慢,我接入CDN来为其加速。原来的访问过程是用户→www.tangruiping.com→Github pages,接入了CDN后就变成用户→www.tangruiping.com→CDN→Github pages

那么此时,我的源站地址则为Github Pages地址,回源Host则是www.tangruiping.com。而CDN中常说的加速域名,就是www.tangruiping.com。而源站地址一定不能和加速域名相同,而加速域名可以和回源Host一样。

CDN前端库

因为是静态网站,很多的css样式js脚本,字体等都可以走CDN,本质上跟前面说的CDN加速没啥区别性。

不同的是,前面的CDN加速需要自己把静态资源传入到对象存储也好,或者其他地方也好,在接入CDN加速。而CDN前端库则是自带有很多这样的资源,直接调用即可。

一来不需要你备案域名,二来还是免费使用,不用担心被人恶意刷流量等问题。当然即便是没有备案,还是可以通过云服务商自带的域名实行加速,目前阿里腾讯是提供域名。七牛则是默认30天回收,管它叫测试域名。又拍云则没有,其他云没用过。

百度的前端公共库现已关闭,腾讯的资源少之又少,又拍云的老之又老,好像没有听过阿里有前端公共库,不过阿里持有七牛股份,勉强算阿里的吧。

360有个由奇舞团主导的,还有个bootcdn的,相比之下,360略胜。不过360的前端公共库也是几经曲折,而bootcdn的有时候我这边加载贼慢。字节跳动也有个前端库,现把他们都列入下表。

服务商 网址
七牛 https://www.staticfile.org/
字节跳动 https://cdn.bytedance.com/
360 https://cdn.baomitu.com
Bootcdn https://www.bootcdn.cn/

以上这几个前端库还是比较全的,推荐顺序也是从上到下。还有一个要单独拿出来说,那就是真正能做到全球都有节点的jsdelivr, 我不知道如何给它排名,因为很多人有点滥用,比如用它给Github加速。(跟jsdelivr相似的还有statically.io

还可以用它加速存储在Github上的图片,文件等。不知道今后会不会被墙,尽管在国内是有正规的ICP备案。当然它也有加载不了的时候,这个时候,怎么办?

coding持续集成github持续部署

对于网站的更新,我目前采用两个更新点,一个是Hexo本地处理好后通过git push到coding,让coding-ci到github pages上,再由Netlify和Vercel自动导入他们的站点进行多站点部署。

本站流程

如图所示,还可以直接在语雀上更新文章使得自动部署到hexo博客,具体可以参见《语雀文章用Serverless自动部署到Hexo博客

但我不习惯这样更新,另外也可以在coding上自动处理好hexo项目,然后输出到coding pages仓库,再一次持续集成后推送到github pages仓库,这样做跟前面直接把hexo源码推送到github 私有仓库通过github actions功能推送到github pages是一样的。

不过一个是由Github来完成,一个是由Coding来完成,而这样一来反而多消耗了一次持续集成的额度,每周200次的额度,折算一半还有100次,也足够用了,但觉得没必要如此。 Coding改版后变为每月1000分钟的时常,单次时常不得超过30分钟。

所以我采用的还是图中前面两个方案,既然是此方案,那么我就可以稍微做点差异化的处理。比如在主题目录下的_config.yml配置文件中,本地的用jsdelivr前端库,coding上的用七牛前端库,这样既可做到在不同地方更新,生成后的网站加载的前端资源是不一样的。

缺点是文章之间可能需要手动同步一下,不然会不一致,不过影响也不是很大,像这几天每天一篇文章的更新频率,那是几乎没有的事儿。

如果想了解本地Hexo处理好后让coding自动推送到Github的可以参见《Coding持续集成自动同步到GitHub》这篇文章。

如果想让coding处理好hexo项目可参见《Coding持续集成自动部署Hexo博客》,再结合前面的《Coding持续集成自动同步到GitHub》即可搞定。

如果觉得Coding额度不够用,想试试Github Actions每月2000分钟的额度,或想体验一下Github的持续集成可参考《Github Actions自动部署Hexo博客

而Coding每周有200次的构建次数,单次构建时长的上限为30分钟,而每个月总构件时长为1000分钟。

如果不用github做后台更新文章,或者也不想用coding为后台更新文章,就习惯语雀优良的Markdown书写体验,则可以试试《语雀文章用Serverless自动部署到Hexo博客

多解析路线

不管从哪里做入口,最终都汇聚到Github Pages上,但有比Github访问速度更好的静态站点,肯定要试试咯。因此使用NetlifyVercel做补充,然后顺带也把CloudFlare上。Netlify自动部署github pages比较简单,其中Netlify的注意事项和Vercel (zeit now)的项目导入可参考《Vercel Zeit now自动部署Github为hexo博客加速

如此一来,那么则有Coding Pages,Github Pages,Netlify,Vercel四个站点,而CDN路线则有CloudFlare和腾讯云做备用路线,其中Netlify,Vercel也自带CDN节点的。另2个备用CDN线路,可以把上面四个站点作为源站。Coding是被腾讯收购了,用的都是腾讯云的服务器,因此腾讯云的CDN可设置为coding pages为源站,另外腾讯云CDN还支持备用线路,可在Netlify,Vercel中选取一个即可。不过如果用Coding pages的话,注意选取图中的方案1和方案4,不然是不会在Coding pages上有文件生成的。

在《CloudFlare CDN GitHub Pages》中说过,CF是可以采用CANME解析的,而不必NS解析,因此用国内的DNS解析即可,则可以把移动路线,电信路线,联通路线分别解析到不同的站点,至于如何解析,则需要用网站测速工具测试一下做个参考。

比如本站目前电信路线走的是Vercel,联通路线走的是Github Pages,移动路线走的是Netlify,搜索引擎路线则自己考虑,如果过于分散,可以不便于Let's Encrypt的续期。