JavaScript is almost everywhere, but that doesn’t mean every site uses it well.

It powers menus, forms, analytics, chat widgets, product filters, checkout flows, personalization, and the dashboards people use to run a business. It also creates some of the web’s most expensive performance problems. A single image is downloaded and decoded. JavaScript must be downloaded, decompressed, parsed, compiled, and executed before it can do useful work.

That difference matters on an older phone, a spotty connection, or a page loaded with marketing tools. The website may look fine on the developer’s laptop while a customer stares at a frozen button.

These JavaScript statistics give web professionals and business owners a shared set of numbers for making better decisions. They cover adoption, page weight, unused code, frameworks, TypeScript, developer behavior, and the performance standards a production website should meet.

JavaScript usage statistics

1. JavaScript runs on 98.9% of websites. W3Techs measures client-side language usage across the web and updates its results daily. Its August 2026 data puts JavaScript on nearly every site it can identify. (W3Techs)

2. JavaScript remains the most-used programming language in Stack Overflow’s survey. In the 2025 survey, 66% of all respondents said they had done extensive development work with JavaScript during the previous year. (Stack Overflow)

3. HTML/CSS was close behind JavaScript at 61.9%. That pairing is a useful reminder: websites still rest on the browser’s native foundation, even when the project uses a framework, CMS, or visual builder. (Stack Overflow)

4. TypeScript was used by 43.6% of Stack Overflow respondents. TypeScript adds static type checking to JavaScript projects, and its adoption has moved well beyond large software companies. (Stack Overflow)

5. Node.js was used by 48.7% of respondents working with web technologies. That makes JavaScript a major server-side language as well as the language of the browser. (Stack Overflow)

6. React was used by 44.7% of web-technology respondents. React had the highest reported usage among the named web frameworks and technologies in Stack Overflow’s 2025 results. (Stack Overflow)

7. Next.js reached 20.8% usage. The React-based framework now sits in the same broad usage tier as several long-established web platforms and server frameworks. (Stack Overflow)

8. Vue.js was used by 17.6% and Angular by 18.2%. Neither framework disappeared when React grew. Real businesses still own large, working applications built on several generations of JavaScript tooling. (Stack Overflow)

9. jQuery still appears on 71.9% of websites where W3Techs detects a JavaScript library. Developer surveys and live-web measurements answer different questions. New projects may favor React, Vue, or no framework, while the installed web still contains an enormous amount of jQuery. (W3Techs)

10. State of JS recorded 11,268 respondents using JavaScript for frontend work and 7,345 using it for backend work. The same language now spans the customer-facing page, build pipeline, server, desktop tools, and mobile apps. (State of JS)

The practical lesson is not that every project should use JavaScript everywhere. It is that nearly every company already depends on it somewhere. The real question is whether your site has a controlled JavaScript system or a pile of scripts accumulated through themes, plugins, tags, and campaign requests.

JavaScript page weight statistics

11. The median mobile home page ships 632 KB of JavaScript. HTTP Archive measured millions of pages for its 2025 Web Almanac. JavaScript was the second-largest resource category on the median mobile home page, behind images. (HTTP Archive)

12. The median desktop home page ships 697 KB of JavaScript. That is transfer size, not the amount of work the browser experiences after the code is decompressed and processed. (HTTP Archive)

13. The median home page weighs 2.56 MB on mobile and 2.86 MB on desktop. JavaScript accounts for about one-quarter of those median transfer totals before considering its CPU cost. (HTTP Archive)

14. The median mobile home page grew 8.4% in one year. It increased from 2.4 MB in 2024 to 2.6 MB in 2025, while the median desktop page grew 7.3% to 2.9 MB. (HTTP Archive)

15. Mobile home-page weight grew 202.8% in a decade. HTTP Archive measured a rise from 845 KB in July 2015 to 2,362 KB in July 2025. Better networks have not made page-weight discipline obsolete. Pages expanded to consume the available capacity. (HTTP Archive)

16. A median mobile page contained 206 KB of unused JavaScript in HTTP Archive’s JavaScript analysis. At the 75th percentile the unused amount reached 450 KB, and at the 90th percentile it reached 818 KB. (HTTP Archive)

17. Median unused JavaScript grew by 8% year over year. HTTP Archive’s 2024 JavaScript chapter found that unused code was getting worse even as teams adopted bundlers, tree shaking, and other optimization tools. (HTTP Archive)

