Half the Web's 'Static' Site Tools Aren't Actually Static, and the Real Ones Load Faster Than Almost Anything

"Static sites are fast" is one of the web's most repeated claims, and the field data both confirms it and disproves half of it. Genuinely static tools like Hugo and Jekyll post some of the best loading scores on the entire web, good on Largest Contentful Paint for around 90% of their mobile sites. But roughly half of what gets called "static" today is a JavaScript framework in disguise, and those sites tell the opposite story. Lumped together under one label, they pull the whole "static" category down to a below-average 32.8% pass rate.

The distinction is not academic, because loading speed decides real outcomes. Google has found that most mobile visitors abandon a page that takes more than three seconds to load, and slow loading costs conversions and search ranking alike, since Core Web Vitals are a confirmed Google ranking signal. A team that picks a "static" tool expecting speed, and gets a heavy JavaScript framework instead, has made a performance decision without realizing it, and their visitors pay for it.

So we separated the two populations that share the "static" name and measured how each actually performs for real Chrome users. The result is clean: the loading advantage belongs to tools that ship little JavaScript, and it disappears for tools that ship a lot, regardless of whether the build step is technically static.

The figures join HTTP Archive's technology detection, which identifies the static generator or meta-framework on each origin, to Google's Chrome User Experience Report, which records how fast that origin is for the real people who visit it. This is field data from actual visits, not a single lab test. The study covers seven static-site tools and meta-frameworks. Because Wappalyzer's "Static site generator" category mixes genuinely static tools with JavaScript meta-frameworks, we report per tool rather than as one category aggregate, and the smaller buckets, Jekyll and Docusaurus at a few thousand origins each, are best read as directional.

A site passes Core Web Vitals only when it is good on all three metrics together: Largest Contentful Paint under 2.5 seconds for loading, Interaction to Next Paint under 200 milliseconds for responsiveness, and Cumulative Layout Shift under 0.1 for visual stability. We measure at the 75th percentile on mobile, the standard Google uses, because it reflects the slower phones and networks a real audience brings rather than a developer's fast laptop.

The JAMstack pitch is simple: pre-render your pages to static files, serve them, and they will be fast. For genuinely static tools, the field data delivers on it emphatically. Hugo and Jekyll output HTML with little or no client-side JavaScript, and on Core Web Vitals they post some of the best loading scores on the web. Hugo is good on Largest Contentful Paint for 89.9% of its mobile sites and Jekyll for 90.2%. Both pass overall at 47% to 50% on mobile, at or above the roughly 42% web-wide average, with near-perfect layout stability.

Now the trap. The tooling category meant to capture "static sites," Wappalyzer's "Static site generator," also files Next.js, Nuxt and Gatsby under it, which are JavaScript frameworks that happen to support static builds. Lump them all together and the category's mobile pass rate collapses to 32.8%, which would tell you static sites are below average. That number is an artifact of mixing two completely different populations, and taking it at face value is how the "static is slow" misconception spreads.

Read the tools top to bottom and the ranking is a clean gradient of JavaScript weight. Hugo and Jekyll pre-render HTML and ship almost no client runtime, so their largest content paints early. Astro's islands model sits in the middle, mostly static and selectively hydrated. Gatsby, though it builds static files, hydrates a full React app on load, and its loading score drops accordingly. Next.js and Nuxt, which lean on heavy hydration, land at the bottom.

"Static" describes the build step. It says nothing about how much JavaScript reaches the phone, and it is the JavaScript that decides the loading score. The two charts below show the same gradient twice: first in loading alone, then in the overall pass rate, where the true static tools clear the web average and the JavaScript-heavy ones fall well below it.

Why do Hugo and Jekyll win? Not because static hosting is special, but because a pre-rendered HTML page with minimal JavaScript gives the browser the least possible work to do before painting content. There is no framework to download, parse, hydrate, or re-render. On a mid-range phone, where every one of those steps is expensive, that restraint shows up directly as fast LCP.

The moment a "static" tool adds a full client-side framework, it takes on the same main-thread burden as any other framework site, and the loading advantage evaporates. That is why Gatsby and a statically-exported Next.js app perform like framework sites rather than like Hugo: the build is static, but the payload is not light. Where you host the files matters far less than what you ship, which is why the hosting and CDN picture is a smaller lever here than the JavaScript weight itself.

The raw "Static site generator" category aggregates to 32.8% pass and 58.8% good LCP, dragged down by the JavaScript meta-frameworks filed under the same label. Astro, Gatsby, Next.js and Nuxt.js are meta-frameworks that support static builds but ship a full client runtime, and their per-tool pass rates are reported in our meta-framework study. On desktop the same shape holds: Hugo leads on loading at 95.8% good LCP, well above any of the hydrated tools.

If loading is the priority, choose the tool by how little JavaScript it ships, not by the word "static." Hugo and Jekyll are good on LCP for 89.9% and 90.2% of their mobile sites and pass overall at 50.4% and 47.4%, both above the roughly 42% web average. Gatsby, Next.js and Nuxt wear the same static label but hydrate a full framework, and their loading falls to 68.4%, 54.8% and 48.4% good LCP.

That is why the raw 32.8% category pass rate is a trap. It averages true static tools with the JavaScript meta-frameworks filed under the same Wappalyzer label. "We use a static site generator" is not a speed strategy, because a statically-exported Next.js app ships the same payload as any other Next.js app and loads like one, at 54.8% good LCP rather than Hugo's 89.9%.

If you need interactivity, the middle of the table is the honest trade. Astro's islands model keeps most of the static loading advantage, 76.7% good LCP, while hydrating only the components that need it. Where you host the files is a smaller lever than what you send, so the JavaScript weight is the number to choose on, and the loading scores at the top of this table are within reach for any content site.