Remix is not a static site generator and shouldn't really be a part of this benchmark, but since it is I have updated it to use https://www.npmjs.com/package/remix-ssg. This is a package that replaces the remix compiler to support SSG.

Locally this took the remix benchmark from 47.82s down to 1.08s.

Compiler support for MDX in Remix is not something we wanted to add and is by no means optimized. Moving to runtime compilation (static HTML generation time in this case) as we recommend drastically speeds things up.

Like the title says, this bumps the Astro templates to v1.0.1 to get the latest and greatest speed improvements by @bholmesdev.

I also updated the astro-with-mdx benchmark, but since this is a test of .md files and not .mdx files I don't think that benchmark is really testing anything, aka the two benchmarks are basically identical and you should be safe to remove one.

It looks like your machine is not configured properly. Here's my test run on a MacBook Pro 16" 2019 2.4 GHz 8-core Intel Core i9 with 64GB RAM.

EDIT Removed results since the benchmark scripts were broken. It actually never copies the posts to the folder, since the folder is previously deleted, cp complains about missing folder. With the actual posts copied, the build times were definitely longer.

Like @jpcafe said on Twitter, this synthetic benchmark is not how Remix would handle markdown files. Those files should be treated as data and rendered on demand. Remix is not an SSG framework. Sure it supports MD routes, but mainly for convenience when you have a few markdown files. But if you have 4000, you'd keep those in a database, or in a lot of cases pull them from GitHub and render it on the fly. Either caching via Redis or using HTTP caching headers.

Anyway, I think it was disingenuous (considering you maintain one of the other frameworks) to release a benchmark result that was such an outlier without reaching out to the Remix community first.

This adds a test for Astro with the official MDX extension.

Why? Because Astro recently deprecated the use of components/expressions/variables in Markdown files, which makes me wonder if it makes the comparison a little less than 1:1.

See the deprecation notice.

I’m not suggesting these tests will run faster, but I hope their notice and official MDX extension would be considered a realistic scenario for working with Markdown. At least, I think it would be helpful to know the impact this would have on any Astro user using components, expressions, or variables.

As I may not be able to replicate your testing conditions, I’m offering this as a PR, but please know I won’t be offended if you decline it.

Creates a bare-bones SvelteKit blog project (using mdsvex for Markdown processing, and the static adapter to build static files). Also adds the requisite .sh file for benchmarking. (Note: just copied an existing .sh file and modified slightly, but it seems to work.)

PR looks much larger than it really is; most of those lines are the package-lock.json file.

The SvelteKit site just has a homepage that lists all the posts with a link, and of course a page for each post. No extras at all.

I suspect one could get quicker build times by using Vite for the markdown processing instead of mdsvex, but that's for another experiment, I suppose.

Lume is not the most popular static site generator, so feel free to close this PR if you don't want to include it.

Disclosure: I am the maintainer (one more reason to discard this PR).

I thought it could be interesting to include it because it's on Deno, so it can compare Node vs Deno. It's one of the most popular SSG for Deno (at least the only one listed in the Jamstack's generators after filtering by "JavaScript (Deno)".

PD: it's heavily inspired by Eleventy (I'm a fan) and Jekyll.

https://kit.svelte.dev

Like Next/Nuxt/Remix, SvelteKit is more a framework that can generate static files than one built specifically for it, but it would still be interesting to see the comparison using MDSvex (Svelte's de facto markdown parser) and the static adapter.

Really interesting project.

Maybe it would be interesting to also compare this across OS's like Mac vs Linux vs Windows. Especially for win the shell script would need to have a runnable equal on windows.

For this to work IMO one of the easiest approaches would be to convert the .sh scripts into js (could also use something like zx for convenience).