18. About 44% of downloaded JavaScript was unused on median mobile pages. That means a large part of the typical script payload consumed bandwidth and processing resources without supporting the page the visitor actually opened. (HTTP Archive)

19. Gzip compressed about 60% of JavaScript responses, while Brotli handled about 29%. Brotli often produces smaller text assets, but gzip remains the dominant delivery method in HTTP Archive’s measured pages. (HTTP Archive)

20. JavaScript is more expensive than the same number of image bytes. HTTP Archive explains that scripts require parsing, compilation, and execution after download, while image bytes primarily require decoding. That is why a JavaScript budget should usually be tighter than an image budget with the same transfer number. (HTTP Archive)

For a business site, 632 KB is not a target. It is a warning about what the median has become. A brochure site with a contact form should not inherit the payload of a software dashboard just because its theme and plugins make that easy.

JavaScript and real-user performance statistics

21. Only 48% of mobile sites passed all three Core Web Vitals in 2025. The share improved from 36% in 2023 and 44% in 2024, but more than half of measured mobile origins still missed at least one threshold. (HTTP Archive)

22. Desktop Core Web Vitals pass rates reached 56%. Desktop improved from 48% in 2023 to 55% in 2024, then gained only one percentage point in 2025. (HTTP Archive)

23. A good Largest Contentful Paint is 2.5 seconds or less. LCP measures how quickly the page’s main visible content appears for real users. Heavy client-side rendering can delay that moment when key content depends on JavaScript. (web.dev)

24. A good Interaction to Next Paint is 200 milliseconds or less. INP measures responsiveness across a user’s visit. Long JavaScript tasks can keep the main thread busy and make clicks, taps, and keyboard input feel broken. (web.dev)

25. A good Cumulative Layout Shift score is 0.1 or less. JavaScript can contribute to layout movement when it inserts banners, forms, widgets, ads, or personalized content after the initial render. (web.dev)

26. Mobile sites improved their Core Web Vitals pass rate by 12 percentage points from 2023 to 2025. That improvement shows performance work can move the web in the right direction, but the 48% pass rate leaves a large gap. (HTTP Archive)

27. JavaScript-heavy pages can punish slower devices even on a fast connection. HTTP Archive identifies CPU work, device memory, parsing, compilation, and execution as separate costs after transfer. Network speed solves only one part of the problem. (HTTP Archive)

28. Google recommends breaking up long tasks that take more than 50 milliseconds. Long tasks block the browser’s main thread and can delay the visual response to a user’s input. (web.dev)

29. Google measures Core Web Vitals at the 75th percentile of page loads. A page should meet the good threshold for at least 75% of visits, split across mobile and desktop, rather than passing once in a lab test on a fast machine. (web.dev)

The business consequence is easy to understand. If the quote button responds late, the visitor does not care which tag manager, framework, or personalization tool caused it. They see a company whose website does not work.

TypeScript and developer statistics

30. TypeScript became GitHub’s most-used language by contributor count in August 2025. It passed Python by roughly 42,000 contributors, marking the first time TypeScript held the top position under GitHub’s methodology. (GitHub Octoverse)

31. TypeScript added more than one million contributors in 2025. GitHub reported 66% year-over-year growth, which it connected to typed code, modern frameworks, and AI-assisted development workflows. (GitHub Octoverse)

32. JavaScript and TypeScript together still form the largest combined ecosystem on GitHub. GitHub explicitly notes that the two languages remain larger together than Python alone, even after TypeScript is counted separately. (GitHub Octoverse)

33. GitHub had more than 180 million developers in 2025. The platform also hosted 630 million repositories, including 121 million repositories created during the year. (GitHub Octoverse)

34. Private repositories received 81.5% of GitHub contributions. Public projects supply much of the shared ecosystem, but most daily software work happens outside public view. (GitHub Octoverse)

35. State of JS counted 3,936 respondents who said all their JavaScript or TypeScript work was TypeScript. Another 3,172 selected the next-highest TypeScript share, showing how strongly typed workflows have taken hold among survey participants. (State of JS)

36. State of JS counted 5,927 respondents who said all their browser code goes through a build step. Only 262 respondents said none of it did. The modern JavaScript production process is heavily dependent on compilers, bundlers, package managers, and automated deployment. (State of JS)

37. Code architecture was the most-selected JavaScript pain point in State of JS. It received 3,719 selections, ahead of state management at 3,290 and dependency management at 3,053. (State of JS)

