TL;DR: HTML-first means shipping real, server-rendered content before any JavaScript runs, then adding scripts only where they earn their place. In 2026 this approach is winning again, not out of nostalgia, but because the median mobile page now ships around 646 KB of JavaScript, fewer than half of mobile sites pass Core Web Vitals, and the browser already does natively what many sites still pull in libraries for. For most business websites, progressive enhancement is faster to ship, cheaper to run, and easier to keep alive.
Sometime in 2026, "just use HTML" stopped being a contrarian take. I noticed it first in my own client work, not in a conference talk. The sites that start close to the platform, plain HTML, forms, links, server rendering, and add JavaScript only where it genuinely helps, are the ones that launch faster, load cleaner, and generate fewer confused support messages two months later.
This is not anti-JavaScript. It is a reaction to a decade of reaching for a framework before asking whether the project needed one. The pendulum is swinging back toward the browser, and the numbers explain why.
What HTML-first actually means (and why it is not 2009 web design)
The fastest way to misunderstand this is to picture table layouts and inline styles. That is not it.
HTML-first is an order of operations. You build a page that is complete and usable as server-rendered HTML, then you enhance it. The content is readable before a single script loads. The form submits even if JavaScript never arrives. This is the old idea of progressive enhancement, applied deliberately with modern tools instead of by accident.
There is a small but real movement around this now. The HTML First community manifesto argues, fairly, that the platform has far more capability than most teams use. You do not have to agree with every line of it to notice the shift. The point is not to ban JavaScript. The point is to stop treating it as the default starting material for every page.
The 2026 numbers: JavaScript keeps getting heavier
Here is the part that moved this from a developer preference to a business problem.
The 2025 Web Almanac, published in January 2026, puts the median mobile page at roughly 646 KB of JavaScript. That is not the heavy end. That is the middle. Every one of those bytes has to be downloaded, parsed, compiled, and executed on the main thread, and while the main thread is busy, the page cannot respond to the person tapping it.
The performance chapter of the same edition is blunter. Only about 48% of mobile sites pass all three Core Web Vitals, and median mobile blocking time jumped well over 50% year on year. Those vitals are not abstract. Google's Largest Contentful Paint and Interaction to Next Paint are now a cross-browser baseline as of late 2025, which means slow, script-heavy pages are measured and penalised the same way everywhere.
I keep watching that cost land on people who just wanted a fast brochure site, a booking form, or a product page. They did not ask for 600 KB of framework. They inherited it because that was the default.
What the browser already does without JavaScript
The other half of the story is how much the platform quietly grew up. A lot of the interactivity that used to justify a library now ships in the browser.
| You used to reach for JavaScript for | In 2026 the browser does it natively |
|---|---|
| Accordions and show/hide panels | <details> and <summary> |
| Modal dialogs and overlays |
<dialog> with showModal()
|
| Form validation libraries | Constraint validation (required, type="email", pattern) |
| Lazy-loading images below the fold | loading="lazy" |
| Smooth in-page scrolling | CSS scroll-behavior: smooth
|
<details> and <dialog> are both Baseline widely available, and MDN's pages on them were last revised in April 2026, so this is current, not a someday promise. When the accordion, the modal, and the form all work without a bundle, the question stops being "which library?" and becomes "do I need a library at all?"
For a lot of pages, the honest answer is no.
HTML-first or a framework: how I actually decide
I am not arguing that every product should go back to static files. If I am building something with dense client state, live collaboration, or a genuinely app-like workflow, JavaScript earns its place and I reach for it without hesitation.
The decision is just not automatic anymore. Here is roughly how I split it:
- Reach for HTML-first when the site is mostly content: company sites, landing pages, service pages, blogs, most ecommerce catalogues, and plenty of internal tools. The job is to render information and capture a lead or a sale.
- Reach for a framework when the interface is the product: dashboards, editors, real-time apps, anything where the user lives inside complex state for long stretches.
Most websites are the first kind. They were being built like the second kind, and paying for it in load time and maintenance.
Does Google rank HTML sites higher than SPAs in 2026?
Not directly, but the structure helps. Google processes a page in three stages: crawl, render, then index. Its own JavaScript SEO guidance, updated in March 2026, is clear that rendering happens with a headless browser and can lag behind crawling.
A server-rendered HTML page is fully readable on that first pass. The content is there before any script runs, so it gets indexed without waiting in the render queue. A single-page app that paints a blank shell and fills it with JavaScript is betting on that render step going smoothly and quickly. Sometimes it does. Often it is slower, and other search engines and AI crawlers are far less forgiving about executing your scripts than Google is.
If organic visibility matters to a business, and it almost always does, shipping the content as HTML is the safer default. This is the same reason I treat SEO and performance work as one job, not two.
How I build HTML-first for clients
In practice this is not exotic. I render pages on the server, lean on native HTML for the interactive bits, and add small, targeted scripts where they clearly improve the experience. No hydration puzzles for a page that was always going to be mostly text and a form.
The payoff shows up after launch. When a local business wants a service added, a price changed, or a lead form fixed, I would rather edit a clean template than reopen a build pipeline and chase a hydration bug on a page that never needed one. Fewer moving parts means fewer failures, which is exactly the reliability I aim for in web development and why I keep arguing that a small business does not need a heavy stack to have a genuinely good website.
There is a bigger thread here too. A lot of what made the web feel slow and disposable came from over-building simple things, the same instinct I wrote about in the case for human-made websites. HTML-first is part of the correction.
So yes, HTML-first websites are winning again, and 2026 is the year it stopped being a niche opinion. They are faster to ship, cheaper to maintain, and more honest about what the project actually needs. If a page needs rich interactivity, I will add it. I just want the page to work before the cleverness arrives.
If that sounds like the kind of site you want, let's talk.
Frequently asked questions
What does HTML-first mean in web development?
HTML-first means the page ships complete, readable content as server-rendered HTML before any JavaScript runs, so it works even if scripts fail. JavaScript is added only to enhance what already works, which is the core idea behind progressive enhancement.
Does a small business website need a framework like React in 2026?
Usually not. A service site, landing page, or catalogue needs HTML, CSS, and a little JavaScript, not a framework that behaves like an operating system. For most brochure-style sites, a lean server-rendered build is faster to ship and cheaper to maintain than a single-page app.
Does a website need JavaScript to rank on Google in 2026?
No. Google processes pages in three steps: crawl, render, then index, and the render step can lag, per Google's JavaScript SEO docs. Server-rendered HTML is readable on the first pass, so core content gets indexed immediately instead of waiting on JavaScript.
How much JavaScript does the average website ship in 2026?
A lot. The 2025 Web Almanac (published January 2026) puts the median mobile page at about 646 KB of JavaScript. The browser still has to download, parse, compile, and run all of it on the main thread before the page feels responsive.
Is progressive enhancement just old-fashioned web development?
No. It is a deliberate 2026 architecture choice, not nostalgia. Tools like Astro, htmx, and 11ty apply it on purpose: build a resilient HTML layer first, then layer in JavaScript only where it adds clear user value. It is the grown-up version of frontend work, not a step back.
What can the browser do natively without JavaScript now?
More than most teams use. Native details and summary handle accordions, dialog handles modals, and constraint validation handles forms. Lazy image loading and smooth scrolling are built in too. That covers a big share of what sites used to pull in libraries for.
Sources: 2025 Web Almanac: Page Weight, 2025 Web Almanac: Performance, web.dev: LCP and INP are now Baseline, Google Search Central: JavaScript SEO basics, MDN: progressive enhancement.
This article was originally published on maxmendes.dev.
