0622优化静态资源由国内服务提供尽管驿站在一段时间内不会备案，但是驿站的静态资源将由白嫖来的备案的域名提供，图片资源(img.xpls.top)国内将由火山引擎的imageX压缩且转换成WebP提供服务，国外方面使用了Bunny 的Object Storage存储处理后的图片，并有ClouFlare进行缓存与分发；Javascript、字体文件（fontawesome）方面（post.cplus8.com/assets)使用了腾讯云的CDN面相国内提供加速，国外同样是Cloudflare服务。 ImageX其实一直都在用的，之前用起来也是蛮不错的。这次既然优化也索性调低了质量分数，调到50percent左右以获得更小的体积和更短的加载时间。当然，如果您需要使用原图的话，您可以去除模板参数获得仅转化为webp不压缩的图片 QUIC 支持扩大化同时，QUIC Http/3 已经覆盖驿站域名（联通、移动Amazon CloudFront，电信阿里云香港移动节点，国外Cloudflare均已支持Http/3)和静态资源域名(post.cplus8.com/assets)，QUIC的拥堵控制与多路复用的特性应该对于链接位于境外的驿站服务器在网络抖动的情况下应该会有更好的表现（猜测）。但事实上我选的这节点都不会很丢包。节点表现与服务响应时间节点方面在上一篇已经讲过了，ping延迟大都在100ms，且网络波动少有出现，这是速度优化的一大基石。不过也有例外，在湖北、内蒙古、甘肃、哈尔滨等地电信网络中，有个别节点到香港移动仍有存在延迟高达200ms的情况，进行TraceRoute尚未发现绕路情况，不排除是测试节点的问题。对此，我表示开摆了如果您在打开驿站时特别慢（尤其是半天导航栏标题还未出来时）您可以在此贴上您的运营商信息，地点我们将为您重新调整节点。然而，ping虽然是基石，但不能说明主要问题。实际上还得看源站与CDN节点的连接情况举个例子，您使用了某某家国内的CDN，得益于广泛的节点分布，可能你的ping延迟会在10ms一下，但是不巧的是您的源站在IBM Cloud原SoftLayer的香港服务器，如果您的cdn对此没有合适的优化，您的响应数据将会在太平洋两岸中往返，自然速度就慢下来。目前，在这方面并无太大问题，Cloudflare不同区域的数据传输速度还是很可观的。驿站源站位于新加坡（当然是因为香港用不起），先套了层CloudFlare，由于Cloudflare到国内实在是没有什么好的线路，高丢包率等，遂再用了Cloudfront/阿里云。大概是这样：移动：香港CloudFront=>香港Cloudflare=>新加坡源站电信：香港移动=>香港Cloudflare=>新加坡源站联通：新加坡CloudFront=>新加坡Cloudflare=>新加坡源站虽然从理论上看，多重转发由于tcp连接的开销这样势必会造成速度减缓，不过鉴于Cloudflare是我们全球性网络基础服务合作伙伴的地位，在安全与速度方面发挥了重要作用，这点损耗不值一提。这也说明了现在比备案使用国内国内节点要好的原因。 http下主页平均响应速度为0.3s，算是很快的了。https的话在完成首次连接后，时间也跟http下不相上下。这就是采用了证书oscp封装的好处。实际上广东等沿海省份可以在200ms内完成加载。华南联通华南电信重新用上了RocketLoader 早前我们就已经谈论过Cloudflare的rocketloader了。不过，在尝试替换css/js连接到静态资源域名时，这玩意表现出不兼容，有涉及到跨域等一些的报错和渲染的问题。后来通过调整解决了前者，但后者似乎是rocketloader的一个不太兼容的地方。当css/层叠样式表的地址是主站域名时，没有这个问题，但如果是其他域名的话，会导致二次加载，并且出现短暂的样式丢失。因此，层叠样式表文件仍然由驿站域名提供。但是，rocketloader带来的巨大提升是令人瞩目的 One key feature is that it makes all Javascript load in a non-blocking fashion (asynchronously), which is quite an incredible feat! This means the HTML/CSS can be rendered without waiting for scripts to load and run. 一个关键的特点是，它使所有的Javascript以非阻塞的方式（异步）加载，这是一个相当令人难以置信的壮举！这意味着HTML/CSS可以渲染，而无需等待脚本的运行！这意味着HTML/CSS可以被渲染，而无需等待脚本的加载和运行。上为RocketLoader加持，下无 RocketLoader的使用，可以将一些不重要的元素（如驿站右侧的lastpost，页脚的Cloudflare合作伙伴图片，百度统计的接口）等延期到渲染之后加载（异步加载），及早完成页面的基本展现，缩短了DOMContentLoaded时间减少了渲染阻塞时间。但怎么减也还是有那么多，一个主要原因还是驿站的forum.js过于庞大，如右下角的聊天框、博客界面等很多功能阻塞了加载。建议的阻塞时长要在350ms一下才有好的体验。字体变更参考了这篇文章的建议： https://www.uisdc.com/web-font 我们抛弃了需要重新加载引入的文件大小达2M的Noto Serif，转而使用了系统（是Windows）自带的字体，整体是Arial+仿宋，帖子标题是等线。少用插件的移除以及其他列表如下；无用的BBCODE FoF Masquerade(化妆舞会，即填写个人相关资料） Categories 用默认的tags页面就好，也没人看过 tohsakarat/tags-filter 首页筛选标签的工具 Group Invitation 用户组邀请链接生成另外，由于插件已经将jqurey集成到forum.js，因此删除了重复的加载。除去了阿里图标库的使用，font awesome那堆已经够了。 Generally speaking,家人们要是有什么意见可以在下方留言，同时也欢迎分享您的来访驿站的速度测试结果

