Improve build perf

[FredKSchott]

Changes

While working on the docs repo, I chased down two performance issues related to docs build:

1. ssrPreload appears to be mostly serial work, so 142+ pages of of docs inside a Promise.all() all blocked each other from completing. This hung the build entirely when I switched the docs parser over to Shiki (see next).
2. Our Shiki markdown plugin and Code component are both unoptimized. After digging into why the build failed once moving over to Shiki, i tracked down the fact that getHighlighter is the most expensive part of shiki, and we were calling it once per page. Caching this for later returned improvement to previous Prism-levels.

@sarah11918 FYI both of these together were causing the failing builds you were seeing when we enabled that config change.

Testing

• Covered by existing tests, all changes were perf based

Docs

• N/A

[changeset-bot]

🦋 Changeset detected

Latest commit: 85140d7

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
@astrojs/markdown-remark	Patch
astro	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[natemoo-re]

LGTM! Nice improvements. 👍🏻

[tony-sull]

lgtm! I'd be curious to see if there's any gains by parallelizing in chunks or with a worker pool, but I'm totally on-board with simplifying this now and looking into optimizations down the road 👍

[matthewp]

lgtm, we can also potentially remove preload entirely if we were to make it a rule that the <Component> name matches the import import Component from './whatever'; That would mean you couldn't do:

---
import Namespace from 'namespace';
const Div = Namespace.Div;
---

<Div />

But we could support this instead:

---
import Namespace from 'namespace';
---

<Namespace.Div />

Seems like an ok restriction to me.

---

edit: this restriction really only needs to apply to client: components. Server-only ones does not matter. We would need it for client: so that the compiler statically would know which files to bundle.

[matthewp]

Note that there are a couple of (code) changes that would be needed to get rid of the preload step, but that's the only one that would be a breaking change (I think).

[matthewp]

Thinking more about it, using runtime variables as component names for client component is already not going to work, so this restriction already kind of exists just not officially.

[FredKSchott]

lgtm, we can also potentially remove preload entirely if we were to make it a rule that the <Component> name matches the import import Component from './whatever'; That would mean you couldn't do:

---
import Namespace from 'namespace';
const Div = Namespace.Div;
---

<Div />

But we could support this instead:

---
import Namespace from 'namespace';
---

<Namespace.Div />

Seems like an ok restriction to me.

edit: this restriction really only needs to apply to client: components. Server-only ones does not matter. We would need it for client: so that the compiler statically would know which files to bundle.

I would be okay with this if there's a really clear error or warning when you break the rule.