Dev Server Performance: Astro vs Eleventy

Build time gets benchmarked because CI bills for it. Dev server time rarely does, yet it is what writers and developers feel all day: the seconds between saving a Markdown file and seeing it in the browser, the minute spent waiting for the server to start after pulling main, the laptop fan when the dev server has been running since the morning. On a documentation site with many contributors, a slow local preview is also why people stop previewing and start pushing to see their changes on a deploy preview, which moves the feedback loop from seconds to minutes.

This guide measures the dev servers of Astro and Eleventy on the same 1,300-page documentation site — cold start, time to first page, edit-to-refresh latency and memory — and covers the settings that made the biggest difference in each. It is part of Astro vs Eleventy for Documentation Sites, and it complements the production build comparison in Astro vs Eleventy Build Times at 10,000 Pages.

Prerequisites

• The same content rendered by both generators (the numbers here come from a migration evaluation where both existed side by side).
• Astro 4.16 with the Content Layer, Eleventy 3.0 with its built-in dev server.
• A way to measure edit latency: a small Playwright script that edits a file and waits for the change in the page, plus /usr/bin/time -v for peak memory.

Two Different Dev Server Designs

The generators approach local development differently, and the design explains the numbers.

Eleventy runs a full build at startup, writes the output to _site/, and serves it with its own dev server (a lightweight server with live reload). On a change, it rebuilds — the whole site by default, or with --incremental, only templates affected by the changed file — and reloads the browser. Everything the reader will see is already built by the time the server says it is ready.

Astro starts a Vite dev server that renders pages on request. Startup syncs the content layer (parsing frontmatter and caching entries in a data store) but does not render pages. The first request for a page renders it, and Vite's module graph hot-reloads components and styles without a full page reload. Content changes update the data store and trigger a reload of the affected page.

Cold Start and First Page

Cold start matters every time someone pulls main or switches branches. Measured from command to "server ready" and then to the first page fully rendered, on a 2023 MacBook Air (M2, 16 GB) and a CI-class Linux VM, median of five runs with caches cleared:

Astro is ready much sooner and pays per page instead; the first page is slow because Vite compiles components and dependencies on first use. Eleventy's startup is a full build, so it scales with the size of the site — on a 10,000-page variant of the corpus, Eleventy took 51 s to be ready and Astro 4.3 s.

Edit-to-Refresh Latency

This is the number writers feel. Measured with a Playwright script that appends a sentence to a Markdown file and waits for it to appear on the page, fifty edits each:

Without --incremental, every Eleventy edit rebuilt all 1,300 pages. With it, body edits were instant, but anything that other pages depend on — a title shown in every page's sidebar, a layout, a global data file — still rebuilt everything, because Eleventy correctly determines that every page's output could change. Astro's on-demand model sidesteps that: only the page being viewed is re-rendered, whatever changed. CSS changes are hot-swapped by Vite without a reload at all.

For writers, who mostly edit body text, incremental Eleventy was as fast as Astro. For developers working on layouts and navigation, Astro was an order of magnitude faster.

Memory

Peak resident memory after an hour of editing, measured with /usr/bin/time -v on Linux and Activity Monitor on macOS:

Astro's Vite server keeps module graphs, transformed modules and the content store in memory, and memory grew as more pages were visited. On 8 GB laptops used by two writers, the Astro dev server alongside a browser and an editor caused noticeable swapping; restarting it every couple of hours was the workaround until the team added the settings below.

Settings That Made the Biggest Difference

Eleventy

• Run npx @11ty/eleventy --serve --incremental by default in the dev script.
• Skip expensive work in development: image processing with eleventy-img only for images on the page being built (its transformOnRequest mode serves images on demand in the dev server), no HTML minification, no search indexing. Gate on process.env.ELEVENTY_RUN_MODE === 'serve'.
• Split navigation data so a title change does not invalidate every page: the sidebar can be rendered client-side from a JSON file in development only, or the sidebar partial can be cached per section.
• Use eleventyConfig.setWatchThrottleWaitTime(100) so editor autosaves do not trigger several rebuilds.

Astro

• Keep the content layer store between runs (it is in node_modules/.astro/); do not clear it in predev scripts.
• Pre-bundle heavy dependencies with vite.optimizeDeps.include so the first page does not wait for on-the-fly dependency optimization — this cut the first page from 1.9 s to 1.1 s.
• Avoid importing large data files into every page; query collections instead, which are indexed.
• Add --max-old-space-size=3072 only if needed; the real fix for memory was removing a remark plugin that cached rendered HTML for every page in a module-level map.

Choosing With Contributors in Mind

If most contributors are writers editing Markdown, both dev servers can be made fast enough, and Eleventy's lower memory use suits the laptops writers often have. If contributors frequently change layouts, components and navigation, Astro's on-demand rendering and hot module replacement make a large, daily difference. Either way, measure your own site: the gaps here come from this corpus's shape — a sidebar on every page, 9,100 code blocks, several hundred images — and a site without a global sidebar would show much smaller Eleventy incremental penalties.

Measured Impact

After tuning both dev servers:

Pitfalls & Rollback

• Development-only shortcuts leaking into production. Gate every shortcut on the run mode and keep production builds full.
• Clearing caches in predev. Makes every start a cold start.
• Global data used everywhere. One edit then invalidates every page in Eleventy.
• Module-level caches in plugins. Memory grows without bound in long-running dev servers.
• Rollback: every change is a dev script flag or a run-mode condition; removing it restores the defaults.

Conclusion

Astro's dev server starts faster and handles layout and navigation changes almost instantly, at the cost of more memory and a slower first page. Eleventy's dev server is lean and, with incremental mode and a few run-mode guards, just as fast for content edits, but slower when shared templates change. For writers' laptops both can be made comfortable; for developers iterating on layouts, Astro's model is hard to beat.

FAQ

Which dev server starts faster on a large documentation site?

On the 1,300-page site measured here, Eleventy's dev server was ready in about 9 seconds because it builds pages up front but has little else to start, while Astro's was ready in about 3 seconds because Vite renders pages on demand. The first page view in Astro then takes longer because it renders on request.

How fast are content edits reflected in the browser?

Both were well under a second for a single Markdown edit with the right settings. Eleventy with incremental mode rebuilt one page in about 0.3 seconds; Astro's Vite server re-rendered the page on request in about 0.4 seconds after the content layer updated.

Why does memory matter for dev servers?

Writers often run the dev server for hours on laptops alongside a browser, editor and chat tools. On large sites a dev server using several gigabytes of memory slows everything down, and on 8 GB machines it can cause swapping or crashes.

What slows dev servers down the most?

Work that runs on every change regardless of what changed, such as regenerating all search indexes, processing every image, fetching remote data without a cache, or global data files that rebuild every page when edited.

Related

• Parent: Astro vs Eleventy for Documentation Sites — the full comparison.
• Astro vs Eleventy Build Times at 10,000 Pages — production build speed.
• Enabling Incremental Builds in Eleventy — incremental mode in CI.
• Incremental Builds in Astro with the Content Layer — the store that speeds up startup.
• Best SSG for Technical Writers Without Coding Experience — the writer's view of tooling.