HTMX Performed 36% Better Than React When Caching Was Disabled. Here’s Why the Gap Widens as Conditions Degrade.

HTMX Performed 36% Better Than React When Caching Was Disabled. Here’s Why the Gap Widens as Conditions Degrade.

Most performance comparisons between HTMX and React happen under ideal conditions: fast laptop, stable Wi-Fi, warm browser cache. The results look close enough that the conversation usually ends in “it depends on the use case” and nothing changes.

A 2025 master’s thesis from Tampere University ran the comparison under conditions that actually matter — throttled CPU, throttled network, and disabled cache — and the gap stopped looking close.

The Study

Yousif Al-Baghdadi’s thesis “Examining HTMX: A Tool Assisting in Building Interactive Multipage Full-Stack Web Applications” (Tampere University, December 2025) built two functionally equivalent prototype applications: one with ASP.NET Razor Pages + HTMX, one with ASP.NET Minimal APIs + React. Performance metrics including Largest Contentful Paint (LCP), memory usage, and codebase size were measured and compared across multiple conditions.

The key findings on LCP:

+15% — HTMX advantage under combined CPU and Network throttling.

+36% — HTMX advantage when caching was disabled in the same test.

The thesis is careful not to declare a universal winner — it explicitly notes that results vary by application context and that React still offers advantages in flexibility and static type checking. But the directional finding is clear and consistent: as environmental conditions degrade from ideal toward realistic, the gap between HTMX and React grows in HTMX’s favor.

That pattern has an architectural explanation, and it’s worth understanding precisely — because “HTMX is faster” is a much less useful claim than “here’s the mechanism that makes it faster as conditions get worse.”

Why the Gap Widens Under Stress

LCP measures how long it takes for the largest visible element on the page to appear. In a React application, that timeline looks roughly like this:

1. HTML document arrives (nearly empty — just a <div id="root">)
2. JavaScript bundle downloads
3. Browser parses and compiles the bundle
4. React hydrates, runs component tree, fetches data
5. Data arrives, component re-renders with content
6. LCP element appears

Steps 2 through 5 are sequential. Each one has to finish before the next begins. And steps 2, 3, and 4 are all directly affected by the throttling conditions in the benchmark: a slower network stretches step 2, a slower CPU stretches steps 3 and 4, and a cold cache forces steps 2 and 3 to run at full cost every time.

An HTMX application’s timeline is structurally different:

1. HTML document arrives (with actual content already rendered by the server)
2. LCP element is already in the document — it appears immediately
3. HTMX library downloads (small — around 14KB minified)
4. Interactions become available

The LCP event fires at step 2, before JavaScript has done anything. The server already did the rendering. What travels across the wire is content, not a rendering engine that will produce content once it finishes loading.

This is why the 36% gap appears specifically when caching is disabled. With a warm cache, the React bundle is already sitting in the browser — steps 2 and 3 are nearly instant, and the structural advantage of server rendering narrows. With caching disabled, the browser has to download and parse the full bundle cold every time. On a throttled network and CPU, that cost is exactly where React’s architectural model is most exposed.

The 15% gap under throttling (with caching) shows that even with the bundle cached, the parse/compile/hydrate cycle on a slow CPU still costs time that HTMX doesn’t spend. The 36% gap without cache shows what happens when that bundle cost is fully reinstated on top of the CPU cost.

The Condition That Actually Describes Enterprise Networks

The caching-disabled scenario isn’t exotic. It’s a reasonable approximation of a category of real-world conditions that matters specifically in B2B and enterprise contexts:

Hard cache clears happen. Corporate IT policies sometimes disable persistent caching for security reasons. First-time users on a new device — or returning users on a company machine that just got reimaged — get the full cold-load experience every time. CDN misses happen under geographic distribution. VPN traffic disrupts the kind of connection stability that warm caching assumes.

The benchmark scenario with throttled network, throttled CPU, and no cache isn’t a stress test designed to make React look bad. It’s a reasonably faithful description of what a regional sales manager opening a B2B dashboard on enterprise hardware, through a VPN, in a WeWork somewhere with inconsistent Wi-Fi, actually experiences.

That user is not on your development machine. They are not on a stable fiber connection. And they are probably not getting a cache hit on the JavaScript bundle from a framework they haven’t opened in a few days.

Where This Connects to Bundle Weight

The thesis finding pairs directly with the bundle size data from my own benchmarks. A React application can’t get to content fast on a cold load because it has to ship a JavaScript runtime first — and that runtime gets larger with every component library layered on top of it.

From the financial dashboard benchmark across five design systems:

Logical Brutalism — 16.3 KB JS

Mantine — 1,227 KB JS

Ant Design — 1,446 KB JS

Chakra UI — 1,732 KB JS

Material Design — 7,678 KB JS

The thesis used a leaner React setup than most production B2B dashboards — ASP.NET Minimal APIs with React, not a full Next.js stack with a component library. In real enterprise applications, the JavaScript that has to download and parse before LCP can fire is often significantly larger than what the thesis benchmarked. Which means the 36% gap in the academic benchmark is probably a conservative floor for the category of application this argument is actually about.

What the Thesis Actually Concludes

The author is honest that this isn’t a universal result. The thesis explicitly states that “the results of such an experiment may be different based on the context of the application” and that React retains real advantages in flexibility and tooling. This isn’t an academic paper declaring HTMX the winner of frontend development.

What it does do, with controlled methodology and reproducible conditions, is establish a directional truth: the HTMX server-rendering model accumulates an advantage as conditions move from ideal toward degraded, because its LCP doesn’t depend on a JavaScript pipeline that gets more expensive as network and CPU slow down.

That’s not a tribal claim about which library is better. It’s a statement about which architectural model is more resilient to conditions you don’t control — and in enterprise deployments, the conditions you don’t control are exactly the ones that determine whether your users think the product is broken.

What does not resolve, does not exist.

Documentation: Download Logical Brutalism

• PyPI: pip install logical-brutalism
• NPM: npm install logical-brutalism

Full benchmarks: github.com/matheuslacerda-dev/logical-brutalism-benchmarks