Of the six access barriers measured in Zyte's State of Web Access 2026, five were built with some version of access-control intent:
- WAFs were designed to block attacks.
- CAPTCHAs were designed to filter out automation.
- Antibot services were built specifically to detect and challenge non-human traffic.
- Rate limiting and TLS fingerprinting are deliberate defensive choices.
JavaScript is different. At 40.6% of all landing pages, it is the second most prevalent technology in the dataset after WAF, and nearly twice the prevalence of CAPTCHA.
However, it also the only technology in the stack that nobody actually installed with an express intent to block access.
The sites requiring JavaScript rendering didn't choose it as a security measure. They chose React, or Next.js, or Angular, or Vue, because those frameworks offer developer productivity, component reuse, and rich interactivity. They chose TailwindCSS because it has become the go-to CSS design framework.
That is a front-end architecture decision driven entirely by how sites want to serve their own users. However, while JavaScript is used to render websites to human visitors, websites' requirement that browsers enable JavaScript can render those sites invisible programmatic visitors. That makes it, in some ways, the most interesting barrier of all.
The SPA revolution and its unintended consequences
To understand why 40.6% of the web now requires JavaScript rendering to return meaningful content, you need a brief history of how the web came to be built the way it is.
Through the early 2000s, the dominant web architecture was server-rendered HTML. A browser requested a URL; the server computed the response and returned a complete HTML page. **JavaScript was enhancement **- adding interactivity and animation to content that existed independently of it.
React changed this when Facebook released it in 2013. The promise of the Single Page Application was a richer, faster user experience: load a JavaScript bundle once, then update the page dynamically without full reloads. The framework renders content in the browser rather than on the server. By the mid-2010s, Angular, Vue, and a proliferating ecosystem of tools were extending this model across the industry. Next.js arrived in 2016 and brought React to production at scale.
The consequences for web access were not part of anyone's planning. An HTTP client that requests a Next.js-powered page in its default configuration receives what amounts to a shell: a <div id="root"></div> and a JavaScript bundle. The actual content - prices, product listings, availability calendars, news articles - materialises only after the bundle executes. A scraper that doesn't render JavaScript gets nothing it can use.
Measuring the missing-content hole
That's what our State of Web Access data captures.
We crawled each of the world's 11,100 most popular sites (and a total of 24,898 across the globe) twice in parallel: once with a plain HTTP request and once with a full browser rendering JavaScript.
Comparing the size of the content returned by each pass against the same URL gives a direct measure of JavaScript dependency.
40.6% of sites return meaningfully less content to a plain HTTP request than to a full browser. On those sites, JavaScript is load-bearing: the content simply does not exist until the code runs.
Sites hide all their JavaScript content, or none
Not all JavaScript dependency is the same, and the distribution reveals a striking pattern.
Among sites where the role of JavaScript in content delivery was measurable, the population splits almost cleanly in two:
- 31.5% treat JavaScript as purely cosmetic - styling, animation, interactivity layered on top of HTML content that exists independently.
- 29.0% are fully JS-rendered, returning blank or near-blank pages without it.
The middle ground (supporting, meaningful, primary dependency) accounts for the remaining 40%, spread thinly across four gradations.
This bimodal shape reflects the binary choice most development teams make. Either you build a traditional server-rendered site and sprinkle JavaScript on top - in which case the scraping picture is benign - or you build a full SPA or React application and JavaScript carries everything. The architectural decision point produces two distinct populations, and there's not much in between.
Where content disappears
The most operationally significant finding in State of Web Access 2026's JavaScript data is what happens to content without rendering, measured by industry.
Real estate, restaurants, and travel and tourism all lose a median 76% of their page content when JavaScript is stripped. Airlines lose 74%, pharmaceuticals 74%.
These are not coincidences. Every industry at the top of this list shares a single characteristic: their core content is dynamic, time-sensitive inventory. Restaurant menus and availability change daily. Flight prices and schedules update by the minute. Real estate listings appear and disappear. Hotel room availability fluctuates continuously.
The JavaScript frameworks powering these sites were chosen precisely because they handle dynamic content updates efficiently - pushing changes to the page without full reloads, keeping availability displays current, enabling the search and filter interfaces that users expect. The framework was never a security tool. It was a product decision. The fact that stripping JavaScript leaves these pages 76% empty is a consequence of that decision, not its intent.
For anyone building data pipelines targeting these sectors, the practical implication is stark: an HTTP scraper hitting a restaurant booking site or a travel aggregator is getting one quarter of the information that's actually there.
TLS-screened sites rely on JavaScript less
One finding in the JavaScript data runs counter to intuition and is worth examining directly.
Sites that require JavaScript rendering are substantially less likely to run TLS fingerprinting than sites that don't: 9.2% versus 17.6%, almost half the rate.
This seems backwards - surely more-complex sites would have more defenses?
The explanation is that JavaScript environments and TLS fingerprinting are, to some degree, functional substitutes.
TLS fingerprinting inspects the characteristics of the network handshake to identify automated clients at the connection layer, before any content is served. It's a passive, network-level signal.
Sites that run rich JavaScript environments don't need it as much because they have access to far richer behavioral signals inside the browser session itself - mouse movement, rendering telemetry, timing patterns, canvas fingerprints.
When you can observe a session's behavior in detail through JavaScript, passive network inspection becomes redundant. The two approaches address the same underlying question ("is this client a real browser?") through different means, and the richer JavaScript environment makes the passive network approach less necessary.
Who stayed simple
The industries with the lowest JavaScript adoption - graphic design at 19%, public relations at 27%, military and farms and ranches at 28% - share the inverse of what drives the high end of the list. Their content changes slowly or not at all.
A graphic design studio's portfolio page doesn't have availability calendars or real-time inventory. A government site is mostly static documents. A fishing industry landing page isn't dynamically computing prices.
These are server-rendered sites not out of ideological commitment but because their content doesn't require anything more. The architecture stayed simple because the use case didn't demand complexity. The scraping picture is accordingly simpler too.
Server-side rendering may reverse the trend
There is a countertrend worth noting. The pure SPA model - where JavaScript handles everything and server-sent HTML is minimal - has been quietly falling out of fashion at the technical frontier.
Core Web Vitals, Google's 2020 ranking signals for page experience, penalised slow-loading JavaScript-heavy pages by reducing their search rankings, creating economic incentive to reduce client-side rendering.
- Frameworks like Astro pioneered what's become known as the "islands architecture": render most content server-side as static HTML, and use JavaScript only for the interactive components that genuinely need it.
- React Server Components, released by Meta in 2023, brought similar thinking to the React ecosystem. The Next.js 13+ App Router makes server components the default.
The effect of these shifts, as they propagate through the installed base of production sites over coming years, may be to reduce the JavaScript access barrier for some sites - not because security thinking changed, but because architectural thinking did. The same accidental dynamic that created the barrier may, in time, erode it.
What this means in practice
JavaScript is the barrier that catches the largest number of naive approaches. A standard HTTP scraping setup - requests library, no browser rendering - fails silently on 40.6% of landing pages, returning content that looks plausible but is missing the majority of what the page actually contains.
The fix, browser rendering via Playwright or equivalent, is well understood; the cost is 10 to 50 times higher per-request than plain HTTP, in both compute and time.
What makes JavaScript distinctive among the six barriers is that the difficulty is structural rather than adversarial. There's no rule being enforced, no threshold being applied, no vendor being paid to challenge your request. The page simply doesn't contain its content until code runs.
Understanding that distinction - and identifying which specific framework and rendering pattern a target site uses - is the starting point for navigating it efficiently.
