实战，利用黑科技ServiceWorker提速你的网站。

本文所标记的内容，大多是直接复制粘贴即可实现的。但依然会存在这和您的服务存在冲突这一情况。请阅读上一篇基础文章欲善其事，必利其器 - 论如何善用ServiceWorker进行合理的修改。

我们简单的列一下表，这是我们加速清单：

• 分离资源，静态加速
• 加速主网页
• 调剂响应
• 首屏加速

前端竞速CDN

最传统的网页加载，其静态资源一旦独立是直接放在同域服务器下的。

不过后来，为了减少主服务器开销，我们通常将静态资分离至其他面向用户加载比较快的节点，以减少主服务器开销，提升网页加载速度。

现在，各种公益cdn服务蓬勃生长，其节点通常是全球部署，并且对各个国家/地区做了优化，使用公益cdn，他的质量和可用性是远远大于自己部署的。

在一个网页加载中，主网页只提供一个html（你所看的网页其大小约15kb），而流量开销巨头是静态资源（只论js，本页大约800kb）。我们对一个网站的加速，第一步就应当从静态加速做起。

对于加速存储的选择，通常市面上有三种主流加速cdnjs/npm/gh。而在这其中，对于个人而言，我还是推崇npm，这在接下来对于竞速节点的选择就多了起来。

对于加速节点的选择，从mainland角度来讲，首先你要遵循一个普世结论：不要用跨国节点。本身China国度就有个奇葩规定，没有ICP备案许可就不得在mainland开展网站服务。这使得大部分本应该分散在边缘末端的流量全压到了国际出口的汇聚层。你再引导他们去海外拉资源，凑过去挤热闹，其稳定性和速率完全无法保证，这在生产环境使用无异于自杀。这里提一嘴jsdelivr，备案掉了，节点迁出中国了，那你面向国内的网站早就可以切了。使用fastly，联通和电信晚上ntt几乎堵到妈都不认识，能连上就是奇迹。除非你真的不在意加速，也不在意资源能不能正常加载，在面向mainland的生产环境里还坚持jsd就是愚不可及的行为。

当然，在这里我还是推崇黑科技ServiceWorker，它可以利用Promise.any，并发数个请求至不同的cdn节点，提升前端资源加载。而借助于强大的js引擎，其在本地处理的效率奇高，性能折损几乎不计。

在这之前，我们定义一个lfetch，它的作用是对urls这个数组里的所有网址发起并发请求，并且在任意一个节点返回正常值时打断其余请求，避免流量浪费。

