Jsonz bug-log

后续更新会放在 github.com/jsonz1993/blog

0%

quicklink学习以及结合React

Posted on Edited on In

介绍

谷歌团队在几个月前开源了一个项目，叫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。不过个人比较建议配合manualPreFetch、manualRemovePreFetch对一些比较重要的加就好了，因为很多都是异步之后再渲染，可能 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
42
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就会重复了。

告辞