最近几天给博客弄了一个看板猫🐱（请看博客右边），相关文件放在CDN上，体积实在是大，导致首次加载时浏览器转圈圈半天，实在是难看。于是就打算把它设置为延迟动态加载，由于桌宠这种东西本身就不是什么必要组件，就打算把它放到LOAD之后再加载，这样子也可以减少转圈圈的时间。之前使用插件优化过博客，效果显著，所以也就很久没博客加载优化了。
不过中间还是有点小曲折的，我之前都没了解过浏览器转圈圈截止是按照什么计算的，于是加上<script defer>发现也没有减少转圈圈的时间。问ai后才知道原来是要完全非堵塞加载才可以减少转圈圈时间。就叫ai写了下面的代码：
<!-- 页面底部，放延迟加载代码 -->
<script>
window.addEventListener('load', function() {
setTimeout(function() {
// 加载管理器
const lazyLoader = {
js: function(src, callback) {
const script = document.createElement('script');
script.src = src;
script.onload = callback;
script.onerror = () => console.log('加载失败:', src);
document.head.appendChild(script);
},
css: function(href) {
const link = document.createElement('link');
link.rel = 'stylesheet';
link.href = href;
document.head.appendChild(link);
}
};
// ===== 在这里添加你要延迟加载的内容 =====
// 加载其他资源（这些可以并行加载）
lazyLoader.js('xxx.min.js');
lazyLoader.css('xxx.min.css');
}, 50); // 延迟50ms
});
</script>正好灵光一现，干脆再给网站加加速吧正好之前塞了一堆没什么实际功能的文件，这些文件不应该与核心功能组件抢着加载，所以延迟加载问题也不大。就把一些字体文件（Font Awesome、博客字体）拖后加载，顺便再把一些美化装饰用的也托后加载。虽然感觉是魔修，但是转圈圈确实短了。我感觉已经优化的差不多了，不能再快了因为中转服务器是在香港节点，本身就快不了。
可以看到加载只用了1.27秒，这时浏览器就会停止转圈圈。完成8.34秒是加载完了那些延迟加载的全部文件。如此可见如果我不把它延迟加载那么他就要一直拖着浏览器转圈圈。
弄完了之后呢又想着去看看隔壁博友们怎么弄的，加载速度怎么样，于是就随机（已经是全部了）挑选了一些幸运儿看看😋
GoodBoyboy ‘s Blog
GoodBoyboy老师的博客其实页面显示得挺快的，但是估计被一些非核心功能拖慢了，花了49.73s转圈圈。还有字体和图片文件可以再压缩一下，目前看起来还是比较大的体积。部分资源等待服务器响应占用的时间比较长，可能是网络问题？
鸦鸦的巢穴
yaya的博客的加载速度是比较快的，ta使用了插件构建静态文件、合并js、css等方式减少了等待时间，花了6s转圈圈。ta也使用了看板猫，而且部分资源似乎是在Load后加载的，减少了转圈圈的时间。部分文件较大，下载时间比较长，可能和ta的服务器带宽有关。但是yaya老师的服务器是内地的，所以缓存后切换页面的速度非常丝滑迅速。
祈星海
zhi老师的博客数据量非常巨大，字体文件完全没有压缩，一堆字体文件几MB加载，花了20.01s转圈圈。由于在首页加载了友链，而且直接链接到原站的图片，部分友链站点头像加载速度慢，导致拖慢了整体速度。站点部分图片没有压缩，比较大，比如说头像图片（1.5MB），不过靠编**猫的国内CDN救回来了，只花了870ms加载(￣▽,￣)╭ 。
Echo小窝
Echo老师的博客DOMContentLoaded用了3.15秒，但完全加载花了15.48秒，转圈圈时间有点长。主要问题出在字体和图片资源上：HanTang.woff2字体文件高达3.6MB，加载耗时13.41秒，这个体积实在太大了，可以压缩一下；图片没有进行压缩，例如kaoyan.png图片1.7MB，加载8.01秒。32个请求传输了6.9MB数据，平均每个请求200多KB，主要是被大文件拉高了。部分小资源如cur文件、svg图标等加载速度都很快（100ms左右），说明服务器响应速度还可以。
真境的博客
真境老师的博客DOMContentLoaded用了2.00秒，完全加载花了2.55秒，整体比较流畅。站点明显使用了Autoptimize插件进行优化，可以看到大量的autoptimize_single合并文件，将多个JS和CSS文件进行了合并压缩。图片资源如purple-blue-firewatch-tower等经过了压缩，大小在200-300KB左右，比较合理。不过还有一些可以优化的地方：主文档加载耗时1.05秒，相对较长，可能是服务器响应或PHP处理速度的问题，可以安装一个生成静态文件的插件试试？
猫球博客
李猫球老师的DOMContentLoaded用了6.23秒，完全加载花了15.77秒，转圈圈时间比较长。从网络面板可以看到，主要问题在于大量图片资源加载速度极慢——41个请求中大部分是图片文件，虽然单个图片体积都不大（大多在5-20KB之间），但加载时间却异常漫长：1.png用了10.20秒，liuyan.jpg用了10.16秒，还有大量图片都在7-10秒之间。这种情况很可能是因为图片都托管在慢速服务器上，或者服务器带宽严重不足。475KB的总传输量并不算大，但却花了近16秒才完成，说明服务器带宽存在瓶颈。也许可以考虑使用一下图床？
光 · 昭
光昭老师DOMContentLoaded用了2.08秒，完全加载花了4.65秒，整体比较流畅。站点使用了WebP格式的图片，有效减小了图片体积。不过还存在一些优化空间：最大的问题是104491469_0_r.png这个PNG图片高达1.3MB，加载耗时3.16秒，严重拖慢了首屏加载速度，建议压缩一下。favicon.ico作为一个图标，却有161KB，体积偏大，加载用了2.56秒。
结语
折腾了一圈下来，最大的感触就是：优化永无止境，但也要适可而止。从一开始为了看板猫延迟加载，到后来把整个网站都梳理了一遍，转圈圈时间短了不少，但其实总数据量并没有改变。不过也发现了很多有趣的现象——有的博友服务器优化得当，速度很快；有的则是资源太大拖慢了整体速度。其实对于个人博客来说，内容才是核心，性能优化只是锦上添花。不过能把转圈圈时间从几十秒缩短到几秒，看着确实舒服多了不是吗？
非常感谢您愿意把我的站点作为案例进行分析与交流！
寒站用了腾讯的EdgeOne（免费版）的CDN+Cloudflare（境外DNS分流）
优化插件如下：Autoptimize（正如文章所说）、Jetpack Boost、WP Super Cache、Redis Object Cache（缓解服务器压力用的）
感谢真境老师解惑！
难怪测试的时候感觉您的网站在速度这么好，原来是背后有 EdgeOne CDN 和 Redis缓存 这些技术在做支撑。特别是那一排优化插件，学到了！话说Redis对服务器压力的缓解效果明显吗？我也弄了个，但是感觉不错什么区别
缓解效果一般吧 没有很惊艳就是了
但是能扣点性能出来谁不愿意话说这些插件的功能有点重叠了吧？Autoptimize、Jetpack Boost都是用来压缩合并代码的（差别可能是Jetpack提供CDN），WP Super Cache生成缓存，Redis拿来内存数据库缓存
我用的litespeed cache，上述这些功能一个插件就都能满足了
我用的插件是Autoptimize 和WP Super Cache和Autoptimize。插件确实越少简洁越好。本来打算使用litespeed cache插件的，但是服务器没有安装OpenLiteSpeed，应该发挥不出它的全部威力，所以就没搞了。
似乎有点重叠，不过…目前似乎没有什么冲突影响？
我比较佛系，比较懒OK，那个104491469_0_r.png其实是首页的友链随机推荐，由于是直接引用的对方提供的友链地址，现已压缩然后丢到自己域上了
现在一翻翻到俩404的资源，但我着实找不到我在哪里引用了这俩图。后来才想起来，以前是写了个页脚，后来弃用了，不过引用这俩资源的JS还留在那，一并删掉了
favicon.ico是主题提供并托管的，我也懒得管了，毕竟矢量图也压缩不到哪里去了
优化插件我倒是只加了一个，litespeedcache。主要这玩意儿是真的all in one，生成缓存、连接Redis、页面优化，它都有。其实我也尝试过要延迟加载JS，但是IRO主题延迟加载JS的话会出现布局错误。合并CSSJS也是。所以对页面的更改只有CSS和HTML最小化了
改进之后好多了，disable cache首屏加载LOAD:1.6s
我没对主题文件的js css延迟加载，这应该是核心文件，老祖宗动不得www
高带宽低体积，我见过最小的页面，只有10K多~
蚌埠住了，看到这2.2MB的字体加载30多s，瞬间就想把腾讯的Edgeone换成阿里的ESA了
edgeone效果这么差吗
eo好像大文件限速
感觉不用特别优化吧，选择国内的服务器应该就能很快。
我用的腾讯云主机，打开也就1s左右。
想问一下我的网站访问速度如何嘞