Shiki: Syntax Highlighting With Zero Runtime

A technical blog that highlights code in the browser ships a highlighting library plus a grammar for every language it supports, then runs it on the main thread while the reader waits. For content that never changes after publication, this is work done at the worst possible time.

Shiki does it during the build.

The idea

It uses TextMate grammars and themes — the same ones VS Code uses. So the output does not merely look similar to your editor; it is produced by the same rules, which is why nobody has to maintain a second, worse regex-based highlighter.

Copy codeimport { codeToHtml } from 'shiki'

const html = await codeToHtml(source, { lang: 'ts', theme: 'github-dark' })

html is a <pre> with inline colours. It goes into the page as content. The browser receives text and renders it. There is no library, no grammar download, no flash of unhighlighted code, and no layout shift when the highlighter finally runs.

Two themes, one output

Copy codeconst html = await codeToHtml(source, {
  lang: 'ts',
  themes: { light: 'github-light', dark: 'github-dark' },
})

This emits CSS variables rather than fixed colours, so light and dark mode both work from a single build with a media query — no second render pass and no theme flicker.

Where it fits

Anywhere content is known at build time: static blogs, documentation, changelogs, marketing pages with code samples. Which is most places code appears.

Genuinely dynamic code — a live playground, user-submitted snippets, a log viewer streaming in — still needs runtime highlighting. For that there is a WASM-backed browser build, but be deliberate: that is a real bundle, and it is only worth it when the content truly cannot be known in advance.

The general principle

This is a specific instance of a rule worth applying everywhere: work that can happen once at build time should not happen once per visitor. Markdown rendering, date formatting for static content, image resizing, table-of-contents extraction — all of it is cheaper for everyone if it runs on your machine instead of theirs.

The site you are reading follows exactly that rule. Articles are markdown, rendered during the build, prerendered to HTML per route. The JavaScript that ships is for interaction, not for producing text that was already known.

Resources

• Repo: shikijs/shiki
• Docs: shiki.style
• Video walkthroughs: YouTube: shiki syntax highlighting setup
• Related: Core Web Vitals on an image-heavy site