JavaScript
## Metadata
- Author: [[Abdul Haddi Amjad]]
- Full Title: JavaScript
- Category: #articles
- Document Note: ---
tags: [#JavaScript, #HTTPArchive, #WebDevelopment]
- #JavaScript
- #HTTPArchive
- #WebDevelopment
Author: HTTP Archive Almanac Team
Source: [HTTP Archive Almanac](https://almanac.httparchive.org/en/2024/javascript)
Reference: [JavaScript Section](https://almanac.httparchive.org/en/2024/javascript)
date created: {{date:2025-03-08}} {{time:12:00}}
---
# Title: JavaScript in 2024 - An In-Depth Analysis
## Table of Contents:
- [📝 Summary](#%F0%9F%93%9D-summary)
- [📖 Main Content](#%F0%9F%93%96-main-content)
- [🗒️ Notes](#%F0%9F%97%92-notes)
- [📖 References](#%F0%9F%93%96-references)
- [🗣️ Paraphrase](#%F0%9F%97%A3-paraphrase)
- [📰 Newsletter](#%F0%9F%93%B2-newsletter)
- [✅ Action Items](#%F0%9F%91%85-action-items)
- [🧪 Hypotheses](#%F0%9F%A7%AA-hypotheses)
- [📊 Methodology](#%F0%9F%93%8A-methodology)
- [❓ Questions](#%E2%9D%93-questions)
- [🔮 Future Research](#%F0%9F%94%AE-future-research)
- [💡 Implications](#%F0%9F%92%A1-implications)
- [🧠 Learning Styles Assessment](#%F0%9F%A7%9A-learning-styles-assessment)
- [📊 Accessibility Assessment](#%F0%9F%93%8A-accessibility-assessment)
- [🌍 DEIB Assessment](#%F0%9F%8C%8D-deib-assessment)
- [✅ Logical validity](#%F0%9F%91%85-logical-validity)
- [🔍 DARVO Analysis](#%F0%9F%94%8D-darvo-analysis)
- [🔍 SEO Evaluation](#%F0%9F%94%8D-seo-evaluation)
- [🎯 Conclusion](#%F0%9F%8E%A0-conclusion)
## 📝 Summary:
The article **"JavaScript in 2024"** from the HTTP Archive Almanac presents a comprehensive overview of JavaScript trends, performance metrics, and evolving framework usage. It outlines empirical data with timestamped insights, contrasts modern approaches with legacy methods, and forecasts future directions for web performance and developer practices.
## 📖 Main Content:
The article systematically explores key dimensions of JavaScript in the current era:
- **Performance Metrics**:
- Analyzes load times, execution efficiency, and memory usage with data highlighted at [Timestamp 00:05](https://almanac.httparchive.org/en/2024/javascript#performance) and [Timestamp 00:15](https://almanac.httparchive.org/en/2024/javascript#performance).
- **Framework Adoption**:
- Compares legacy approaches with modern, component-based architectures. Detailed comparisons are provided at [Timestamp 00:20](https://almanac.httparchive.org/en/2024/javascript#frameworks).
- **User Experience and Web Performance**:
- Examines the role of asynchronous programming and dynamic interactivity, with usage trends evident at [Timestamp 00:30](https://almanac.httparchive.org/en/2024/javascript#usage).
- **Future Outlook**:
- Projects upcoming enhancements and challenges in JavaScript, as discussed at [Timestamp 00:45](https://almanac.httparchive.org/en/2024/javascript#future).
### 🗒️ Notes
- **Performance Trends**:
- 😊 **Key Data Points**:
- Metrics from [Timestamp 00:05](https://almanac.httparchive.org/en/2024/javascript#performance) show continuous improvement in script execution.
- [Timestamp 00:15](https://almanac.httparchive.org/en/2024/javascript#performance) confirms that modern browsers are optimizing JavaScript processing.
- 😊 **Subpoints**:
- Increased efficiency directly correlates with better user engagement.
- Browser updates have minimized load times and memory overhead.
- **Framework Analysis**:
- 😊 **Modern vs. Legacy**:
- Data at [Timestamp 00:20](https://almanac.httparchive.org/en/2024/javascript#frameworks) highlights the migration towards lightweight, modular frameworks.
- 😊 **Subpoints**:
- Enhanced maintainability and scalability are driving adoption.
- A clear shift to component-based models reflects broader industry trends.
- **Usage Patterns**:
- 😊 **Adoption of Asynchronous Techniques**:
- Trends at [Timestamp 00:30](https://almanac.httparchive.org/en/2024/javascript#usage) indicate a rise in asynchronous programming usage.
- 😊 **Subpoints**:
- Leads to smoother page transitions and richer interactive experiences.
- Contributes to the overall responsiveness of web applications.
- **Future Directions**:
- 😊 **Emerging Predictions**:
- Forecasts at [Timestamp 00:45](https://almanac.httparchive.org/en/2024/javascript#future) project further performance gains.
- 😊 **Subpoints**:
- Anticipated challenges include balancing complexity and backward compatibility.
- Continued evolution in standards and practices is expected.
## 📖 References:
- [HTTP Archive Almanac: JavaScript 2024](https://almanac.httparchive.org/en/2024/javascript)
- Industry benchmarks and performance analyses from leading web development studies.
## 🗣️ Paraphrase:
- **Original Paragraph 1**:
"JavaScript continues to evolve at a rapid pace, with performance optimizations and new frameworks reshaping the web development landscape."
**Paraphrase**:
"Rapid advancements in JavaScript, marked by significant performance boosts and innovative frameworks, are fundamentally transforming web development practices."
- **Original Paragraph 2**:
"The data indicates that modern browsers are significantly better at handling complex JavaScript, paving the way for richer, more interactive web experiences."
**Paraphrase**:
"Empirical data shows that today’s browsers efficiently manage complex JavaScript tasks, thereby enabling more dynamic and engaging user interactions."
## 📰 Newsletter:
Get ready to revolutionize your web development workflow! Our latest issue dives deep into the dynamic world of JavaScript in 2024, showcasing performance optimizations, the rise of modern frameworks, and critical data insights. With detailed timestamped analyses—from [00:05 performance metrics](https://almanac.httparchive.org/en/2024/javascript#performance) to [00:20 framework insights](https://almanac.httparchive.org/en/2024/javascript#frameworks)—we bring you the latest trends and community highlights. Discover how these innovations can empower your projects and drive efficiency. Stay informed, stay ahead—[read more](https://almanac.httparchive.org/en/2024/javascript)!
## ✅ Action Items:
- **For Open Source Advocacy & Education**:
- 😊 **Review Data Trends**:
- Examine performance metrics to integrate into webinars and workshops.
- Use [Timestamp 00:05](https://almanac.httparchive.org/en/2024/javascript#performance) data to highlight browser optimizations.
- 😊 **Framework Discussions**:
- Compare modern and legacy frameworks using insights from [Timestamp 00:20](https://almanac.httparchive.org/en/2024/javascript#frameworks).
- Discuss implications on maintainability and scalability.
- **For Community Engagement**:
- 😊 **Interactive Sessions**:
- Organize coding meetups focusing on asynchronous programming practices.
- Use live data references to spark discussion.
- **For Career Objectives (OSPO and Beyond)**:
- 😊 **Advocacy Materials**:
- Leverage empirical insights to support funding initiatives.
- Prepare detailed presentations aligning with open source principles and educational outreach.
## 🧪 Hypotheses:
- **H1**: Enhanced JavaScript performance is directly linked to increased user engagement.
- **H2**: Transitioning to modern, component-based frameworks reduces overall development time.
- **H3**: Asynchronous operations significantly improve web application responsiveness.
### 📊 Methodology:
- 😊 **Data Sources**:
- HTTP Archive metrics, browser analytics, developer surveys.
- 😊 **Research Design**:
- Mixed-method: quantitative benchmarking coupled with qualitative developer interviews.
- 😊 **Analysis Techniques**:
- Statistical trend analysis, thematic coding of interview responses, comparative framework evaluations.
### ❓ Questions:
- What specific performance improvements most influence user experience?
- How do modern frameworks compare with legacy systems in real-world applications?
- What are the long-term impacts of asynchronous JavaScript on web responsiveness?
### 🔮 Future Research:
- Investigate emerging JavaScript features and their effects on load times.
- Explore the sustainability of component-based architectures in large-scale projects.
- Study developer adaptation
- Summary: JavaScript chapter of the 2024 Web Almanac covering the usage of JavaScript on the web, libraries and frameworks, compression, web components, and source maps.
- URL: https://almanac.httparchive.org/en/2024/javascript
Part I Chapter 1
Date published: Mar 3, 2025
Hero image of the Web Almanac characters cycling to power a website.
Reviewed by [Barry Pollard](https://almanac.httparchive.org/en/2024/contributors#tunetheweb)
Analyzed by [Onur Güler](https://almanac.httparchive.org/en/2024/contributors#onurguler18) and [Nurullah Demir](https://almanac.httparchive.org/en/2024/contributors#nrllh)
Edited by [Barry Pollard](https://almanac.httparchive.org/en/2024/contributors#tunetheweb)
#### [Introduction](https://almanac.httparchive.org/en/2024/javascript#introduction)
JavaScript is essential for creating interactive web experiences, driving everything from basic animations to advanced functionalities. Its development has significantly enhanced the web’s dynamic capabilities.
However, this heavy dependence on JavaScript involves compromises. Each stage—from downloading and parsing to execution—demands substantial browser resources. Using too little can compromise user experience and business objectives while overusing it can lead to sluggish load times, unresponsive pages, and poor user engagement.
In this chapter, we will re-evaluate JavaScript’s role on the web and offer recommendations for designing smooth, efficient user experiences.
#### [How much JavaScript do we load?](https://almanac.httparchive.org/en/2024/javascript#how-much-javascript-do-we-load)
We will analyze the volume of JavaScript being deployed by web developers. Gaining a clear picture of the current state is crucial for driving any impactful improvements.
[Figure 1.1.](https://almanac.httparchive.org/en/2024/javascript#fig-1) Median JavaScript kilobytes per page.
There has been a continuous increase in the volume of JavaScript. In 2024, this upward trend resumed, with the median JavaScript payload rising by 14%, reaching 558 kilobytes on mobile and 613 kilobytes on desktop. This ongoing trend is concerning. While device capabilities are improving, not everyone has access to the latest technology. Larger JavaScript bundles place additional strain on device resources, impacting performance, especially for users with older or less powerful hardware.
#### [How many JavaScript requests per page?](https://almanac.httparchive.org/en/2024/javascript#how-many-javascript-requests-per-page)
Every resource on a web page sparks at least one request, but it can snowball quickly if that resource starts pulling in others.
[Figure 1.2.](https://almanac.httparchive.org/en/2024/javascript#fig-2) Median JavaScript requests per page.
With script requests, the stakes are higher. The more requests you send, the more JavaScript you load—and the more likely you’ll trigger a bottleneck as these scripts compete for attention on the main thread. This battle for resources can grind performance to a crawl, delaying startup and leaving users waiting.
In 2024, the median mobile page is making 22 JavaScript requests, while those in the 90th percentile soar to 68. This represents a subtle yet notable increase of one request at the median and four at the 90th percentile compared to last year.
On the desktop front, the story is similar: the median jumps to 23 JavaScript requests, with the 90th percentile climbing to 70 requests. Again, we see an increase of one request at the median and five at the 90th percentile—echoing the trends we observe in mobile.
While these increases might appear modest at first glance, they signal a continuing evolution in web-behavior. Since the Web Almanac’s inception in 2019, we’ve witnessed a steady rise in JavaScript requests, hinting at a future where growth may substantially outpace performance improvements to counteract this. What will this mean for developers and users alike as we navigate the complexities of an increasingly JavaScript-heavy web?
[Figure 1.3.](https://almanac.httparchive.org/en/2024/javascript#fig-3) Distribution of unused JavaScript.
Along with this increase in JavaScript, we see an increase in unused bytes of JavaScript with approximately half the bytes downloaded being unused during page load (206 kilobytes—or 44% of bytes delivered—at the media on mobile).
#### [How is JavaScript packaged processed?](https://almanac.httparchive.org/en/2024/javascript#how-is-javascript-packaged-processed)
JavaScript bundling and transpiling have transformed web development by optimizing how applications are built and delivered. Bundlers like webpack and Parcel package multiple files into a single bundle, reducing HTTP requests and improving loading times. Transpilers like Babel allow developers to use modern JavaScript features while ensuring compatibility across various browsers. However, managing these processes is crucial to avoid larger payloads that can hinder performance. Ultimately, they strike a balance between innovation and user experience, ensuring powerful yet efficient applications.
##### [Bundlers](https://almanac.httparchive.org/en/2024/javascript#bundlers)
JavaScript bundlers, like webpack and Parcel, package multiple JavaScript files into a single bundle to streamline delivery to users. They analyze the code and its dependencies, optimizing the final output to reduce the number of HTTP requests. By combining files, bundlers can improve loading times and performance. However, these tools can sometimes unintentionally tangle functional code with user tracking scripts, complicating performance and privacy considerations.
[Figure 1.4.](https://almanac.httparchive.org/en/2024/javascript#fig-4) Sites using webpack grouped by rank.
While webpack usage remains at a steady 5% across websites, recent trends reveal a decline in its adoption among the top 1,000 sites, both on mobile and desktop. Although 5% may seem modest, it still represents a substantial number of Web Almanac’s sites.
[Figure 1.5.](https://almanac.httparchive.org/en/2024/javascript#fig-5) Sites using Parcel grouped by rank.
Parcel stands as the second most popular alternative to webpack, boasting a notable adoption rate among developers. However, recent trends indicate a decline in its usage, dropping from 1.3% of mobile websites last year to just 0.3% this year. A similar pattern emerges on desktop platforms, reflecting a shift in the landscape of JavaScript bundlers.
##### [Transpilers](https://almanac.httparchive.org/en/2024/javascript#transpilers)
In the 2022 Web Almanac, year we [looked at transpilers as a percentage of those sites with available source maps](https://almanac.httparchive.org/en/2022/javascript#transpilers). This year, we’ve changed to the percentage of overall sites. This methodology change means we’re moving from a likely over counting of sites (sites using sourcemaps are, by definition, more likely to more complex web applications than need transpilation), to an under counting (as not all sites publish public source maps).
[Figure 1.6.](https://almanac.httparchive.org/en/2024/javascript#fig-6) Sites using Babel grouped by rank.
Babel is particularly prevalent among higher-ranked websites, with 12% of the top 10,000 mobile sites using Babel (and this is 23% - 38% of sites using source maps, so similar to [last year’s Babel results](https://almanac.httparchive.org/en/2022/javascript#fig-6)). Mobile sites consistently show higher adoption rates than desktop sites, regardless of rank. These trends highlight Babel’s prominence, especially among top-tier and mobile-optimized sites, indicating its growing importance in modern web development.
###### [How often is TypeScript used?](https://almanac.httparchive.org/en/2024/javascript#how-often-is-typescript-used)
TypeScript is a superset of JavaScript that adds static types, which help catch errors during development and make the code more maintainable. These tools streamline the development process and ensure cross-browser compatibility.
[Figure 1.7.](https://almanac.httparchive.org/en/2024/javascript#fig-7) Sites using TypeScript grouped by rank.
Across all ranks, around 6% of pages use TypeScript, with mobile generally having slightly higher adoption. Again, this only counts sites publishing sourcemaps. The usage is fairly consistent, though top-ranked pages (1,000) show slightly lower TypeScript adoption compared to lower-ranked ones.
#### [How is JavaScript requested?](https://almanac.httparchive.org/en/2024/javascript#how-is-javascript-requested)
In the fast-paced world of web development, the way JavaScript is loaded can make or break a site’s performance. From synchronous loading that can slow page rendering to asynchronous techniques that boost speed, developers have a range of options at their disposal. The challenge lies in balancing the power of JavaScript’s interactivity with the need for swift, seamless user experiences. By mastering optimal loading strategies, web creators can significantly enhance their sites’ responsiveness and user satisfaction.
##### [`async`, `defer`, `module`, and `nomodule`](https://almanac.httparchive.org/en/2024/javascript#async-defer-module-and-nomodule)
When optimizing JavaScript loading, developers have several powerful attributes at their disposal.
The `async` attribute allows scripts to load asynchronously while HTML parsing continues, executing them as soon as they’re available. In contrast, `defer` postpones script execution until after HTML parsing is complete, maintaining the order of deferred scripts.
For modern web applications, the `module` attribute indicates that a script is a JavaScript module, enabling ES6 import/export syntax and strict mode by default. Complementing this, the `nomodule` attribute specifies fallback scripts for browsers that don’t support ES6 modules, ensuring broader compatibility while allowing modern browsers to ignore these fallbacks. By strategically employing these attributes, developers can fine-tune script loading behavior to optimize page performance and user experience.
[Figure 1.8.](https://almanac.httparchive.org/en/2024/javascript#fig-8) How is JavaScript requested?.
Comparing JavaScript loading trends from [the last Web Almanac 2022](https://almanac.httparchive.org/en/javascript/#async-defer-module-and-nomodule) to 2024 reveals notable shifts in developer practices. The use of the `async` attribute has increased significantly, from 76% to 87% of pages on both desktop and mobile. The `defer` attribute usage has seen a modest increase from 42% to 47%. The combination of `async` and `defer` attributes has decreased slightly from 28-29% to 22%, possibly due to developers choosing one method over the other.
`module` usage remains low at 4%, while `nomodule` shows xlose to zero adoption, indicating that modern JavaScript module systems are still not widely implemented across the web.
| Attribute | 2022 | 2024 | % change |
| --- | --- | --- | --- |
| `async` | 47.2% | 49.5% | 4.8% |
| `defer` | 9.1% | 13.0% | 43.3% |
| `async` and `defer` | 3.1% | 3.0% | -3.0% |
| `module` | 0.4% | 1.2% | 208.8% |
| `nomodule` | 0.0% | 0.0% | N/A |
[Figure 1.9.](https://almanac.httparchive.org/en/2024/javascript#fig-9) JavaScript requests by script (mobile).
Comparing the trends on `<script>` tags from 2022 to 2024, the overall use of `async` in scripts saw a 4.8% increase, maintaining its dominance. The `defer` attribute usage, however, experienced a notable increase, where it climbed from 9.1% to 13.0% on mobile in 2024. The combination of `async` and `defer` saw a slight decrease. The `module` attribute saw a tripling in used but continues to have very low adoption across both desktop and mobile platforms.
##### [`preload`, `prefetch`, and `modulepreload`](https://almanac.httparchive.org/en/2024/javascript#preload-prefetch-and-modulepreload)
Resource hints play a crucial role in optimizing browser performance by indicating which resources should be fetched early. Preload is used to fetch resources required for the current navigation, ensuring that critical assets are available as soon as they are needed. Modulepreload serves a similar purpose but specifically for preloading JavaScript modules, helping to load modular scripts efficiently. Prefetch, on the other hand, is designed for resources that will be needed in the next navigation, allowing the browser to anticipate and prepare for future page transitions.
[Figure 1.10.](https://almanac.httparchive.org/en/2024/javascript#fig-10) Resource hints adoption for JavaScript resources.
In comparing the trends between 2022 and 2024 for resource hints adoption, `preload` usage dropped significantly from [16.4% on desktop in 2022](https://almanac.httparchive.org/en/2022/javascript#preload-prefetch-and-modulepreload) to 7.5% overall in 2024. `prefetch` adoption increased considerably from around 1.0% in 2022 to 4.8% overall in 2024. `modulepreload` usage stayed very minimal across both years, hovering around 0.1% in 2022 and showing a similar low percentage of 0.7% in 2024.
[Figure 1.11.](https://almanac.httparchive.org/en/2024/javascript#fig-11) Distribution of `prefetch` adoption for JavaScript resources per page.
The distribution of `prefetch` adoption for JavaScript resources (among pages that use `prefetch`) shows that the number of prefetch hints peaks at 15 prefetch hints from the median to 90th percentile.
[Figure 1.12.](https://almanac.httparchive.org/en/2024/javascript#fig-12) Distribution of `preload` adoption for JavaScript resources per page.
Among pages that use `preload`, there is less usage with only one `preload` at the median, increasing to six at the 90th percentile.
[Figure 1.13.](https://almanac.httparchive.org/en/2024/javascript#fig-13) Distribution of `modulepreload` adoption for JavaScript resources per page.
`modulepreload` usage is much more varied, but with low usage this is easily skewed by a few sites.
##### [Injected scripts](https://almanac.httparchive.org/en/2024/javascript#injected-scripts)
Script injection involves creating an `HTMLScriptElement` using `document.createElement` and adding it to the DOM via a DOM insertion method, or injecting `<script>` markup as a string using `innerHTML`. While common in many use cases, this practice bypasses the browser’s preload scanner, making the script undetectable during the initial HTML parsing. This can negatively impact performance metrics like [Largest Contentful Paint (LCP)](https://web.dev/articles/lcp), especially if the injected script triggers long tasks or parses large amounts of markup dynamically.
[Figure 1.14.](https://almanac.httparchive.org/en/2024/javascript#fig-14) Distribution of percentage of injected scripts.
Comparing the two distributions of injected scripts, the 2024 graph shows a notable decrease in the percentage of injected scripts at the 50th percentile, rising from 25% in 2022 to 21% in 2024. At higher percentiles, the trend remains consistent between the two years, with 70% of scripts being injected at the 90th percentile in both 2022 and 2024. The early percentiles saw a slight uptick in injection, but overall, the pattern of script injection has remained steady at higher resource levels.
##### [First-party versus third-party JavaScript](https://almanac.httparchive.org/en/2024/javascript#first-party-versus-third-party-javascript)
First-party JavaScript is code that is directly served by and belongs to the website’s domain, playing a key role in the site’s functionality and user experience. In contrast, third-party JavaScript comes from external domains and is typically used for services like analytics, ads, or social media integrations. While first-party scripts have direct control and transparency, third-party scripts can introduce performance, security, and privacy risks. Managing the balance between these two types is crucial for optimizing site performance and safeguarding user data. In this section, we’ll explore the distribution of first-party and third-party code and assess how modern websites are splitting their JavaScript loads across different sources.
###### [Requests](https://almanac.httparchive.org/en/2024/javascript#requests)
[Figure 1.15.](https://almanac.httparchive.org/en/2024/javascript#fig-15) Distribution of JavaScript requests by host.
Comparing the two trends, the 2024 graph shows an increase in [third-party JavaScript requests compared to 2022](https://almanac.httparchive.org/en/2022/javascript#first-party-versus-third-party-javascript), particularly at the 90th percentile, where third-party requests grew from 34 in 2022 to 36 in 2024. First-party requests also increased slightly, but the rise in third-party scripts is more pronounced. This increase in third-party JavaScript is concerning, as it can negatively impact performance, introduce security vulnerabilities, and pose privacy risks for users due to the lack of direct control over external scripts
###### [Bytes](https://almanac.httparchive.org/en/2024/javascript#bytes)
[Figure 1.16.](https://almanac.httparchive.org/en/2024/javascript#fig-16) Distribution of JavaScript bytes by host.
The amount of bytes downloaed, shows simialr increases to the number of requests.
##### [Dynamic Imports](https://almanac.httparchive.org/en/2024/javascript#dynamic-imports)
Dynamic `import()` offers a more flexible alternative to the traditional static import syntax, allowing it to be called from anywhere within a script, unlike static imports that are restricted to the top of a JavaScript file.
By deferring the loading of non-essential code until it’s actually needed, dynamic imports can significantly enhance startup performance, reducing the initial load and boosting overall efficiency.
[Figure 1.17.](https://almanac.httparchive.org/en/2024/javascript#fig-17) The percentage of mobile pages using dynamic `import()`.
The jump in the usage of dynamic imports on mobile pages from 0.34% to 3.70% signifies a growing adoption of this technique for performance optimization. This sharp increase highlights how developers are increasingly leveraging dynamic imports to improve load times and reduce the upfront JavaScript payload on mobile devices. By deferring non-critical scripts, websites can enhance both performance and user experience, particularly on resource-constrained mobile environments. The rise reflects an industry shift towards more efficient and on-demand loading strategies for better mobile performance.
##### [Web workers](https://almanac.httparchive.org/en/2024/javascript#web-workers)
Web workers are a powerful web platform feature designed to alleviate the load on the main thread by running JavaScript in the background on a separate thread. Unlike traditional scripts, web workers operate independently without direct access to the DOM, allowing them to handle intensive tasks—such as data processing or complex calculations—without affecting the UI’s responsiveness. By offloading these resource-heavy operations, web workers ensure smoother performance and prevent the main thread from becoming overwhelmed, making them essential for delivering faster, more efficient web experiences.
[Figure 1.18.](https://almanac.httparchive.org/en/2024/javascript#fig-18) The number of mobile pages using web workers.
The increase in mobile pages utilizing web workers from 12% to 30% marks a significant shift in the adoption of this technology. This nearly threefold rise highlights how developers are increasingly leveraging web workers to offload intensive tasks, improving performance and ensuring smoother user experiences on mobile devices. With nearly a third of mobile pages now incorporating web workers, it reflects a growing recognition of the importance of keeping the main thread free for critical UI updates, ultimately driving more responsive and efficient mobile interactions.
##### [Worklets](https://almanac.httparchive.org/en/2024/javascript#worklets)
Worklets are a specialized class of web workers designed to provide low-level access to rendering pipelines for tasks like painting and audio processing. A key performance advantage of worklets is their ability to run independently on separate threads, offloading resource-intensive tasks from the main thread. This not only boosts efficiency but also enhances performance by keeping the main thread free for essential operations, leading to smoother visuals and seamless audio experiences.
[Figure 1.19.](https://almanac.httparchive.org/en/2024/javascript#fig-19) The percentage of mobile pages that register at least one paint worklet.
[Figure 1.20.](https://almanac.httparchive.org/en/2024/javascript#fig-20) The percentage of mobile pages that register at least one audio worklet worklet.
The adoption of worklets on mobile devices remains extremely low, with paint worklets slightly higher at 0.0016%, a slight increase from the previous Web Almanac, and audio worklets used on just 0.0004% of mobile pages. These figures suggest that despite the potential benefits worklets offer for offloading tasks like audio processing and rendering, their usage is still far from mainstream in the mobile web development space. This could be due to their specialized functionality and the need for more widespread browser support and developer familiarity.
#### [How is JavaScript delivered?](https://almanac.httparchive.org/en/2024/javascript#how-is-javascript-delivered)
The way JavaScript resources are delivered to browsers continues to be a critical aspect of web performance, with compression playing a significant role in reducing payload sizes and improving load times. Let’s examine how JavaScript resources are being compressed and delivered across the web in 2024.
##### [Compression Methods](https://almanac.httparchive.org/en/2024/javascript#compression-methods)
When JavaScript resources are delivered over the network, they can be compressed to reduce their transfer size. Compression is a crucial optimization technique that helps reduce bandwidth usage and improve page load times. Several compression algorithms used for JavaScript delivery include brotli (br), gzip, zstd.
While brotli offers better compression ratios than gzip, especially for text resources like JavaScript, gzip has been a web standard for many years with its broader browser support and fast compression speeds. Zstandard (zstd) is a newer compression algorithm developed by Facebook that aims to provide high compression ratios with fast compression and decompression speeds. Despite its promising capabilities, our data shows minimal adoption at just 1% of requests in 2024.
[Figure 1.21.](https://almanac.httparchive.org/en/2024/javascript#fig-21) Compression methods of script resources.
Turns out 2024 marks a pivotal shift in JavaScript compression trends, with Brotli (`br`) finally overtaking gzip as the most prevalent compression method. Brotli now commands 45% of mobile and 44% of desktop JavaScript requests, compared to gzip’s 41% across both platforms. This is a remarkable transformation from 2022, when gzip led with 52% compared to Brotli’s 34%, and an even more dramatic change from 2021’s numbers (gzip: 55%, Brotli: 30.8%).
This Brotli ascendancy represents a major win for web performance, as Brotli typically achieves better compression ratios than gzip, particularly for JavaScript resources. The steady year-over-year growth in Brotli adoption (30.8% → 34% → 45%) suggests a growing recognition of its benefits among web developers and hosting providers.
[Figure 1.22.](https://almanac.httparchive.org/en/2024/javascript#fig-22) Growth of Brotli for compressing JavaScript.
The remaining landscape shows that about 12-13% of requests still arrive uncompressed, while the newer zstd compression method maintains a minimal 1% adoption rate across both platforms. A negligible amount of websites also seem to use a combination of compression techniques, like gzip + deflate, or br + gzip. This doesn’t necessarily mean that both are being used at the same time, because using both anyway doesn’t have any additional effect. What could explain the usage is either that different assets on the same page might be using different compression methods, or supporting different kind of browsers when brotli for example was not supported in all browsers.
[Figure 1.23.](https://almanac.httparchive.org/en/2024/javascript#fig-23) Compression methods of script resources by host.
An interesting contrast is seen when looking at third-party scripts making gzip a clear winner again. Looking at the trends, gzip is still the primary compression method used with a 60% vs 29% comparison. This shows the missed performance gains due to a lot of third-party JavaScript still being deployed without brotli compression.
[Figure 1.24.](https://almanac.httparchive.org/en/2024/javascript#fig-24) Uncompressed resources by host.
Looking at uncompressed resources across the spectrum, we see the same smaller resources of less than 5 KB that are not sent over with any compression which makes sense as applying compression on such small resources does not add much value and in fact could add the compression overhead. However, some larger first party resources are still not enjoying the benefits of any kind of compression methods, wiht 6% of scripts of 100 kilobytes or mote not being compressed at all.
##### [Minification](https://almanac.httparchive.org/en/2024/javascript#minification)
JavaScript minification is a crucial optimization technique that reduces the size of JavaScript code by eliminating unnecessary characters without changing its functionality. Think of it like taking a lengthy novel and removing all the whitespace and making character names shorter - the story remains the same, but it takes up less space. The part about making function names, variable names, class names etc. shorter is also called uglification.
[Figure 1.25.](https://almanac.httparchive.org/en/2024/javascript#fig-25) Distribution of unminified JavaScript audit scores.
Here, 0.00 represents the worst score whereas 1.00 represents the best score. 62% of mobile pages are scoring between 0.9 and 1.0 on Lighthouse’s minified JavaScript audit, whereas the figure for desktop pages is 60%. This means that on mobile, 38% of pages have opportunities to ship minified JavaScript, whereas that figure for desktop pages is 40%.
[Figure 1.26.](https://almanac.httparchive.org/en/2024/javascript#fig-26) Unminified JavaScript bytes per page.
At the median, we see that pages are shipping around 12 KB of JavaScript that can be minified. By the time we get to the 75th and 90th percentiles, however, that number jumps quite a bit, from 34 KB to about 76 KB. Third-parties are pretty good throughout, up until we get to the 90th percentile, however, where they’re shipping around 19 KB of unminified JavaScript.
[Figure 1.27.](https://almanac.httparchive.org/en/2024/javascript#fig-27) Average wasted bytes of unminified JavaScript.
When it comes to unminified JavaScript wasting bandwidth in 2024, first-party code is still the main offender. The numbers don’t lie—82.7% of these wasted bytes come from an organization’s own scripts, while third-party code chips in a smaller but still notable 17.3%. It’s a pattern we’ve seen before, but it’s surprising how little has changed. We often point fingers at third parties for performance issues, but the real low-hanging fruit seems to be the first party code.
Minification isn’t just a checkbox—it’s a must. Stripping out comments, whitespace, and unused code shrinks file sizes, which speeds up how fast a page loads. And first-party scripts are our responsibility, which if not minified leaves obvious performance gains on the table. Third parties aren’t off the hook, though. That 17.3% might seem small, but unoptimized vendor scripts can drag down performance, especially on slower networks or older devices. If a third-party script isn’t minified, the question really should be to ask ourselves if the tool is worth it or could we swap it for something leaner?
Every kilobyte shaved off a script means faster load times, happier users, and better SEO.
##### [Source Maps](https://almanac.httparchive.org/en/2024/javascript#source-maps)
Source maps remain a critical tool for developers, bridging the gap between minified production code and its original, human-readable form. They’re essential for debugging but often underutilized—or misused—in practice. Let’s break down the 2024 data.
[Figure 1.28.](https://almanac.httparchive.org/en/2024/javascript#fig-28) The percentage of mobile pages specifying source map comments to publicly accessible source maps.
This marks a slight uptick from previous years. In 2022, only 14% of mobile pages used source map comments, and just 0.12% leveraged headers. While adoption is inching upward, progress feels glacial. The HTTP header method remains stubbornly rare, likely due to its reliance on server configuration and developer awareness.
[Figure 1.29.](https://almanac.httparchive.org/en/2024/javascript#fig-29) The number of mobile pages specifying source map headers.
Source maps themselves aren’t a performance issue—browsers ignore them unless explicitly requested (e.g., via DevTools). However, their misuse can backfire:
Inline source maps (base64-encoded within production files) bloat JavaScript payloads, slowing downloads and processing. Publicly exposed source maps risk revealing sensitive code logic or credentials if not properly scoped.
The data suggests most teams still opt for source map comments over headers. While comments are easier to implement (often automated by build tools like webpack or Rollup), headers offer better control. For instance, headers can be conditionally served only to internal tools or authenticated users, reducing exposure of raw source code.
#### [Responsiveness](https://almanac.httparchive.org/en/2024/javascript#responsiveness)
We rely on JavaScript to provide interactivity, but the use of JavaScript can result in poor input responsiveness. More information can be found in the dedicated [Performance](https://almanac.httparchive.org/en/2024/performance) chapter.
##### [Metrics](https://almanac.httparchive.org/en/2024/javascript#metrics)
We look at both field data from the [Chrome UX Report (CrUX)](https://developer.chrome.com/docs/crux) and Lighthouse lab data to measure responsiveness.
###### [Interaction to Next Paint (INP)](https://almanac.httparchive.org/en/2024/javascript#interaction-to-next-paint-inp)
[Figure 1.30.](https://almanac.httparchive.org/en/2024/javascript#fig-30) Distribution of INP by origin.
[Interaction to Next Paint (INP)](https://web.dev/articles/inp) became [a Core Web Vital in 2024](https://web.dev/blog/inp-cwv-launch). It measures all keyboard, mouse, and touch interactions on a page and selects a high percentile of interaction latency to represent overall page responsiveness.
A “good” INP score is 200 milliseconds or less. At the median (50th percentile), both mobile (100 ms) and desktop (75 ms) score well within this threshold. However, at the 75th percentile, desktop (125 ms) and mobile (150 ms) approach the “needs improvement” range. By the 90th percentile, desktop (225 ms) and mobile (275 ms) exceed the “good” threshold, indicating responsiveness issues for a significant portion of websites.
###### [Total Blocking Time (TBT)](https://almanac.httparchive.org/en/2024/javascript#total-blocking-time-tbt)
[Figure 1.31.](https://almanac.httparchive.org/en/2024/javascript#fig-31) Distribution of TBT.
The [Total Blocking Time (TBT)](https://web.dev/articles/tbt) metric is a lab metric which calculates the total blocking time of long tasks during startup.
TBT is sourced from Lighthouse rather real-user data. This measures synthetic performance in simulated desktop and mobile environments with device-appropriate CPU and network throttling enabled.
At the 75th percentile, mobile pages have nearly 3.0 seconds (2,988 ms) of blocking time, indicating a poor user experience. By the 90th percentile, mobile blocking time surges to 5.95 seconds (5,950 ms), whereas desktop remains substantially lower, reinforcing the performance gap between device types.
##### [Long Tasks / blocking time](https://almanac.httparchive.org/en/2024/javascript#long-tasks--blocking-time)
A long task is any task that runs on the main thread for longer than 50 milliseconds. The length of the task beyond 50 milliseconds is that task’s blocking time, which can be calculated by subtracting 50 milliseconds from the task’s total time.
[Figure 1.32.](https://almanac.httparchive.org/en/2024/javascript#fig-32) Distribution of number of long tasks per page.
The median page encounters 14 long tasks on mobile and 3 long tasks on desktop devices. This aligns with expectations, as desktop devices typically have greater processing power and memory resources than mobile devices.
At the 75th percentile, mobile pages experience 24 long tasks, while desktop pages have 6 long tasks. By the 90th percentile, mobile pages encounter 38 long tasks, whereas desktop pages still manage significantly fewer at 11 long tasks. This highlights the challenge of optimizing JavaScript execution, particularly for mobile users who face a much higher burden of blocking tasks.
[Figure 1.33.](https://almanac.httparchive.org/en/2024/javascript#fig-33) Distribution of long tasks time per page.
The median mobile page has 2.37 seconds (2,366 ms) dedicated to long tasks, whereas desktop pages experience significantly less, at just a fraction of that time.
At the 75th percentile pages spend 4.48 seconds (4,483 ms) processing long tasks, while desktop pages remain much lower. By the 90th percentile, mobile long task time soars to 7.77 seconds (7,770 ms), highlighting a major responsiveness issue. This excessive processing time suggests a strong need for JavaScript optimizations, such as breaking up long tasks or leveraging web workers to handle intensive computations off the main thread. These results underscore the challenges mobile users face when dealing with heavy JavaScript execution.
##### [Scheduler API](https://almanac.httparchive.org/en/2024/javascript#scheduler-api)
The [Scheduler API](https://developer.mozilla.org/docs/Web/API/Scheduler) has recently been expanded with the [`yield` method](https://developer.mozilla.org/docs/Web/API/Scheduler/yield), which provides an easier method to [break up long tasks](https://web.dev/articles/optimize-long-tasks).
[Figure 1.34.](https://almanac.httparchive.org/en/2024/javascript#fig-34) The percentage of mobile pages using the Scheduler API.
Currently, only 0.65% desktop pages are shipping JavaScript that uses the Scheduler API, a significant increase from [0.002% last time we looked](https://almanac.httparchive.org/en/2022/javascript#scheduler-api). On mobile, 0.81% of pages now utilize this feature. This growth from 2022 suggests that as documentation improves and support expands, developers are increasingly integrating the Scheduler API into their applications. The rising adoption, especially in frameworks, indicates a shift towards more efficient scheduling and performance optimization in JavaScript execution. We expect this trend to continue, ultimately contributing to better user experience outcomes.
##### [Synchronous XHR](https://almanac.httparchive.org/en/2024/javascript#synchronous-xhr)
AJAX—or usage of the XMLHttpRequest (XHR) has a flag that allows you to make synchronous requests. Synchronous XHR is harmful for performance because the event loop and main thread is blocked until the request is finished, resulting in the page hanging until the data becomes available. `fetch` is a much more effective and efficient alternative with a simpler API, and has no support for synchronous fetching of data.
[Figure 1.35.](https://almanac.httparchive.org/en/2024/javascript#fig-35) The percentage of mobile pages using synchronous XHR.
Synchronous XHR is now used on 2.15% of mobile pages and 2.22% of desktop pages, marking a small decline from 2022 (2.5% and 2.8% respectively). While its usage is decreasing, its continued presence—even at these levels—indicates that some legacy applications still rely on this outdated method, which negatively impacts user experience.
##### [`document.write`](https://almanac.httparchive.org/en/2024/javascript#documentwrite)
The only `document.write` API is very problematic for a number of reasons that [the HTML spec itself warns against its use](https://html.spec.whatwg.org/multipage/dynamic-markup-insertion.html#document.write()).
[Figure 1.36.](https://almanac.httparchive.org/en/2024/javascript#fig-36) The number of mobile pages using `document.write`.
A notable 12% of mobile pages observed are still using `document.write` to add content to the DOM instead of proper insertion methods. On desktop, 13% of pages continue to rely on this approach. This marks a decline from 2022 (18% and 17%), suggesting that more developers are moving away from this inefficient method. However, legacy applications and third-party scripts still contribute to its usage.
##### [Legacy Javascript](https://almanac.httparchive.org/en/2024/javascript#legacy-javascript)
Lighthouse currently checks for Babel transforms that may be unnecessary on the modern web, such as transforming use of `async` and `await`, JavaScript classes, and other newer, yet widely supported language features.
[Figure 1.37.](https://almanac.httparchive.org/en/2024/javascript#fig-37) The percentage of mobile pages that ship legacy JavaScript.
Just over two-thirds of mobile pages are still shipping JavaScript resources that are being transformed or contain unnecessary legacy JavaScript. This figure remains unchanged from 2022, indicating that despite awareness of performance issues, many pages continue to rely on these transformations. On desktop, 70% of pages are still shipping these transforms.
Despite a negligible change in this statistic from 2022, we hope to see a decline over time as JavaScript’s evolution stabilizes and developers adopt more efficient practices.
#### [How is JavaScript used?](https://almanac.httparchive.org/en/2024/javascript#how-is-javascript-used)
JavaScript can be used directly, or via abstractions such as libraries and frameworks.
##### [Library usage](https://almanac.httparchive.org/en/2024/javascript#library-usage)
To understand the usage of libraries and frameworks, HTTP Archive uses [Wappalyzer](https://almanac.httparchive.org/en/2024/methodology#wappalyzer) to detect the technologies used on a page.
[Figure 1.38.](https://almanac.httparchive.org/en/2024/javascript#fig-38) Adoption of top libraries and frameworks.
Readers of previous editions of the Web Almanac will not be surprised to see that jQuery still remains the most widely used library on the web, appearing on 74% of pages. A significant portion of this is due to WordPress, but even outside of WordPress, jQuery continues to be a dominant choice for many websites.
The widespread adoption of core-js (41%) is also expected, as many web applications rely on Babel, which often uses core-js to provide polyfills for missing JavaScript features. As browsers continue to evolve and support more modern features natively, this number should decline, reducing unnecessary bytes in web applications.
jQuery Migrate is present on 33% of pages, indicating that a large number of websites are still relying on older jQuery versions. Similarly, jQuery UI is still in use on 22% of pages, despite being mostly deprecated.
Other notable libraries include Swiper (15%), Lodash (11%), and Modernizr (11%), all of which play roles in handling UI elements and feature detection.
React usage has grown slightly to 10%, compared to 8% last year, but this still suggests a relatively stable adoption rate. This may indicate that while React remains popular, its growth has plateaued due to increasing competition in the JavaScript ecosystem.
Meanwhile, libraries like GSAP (9%), OWL Carousel (8%), Slick (8%), LazySizes (8%), and FancyBox (7%) continue to be widely used, especially in performance and animation-heavy applications.
As the web ecosystem continues to modernize, we expect some of these legacy libraries, especially jQuery-based ones, to decline over time in favor of more native solutions and modern frameworks.
##### [Libraries used together](https://almanac.httparchive.org/en/2024/javascript#libraries-used-together)
Frameworks and libraries are often used together on the same page. As with last year, we’ll examine this phenomenon to gain insight into how many libraries and frameworks have been used together in 2024.
| apps | desktop | mobile |
| --- | --- | --- |
| jQuery | 7.57% | 7.61% |
| jQuery, jQuery Migrate | 3.71% | 3.91% |
| core-js, jQuery | 1.71% | 1.67% |
| GSAP, Lodash, React | 1.25% | 1.50% |
| jQuery, jQuery UI | 1.71% | 1.48% |
| core-js, jQuery, jQuery Migrate | 1.33% | 1.29% |
| Swiper, core-js, jQuery, jQuery Migrate, jQuery UI | 1.10% | 1.22% |
| core-js, jQuery, jQuery Migrate, jQuery UI | 1.02% | 1.12% |
| Lodash, Modernizr, Stimulus, YUI, core-js | 1.02% | 0.88% |
| core-js | 0.73% | 0.75% |
[Figure 1.39.](https://almanac.httparchive.org/en/2024/javascript#fig-39) Common library combinations.
It’s clear though that jQuery has some serious staying power, with some combination of it, its UI framework, and its migration plugin occurring in the top seven spots, with core-js having a prominent role in library usage as well.
#### [Web Components and Shadow DOM](https://almanac.httparchive.org/en/2024/javascript#web-components-and-shadow-dom)
Web Components allows encapsulation of logic and styling through web components and the shadow DOM. To kick off this year’s analysis, we’ll begin with custom elements.
[Figure 1.40.](https://almanac.httparchive.org/en/2024/javascript#fig-40) The percentage of desktop pages that used custom elements.
This figure has increased from the 2022 analysis of custom element usage on desktop pages, which was 2.0%. With the advantages that custom elements provide and their reasonably broad support in modern browsers, we’re encouraged to see the growing adoption of the web component model. This trend suggests that developers are increasingly leveraging web platform built-ins to create faster user experiences.
[Figure 1.41.](https://almanac.httparchive.org/en/2024/javascript#fig-41) The percentage of mobile pages that used shadow DOM.
Shadow DOM allows you to create dedicated nodes in a document that contain their own scope for sub-elements and styling, isolating a component from the main DOM tree. Compared to the 2022 figure of 0.39% of mobile pages using shadow DOM, adoption of the feature has significantly increased, reaching 2.51% in 2024. This growth indicates a rising trend in developers leveraging shadow DOM for better component encapsulation and styling consistency.
[Figure 1.42.](https://almanac.httparchive.org/en/2024/javascript#fig-42) The percentage of mobile pages that use templates.
The template element helps developers reuse markup patterns. Their contents render only when referenced by JavaScript. Templates work well with web components, as the content that is not yet referenced by JavaScript is then appended to a shadow root using the shadow DOM.
Roughly 0.28% of web pages on mobile are currently using the template element, a notable increase from 0.05% in 2022. Though templates are well-supported in browsers, their adoption remains relatively low but is showing signs of growth.
[Figure 1.43.](https://almanac.httparchive.org/en/2024/javascript#fig-43) The percentage of mobile pages that used the `is` attribute.
The HTML `is` attribute is an alternate way of inserting custom elements into the page. Rather than using the custom element’s name as the HTML tag, the name is passed to any standard HTML element, which implements the web component logic. The `is` attribute is a way to use web components that can still fall back to standard HTML element behavior if web components fail to be registered on the page.
In 2024, the adoption of the `is` attribute has increased to 0.29% from 0.08% in 2022. Despite this growth, its usage remains lower than custom elements themselves. Due to the lack of support in Safari, browsers on iOS and macOS cannot utilize the attribute, possibly contributing to its limited adoption.
#### [Conclusion](https://almanac.httparchive.org/en/2024/javascript#conclusion)
The state of JavaScript continues to follow expected trends—its usage keeps growing, but so do efforts to mitigate its impact. Developers are increasingly leveraging minification, resource hints, compression, and smarter dependency management to balance performance and functionality.
However, our growing reliance on JavaScript raises concerns for web performance and user experience. Reducing unnecessary script execution and optimizing delivery remain crucial challenges. As the web platform evolves, we hope to see greater adoption of native APIs where feasible, while frameworks continue to improve their efficiency and embrace performance-conscious best practices.
Looking ahead, a meaningful shift in the trend would require a collective push toward better tooling, best practices, and awareness. Until then, we must remain diligent in optimizing JavaScript delivery—ensuring a fast, resilient web for all users., JavaScript, Abdul Haddi Amjad, 01jnvb7gr6snj94f8c5y0qy6k8.