perf(template-compiler): optimize all static nodes

[nolanlawson]

Details

Fixes #2890.

Rather than avoiding unsafe top-level elements like <td> and <th>, we can use a <template> for parsing these. This allows us to extend the static optimization to more elements.

To support IE11, we can fall back to a partial implementation of the <template> element borrowed from webcomponents/polyfills. So this PR is not dropping IE11 support.

Does this pull request introduce a breaking change?

• ✅ No, it does not introduce a breaking change.

Does this pull request introduce an observable change?

• ✅ No, it does not introduce an observable change.

[nolanlawson]

The tests are passing in all browsers, and as a reminder, we have a Karma test for static <td>s. 🙂

lwc/packages/@lwc/integration-karma/test/static-content/index.spec.js

Lines 172 to 186 in dba53e7

	describe('tables and static content', () => {
	it('should work with a static <td>', () => {
	const elm = createElement('x-table', { is: Table });
	document.body.appendChild(elm);
	expect(elm.shadowRoot.querySelectorAll('td').length).toEqual(0);
	elm.addRow();
	return Promise.resolve().then(() => {
	expect(elm.shadowRoot.querySelectorAll('td').length).toEqual(1);
	expect(elm.shadowRoot.querySelector('td').textContent).toEqual('');
	});
	});
	});

[nolanlawson]

I considered caching and re-using the template here, but I decided against it because:

1. This is just a one-time setup cost anyway – it wouldn't improve any of our benchmarks
2. Holding onto the memory from the last HTML in the cached template strikes me as a little weird
3. I'm not even sure if it's a big perf improvement in the first place

We might explore caching the template in a follow-up PR, though.

[nolanlawson]

/nucleus test

[jodarove]

does tfoot, colgroup, tbody and caption also need to be on this map? (I don't think you can add head, body and html on an lwc template)

[nolanlawson]

Nice catch! Fixed and added a test to make sure it actually works in IE11. I did not include head/body/html.

[jodarove]

why we use .lastChild here, and .firstChild at the end?

[nolanlawson]

That was copypasta from webcomponents/polyfills here, but I think you're right; we can just use firstChild which is less confusing.

[nolanlawson]

Fixed, switched to firstChild.

[jodarove]

🥇

[jodarove]

Suggested change

	for (let i = 0; i < wrapperTags.length; i++) {
	for (let i = 0, n = wrapperTags.length; i < n; i++) {

[nolanlawson]

Last I checked, JS engines have optimized this; there's no need to cache the length.

There is some discussion on SO, although sadly all the JSPerf links are dead now. 😢

[nolanlawson]

OK, found a post from a V8 engineer; we do not need to cache length. 😁