Replace cheerio with native API

[curbengh]

Feature Request

From the benchmark (performed by @SukkaW) we can see that cheerio can cause significant performance hit.

While cheerio is not necessary for the core functions of Hexo, it is currently utilized by several default plugins:

• meta_generator.js
• external_link.js
• toc.js
• open_graph

We are hoping to re-implement them without depending on cheerio, if possible.

Related PRs:

• meta_generator: perf(meta_generator): re-implement as a helper  #3669 perf(meta_generator): drop cheerio #3671
• open_graph: perf(open_graph): only require cheerio when content contains '<img' #3670 perf(open_graph): replace cheerio with dom-parser #3679 refactor(open_graph): drop cheerio and use regex #3680
• external_link: perf(external_link): drop cheerio and use regex #3685
• toc: refactor(toc_helper): utilize hexo-util #3850

Related issue:

• Speed up generating speed #550

[curbengh]

Can this be part of the roadmap?
@NoahDragon

[SukkaW]

Cheerio use perse5 now and use htmlparser2 before.

There is a benchmark between NodeJS side dom parser: https://travis-ci.org/AndreasMadsen/htmlparser-benchmark

[curbengh]

That means cheerio@1.x is slower than cheerio@0.x. (Edit: not necessarily after benchmark)

---

After a glance through the htmlparser2, I wonder if we can use it directly, instead of via cheerio; not sure if that can bring perf benefit.

[SukkaW]

@curbengh Hexo is now using cheerio@0.22
Maybe we should first test the performance of hexo using cheerio@1.x, to see is it actually slower.

Update

Here is the result:

Test A

latest hexo master branch, with meta_generator commented out.

Test B

sukkaw/hexo#bump-cheerio-1.x using github:curbengh/cheerio#decode-test, with meta_generator commented out.

The cheerio@1.0.0-rc3 is even slightly faster than cheerio@0.22.

[curbengh]

Interesting, perhaps cheerio@1.x includes some optimizations that somehow negate the latency of parse5. Judging from cheeriojs/dom-serializer#85, cheerio@1.x dropped decodeEntities and xmlMode options, maybe that's why it's faster.

This also means parse5 may not be that slow, so we can consider it in addition to htmlparser2.

[segayuu]

The DOMParser package performs high-speed analysis according to web standards Draft.
However, it may be inconvenient because it is a pure parser.

[curbengh]

DOMParser looks promising, too bad it can't do any manipulation.

---

Just realized DOMParser can be utilized in open_graph since it just needs to parse.

---

and in unit tests.

Edit: Unit test is usually tiny (<5 posts), so the improvement might not be noticeable.

[curbengh]

I just tried re-implementing toc using dom-parser. Somehow parentNode doesn't work, to replace $.parent().

const DomParser = require('dom-parser')
const source = `<span class="john">hey<h1>aaa</h1><h2>bbb</h2><h3>ccc</h3></span>`
const dom = new DomParser().parseFromString(source)
const heading = dom.getElementsByTagName('h1')
console.log(heading[0].parentNode)
// null

const cheerio = require('cheerio')
const $ = cheerio.load(source)
console.log($('h1').parent().attr('class'))
// john

[SukkaW]

cheerio is easy to use, and I think the problem of cheerio is it will become very slow when it need to load huge content (for small content cheerio will consume 11ms, for huge content cheerio might consume 65ms).
We might try to use regex to obtain small fragment, then let cheerio to load and manipulate that fragment.

[SukkaW]

For the optimization for toc() helper, I start with conditional require cheerio and return before cheerio.load: sukkaw/hexo:lazy-cheerio-for-toc. But the performance dropped by 5%, so I stopped.

@curbengh do you work out the dom-parser problem?