［再优化］借着掉备案的契机把加载速度再缩减

傑克•特裡•斯科鋪

0622优化

This in image

静态资源由国内服务提供

尽管驿站在一段时间内不会备案，但是驿站的静态资源将由~~白嫖来的~~备案的域名提供，图片资源(img.xpls.top)国内将由火山引擎的imageX压缩且转换成WebP提供服务，国外方面使用了Bunny 的Object Storage存储处理后的图片，并有ClouFlare进行缓存与分发；Javascript、字体文件（fontawesome）方面（post.cplus8.com/assets)使用了腾讯云的CDN面相国内提供加速，国外同样是Cloudflare服务。
ImageX其实一直都在用的，之前用起来也是蛮不错的。这次既然优化也索性调低了质量分数，调到50percent左右以获得更小的体积和更短的加载时间。当然，如果您需要使用原图的话，您可以去除模板参数获得仅转化为webp不压缩的图片

QUIC 支持扩大化

同时，QUIC Http/3 已经覆盖驿站域名（联通、移动Amazon CloudFront，电信阿里云香港移动节点，国外Cloudflare均已支持Http/3)和静态资源域名(post.cplus8.com/assets)，QUIC的拥堵控制与多路复用的特性应该对于链接位于境外的驿站服务器在网络抖动的情况下应该会有更好的表现（猜测）。
但事实上我选的这节点都不会很丢包。

节点表现与服务响应时间

节点方面在上一篇已经讲过了，ping延迟大都在100ms，且网络波动少有出现，这是速度优化的一大基石。
This in image
不过也有例外，在湖北、内蒙古、甘肃、哈尔滨等地电信网络中，有个别节点到香港移动仍有存在延迟高达200ms的情况，进行TraceRoute尚未发现绕路情况，不排除是测试节点的问题。对此，~~我表示开摆了~~如果您在打开驿站时特别慢（尤其是半天导航栏标题还未出来时）您可以在此贴上您的运营商信息，地点我们将为您重新调整节点。

This in image