38. Performance was selected as a pain point 2,538 times. That placed it behind architecture, state, dependencies, and build tools, but ahead of debugging in the survey’s ranked responses. (State of JS)

39. Static typing was the most-requested missing JavaScript feature. State of JS recorded 5,403 selections for static typing and 4,378 for a standard library. (State of JS)

40. More than 8,300 respondents wanted native types to resemble TypeScript. Only 1,000 said they did not want native types implemented. (State of JS)

41. Only 18 State of JS respondents said 100% of their code was AI-generated. The largest group, 4,319 respondents, selected the next step above zero, while 2,263 said none of their code was AI-generated. (State of JS)

42. GitHub recorded more than 986 million commits in 2025, up 25% year over year. TypeScript’s rise happened during a broader surge in developer activity, not in a shrinking market. (GitHub Octoverse)

TypeScript does not make a product fast by itself. A typed 700 KB bundle is still a 700 KB bundle. Its value is maintainability: clearer contracts, safer changes, and fewer surprises as a codebase and team grow.

A practical JavaScript budget for a business website

Statistics are only useful when they change a decision. Before adding another script, ask who owns it, what outcome it supports, which pages need it, and what happens if it fails.

A sensible audit starts with the browser’s coverage report and performance trace. Test the home page, a service page, a lead form, and any checkout or booking flow. Do it on a throttled mobile profile, not just office Wi-Fi. Record the transfer size, unused bytes, long tasks, and third-party origins.

Then sort each script into one of four groups:

  • Required for the page to work, such as navigation, validation, checkout, or booking.
  • Required for measurement, with a named owner and a current business use.
  • Useful enhancement that can load after the core page becomes interactive.
  • Unused, duplicated, expired, or installed for a campaign that ended.

Remove the fourth group. Delay the third. Limit the second. Protect the first with testing.

For new projects, set a performance budget before design and development are finished. The exact number depends on what the product does. A customer portal needs more application code than a five-page service website. The budget should still be explicit, measured in transfer bytes and main-thread time, and checked during deployment.

Also test failure. Block the chat provider. Reject analytics consent. Load the page on a slow connection. Disable JavaScript long enough to see whether the business name, offer, address, phone number, and main content remain available. A marketing site should not become a blank screen because one vendor timed out.

What business owners should ask their web team

You do not need to choose a bundler or read a performance trace. You do need clear answers to a few operational questions.

Ask how much JavaScript the main templates ship, which scripts are third-party, who approves new tags, and how old tools are removed. Ask whether the site passes Core Web Vitals with field data, not only a one-time desktop test. Request a list of scripts tied to an active contract, campaign, or reporting decision.

If nobody can explain why a script is present, it probably does not have an owner. Unowned code does not stay neutral. It becomes a security dependency, a privacy question, a performance cost, and another thing that can break during the next redesign.

The goal is not a website with zero JavaScript. The goal is a site where every script earns its place.

If your website feels slower or harder to maintain than it should, talk with Your Web Team. We’ll trace what the site loads, separate necessary code from accumulated clutter, and give you a practical path to a faster, easier-to-own website.

FAQ

How much JavaScript does the average website use?

HTTP Archive’s 2025 data found 632 KB of JavaScript on the median mobile home page and 697 KB on the median desktop home page. Those figures describe the current web, not an ideal target. (HTTP Archive)

Is JavaScript bad for SEO?

JavaScript is not automatically bad for search. The risk appears when essential content requires unreliable client-side rendering, links are not crawlable, or performance suffers. Google’s documentation says server-side or pre-rendering remains a good idea because it makes sites faster for users and crawlers, and not all bots can run JavaScript. (Google Search Central)

Is TypeScript replacing JavaScript?

No. TypeScript builds on JavaScript and normally compiles to JavaScript for browsers and runtimes. Its adoption is growing fast, and it became GitHub’s top language by contributor count in August 2025, but the delivered web still depends on JavaScript. (GitHub Octoverse)

Why is unused JavaScript a problem?

Unused code still has to be transferred and processed before the browser can determine what work is needed. HTTP Archive found a median 206 KB of unused JavaScript on mobile pages in its analysis, equal to about 44% of downloaded JavaScript. (HTTP Archive)

What should I remove first?

Start with duplicate analytics, abandoned A/B testing tools, expired campaign tags, widgets that appear on every page but are used on one, and plugin features the site no longer uses. Confirm business ownership before removal, then test forms, tracking, checkout, and booking flows after each change.