网站优化
国内和国外隔着一堵墙，无论如何你都没办法快速绕过它。对于我来说，在域名没有备案的情况下，本站算是差不多已经优化到极限了。
但就在刚刚，我的移动数据流量打开加载十余秒，差不多算是超时了，要彻底解决这个问题，只有备案，无其他路可走。
好在，同之前相比，速度已经有了明显提升，也总算没白费这个折腾劲儿。有一点感受是对网站理解又稍微深刻了些许。
CDN加速
比如，之前在CDN中有CORS（跨域请求）这一项不大理解，当然现在也不是很理解，至少知道如果没有正确配置它，会导致类似于字体文件这类资源没办法在浏览器上正常加载。
尽管状态码为200，但资源大小确实零字节，须得设置后才得以解决。之前没有遇到这个情况，一直不知道具体有什么用，反正没设置也能用。
既然谈到了CDN，那么就在谈谈CDN中的回源，源站等问题。比如我的网站主域名为www.tangruiping.com，不带www的tangruiping.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备案。当然它也有加载不了的时候，这个时候，怎么办？
时间来到了2021年12月20日，jsdelivr在国内的ICP备案掉了，导致国内无法加载，目前jsdelivr采用的方法是把国内网宿的请求转发到Fastly上，我这里的延迟还挺低的，不知道未来如何，如果未来没能取得备案，那么不稳定的概率是越来越大了。
从V2EX的讨论来看，其原因是jsdelivr有“违规”内容，应该是海外的轮子在Github上发布相关信息，甚至当做发布源使用，而jsdelivr无差别代理Github上的内容，故此导致了较为严重的问题。
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访问速度更好的静态站点，肯定要试试咯。因此使用Netlify和Vercel做补充，然后顺带也把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的续期。
