The metric nobody counts.
Look in Google Analytics for a standard site, and the "percentage of users without JavaScript" column usually shows a nice zero. That doesn't mean those users don't exist — it means Google Analytics doesn't see them. Analytics also runs on JavaScript, and for a user without JS it simply doesn't load.
By more reliable measurements — from WebAIM, from GitHub, from the BBC — the real share of visitors with JavaScript disabled is between 0.2 and 1.5 percent. That's a lot for a large site (thousands of people a day) and meaningful for a premium site, where every visitor matters.
These people aren't fringe. They are, to a large degree, your B2B clients. Lawyers at large firms opening the site through a corporate browser with a strict security policy. IT directors who historically have JS disabled for unfamiliar domains. Financial analysts reading materials through a news aggregator. Journalists who open the site in Reader Mode. Search bots that don't execute complex JavaScript.
That one percent is the most valuable. And usually the most invisible.
What we test.
Before every release — a simple ritual. Open the site in a browser, switch JavaScript: off in DevTools, reload the page. And walk through everything by hand.
We check: does the page load (often yes, if SSR is used). Are the texts, images, fonts visible. Does navigation work — that is, do the header and footer links go to the right addresses. Can a form be submitted. Do mobile menus work (if they're CSS-only rather than a JS toggle). Are there no empty blocks where dynamic content should have been.
If something breaks without JS, it's a bug we fix before release. With one exception: the "wow effects." If a magnetic button becomes an ordinary one with JS off — that's fine. If the magnetic button is gone entirely and there's an empty space in its place — that's a bug.
This test takes a developer 20–30 minutes on a typical site. Over a year of work — ten to fifteen hours total. The cost is negligible. The effect — a site that works for exactly those valuable one and a half percent of users.
What works.
I'll list it point by point — because this is the essay's main argument:
- Page load. We use server-side rendering via the Next.js App Router. It means the HTML page goes to the browser fully rendered, with all its text and structure. JavaScript is needed only for interactivity — but the content is already visible.
- Navigation between pages. Every link is a real
<a href>. Without JS it reloads the page — slower than a JS router, but it works. - Forms. Every form has an
actionand amethod. Submitting without JS — the browser POSTs to the server, the server processes it, returns a page with the result. A classic 2005 form. Works without a single line of JavaScript. - Images and video.
<img>,<video>,<picture>. Standard HTML tags, don't depend on JS at all. - Fonts. Loaded via
@font-facein CSS. Without JS, a system-font fallback shows, which is sometimes even better for performance. - The responsive grid. CSS Grid and Flexbox. No JS to compute positions.
- Dark theme. The CSS media query
prefers-color-scheme. The browser determines the system setting itself. Without JS — it works. - Hover effects, focus rings, basic animations. Pure CSS.
- Mobile menu. If it's built on
<details>/<summary>, it works without JS. These are HTML tags people often forget. - The language switcher. Ours is implemented as two
<a>links to different URLs. Without JS — you click, the page reloads in the chosen language. With JS — it switches without a reload.
That's most of the site. About 90% of the content and functionality.
Where JS is mandatory.
Without pretending everything works without JS, I'll list the reverse:
- Interface animations. Reveal effects on scroll, magnetic buttons, the custom cursor. All of it a layer of pleasure, not a layer of existence. Without JS, the site is duller, but it works.
- Live form validation. "This email is already registered" — without JS you only find out after submitting. With JS — at the moment of typing.
- Edit mode for the CMS. The content editor runs in the browser and requires JS. Obviously.
- Complex interactive elements. Maps, drag-and-drop, charts with hover tooltips. All JS.
- Analytics. Most counters run on JS. That's a shame, because we lose exactly those valuable users in the statistics.
Important: everything on this list is an enhancement, not existence. A site without them is less pleasant. A site without working navigation isn't a site.
Progressive enhancement.
This approach is called progressive enhancement in the industry. The idea is simple: first you build a site that works on bare HTML and CSS. Then — layer by layer — you add JavaScript for extra convenience. If some layer doesn't load (because the user has no JS, or because our CDN is temporarily down), the lower layers keep working.
It's the opposite of client-side rendering, where the HTML is served nearly empty and JavaScript has to build it on the fly. In the CSR approach, without JS, the page is an empty <div id="root">. And that's it.
CSR is simpler for the developer — especially with React or Vue. But it shifts work from the server to the user's browser. On a fast desktop the difference is imperceptible. On a slow mobile it's seconds of staring at a blank screen.
JavaScript is a layer of enhancement. Not a layer of existence.
Progressive enhancement is an engineering discipline, not a fashionable technique. It takes a little more work at the planning stage, but in exchange it gives a site that works for everyone. Including the one percent you don't see in analytics.
Why this is about premium.
In the premium segment this question becomes especially sharp. A premium site is obligated to work for everyone. Not "for 99% of users in normal conditions." For everyone.
The reason is simple: your clients aren't average. A lawyer at a large firm checking you out before a call on a Saturday evening over slow hotel Wi-Fi, on a corporate laptop with JS blocked — that isn't an edge case. That's a typical premium client.
If at that moment the site shows a white screen, the Monday meeting most likely won't happen. The client will email a colleague: "forget them, their site doesn't even open." That isn't "one percent of users." It's one percent of users who generate thirty percent of revenue.
A site that works without JavaScript isn't a "feature for a minority." It's insurance against losing the most valuable people.
Archive, search engines, readers.
There are non-human consumers of sites too, which usually don't execute JS:
The Wayback Machine — an archive a site is recorded into for decades. If it's empty without JS, it'll be empty in the archive. In twenty years nobody will be able to see what your site looked like in 2026.
Search bots. Google can execute JS, but does it with a delay and not for every page. Bing, Yandex, DuckDuckGo, the search bots inside LinkedIn and Twitter — usually read only HTML. If your content isn't visible in the HTML, it won't be in the results.
Screen readers. Screen readers like NVDA or VoiceOver work on top of the DOM. If the DOM is built via JS, the reader may skip it or read it in the wrong order. That's bad accessibility.
RSS aggregators and news readers. Part of the audience reads your blog not on the site but through a third-party aggregator. Most aggregators don't execute JavaScript.
All of these are channels invisible in ordinary analytics, through which part of your readers pass. If the site doesn't work without JS, you don't have those channels.
The test: turn JS off.
A simple quality check for a site — open DevTools, turn off JavaScript, walk through the site. It takes fifteen minutes.
If the site stays readable, navigable, submits forms — it's a site built correctly. If there's emptiness left, or some pages "slid apart," or the mobile menu stopped working — it's a site where JavaScript carries work that HTML and CSS should have carried.
This isn't an "advanced practice." It's basic engineering hygiene, lost across the industry over the last ten years. We simply observe it — and we've found it gives a small but steady edge over competitors who stopped observing it.