colin/Colinx-Blog
1
0
Fork 0
mirror of https://github.com/Colin-XKL/Colinx-Blog.git synced 2026-11-04 06:29:22 +08:00
Code Issues Packages Projects Releases Wiki Activity

chore: lint text and auto correct

Browse Source
This commit is contained in:
github-actions[bot]
2023-06-06 06:13:34 +00:00
committed by GitHub
parent 263610a74c
commit 663265dccc
28 changed files with 610 additions and 610 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
content/posts/前端静态资源加载的一些优化.md
View File

@@ -1,7 +1,7 @@
---
title: 前端静态资源加载的一些优化
date: 2022-05-06
description: 最近在折腾优化博客，由于全站都是部署在Netlify、Vercel的CDN上，都是海外节点，国内访问延迟高，在想办法优化下访问速度和体验。这篇文章来探讨下前端CSS和JS资源的加载。优化目标主要就两个：1. 尽可能快，但是不希望我引入的辅助性第三方库影响到页面体验，不要阻塞主要内容渲染. 2. 为了快第三方静态资源肯定是上CDN，但是要有容灾，CDN挂了要能fallback到其他url
description: 最近在折腾优化博客，由于全站都是部署在 Netlify、Vercel 的 CDN 上，都是海外节点，国内访问延迟高，在想办法优化下访问速度和体验。这篇文章来探讨下前端 CSS 和 JS 资源的加载。优化目标主要就两个：1. 尽可能快，但是不希望我引入的辅助性第三方库影响到页面体验，不要阻塞主要内容渲染。2. 为了快第三方静态资源肯定是上 CDN，但是要有容灾，CDN 挂了要能 fallback 到其他 url
categories:
- 技术
tags:
@@ -13,22 +13,22 @@ tags:
<!-- # 前端静态资源加载的一些优化 -->
最近在折腾优化博客，由于全站都是部署在Netlify、Vercel的CDN上，都是海外节点，国内访问延迟高，在想办法优化下访问速度和体验。线路部分的优化可以看另一篇文章[国外静态网站托管服务商国内速度对比及线路优化](https://blog.colinx.one/posts/%E5%9B%BD%E5%A4%96%E9%9D%99%E6%80%81%E7%BD%91%E7%AB%99%E6%89%98%E7%AE%A1%E5%9C%A8%E5%9B%BD%E5%86%85%E9%80%9F%E5%BA%A6%E5%AF%B9%E6%AF%94%E5%8F%8A%E7%BA%BF%E8%B7%AF%E4%BC%98%E5%8C%96/)。这篇文章来探讨下前端CSS和JS资源的加载。
最近在折腾优化博客，由于全站都是部署在 Netlify、Vercel 的 CDN 上，都是海外节点，国内访问延迟高，在想办法优化下访问速度和体验。线路部分的优化可以看另一篇文章[国外静态网站托管服务商国内速度对比及线路优化](https://blog.colinx.one/posts/%E5%9B%BD%E5%A4%96%E9%9D%99%E6%80%81%E7%BD%91%E7%AB%99%E6%89%98%E7%AE%A1%E5%9C%A8%E5%9B%BD%E5%86%85%E9%80%9F%E5%BA%A6%E5%AF%B9%E6%AF%94%E5%8F%8A%E7%BA%BF%E8%B7%AF%E4%BC%98%E5%8C%96/)。这篇文章来探讨下前端 CSS 和 JS 资源的加载。
优化目标主要就两个：
* 尽可能快，但是不希望我引入的辅助性第三方库影响到页面体验，不要阻塞主要内容渲染
* 为了快第三方静态资源肯定是上CDN，但是要有容灾，CDN挂了要能fallback到其他url
* 为了快第三方静态资源肯定是上 CDN，但是要有容灾，CDN 挂了要能 fallback 到其他 url
## 静态资源异步加载
`prefetch`、`preload`这些预加载技术暂且不谈，博客站点没那么多资源。这里主要是用`async`和`defer`来控制脚本异步加载，以避免阻塞DOM解析和页面渲染。
`prefetch`、`preload`这些预加载技术暂且不谈，博客站点没那么多资源。这里主要是用`async`和`defer`来控制脚本异步加载，以避免阻塞 DOM 解析和页面渲染。
使用`async`异步加载，对于[pangu](https://github.com/vinta/pangu.js/)这种会影响到内容呈现的使用`async`，对于统计类第三方库使用`defer`延迟加载，到DOM加载完再执行
使用`async`异步加载，对于[pangu](https://github.com/vinta/pangu.js/)这种会影响到内容呈现的使用`async`，对于统计类第三方库使用`defer`延迟加载，到 DOM 加载完再执行
有些第三方库需要手动init，这样就不能使用`defer`、`async`关键字加载资源了，**`defer`和`async`关键字只适用于远程资源**，本以为把远程资源的`<script>`和内嵌在HTML里用来init的`<script>`都加上`defer`就可以利用它顺序加载的特性解决这个问题，结果发现不是这样的。。。。异步打乱脚本执行顺序，init脚本不等待资源下载完毕会先执行。利用好`onload`事件可以解决这个问题。
有些第三方库需要手动 init，这样就不能使用`defer`、`async`关键字加载资源了，**`defer`和`async`关键字只适用于远程资源**，本以为把远程资源的`<script>`和内嵌在 HTML 里用来 init 的`<script>`都加上`defer`就可以利用它顺序加载的特性解决这个问题，结果发现不是这样的。。。。异步打乱脚本执行顺序，init 脚本不等待资源下载完毕会先执行。利用好`onload`事件可以解决这个问题。
before
@@ -65,7 +65,7 @@ after
除了`onload`还有`onerror`，还可以利用`onerror`事件在资源加载失败时fallback到其他CDN，详见下文
除了`onload`还有`onerror`，还可以利用`onerror`事件在资源加载失败时 fallback 到其他 CDN，详见下文
这里跑了个测试看下优化前后的差距
@@ -75,26 +75,26 @@ after
![image-20220506193800266](https://blog-1301127393.file.myqcloud.com/BlogImgs/202205062117127.png)
First Contentful Pain Time在1.5s，整个页面到1.5s才能可见，DOM加载总时间达到了2.5s
First Contentful Pain Time 在 1.5s，整个页面到 1.5s 才能可见，DOM 加载总时间达到了 2.5s
本来我都已经把首页不需要加载的三方库都拿走了，但是还剩下一个，这个用于前端性能监控的js阻塞了渲染，挂的是腾讯云的CDN，国内快到飞起，国外就卡到不行（作为对比上图里从jsdelivr加载的js也是快到飞起，墙内就慢得一批）
本来我都已经把首页不需要加载的三方库都拿走了，但是还剩下一个，这个用于前端性能监控的 js 阻塞了渲染，挂的是腾讯云的 CDN，国内快到飞起，国外就卡到不行（作为对比上图里从 jsdelivr 加载的 js 也是快到飞起，墙内就慢得一批）
**优化后**
![image-20220506193652188](https://blog-1301127393.file.myqcloud.com/BlogImgs/202205062117498.png)
优化后页面没有再阻塞，0.8s页面就可用了，总DOM加载时间只有1.5s，相较之前简直直接起飞。
优化后页面没有再阻塞，0.8s 页面就可用了，总 DOM 加载时间只有 1.5s，相较之前简直直接起飞。
![cn](https://blog-1301127393.file.myqcloud.com/BlogImgs/202205071426038.png)
国内某检测平台的结果也显示优化效果明显
## 静态资源Fallback加载
## 静态资源 Fallback 加载
国内好用的静态资源CDN还真没有，新浪那种只提供那么几个热门的库完全不符合需求，BootCDN炸了不是一次两次，字节CDN的资源URL有够ugly，URL里面还带节点信息多半后面会出问题。360奇舞CDN之前也换过域名、备案出问题，感觉每一个能省心用。七牛的目前看上去还行，也不知道后面会不会出什么幺蛾子。。。为了稳妥起见+照顾全球的访客，还是优先使用的cloudflare和jsdelivr的CDN
国内好用的静态资源 CDN 还真没有，新浪那种只提供那么几个热门的库完全不符合需求，BootCDN 炸了不是一次两次，字节 CDN 的资源 URL 有够 ugly，URL 里面还带节点信息多半后面会出问题。360 奇舞 CDN 之前也换过域名、备案出问题，感觉每一个能省心用。七牛的目前看上去还行，也不知道后面会不会出什么幺蛾子。。。为了稳妥起见 + 照顾全球的访客，还是优先使用的 cloudflare 和 jsdelivr 的 CDN
网站主要三方库都是通过jsdelivr和cloudflare引入的，但是毕竟是海外的节点不知道哪一天就被墙了，所以还要为墙内的访客准备一个fallback方案。这里利用到`script`标签的`onerror`事件
网站主要三方库都是通过 jsdelivr 和 cloudflare 引入的，但是毕竟是海外的节点不知道哪一天就被墙了，所以还要为墙内的访客准备一个 fallback 方案。这里利用到`script`标签的`onerror`事件
@@ -104,7 +104,7 @@ First Contentful Pain Time在1.5s，整个页面到1.5s才能可见，DOM加载
关于`onerror`，中文互联网上有好几篇文章说他会捕获`script`标签里的代码的执行错误。。。简直离谱。稍微查下MDN之类的文档就可以发现这玩意本来就是只捕获资源加载错误的
关于`onerror`，中文互联网上有好几篇文章说他会捕获`script`标签里的代码的执行错误。。。简直离谱。稍微查下 MDN 之类的文档就可以发现这玩意本来就是只捕获资源加载错误的
> The onerror event is triggered if an error occurs while loading an external file (e.g. a document or an image).
>
@@ -112,7 +112,7 @@ First Contentful Pain Time在1.5s，整个页面到1.5s才能可见，DOM加载
利用好这个特性，就可以实现在资源加载失败时fallback从另一个url加载资源。
利用好这个特性，就可以实现在资源加载失败时 fallback 从另一个 url 加载资源。
```html
<script>
@@ -135,9 +135,9 @@ onerror="fallbackJSloader('https://cdn.staticfile.org/gitalk/1.7.2/gitalk.min.js
src="https://cdn.jsdelivr.net/npm/gitalk@1/dist/gitalk.min.js">
```
CSS的fallback加载同理，此处不再赘述
CSS 的 fallback 加载同理，此处不再赘述
优化后如图，在开发者工具中手动block资源网站，可以自动fallback从另一个url加载资源，这下网站的可用性又提升了一点点🤏哈哈哈
优化后如图，在开发者工具中手动 block 资源网站，可以自动 fallback 从另一个 url 加载资源，这下网站的可用性又提升了一点点🤏哈哈哈
![66230832-3581-42DF-9F2F-B817E88DAF4D](https://blog-1301127393.file.myqcloud.com/BlogImgs/202205062133393.png)
@@ -149,6 +149,6 @@ CSS的fallback加载同理，此处不再赘述
* [defer 和 async 的区别](https://segmentfault.com/q/1010000000640869)
* [动态加载 css](http://lengyun.github.io/js/3-2-2dynamicAddCSS.html#%E4%B8%8E%E5%8A%A8%E6%80%81%E5%8A%A0%E8%BD%BDjs%E7%9A%84%E5%8C%BA%E5%88%AB)
**网站profile**工具
**网站 profile**工具
* [https://www.webpagetest.org](https://www.webpagetest.org)