最近几天给博客弄了一个看板猫🐱（请看博客右边），相关文件放在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秒。
结语
折腾了一圈下来，最大的感触就是：优化永无止境，但也要适可而止。从一开始为了看板猫延迟加载，到后来把整个网站都梳理了一遍，转圈圈时间短了不少，但其实总数据量并没有改变。不过也发现了很多有趣的现象——有的博友服务器优化得当，速度很快；有的则是资源太大拖慢了整体速度。其实对于个人博客来说，内容才是核心，性能优化只是锦上添花。不过能把转圈圈时间从几十秒缩短到几秒，看着确实舒服多了不是吗？