const lfetch = async (urls, url) => {    let controller = new AbortController(); //针对此次请求新建一个AbortController,用于打断并发的其余请求    const PauseProgress = async (res) => {        //这个函数的作用时阻塞响应,直到主体被完整下载,避免被提前打断        return new Response(await (res).arrayBuffer(), { status: res.status, headers: res.headers });    };    if (!Promise.any) { //Polyfill,避免Promise.any不存在,无需关注        Promise.any = function (promises) {            return new Promise((resolve, reject) => {                promises = Array.isArray(promises) ? promises : []                let len = promises.length                let errs = []                if (len === 0) return reject(new AggregateError('All promises were rejected'))                promises.forEach((promise) => {                    promise.then(value => {                        resolve(value)                    }, err => {                        len--                        errs.push(err)                        if (len === 0) {                            reject(new AggregateError(errs))                        }                    })                })            })        }    }    return Promise.any(urls.map(urls => {//并发请求        return new Promise((resolve, reject) => {            fetch(urls, {                signal: controller.signal//设置打断点            })                .then(PauseProgress)//阻塞当前响应直到下载完成                .then(res => {                    if (res.status == 200) {                        controller.abort()//打断其余响应(同时也打断了自己的,但本身自己已下载完成,打断无效)                        resolve(res)//返回                    } else {                        reject(res)                    }                })        })    }))}

在这其中，有一个难点：fetch返回的时状态而非内容。
即当fetch的Promise resolve时，它是已经获得了响应，但此时内容还没下载，提前打断会导致无法返回。这是PauseProgress作用。

之后我们考虑静态资源加速。这时候用npm的好处就体现出来了，不仅镜像多，其格式也还算固定。

注意，此方法是以流量换速度的方式进行的，虽然在任何一个节点返回正确内容后会打断其余请求，但依然会造成不可避免的流量消耗(+~20%)。如果你面向的是手机流量用户，请三思而后行！

此代码与freecdn-js核心功能相似，但实现方法并不同，并且完全支持动态网页。

例如jquery，你可以这样加速：

原始地址:https://cdn.jsdelivr.net/npm/jquery@3.6.0各类镜像：https://fastly.jsdelivr.net/npm/jquery@3.6.0https://gcore.jsdelivr.net/npm/jquery@3.6.0https://unpkg.com/jquery@3.6.0https://unpkg.zhimg.com/jquery@3.6.0 #回源有问题https://unpkg.com/jquery@3.6.0https://npm.elemecdn.com/jquery@3.6.0https://npm.sourcegcdn.com/jquery@3.6.0 #滥用封仓库https://cdn1.tianli0.top/jquery@3.6.0 #滥用封仓库

我们可以简单搓一个sw小脚本完成前端加速：

const CACHE_NAME = 'ICDNCache';let cachelist = [];self.addEventListener('install', async function (installEvent) {    self.skipWaiting();    installEvent.waitUntil(        caches.open(CACHE_NAME)            .then(function (cache) {                console.log('Opened cache');                return cache.addAll(cachelist);            })    );});self.addEventListener('fetch', async event => {    try {        event.respondWith(handle(event.request))    } catch (msg) {        event.respondWith(handleerr(event.request, msg))    }});const handleerr = async (req, msg) => {    return new Response(`<h1>CDN分流器遇到了致命错误</h1>    <b>${msg}</b>`, { headers: { "content-type": "text/html; charset=utf-8" } })}let cdn = {//镜像列表    "gh": {        jsdelivr: {            "url": "https://cdn.jsdelivr.net/gh"        },        jsdelivr_fastly: {            "url": "https://fastly.jsdelivr.net/gh"        },        jsdelivr_gcore: {            "url": "https://gcore.jsdelivr.net/gh"        }    },    "combine": {        jsdelivr: {            "url": "https://cdn.jsdelivr.net/combine"        },        jsdelivr_fastly: {            "url": "https://fastly.jsdelivr.net/combine"        },        jsdelivr_gcore: {            "url": "https://gcore.jsdelivr.net/combine"        }    },    "npm": {        eleme: {            "url": "https://npm.elemecdn.com"        },        jsdelivr: {            "url": "https://cdn.jsdelivr.net/npm"        },        zhimg: {            "url": "https://unpkg.zhimg.com"        },        unpkg: {            "url": "https://unpkg.com"        },        bdstatic: {            "url": "https://code.bdstatic.com/npm"        },        tianli: {            "url": "https://cdn1.tianli0.top/npm"        },        sourcegcdn: {            "url": "https://npm.sourcegcdn.com/npm"        }    }}//主控函数const handle = async function (req) {    const urlStr = req.url    const domain = (urlStr.split('/'))[2]    let urls = []    for (let i in cdn) {        for (let j in cdn[i]) {            if (domain == cdn[i][j].url.split('https://')[1].split('/')[0] && urlStr.match(cdn[i][j].url)) {                urls = []                for (let k in cdn[i]) {                    urls.push(urlStr.replace(cdn[i][j].url, cdn[i][k].url))                }                if (urlStr.indexOf('@latest/') > -1) {                    return lfetch(urls, urlStr)                } else {                    return caches.match(req).then(function (resp) {                        return resp || lfetch(urls, urlStr).then(function (res) {                            return caches.open(CACHE_NAME).then(function (cache) {                                cache.put(req, res.clone());                                return res;                            });                        });                    })                }            }        }    }    return fetch(req)}const lfetch = async (urls, url) => {    let controller = new AbortController();    const PauseProgress = async (res) => {        return new Response(await (res).arrayBuffer(), { status: res.status, headers: res.headers });    };    if (!Promise.any) {        Promise.any = function (promises) {            return new Promise((resolve, reject) => {                promises = Array.isArray(promises) ? promises : []                let len = promises.length                let errs = []                if (len === 0) return reject(new AggregateError('All promises were rejected'))                promises.forEach((promise) => {                    promise.then(value => {                        resolve(value)                    }, err => {                        len--                        errs.push(err)                        if (len === 0) {                            reject(new AggregateError(errs))                        }                    })                })            })        }    }    return Promise.any(urls.map(urls => {        return new Promise((resolve, reject) => {            fetch(urls, {                signal: controller.signal            })                .then(PauseProgress)                .then(res => {                    if (res.status == 200) {                        controller.abort();                        resolve(res)                    } else {                        reject(res)                    }                })        })    }))}

全站NPM静态化

此法chen独创，是一种比较野路子的手法，但加速效果显著。
通常建议用于Hexo等静态博客，WordPress等需要做好伪静态，并且要配置好动态接口。

hexo作为静态博客有什么好处，那当然是纯静态啦。生成的静态文件随便搬到一个web服务器都能用。

自然就有了接下的骚操作，用npm托管博客，然后在请求的时候用sw劫持并引流到npm镜像，效果就如同本博客所示，加载速度（抛开首屏不谈）接近于闪开。

首先我博客的CI是用GithubAction的，在部署的过程中顺便把html上传到npm是最简单不过的事情，只要在生成代码块后面再加一块：

- uses: JS-DevTools/npm-publish@v1  with:    token: ${{ secrets.NPM }}

配置NPM环境变量，之后需要更新的时候叠一个新版本就行。

然后接下来我们就要解决ServiceWorker获取问题。我们先设立一个监听器：

self.addEventListener('fetch', async event => {    event.respondWith(handle(event.request))});const handle = async(req)=>{    const urlStr = req.url    const urlObj = new URL(urlStr);    const urlPath = urlObj.pathname;    const domain = urlObj.hostname;    //从这里开始}

首先我们要判断一下这个域名是不是博客主域名,不然瞎拦截到其他地方可不好:

if(domain === "blog.cyfan.top"){//这里写你需要拦截的域名    //从这里开始处理}

我们还要记得给url进行提前处理，剥离出路径，去除参数。在这其中尤其要注意的是默认路由的处理。

通常情况下我们访问一个网址，web服务器会在后面添加.html后缀。对于一个默认路径则是index.html。

还要注意的是剥离#，不然又会获取失败。

定义一个fullpath函数，用于预处理和剥离路径：

const fullpath = (path) => {    path = path.split('?')[0].split('#')[0]    if (path.match(/\/$/)) {        path += 'index'    }    if (!path.match(/\.[a-zA-Z]+$/)) {        path += '.html'    }    return path}

结果类似于：

> fullpath('/')'/index.html'> fullpath('/p/1')'/p/1.html'> fullpath('/p/1?q=1234')'/p/1.html'> fullpath('/p/1.html#QWERT')'/p/1.html'

然后再定义一个镜像并发函数，用于生成待获取的网址：

const generate_blog_urls = (packagename, blogversion, path) => {    const npmmirror = [        `https://unpkg.com/${packagename}@${blogversion}/public`,        `https://npm.elemecdn.com/${packagename}@${blogversion}/public`,        `https://cdn.jsdelivr.net/npm/${packagename}@${blogversion}/public`,        `https://npm.sourcegcdn.com/npm/${packagename}@${blogversion}/public`,        `https://cdn1.tianli0.top/npm/${packagename}@${blogversion}/public`    ]    for (var i in npmmirror) {        npmmirror[i] += path    }    return npmmirror}

接下来我们将其填入主路由中:

if(domain === "blog.cyfan.top"){//这里写你需要拦截的域名    return lfetch(generate_blog_urls('chenyfan-blog','1.1.4',fullpath(urlPath)))}

然而谨记,npm返回的文件格式通常是text而非html，所以我们还要进一步处理header。处理也简单，连环then下去就行：

if(domain === "blog.cyfan.top"){    return lfetch(generate_blog_urls('chenyfan-blog','1.1.4',fullpath(urlPath)))    .then(res=>res.arrayBuffer())//arrayBuffer最科学也是最快的返回    .then(buffer=>new Response(buffer,{headers:{"Content-Type":"text/html;charset=utf-8"}}))//重新定义header}

那么接下来，除了首屏以外，你的网站相当于托管在全球(包括中国)各个主流cdn服务器中，提速效果无与伦比.如果你将原网站托管在cf，那么你将获得一个打不死，国内加载速度超快(首屏除外)的网站。

解放双手 - npm版本自定义更新

有人会问了，我为什么不能直接用latest来获取最新版本，还要手动指定？

简单地说，在生产环境中用@latest指定最新版本是一个很不合理、且非常愚蠢的操作。你永远都不知道对面的缓存什么时候清除，获取到的可能是一年前的版本。

为了节约成本，避免回源，cdn服务商通常会缓存资源，尤其是那些静态资源。以jsd为例，其latest缓存为7天，不过可以手动刷新。unpkg cf边缘2星期，eleme已经将近6个月没更新了。至于那些自建的。你根本搞不懂他什么时候更新，使用latest会导致随机获取到版本，接近无法正常使用。

而指定版本的，cdn通常会永久缓存。毕竟版本定死了东西是不会变的，而请求指定版本的cdn也可以或多或少提升访问速度，因为文件时永久缓存的，HIT的热度比较高。

sw端

利用npm registry获取最新版本，其官方endpoint如下：

https://registry.npmjs.org/chenyfan-blog/latest

其version字段即最新版本。

npm registry的镜像也不少，以腾讯/阿里为例：

https://registry.npmmirror.com/chenyfan/latest #阿里，可手动同步https://mirrors.cloud.tencent.com/npm/chenyfan/latest #腾讯，每日凌晨同步

获取最新版本也不难:

const mirror = [        `https://registry.npmmirror.com/chenyfan-blog/latest`,        `https://registry.npmjs.org/chenyfan-blog/latest`,        `https://mirrors.cloud.tencent.com/npm/chenyfan-blog/latest`]const get_newest_version = async (mirror) => {    return lfetch(mirror, mirror[0])        .then(res => res.json())        .then(res.version)}

在这里还有一个坑点：ServiceWorker的全局变量会在所有页面关闭后销毁。下次启动时会优先响应handle，其定义变量要在handle响应后才会执行。因此，对于最新版本的存储，不能直接定义变量，需要持久化，这里另辟蹊径，采用CacheStorage存储：

self.db = { //全局定义db,只要read和write,看不懂可以略过    read: (key, config) => {        if (!config) { config = { type: "text" } }        return new Promise((resolve, reject) => {            caches.open(CACHE_NAME).then(cache => {                cache.match(new Request(`https://LOCALCACHE/${encodeURIComponent(key)}`)).then(function (res) {                    if (!res) resolve(null)                    res.text().then(text => resolve(text))                }).catch(() => {                    resolve(null)                })            })        })    },    write: (key, value) => {        return new Promise((resolve, reject) => {            caches.open(CACHE_NAME).then(function (cache) {                cache.put(new Request(`https://LOCALCACHE/${encodeURIComponent(key)}`), new Response(value));                resolve()            }).catch(() => {                reject()            })        })    }}const set_newest_version = async (mirror) => { //改为最新版本写入数据库    return lfetch(mirror, mirror[0])        .then(res => res.json()) //JSON Parse        .then(async res => {            await db.write('blog_version', res.version) //写入            return;        })}setInterval(async() => {    await set_newest_version(mirror) //定时更新,一分钟一次}, 60*1000);setTimeout(async() => {     await set_newest_version(mirror)//打开五秒后更新,避免堵塞},5000)

再将上面的生成urls从:

generate_blog_urls('chenyfan-blog','1.1.4',fullpath(urlPath))

改为

//若第一次没有,则使用初始版本1.1.4,或者你也可以改成latest(不推荐)generate_blog_urls('chenyfan-blog',await db.read('blog_version') || '1.1.4',fullpath(urlPath))

此后用户加载时，会尽可能的获取最新版本，无需手动更新。

ci端

有了前端自动更新，我们在上传包的时候还要手动更新package.json中的version字段。其实这里也可以直接交给ci处理。

然而需要注意，npm version patch 虽然能更新z位数版本，但其更新不会上传到仓库。换句话说，这只能上传一次。因此这个地方我干脆建议用随机数，反正通过api获得的latest都是最新的上传。

案例代码这里不展示，实际上这一步做起来也不难。

调剂响应

缓存 - 互联网上一伟大发明

虽然我也不清楚有一小部分人对那么丁点CacheStorage缓存占用那么敏感，但至少，缓存对网站加载速度的提升有极大的帮助。

通常，有大量的资源是访问一个网站重复需要的，对于这些东西，浏览器会自带MemoryCache或DiskCache，但这一类缓存不是持久的，在下一次打开网站的时候缓存不一定生效。而CacheStorage是浏览器自带的缓存桶（Key/Value），这种桶是持久存储，长期有效，而sw是能控制这桶。

而不同的网域资源所应当采取的缓存策略也是不一样的。对于确定版本的静态资源，直接终生缓存；对于有时限的静态资源，应当不缓存或只缓存一小段时间。

CacheStorage不是sw专属的，你可以在前端和sw中同时控制它，这是几分样例代码：

const CACHE_NAME = 'cache-v1'; //定义缓存桶名称caches.open(CACHE_NAME).then(async function (cache) {    const KEYNAME = new Request('https://example.com/1.xxx') //定义KEY，[Object Request]    await cache.put(KEYNAME, new Response('Hello World')); //自定义填入    await cache.match(KEYNAME).then(async function (response) {        console.log(await response.text()); //匹配并输出    })    await cache.put(KEYNAME, await fetch('https://example.com/2.xxx').then(res=>res.arrayBuffer())); //使用fetch填入缓存    await cache.matchAll().then(function (responses) { //列出所有（也可以根据内容列出指定的项        for (let response of responses) {            console.log(response.url);        }    })    await cache.delete(KEYNAME) //删除指定项});

SetTimeout - 毫秒级调控响应

对于同一个网页，你需要合理的对他执行决策树，这是目前我的博客[网页]采取的决策树:

js里有两个对时间控制的古老函数：SetTimeout和SetInterval.在这里我采用SetTimeout,同时并行执行任务.

这里采用代码片段比较容易解释:

if (请求的网址是博客) {    //这里一定要用Promise,这样在之后settimeout就不需要回调,直接Resolve    return new Promise(function (resolve, reject) {        setTimeout(async () => {            if (存在缓存) {                setTimeout(() => {                    resolve(获取当前页面缓存(请求))                }, 200);//200ms表示下面的拉取失败后直接返回缓存,但下面的拉取不会被踢出,更新会在后台执行,会填入缓存,但也不会返回                setTimeout(() => {                    resolve(                        拉取最新版本的网页(请求)                            .then(填入缓存并返回内容)//返回缓存                    )                }, 0);//表示立刻执行,优先级最高            } else {                setTimeout(() => {                    resolve(                        拉取最新版本的网页(请求)                            .then(填入缓存并返回内容)//返回缓存                    )                }, 0);//表示立刻执行,优先级最高                setTimeout(() => {                    resolve(返回错误提示())                }, 5000)//5000ms后如果没有返回最新内容就直接返回错误提示,如果成功了此次返回是无效的            }        }, 0)//这里需要一个大settimeout包裹以便于踢出主线程,否则无法并行处理    })}

优化首屏

window.stop - 与死神擦肩而过

事实上，ServiceWorker最显著的缺点是要在第一次加载网页安装后，刷新一次才能激活。即访客第一次访问是不受sw控制的。换句话说，访客首屏不受加速，其加载速度与你的服务器有直接联系 [虽然安装完成后就起飞了,但安装前就是屑]。

而本人未成年，浙江的规定又是未成年不得备案，在加上之后备案主题切换异常的麻烦。我的决定是至少高考前都不会备案。那这后果就很直接，我并不能使用国内的cdn节点。再加上我又没这个经济实力用香港CN2或拉iplc专线，对首屏服务器这一块优化其实能做的很少。

更加令人抓狂的是，在首屏加载时，静态资源会被直接获取，并且不缓存，而sw激活后又会强制第二次获取，拉跨速度。

不过我们可以尽可能弱化这一劣势。我们可以用js打断所有的请求，以确保首屏只加载一个html和一个sw.js，其余资源都不会加载，降低首屏加载延迟。

我们尽可能将打断代码提到<head> 以确保不被其他资源堵塞，对于hexo来说打开主题的head.ejs，在<head>标签靠前的位置中加入：

(async () => {//使用匿名函数确保body已载入    /*    ChenBlogHelper_Set 存储在LocalStorage中,用于指示sw安装状态    0 或不存在 未安装    1 已打断    2 已安装    3 已激活,并且已缓存必要的文件(此处未写出,无需理会)    */    const $ = document.querySelector.bind(document);//语法糖    if ('serviceWorker' in navigator) { //如果支持sw        if (Number(window.localStorage.getItem('ChenBlogHelper_Set')) < 1) {            window.localStorage.setItem('ChenBlogHelper_Set', 1)            window.stop()            document.write('Wait')        }        navigator.serviceWorker.register(`/sw.js?time=${ranN(1, 88888888888888888888)}`)//随机数,强制更新            .then(async () => {                if (Number(window.localStorage.getItem('ChenBlogHelper_Set')) < 2) {                    setTimeout(() => {                        window.localStorage.setItem('ChenBlogHelper_Set', 2)                        //window.location.search = `?time=${ranN(1, 88888888888888888888)}` //已弃用,在等待500ms安装成功后直接刷新没有问题                        window.location.reload()//刷新,以载入sw                    }, 500)//安装后等待500ms使其激活                }            })            .catch(err => console.error(`ChenBlogHelperError:${err}`))    }})()

当然了，这回导致白屏500ms，如果你觉得不好看，也可以和我一样载入一个等待界面，将document.write()改为:

document.body.innerHTML = await (await fetch('https://npm.elemecdn.com/chenyfan-blog@1.0.13/public/notice.html')).text()

即可

主服务器优化 - 绝望中的最后一根稻草

实际上我一直以为，主服务器的优化在整个网站中是最必要的，也是最不重要的。必要的原因是它关系到最初的加载速度，也是访客中最主要的一环；不重要的是相对于静态资源的记载、页面的渲染和脚本的编译，首屏的加载对整体效果太小了。

尤其是在sw托管后，之后的所有访问，除了sw的更新（以及所有镜像源全炸后），基本与主服务器脱离了关系，正常访问与其没有关系。加速源站实则没有必要。

当然，你说有用吗，那肯定还有点用处，至少首次加载不至于卡人心态。我的要求很简单，能在600ms内完成首次html下载的基本就没问题了。
最优的无非是香港CN2，不过我们没这个能力。退而求其次，普通的香港服务器我们也能接受。不过依旧是白嫖至上的念头，我才用了Vercel。Vercel也是可以自选节点（主要是亚马逊和谷歌）的，我稍加测试【主要注重可连接性，其次是延迟。丢包和速度作为建站（尤其只有一个10kb的网页）最次】，决定使用一下策略：

电信 104.199.217.228 【台北 谷歌Cloud】 70ms （绕新加坡 但是是质量最好的）联通 18.178.194.147 【日本 亚马逊】 45ms （4837和aws在tyo互联）移动 18.162.37.140 【香港 谷歌Cloud】 60ms （移动去香港总是最好的选择）

在这里，不推荐其他地区的理由是：

电信：基本上除了台北，去GoogleCloud的都是走日本ntt × ； 亚马逊这一块有大部分绕美，去日本延迟异常的大。
联通：去香港的绕美了，去日本这一条存在这直接的互联点，负载比较小，延迟也不错。
移动：没什么好说的，移动互联除了去亚太的都是垃圾。

后记

一张思维导图总结全文，你学废了吗？

“共和国勋章”获得者、中国工程院院士、国家杂交水稻工程技术研究中心主任、湖南省政协原副主席袁隆平，因多器官功能衰竭，于2021年5月22日13时07分在长沙逝世，享年91岁。

感谢袁老，让我们端的起饭碗，让我们00后的孩子至少吃得饱。一路走好。

我的博客即将同步至腾讯云+社区，邀请大家一同入驻：https://cloud.tencent.com/developer/support-plan?invite_code=3uzi7w7znlsa

众所周知，CloudFlare曾开放CloudFlarePage内测资格申请，如今我获得了资格，免费享受边缘部署岂不美哉！可万万没想到，简单的迁移过程会出现如此问题

据我所知，使用CloudFlare做hexo无非以下两种：

• GithubPage+CloudFlareCDN
• CloudFlareWorkerKV+ClouFlareWorkerSite

CloudFlare早先时候支持WorkerSite，当时KV照实没有免费，我也不想为了100ms的回源耗时而花费金钱。不过后来KV在一定额度上免费了，打开WorkerSite的文档，第一步wrangler直接把我劝退。

笑话，国内使用wrangler，那还不如CloudFlare+GithubPage。

苏卡卡大佬写的一篇文章讲述了自己部署WorkerSite的经历，ChrAlpha’s Blog也曾提到过迁移的过程。不过我懒，我觉得100ms回源不算什么，赔个Worker还是有点亏。

2020年11月份，偶然得知CFPage正在公开招聘Pagebeta计划，抱着试试看的心理，我简单写了些就交了上去。凭借着对CloudFlare发布新产品小心翼翼的态度，我揣摩估计很难申请到。果不其然，年都过了，连封邮件都没通知我。

2021年2月20日，我先日常翻了遍邮件，0。正准备继续开发HexoPlusPlus，登陆CloudFlare，却发现右边多了个新玩意：

不愧是我，我一眼就看出来我的CFPage申请到了。

迁移

由于我的博客源码在Github上，而CFPage只能从Github上获取源码。
我面向中国大陆CDN有一部分用的也是CloudFlare，通过BNXB第三方接入。
因为之前用的就是GithubAction的集成部署，所以package.json已经配置完成了。

那么我看起来确实是最佳的接入选择。

首先，进去，点击创建项目选择博客的github存储库，获得GithubAccess权限后跳转到这：

勾选需要接入的项目

• 构建设置 - 框架预设

由于之前吃过Vercel的亏，不想选Hexo，但是抱着试试看的心态，还是选择了内置的hexo。

选择之后，后面的构建命令和构建输出也直接填好了，保存并部署？

因为本博客使用了neat而不是gulp插件压缩html管他呢反正丢CI，所以构建时间会比较长。

修改CNAME记录和TXT记录，分别去BNXB修改CNMAE和DNSPOD【NS所在处】修改TXT记录

就好了？就好了。

这是我最快的迁移速度

NetWork选项卡里出x-server: Cloudflare Pages说明迁移完毕。

使用体验

简洁，加载速度快，这是我第一个感受。

用GithubAction老是卡在同一个界面不会动，要手动刷新一下才能出来，而且加载的东西贼多，我这台破笔记本有点卡。

CloudFlarePage则轻巧的多，并且部署状况很快就能体现出来。

无缝切换，这是我的第二个体验。

以前换CI换CDN的时候，非得断掉先然后才能切换回来，现在两步走之后，直接在dns平台修改无缝迁移，体验良好，总耗时不超过10分钟。

鉴于CloudFlare在国内的连接情况，电信这一条线我还是切回vercel【也是0回源】，其他的走CloudFlarePage

平台还是beta，这是第三个感受。

我删不掉已经添加的域名，这是我最纳闷的一点。

然后我不想让cfpage检测我的gh-pages分支，因为GithubAction还有存在的必要，但是CFpage每每还是检测pages分支，然后扔出部署失败，提示错误。

这两个问题我已经丢论坛里了，目前还未回复

至于快多少，因为没有免费版本Argo做对比，也没有大量数据做对比，目前无法得出结论。

真的要说快多少，因为大部分静态资源切jsd上，所有经过cf的只有一个单html，至少我在国内大环境下，我还没体会出100ms能快多少(´இ皿இ｀)

另外CloudFlarePage用的证书很奇怪，可能是为了CNAME兼容性，不用自己自家的证书，反而用Let’s Encrypt，鉴于OSCP在国内阻断，ios用户可能会出现首次访问白屏，这一点我有点担心。

最好的一点莫过于完全贴合HexoPlusPlus了，以后我就有充分的理由宣传HPP了

额度

• 每月构建次数：500次

【用了HPP，构建次数再多也不够500/mo，这一点我还是放心的，再说我常年咕咕咕】

• 自定义域名：10个 【我也没这么多域名】

• 文件：2w个【绝对用不完】

• 总大小：25MB【图片啥的都扔图床，其实也就5MB】

• 带宽：无限制【！！！】

然后我切回来了

高高兴兴的搞完了CFPage部署，水了这篇文章去吃饭。吃完饭后回来一看谷歌统计，好家伙404的怎么这么多。

还好之前的GithubPage没有删掉，去bnxb赶紧切了回来。

完了我也经历了和Sukka大佬一样的问题

问题很容易定位，所有的404来自cfpage而非vercel。

首先是Vercel，开代理的情况下国外访问均正确解析至vercel，可以在x-vercel头里看出来

地址是https://blog.cyfan.top/p/52382e42.html，相应代码是200

关闭代理，将自动选择CloudFlareCDN+GithubPage，可以从x-github-request-id看出

地址是https://blog.cyfan.top/p/52382e42.html，相应代码是200

然后是有问题的CFPage，可以在x-server头里看出来

地址是https://blog-9una.pages.dev/p/52382e42.html，相应代码是308跳转，跳向https://blog-9una.pages.dev/p/52382e42，CFPage会把末尾.html抹掉

抹掉就罢了,结果在vercel这边又出问题

但是最奇葩的是,githubpage是允许不带html裸访

这就是整个经过,CFPage必须抹掉后缀,GithubPage保持无所谓,Vercel必须不能抹掉

解决办法

先从自己入手，CFPage和vercel不能共留，干掉vercel？好主意，毕竟国内访问CF并无大碍，但是有个大问题梗在面前，评论怎么办，之前的收录怎么办，首页链接不一致怎么办？

我又不想抛弃CFpage，于是试图和Sukka大佬针对中文解码一样来个拯救计划，结果发现，CFPage不开源……

后来仔细翻了一遍文档才发现，这样是有意为之，故意删掉后缀名。

的，切回Github+CFCDN，这一早上的折腾白费了( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃

写在最前面
自从这篇博文发布后，OneIndex迎来了一次重大更新，去除了FireBase依赖，转用KV存储刷新令牌。本片教程已过时，具体会在春节前后更新最新版本。

OneDrive，相信大家都不陌生，微软家的网盘，虽说有类似于OneManager一样的目录列表程序，但是直连海外总是会遭受严重的丢包，得到极其糟糕的体验。这时候CLoudFlare作为不那么好使的CDN就排上用场了，项目onedrive-cf-index 解决了这个问题,但是据我观察,这个仓库作者应该是个中国人,但是readme文档可不是中文,这对一些使用者造成了一定的困扰,而且文档相当言简意赅,这一篇文章相当于文档的中文翻译和使用教程.

使用前言
部署此项目较为麻烦,请确保你满足以下俩个及以上想法后,才继续往下读:

1. 我非常需要搭建于CloudFlare的OneDrive目录列表吗?
2. 我非常需要这个版本的目录列表吗?
3. 我有这个耐心吗?
   如果没有,那么我们建议你可以使用另一个功能和UI稍差的cf目录列表OneDrive-Index-Cloudflare-Worker 这个版本有不是很详尽的中文文档,并且较为简单,或者试试一步生成的GDIndex,可以参考我之前写的GDIndex部署参考

简介

新功能

• 新设计： spencer.css。
• 根据文件类型呈现的文件图标。
• 使用“Font Awesome icons” 图标代替材料设计图标（以获得更好的设计一致性）。
• 使用github-markdown-css进行README.md渲染
• 添加Cookie以更好地进行目录导航。
• 支持文件预览：
• 图片：.png，.jpg，.gif
• 纯文本：.txt
• 文档：.md，.mdown，.markdown
• 代码：.js，.py，.c，.json。
• PDF：延迟加载，加载进度和内置的PDF查看器
• 音乐/音频： .mp3，.aac，.wav，.oga
• 视频： .mp4，.flv，.webm，.m3u8

…

• 代码语法以GitHub样式突出显示。（使用PrismJS。）
• 图像预览支持中型缩放效果。
• 使用Google Firebase实时数据库缓存和刷新令牌。（对于那些负担不起Cloudflare Workers KV存储的人。 😢）
• 在Turbolinks®的帮助下进行延迟加载。（从folder转到时有些问题file preview，但不会降低用户体验。）
  …

在这表面下:

• 一直以来都是CSS动画。
• 使用wrangler和webpack打包源代码。
• 转换所有CDN以使用jsDelivr加载。
• 没有外部JS脚本，所有脚本都已通过webpack加载！（除了某些库。）

…
所有其他功能

请参阅：新功能| OneDrive-Index-Cloudflare-Worker。

开始

导入此项目

请注意!
请不要Fork此项目,
在这个过程中你将会获取到数串token,fork的仓库无法转为私有仓库,这将会对你的数据造成威胁.

点击右上角的 + 号选择Import项目

原先仓库地址填写https://github.com/spencerwooo/onedrive-cf-index,新仓库名称随意,仓库类型必须改为Private私人,最后导入

导入成功,进入repo:

获取Token

进入https://heymind.github.io/tools/microsoft-graph-api-auth 开始准备你所需要的东西：

进入https://portal.azure.com/#blade/Microsoft_AAD_RegisteredApps/ApplicationsListBlade，注册一个新app【使用微软账号】

几番跳转后，来到这样的界面：

注意，我们强烈建议用英文界面，中文界面可能存在翻译错误产生误导

点击OneIndex，进入应用详情

点击 Redirect URIs 修改跳转链接:

将此处改为 https://heymind.github.io/tools/microsoft-graph-api-auth

设置API：

至少选择 offline_access, Files.Read, Files.Read.All .

返回，获取 Application (client) ID

在这里填上复制的client id，并点击AUTHORIZE验证

你会发现跳转一段时间后又回到了拉取界面,不过多了一个提示框,上面写着已经获取到Code

接着我们获取Secrets,点击 Certificates & secrets,进入该选项卡:

新增一个:

名字随意,期限为永久:

复制生成的密钥,请注意此处密钥仅出现一次,以后就不会再出现了

将获得密钥粘贴进第五步:

点击GetToken,将跳转至如下界面:

此处若失败，请重试第四步

将获得字段的refresh_token写入，重新制得token：

取得token：

妥善保管，接下来我们会用到。

OneDriveToken完毕，接下来进入FireBase教程：

作为数据库存储，原本采用的是cloudFlareKV存储，但考虑到大部分用户没有这个钱去买KV，于是采用了第三方存储。

进入https://firebase.google.com/

开始创建项目：

项目名字随意，下一步

一直下一步，稍后将进入管理界面

选择Database，将其设置为发布模式，禁用写入权限，在数据一栏中添加key，名字为value,值为 https://项目名.firebaseio.com/auth.json ，如我的：
https://oneindex-chenyfan.firebaseio.com/auth.json

点击右上角的小齿轮-项目设置-服务账号-旧版凭据-数据库账号-显示密钥，复制密钥。

FireBase教学完毕。

配置CloudFlare

登录你的CloudFlare，点击右上角，账户设置：

选择API令牌选项卡，生成新的API：

选择自定义令牌：

配置至少如下，可以选择增加

点击获取API令牌

接着还要获取账户ID和区域ID

进入任意一域名，右侧拦里头会有俩ID，复制：

到这里，你获取了以下所有密钥：

• Azure-refresh_token
• Azure-client_id
• Azure-client_secret
• GoogleFireBase-firebase_url
• GoogleFireBase-firebase_token
• CloudFlare-APIToken
• CloudFlare-ZoneID
• CloudFlare-AccountID

八个Token，切勿丢失 累死我了

配置OneDrive

用微软账户登录OneDrive，新建文件夹，名字为“Public”

本地wrangler部署

由于此篇教程具体将GithubAction实现无服务器部署，本块内容一笔带过，请直接看到GithubAction部署一块

本地安装依赖环境

yarn global add @cloudflare/wrangleryarn install

用wrangler登录CloudFlare

wrangler config

wrangler.toml 修改

name: The draft worker's name, your worker will be published at <name>.<worker_subdomain>.workers.dev.account_id: Your Cloudflare Account ID.zone_id: Your Cloudflare Zone ID.

src/config/default.js 修改:

client_id: Your client_id from above.base: Your base path from above.firebase_url: Your firebase_url from above.

添加环境变量:

wrangler secret put REFRESH_TOKENwrangler secret put CLIENT_SECRETwrangler secret put FIREBASE_TOKEN

部署命令:

wrangler publish

GithubAction部署

GithubAction部署

进入你导入的仓库，点击 wrangler.toml

• name ==> 默认生成为<#name>.<#User>.workers.dev，随意
• account_id ==> CloudFlare-AccountID
• zone_id ==> CloudFlare-ZoneID

进入/src/config/default.js

• refresh_token ==> Azure-refresh_token
• client_id ==> Azure-client_id
• client_secret ==> Azure-client_secret
• redirect_uri ==> ‘https://heymind.github.io/tools/microsoft-graph-api-auth'
• firebase_url ==> GoogleFireBase-firebase_url

修改样式

src/render/htmlWrapper.js : 修改标题

src/folderView.js : 修改介绍

设置密钥

密钥名：CF_API_TOKEN

内容: ==> CloudFlare-APIToken

激活Action：

设置CloudFlare变量

进入新创建的Worker：

• CLIENT_SECRET ==> Azure-client_secret
• FIREBASE_TOKEN ==> GoogleFireBase-firebase_token
• REFRESH_TOKEN ==> Azure-refresh_token

部署，发布，绑定域名【可选】：

成品：

Demo:https://onedrive.cyfan.top

后言

其实默认才5GB，还不如GoogleDrive香，但是据说白嫖E5开发者还不错。

OK就到这了，还不懂的欢迎评论区，或者去官方github地址发issues。