quicklink学习以及结合React

介绍

谷歌团队在几个月前开源了一个项目,叫quicklink。官方给出的介绍是

Faster subsequent page-loads by prefetching in-viewport links during idle time

这里简单的介绍一下这个项目,并且说明一下为什么我需要fork这个项目~

quicklink的源码很简洁,作用可以用一句话总结: 利用空闲时间来缓存界面上看到的链接,加快这些链接的访问速度。

所以quicklink的作用是在下一个链接快速打开,而不是当前链接,这一点和很多其他优化都不一样。

原理很简单:

  • 获取页面上所有的A标签(注意,这里的a标签指的是调用函数的时候document下的a标签)
  • 等待浏览器空闲 (requestIdleCallback 或者用 setTimeout 做兼容)
  • 利用 IntersectionObserver 做监控,当监控的dom进入视图,就开始预加载
  • 与获取视图内的URL(<link rel="prefetch"> or XHR or fetch),以获得快速访问该链接的效果

代码真的很简洁,很棒,这边没必要再贴出来,有兴趣的直接github fork一个去看或修改,除去注释代码量加起来不到200行

forked

我fork该项目之后修改了一些东西

默认添加了polyfill,直接打到包里

为什么要加polyfill呢? 因为IntersectionObserver 虽然好用,但是pc端IE11都不支持,移动端也要到了IOS12 safari才支持…支持面太窄了而且不用polyfill的话,直接报错….所以权衡之下,干脆直接全量引用IntersectionObserver的polyfill,gzip情况下整个包加起来才3.5k 值了。

添加了quicklink全局配置

在包里写了 quicklinkOptions 对象,这样每次调用 quicklink 的时候就可以公用一些配置,而不需要每次调用都塞一样的配置进去,至于为什么提到每次调用…后面会解释到

添加了manualPreFetch方法: 手动绑定某些dom监听

manualPreFetch 方法,就是手动的意思,支持传入这些参数{dom, isForce, link, priority}
为什么需要加多个方法呢? 因为我发现 quicklink 只支持扫<a>标签去获取link,但是很多情况可能我们不是用a标签,而是类似写一个button,点击之后js控制跳转。 虽然说我们可以在代码层用button包a链接等方式去实现,但是这样就太局限了,所以才加了个方法。

1
2
3
4
5
6
7
// html
<button id="btn">跳转到xxx</button>

manualPreFetch({
dom: document.getElementById('btn'),
link: 'www.easyrentcars.com',
});

该方法和 quicklink 一样,也是监听dom滚到当前位置才会发起预加载。这里会读取一部分的quicklinkOptions,这就是我加多个全局配置的原因了,不需要每次调用的时候都写一堆

增加了manualRemovePreFetch方法: 手动删除监听预加载

添加个移除的方法,只是简单的移除掉要监听的dom,虽然对性能不会造成影响…但是就是有点强迫症鸭🦆

React demo

quicklink是在执行的时候用 (el || document).getQuesySelectorAll('a') 去获取页面上的<a>,所以对于React就比较尴尬了,渲染是异步的,如果调用早的话,肯定是拿不到,那什么时候调用这个才是最佳时机?

比较通用的是componentDidMount 或者是UseEffect。不过个人比较建议配合manualPreFetchmanualRemovePreFetch对一些比较重要的加就好了,因为很多都是异步之后再渲染,可能 componentDidMount的时候,你需要预加载的链接还没出现。

这里简单给出两个关于React的通用demo。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
import React, { useEffect, useRef } from 'react';
import quicklink, { manualPreFetch, manualRemovePreFetch} from '@jsonz/quicklink';

// class 类型
class QuicklinkComponent extends React.Component {
constructor(props) {
super(props);
this.refRoot = React.createRef();
}

componentDidMount() {
// didMount 监听组件内所有的a链接
quicklink({
el: this.refRoot.current,
});
}

componentWillUnmount() {
// willunmount 移除所有的a链接监听
batchManualRemove(this.refRoot.current);
}
render() {
return <div ref={this.refRoot}>{this.props.children}</div>
}
}

// hook 类型
function QuicklinkDemo() {
const refRoot = useRef(null);

useEffect(()=> {
quicklink({
el: refRoot.current,
});
return ()=> {
batchManualRemove(refRoot.current);
}
});

return ( <div ref={refRoot}>{this.props.children}</div> );
}

3.1 致夭折的小ql

本来已经加在项目上,打算拿一个项目/页面来试点,不过最后被说服暂时不用,原因有三

  1. quicklink 可能会对后端造成不小的压力,比如你的网站一打开,滑到最底部,那中间可能就会预加载20个链接….然而用户可能一个都不打开就关闭,那就白白给服务器添加20个请求,对于量比较大的网站,可能会很坑爹。总结来说就是命中率太低,不过可以改成做针对性的预加载,比如下单页预加载支付页的。
  2. 只能预加载document,对于页面上占大头的js引用等静态资源没有起作用。效果可能对于实用站点不明显,对文章类会好很多。
  3. 针对前面两种情况,好像pwa能做的会更多? 所以如果是过渡方案或文字类(document)资源占比比较多的用quicklink比较好。

但是项目上的pwa比较残疾,之前做的同事做了一版之后就离职了…一直没人去维护,所以pwa要被提上日程?

补一个问题,我直接在quicklink内打polyfill不是很好,因为如果项目上也引用这个Polyfill就会重复了。

告辞