Eleventy's performance documentation

Eleventy's own /docs/performance/ page, read together with the Image plugin docs, hunted to answer how you improve Core Web Vitals on Eleventy.

The answer is that the documentation does not discuss them

/docs/performance/ never mentions Core Web Vitals, LCP, CLS or INP — not once, under any name. The word "performance" on that page means build performance almost throughout, and its eight recommendations are all about making the build faster:

• profile the build (DEBUG, Node.js CPU profiling)
• memoize costly shortcodes and filters — minification is called out as usually the most expensive
• use the dev server to take passthrough copy "out of your build-loop"
• the Image plugin's Build Performance method
• --incremental builds
• the Directory Output plugin, for "per-template performance and file size information"
• the Fetch utility's local cache, to avoid repeat "network requests (to an API)"

The benchmark on the same page is a build benchmark: 4,000 Markdown files in 1.93s, against Hugo 0.68s, Astro 22.90s, Next.js 70.65s — "best-in-class build performance for JavaScript site generators."

The page-speed claim it does make is architectural, not instructional

One sentence covers the runtime: "by-default we do not include any costly runtime JavaScript bundles that often hamper site performance", with the partial-hydration <is-land> component named as the tool for when you do need some.

That is a claim about a default, not a technique. There is nothing to enable, tune or measure.

The CLS lever is real, and it is filed under build cost

The Image plugin is where Eleventy actually touches page metrics, and it does the two biggest things:

• Layout stability: it will "easily add width and height attributes for proper aspect ratio to reduce layout shift." That is the only CLS-adjacent sentence in the documentation, and it does not use the term Cumulative Layout Shift.
• Payload: avif, webp, jpeg, png, gif, svg output with automatic srcset at multiple sizes, never upscaling past the original. AVIF carries a noted "+1 Build Cost".

And the plugin's headline pitch is "Fast: de-duplicates with both an in-memory and disk cache. During local development, images are processed on request for even faster build performance." The lever that most affects a visitor's LCP and CLS is documented by how much it slows the developer down.

What this says

Eleventy improves Core Web Vitals structurally rather than instructionally. No runtime JS by default and width/height on every processed image are the two largest levers for LCP and CLS, and both are defaults rather than optimizations. From the project's point of view there is nothing to write a guide about, which is why a search for "improving Core Web Vitals on Eleventy" returns generic listicles and no first-party page.

The cost of that framing is that a developer using these docs is given no way to check. Nothing here names a field metric, a threshold, or a measurement tool — see speedlify for what the community measures instead, and what that measurement cannot see.

Related

eleventy · speedlify · core-web-vitals · static-site-generator · islands-architecture · astro · hugo