然而，ping虽然是基石，但不能说明主要问题。实际上还得看源站与CDN节点的连接情况
举个例子，您使用了某某家国内的CDN，得益于广泛的节点分布，可能你的ping延迟会在10ms一下，但是不巧的是您的源站在IBM Cloud原SoftLayer的香港服务器，如果您的cdn对此没有合适的优化，您的响应数据将会在太平洋两岸中往返，自然速度就慢下来。
目前，在这方面并无太大问题，Cloudflare不同区域的数据传输速度还是很可观的。驿站源站位于新加坡（当然是因为香港用不起），先套了层CloudFlare，由于Cloudflare到国内实在是没有什么好的线路，高丢包率等，遂再用了Cloudfront/阿里云。
大概是这样：
移动：香港CloudFront=>香港Cloudflare=>新加坡源站
电信：香港移动=>香港Cloudflare=>新加坡源站
联通：新加坡CloudFront=>新加坡Cloudflare=>新加坡源站
虽然从理论上看，多重转发由于tcp连接的开销这样势必会造成速度减缓，不过鉴于Cloudflare是我们全球性网络基础服务合作伙伴的地位，在安全与速度方面发挥了重要作用，这点损耗不值一提。
这也说明了现在比备案使用国内国内节点要好的原因。
This in image
http下主页平均响应速度为0.3s，算是很快的了。https的话在完成首次连接后，时间也跟http下不相上下。这就是采用了证书oscp封装的好处。实际上广东等沿海省份可以在200ms内完成加载。

华南联通

华南电信

重新用上了RocketLoader

早前我们就已经谈论过Cloudflare的rocketloader了。不过，在尝试替换css/js连接到静态资源域名时，这玩意表现出不兼容，有涉及到跨域等一些的报错和渲染的问题。后来通过调整解决了前者，但后者似乎是rocketloader的一个不太兼容的地方。当css/层叠样式表的地址是主站域名时，没有这个问题，但如果是其他域名的话，会导致二次加载，并且出现短暂的样式丢失。因此，层叠样式表文件仍然由驿站域名提供。但是，rocketloader带来的巨大提升是令人瞩目的
This in image

One key feature is that it makes all Javascript load in a non-blocking fashion (asynchronously), which is quite an incredible feat! This means the HTML/CSS can be rendered without waiting for scripts to load and run.
一个关键的特点是，它使所有的Javascript以非阻塞的方式（异步）加载，这是一个相当令人难以置信的壮举！这意味着HTML/CSS可以渲染，而无需等待脚本的运行！这意味着HTML/CSS可以被渲染，而无需等待脚本的加载和运行。

This in image

上为RocketLoader加持，下无
RocketLoader的使用，可以将一些不重要的元素（如驿站右侧的lastpost，页脚的Cloudflare合作伙伴图片，百度统计的接口）等延期到渲染之后加载（异步加载），及早完成页面的基本展现，缩短了DOMContentLoaded时间减少了渲染阻塞时间。但怎么减也还是有那么多，一个主要原因还是驿站的forum.js过于庞大，如右下角的聊天框、博客界面等很多功能阻塞了加载。建议的阻塞时长要在350ms一下才有好的体验。
This in image

字体变更

参考了这篇文章的建议：
https://www.uisdc.com/web-font
我们抛弃了需要重新加载引入的文件大小达2M的Noto Serif，转而使用了系统（是Windows）自带的字体，整体是Arial+仿宋，帖子标题是等线。

少用插件的移除以及其他

列表如下；
无用的BBCODE
FoF Masquerade(化妆舞会，即填写个人相关资料）
Categories 用默认的tags页面就好，也没人看过
tohsakarat/tags-filter 首页筛选标签的工具
Group Invitation 用户组邀请链接生成

另外，由于插件已经将jqurey集成到forum.js，因此删除了重复的加载。除去了阿里图标库的使用，font awesome那堆已经够了。

Generally speaking,家人们要是有什么意见可以在下方留言，同时也欢迎分享您的来访驿站的速度测试结果