Once an archive passes around 300 articles, deploying a fix for a single typo starts taking two minutes. Faced with that waiting time between wanting to make a fix and seeing it published, writers begin to give up on making edits altogether.
This is a situation companies running in-house owned media usually run into around their second year. At launch, nobody minds because there are only a few dozen posts. By the time content becomes an asset, build times have quietly climbed.
The true culprit behind the slowness: passing through Markdown repeatedly
When a static site generator converts Markdown into HTML, multiple internal processes run sequentially on each article. It parses the file, builds an abstract syntax tree, applies plugins to that tree one after another, and finally writes out the HTML. This plugin sequence repeats for every single article.
That means running JavaScript processes a dozen or more times per post across several hundred posts. Even if the difference per article is only a few milliseconds, the multiplied total emerges as your build time. In short, the slowness is not caused by heavy articles, but rather by how the conversion architecture scales linearly with post count.
Sätteri replaced this sequence with Rust
Sätteri, adopted by Astro, is a Markdown/MDX processor rewritten in Rust for this conversion step. Maintained by Astro core contributor Erika under the Bruits collective outside the Astro organization, it is now a core dependency of the framework.
Under the hood, it uses pulldown-cmark for CommonMark parsing and Oxc for parsing MDX expressions. The key is that frequently used features—such as GFM tables, smart punctuation, and syntax highlighting hooks—are implemented natively in Rust rather than via plugins. This is where the speed comes from.
Astro's own benchmarks report build time reductions of 15% to 61%.
| Target | Before | After |
|---|---|---|
| astro.build | 62.70 seconds | 24.24 seconds |
| Cloudflare developer documentation (8,431 pages) | 386.89 seconds | 261.94 seconds |
Note that larger scale does not necessarily mean greater gains. The reduction was 32% for a site with 8,431 pages, yet 61% for the official site; the rate of reduction depends on what your plugins are doing rather than page count.
What to verify in exchange for higher speed
This is where the decision diverges. Sätteri is designed to support flexible JavaScript plugins on top, maintaining compatibility with the unified ecosystem. Even so, sites relying on custom plugins need thorough verification before migrating.
To take a concrete example: this GH Media repository uses two custom rehype plugins. One is rehype-bold-fix.mjs, which remedies cases where **強調** adjacent to full-width characters is not converted to <strong>. In Japanese Markdown, placing emphasis immediately after punctuation or brackets sometimes prevents conversion, so we supplement that behavior ourselves. The other is rehype-table-wrapper.mjs, which wraps tables in horizontally scrollable elements.
Both belong to the category of processing where articles will still publish without them, but display formatting will break. When swapping out the conversion engine, you will not know whether these plugins receive the same syntax tree for the same input until you run them. This is especially true for conditions rarely covered in Western test suites, such as handling Japanese full-width characters.
Ultimately, your decision comes down to this: sites that use almost no plugins can reap the speed gains almost entirely as-is. Conversely, the more a site has refined display details using custom plugins, the smaller the reduction rate and the higher the verification cost. Migration feasibility is determined not by your Astro version, but by what your organization relies on plugins to do.
Speeding up conversion is not the only measure for build times
There is another alternative you should compare: reducing the number of articles converted in the first place.
This site has incremental builds enabled in Astro 7.2. When modifying a single article, only that page and shared static pages are regenerated. In our local benchmarks, an incremental build took 7 seconds compared to 34 seconds for a full build. Between accelerating each conversion and reducing conversion frequency, the latter delivered a far larger impact.
However, incremental builds come with their own pitfall: misconfigured cache keys will cause outdated pages to stay served. We detailed this implementation in Incremental Build Operations. Because the two approaches are not mutually exclusive, evaluating incremental builds first makes return on investment easier to forecast.
Furthermore, build time and page display speed are separate metrics. Readers experience the latter, which belongs to reducing served JavaScript. When people internally say the site is slow, first distinguish whether they mean waiting time for writers or waiting time for readers.
What to do next
First, check your site build logs to see how many seconds are spent on Markdown conversion. Whether the entire build is slow or only the conversion step is slow changes the right course of action. If image processing or type checking dominates, swapping the Markdown engine will not make a noticeable difference.
Next, take inventory of the remark and rehype plugins you use. If you have zero custom plugins, verification for the migration will be straightforward. If you have even one, you must understand what that plugin is remedying before considering a migration. If the original author has left the company, this will be the most time-consuming task.
At GleamHub, we assist with improving owned media build times, reviewing Astro site configurations, and auditing existing plugins for migration verification through our development, AI, and automation consulting services. Because the most effective measures depend on article volume and architecture, feel free to consult with us individually via Contact Us.
