The HTMX versus React debate isn’t theoretical anymore. We’ve got real performance data to work with. If you’ve read our piece on the HTMX renaissance overview, you know HTMX is bringing back server-driven hypermedia patterns.
In this article we’re going to give you hard numbers: bundle sizes, Core Web Vitals, state management complexity, and how these technologies scale. You’ll get concrete metrics—LCP, FCP, TTI, TTFB—and a use case matrix you can map to your own requirements. The Developer Way performance study and other benchmark sources provide the evidence. This is an honest trade-off analysis, not cheerleading.
What are the real-world performance differences between HTMX and React?
HTMX’s 14KB library versus React’s 42KB base payload creates a measurable gap before you’ve written a single line of application code. The difference is most obvious on constrained networks—3G and 4G mobile—and less significant on fast WiFi.
Benchmark data shows HTMX consistently delivers faster First Contentful Paint (FCP) and Largest Contentful Paint (LCP) for content-driven pages. React pulls ahead when you’ve got highly interactive interfaces where Virtual DOM diffing cuts down on re-render costs during complex state transitions.
Here’s what the numbers tell us: Client-Side Rendering creates multi-second delays before anything appears. Server-Side Rendering with client data fetching hit 1.61s LCP but introduced that annoying gap where the page looks loaded but buttons don’t work yet.
Nadia Makarevich puts it bluntly: “4.1 seconds wait to see anything on the screen. Whoever thought it was a good idea to render anything on the client?”
How well you implement either technology matters more than which one you choose. A poorly optimised HTMX app can underperform a well-tuned React app. But on a simulated 3G connection, the gap between HTMX and React initial load can exceed 2-3 seconds. That’s not academic. That’s users bouncing before they see your product.
How does initial page load performance compare between HTMX and React?
HTMX sends fully-rendered HTML in a single request. The browser paints content immediately. React’s Client-Side Rendering delivers an empty div with script tags—JavaScript must download and execute before any content appears.
Look at the network waterfall. HTMX: one request returns usable HTML. React CSR: initial HTML, then JavaScript bundles, then API calls, then render. Multiple round trips before content.
TTFB (Time to First Byte) can be slightly slower for HTMX because the server does the rendering work before responding, whereas server-rendered HTML takes processing time. But FCP and LCP metrics strongly favour server-rendered approaches.
React CSR with uncached JavaScript: 4.1s until anything is visible. React SSR with no data fetching: 1.61s LCP—a 2.5s improvement. React SSR with server data fetching: 2.16s LCP.
Cached JavaScript reduces React CSR LCP from 4.1s to 800ms, but first-time visitors still cop that delay. Plus, for SEO purposes, it wasn’t the best solution.
If you’re building SaaS with repeat visitors, React CSR’s 800ms cached performance might be acceptable. Think about a hybrid approach: landing pages server-rendered for fast FCP/LCP, authenticated dashboard as React SPA for cached performance. Just make sure you monitor simulated 3G/4G conditions where the initial load gap can be significant.
What are the bundle size differences between HTMX and React applications?
HTMX’s core library is approximately 14KB minified and gzipped. React’s base is 42KB—that’s a 3x difference before any application code, routing, or state management.
Real-world React applications commonly ship 200-500KB or more when you include React DOM, React Router, Redux, and application logic. A comparable HTMX application typically ships 14-30KB total because interactivity is driven by HTML attributes and server-side logic.
Bundle size directly affects download time (especially on mobile networks), JavaScript parse and compile time, and memory consumption. You’ve shipped enough production code to know a simple modal shouldn’t demand a five-minute build. Each abstraction solves legitimate problems—component reuse, client routing, offline caching—but collectively they create overhead.
React’s code splitting and lazy loading can reduce bundle size, but this adds architectural complexity and doesn’t get rid of the base framework cost. React Server Components reduce client-side bundle by moving component logic to the server, but still require a React runtime on the client.
For mobile-first applications and emerging markets, 14KB versus 200KB is a measurable user experience difference. The question isn’t whether you can optimise React to be smaller. The question is whether that optimisation effort is worth it for your use case.
How does HTMX handle state management compared to Redux and React state libraries?
HTMX gets rid of client-side state management entirely by keeping application state on the server. Each user interaction triggers a server request that returns updated HTML. This aligns with the hypermedia philosophy that treats the server as the single source of truth. As Carson Gross explains, “With hypermedia, the server is the source of truth and you’re going to make a request, we’re going to respond with the new state of the system and that’s it.”
React applications manage state through useState, Context API, and Redux or Zustand, each adding cognitive and bundle overhead. A Redux shopping cart requires actions, reducers, selectors, middleware, and store configuration—often 100 or more lines of boilerplate before business logic begins.
The equivalent HTMX implementation handles the same feature with server-side session state and HTML attributes. Server-side templates eliminate duplicated validation. Validation logic lives once on the server instead of being duplicated client and server.
The trade-off: HTMX’s server-side state means every state change requires a network round trip. This can feel sluggish for rapid interactions like typing or dragging. React’s client-side state gives you instant UI feedback—necessary for collaborative editors or data visualisation tools.
When a feature request comes in, pretty much anyone can pick it up. Even making text changes in Angular or React apps can be too difficult for a junior developer.
Use HTMX for “server interactivity”—data submission, table sorting, data refresh. Use vanilla JavaScript or Alpine for “client interactivity”—theme toggle, popups. Single source of truth on the server prevents client-server state sync bugs common in React applications with optimistic updates.
How do React Server Components compare to HTMX’s server-driven architecture?
React Server Components (RSC) represent React’s move toward the same server-driven patterns HTMX has been championing. This convergence matters: the React team’s decision to move rendering server-side validates HTMX’s core architectural approach.
RSC still requires client-side React runtime for interactive “Client Components,” whereas HTMX uses plain HTML attributes with no client-side framework. RSC reduces bundle size compared to traditional React CSR but doesn’t match HTMX’s minimal footprint because the React runtime and client component code still ship to the browser.
RSC introduces complexity: developers must work out which components run on the server versus client, manage serialisation boundaries, and work with Next.js or similar frameworks. Traditional React SSR still requires full JavaScript bundle download for hydration. RSC allows components to render on the server sending minimal JavaScript to the client, but hydration is still required for interactivity.
For hydration to work properly, the HTML coming from the server should be exactly the same as on the client, creating data serialisation complexity.
Both approaches face the same TTFB trade-off. Server rendering takes time. Next.js App Router is the primary RSC implementation. RSC positions as a middle ground: better than full CSR for bundle size, more familiar to React developers than HTMX. Teams invested in the React ecosystem can get server-rendering benefits through RSC without ditching the component model.
HTMX has a simpler mental model: no server-client boundary complexity, just HTML attributes triggering server responses.
What are the Core Web Vitals implications of choosing HTMX vs React?
Core Web Vitals—LCP, FID/INP, CLS—directly affect search rankings and user experience. Choosing between HTMX and React has measurable SEO and UX consequences.
LCP (Largest Contentful Paint): HTMX’s server-rendered HTML typically achieves better LCP because content arrives ready to display. Benchmark data shows React CSR at 4.1s LCP uncached versus React SSR at 1.61s uncached.
FID/INP (First Input Delay / Interaction to Next Paint): HTMX pages are interactive immediately because there is no hydration step. React SSR pages may look loaded but remain unresponsive during hydration—the “interactivity gap.”
React SSR creates a no-interactivity gap of 2.39s uncached (100ms cached). The page is visible but buttons don’t work. The experience feels almost broken for more than 2 seconds on initial load.
CLS (Cumulative Layout Shift): Both approaches can achieve good CLS, but React applications that load content asynchronously are more prone to layout shifts as data arrives and components re-render.
HTMX gets rid of the interactivity gap entirely. Implementation quality caveat: a well-optimised React application with SSR, code splitting, and careful hydration can achieve excellent Core Web Vitals, whilst a naive HTMX implementation with slow server responses will perform poorly.
Measure Time to Interactive (TTI), not just visual load metrics. Users clicking non-functional buttons damages UX. For SEO-sensitive sites, server-rendered HTML achieves better Core Web Vitals scores.
How do HTMX and React performance characteristics change at scale?
HTMX scales server-side: more features mean more server endpoints and rendering logic. React scales client-side: more features mean larger JavaScript bundles and increased browser memory consumption. Server costs remain relatively stable since the server only serves APIs.
HTMX’s approach means scaling costs are infrastructure costs—more or bigger servers—which are predictable and controllable. React’s approach pushes costs onto user devices, which are uncontrollable. Large React applications commonly suffer from “bundle bloat” as teams add features.
HTMX applications avoid client-side complexity growth but may face server bottlenecks. Techniques like caching server-rendered fragments, CDN edge rendering, and connection pooling become important at scale.
Hybrid architectures emerge: HTMX for content-driven pages with occasional React islands for genuinely complex interactive components. The main concern with HTMX is there’s still a bit of raw string logic. You’re building frontends connected to backends based on raw string URL paths with logic embedded in markup.
For applications growing in complexity, monitor bundle size actively. Implement code splitting and lazy loading as React application grows. For HTMX at scale, invest in server-side fragment caching and CDN strategies. Consider a hybrid approach: HTMX for the majority of UI with React islands for genuinely complex interactions.
When does performance favour HTMX vs React? A use case matrix
HTMX excels for content-driven sites, CRUD applications, dashboards, e-commerce catalogues, and internal tools where server-rendered HTML delivers fast initial loads and interactions are primarily form submissions and navigation.
React excels for real-time collaborative tools, data visualisation dashboards, complex form builders, drag-and-drop interfaces, and offline-capable applications requiring rich client-side interactivity and instant UI feedback.
Mobile and emerging market performance strongly favours HTMX: smaller bundles, less JavaScript parsing, and server-side rendering deliver significantly faster experiences on constrained devices and networks. SEO-sensitive content sites favour HTMX because server-rendered HTML is immediately indexable and achieves better Core Web Vitals scores.
HTMX works well for form-driven applications with significant user thinking time. If you’re building something that needs to work offline or requires very low latency client-only changes (like real-time map interactions or video games), then HTMX is not the best choice.
React CSR page transitions are incredibly fast: navigating from Inbox to Settings takes just 80ms once JavaScript is cached.
For most organisations they just want to build, so choosing technologies that are so simple anyone can make a change likely leads to velocity and business benefits over time.
Work out your interactivity requirements: server round-trip acceptable (HTMX) versus instant client feedback required (React). Think about team composition: generalist team (HTMX advantage) versus specialised frontend and backend (React acceptable). Check your mobile audience: high mobile or emerging markets percentage favours HTMX bundle size advantage.
The decision is rarely binary. Many production applications benefit from HTMX as the primary architecture with targeted React for specific high-interactivity components.
Armed with this performance data, see our decision framework for evaluating HTMX adoption. To achieve these performance characteristics in practice, follow these implementation patterns.
Conclusion
The data tells a nuanced story. HTMX wins on initial load performance, bundle size, and simplicity. React wins on complex interactivity and rich client-side experiences.
React Server Components confirm the industry is converging toward server-driven patterns. Performance is ultimately determined by implementation quality, architectural fit, and use case alignment, not framework identity alone.
For a comprehensive overview of the HTMX movement, see The HTMX Renaissance. For readers ready to evaluate adoption, see our decision framework.
FAQ Section
Is HTMX faster than React for all types of web applications?
No. HTMX delivers faster initial page loads and smaller bundle sizes for content-driven and CRUD applications. However, React outperforms HTMX for highly interactive interfaces (real-time collaboration, complex data visualisation, drag-and-drop) where client-side state management and instant UI feedback without server round trips are necessary. The performance winner depends on application type and interaction patterns.
What is the actual bundle size difference between HTMX and a typical React application?
HTMX’s core library is approximately 14KB minified and gzipped. React’s base is 42KB, but real-world React applications with React DOM, a router, and state management typically ship 200-500KB or more of JavaScript. A comparable HTMX application usually ships 14-30KB total because business logic runs server-side rather than in the browser.
Does HTMX work with React Server Components in the same application?
Not directly. HTMX and React Server Components represent different architectural approaches to server-driven rendering. However, you can build hybrid applications using HTMX as the primary architecture with React “islands” for specific complex interactive components. This pattern gives you HTMX’s simplicity for most pages whilst leveraging React where client-side interactivity justifies the additional JavaScript.
How does the interactivity gap affect user experience in React applications?
The interactivity gap occurs when server-rendered React pages look complete but don’t respond to user input until JavaScript finishes downloading and hydrating the page. Users click buttons that do nothing, fill in forms that don’t submit, and experience a frustrating delay between seeing content and being able to interact with it. HTMX avoids this entirely because its pages are interactive as soon as they render—there is no hydration step.
Can React achieve the same Core Web Vitals scores as HTMX?
Yes, with significant effort. React applications using Server-Side Rendering (via Next.js), careful code splitting, optimised hydration, and disciplined bundle management can achieve excellent Core Web Vitals scores. However, HTMX achieves strong Core Web Vitals with less optimisation effort because its architecture inherently favours fast initial loads and immediate interactivity. The question is whether the engineering investment in optimising React is worth it for your use case.
What happens to HTMX performance when the server is slow?
HTMX’s performance is directly tied to server response times because every interaction requires a server round trip. If your server takes 500ms to render a response, every click or form submission will feel slow. Mitigation strategies include server-side caching, CDN edge rendering, database query optimisation, and connection pooling. React’s client-side architecture can mask server latency for interactions that don’t require fresh data, giving it an advantage when servers are under load.
How does HTMX vs React choice affect SEO performance?
HTMX’s server-rendered HTML is immediately indexable by search engines and naturally achieves strong Core Web Vitals (LCP, FID, CLS), which Google uses as ranking signals. Traditional React CSR applications require additional work (SSR via Next.js, or prerendering) to be properly indexed. React Server Components improve this situation, but HTMX’s simpler architecture achieves SEO-friendly performance with less configuration and tooling.
Is it practical to migrate from React to HTMX incrementally?
Yes. The most practical approach is the “strangler fig” pattern: new features and pages are built with HTMX whilst existing React pages remain in place. Over time, React pages can be gradually replaced. Many teams maintain both during transition, using a reverse proxy or server-side routing to direct traffic to the appropriate architecture. This avoids the risk and cost of a big-bang rewrite whilst progressively capturing HTMX’s performance benefits.
How does HTMX perform on mobile devices compared to React?
HTMX significantly outperforms React on mobile devices, particularly on mid-range and budget phones common in emerging markets. The 14KB vs 200KB+ JavaScript difference means faster downloads on cellular networks, less CPU time spent parsing and compiling JavaScript, and lower memory consumption. These advantages compound on constrained devices where processing power and network bandwidth are limited.
Does choosing HTMX mean giving up modern developer tooling and ecosystem?
HTMX has a smaller ecosystem than React, with fewer third-party component libraries, fewer dedicated DevTools, and fewer specialised hosting platforms. However, HTMX works with any server-side language and framework (Django, Rails, Spring, Express, Go), leverages existing server-side tooling for debugging and testing, and benefits from simpler architecture that reduces the need for complex tooling. The trade-off is fewer client-side tools in exchange for simpler overall development.
What network conditions make the biggest difference between HTMX and React performance?
The performance gap between HTMX and React is most pronounced on slow networks (3G, slow 4G) and least significant on fast WiFi. On a simulated 3G connection, the initial load difference can exceed 2-3 seconds due to React’s larger JavaScript payload requiring more download and parse time. On fast WiFi, both approaches deliver sub-second initial loads, and the difference becomes negligible for initial page rendering—though HTMX still maintains an advantage in total JavaScript execution overhead.
How do HTMX and React compare for applications that need offline functionality?
React has a clear advantage for offline-capable applications. Client-side state management and service workers allow React apps to function without a network connection, caching data and syncing when connectivity returns. HTMX’s server-dependent architecture fundamentally requires network connectivity for every interaction. If offline functionality is necessary, React (or a React-based framework like Next.js with service workers) is the better architectural choice.
