Feature Request: Built-In Web Libraries (BWL) via browser-lib attribute

[TTMTT]

What problem are you trying to solve?

Proposal: Built-In Web Libraries (BWL) via browser-lib Attribute

Summary

This proposal introduces a new optional HTML attribute, browser-lib, to <script> and <link> elements, enabling modern browsers to natively serve popular open-source libraries (e.g., jQuery, Bootstrap, Tailwind CSS) directly from within the browser binary, rather than fetching them from the network. The attribute uses the following format:

<script src="..." browser-lib="jquery@3.6.0"></script>
<link href="..." browser-lib="bootstrap@5.3.2" rel="stylesheet">

---

Motivation

Web developers across the globe rely heavily on a small number of widely used frontend libraries. These include:

• jQuery (used by millions of sites)
• Bootstrap (used for UI/UX layout and components)
• Tailwind CSS (popular utility-first framework)

Despite widespread usage and relatively static versions in production, every website still fetches its own copy of these libraries, leading to:

• Unnecessary bandwidth consumption
• Redundant storage and caching
• Slower page load times
• Increased data usage, especially on mobile networks

Built-In Web Libraries (BWL) solves this by embedding selected versions of these libraries directly inside the browser. With a simple browser-lib hint, developers can request the browser to use its built-in copy, falling back to external loading if not available.

---

How It Works

1. The developer includes the browser-lib attribute with the desired library name and exact version:

   <script src="/fallback/jquery.js" browser-lib="jquery@3.6.0"></script>

2. If the browser supports this feature and includes jquery@3.6.0 internally:

   • It ignores the external src
   • Injects the native library directly into the DOM

3. If not:

   • The browser loads from the src or href path as normal (graceful fallback)

---

Browser Storage Considerations

• Libraries are bundled within the browser itself as part of its installation or update package

• Stored in a read-only, signed, compressed format

• Only stable and commonly used versions are included to avoid bloat

• Examples:

  • jQuery 3.6.0
  • Bootstrap 5.3.2
  • Tailwind CSS 3.4.1

• Total estimated space usage: ~30MB

• No network access required — ensures perfect load speed and consistency

---

Benefits

• Zero-latency load for embedded libraries
• Reduced bandwidth for both clients and servers
• Eco-friendly: Less global data transfer
• Security: Controlled and verified versions only
• Developer freedom: Still able to override by simply omitting browser-lib

---

Security and Compatibility

• Only libraries with open-source licenses, wide adoption, and stable release cycles are eligible

• Strict version matching, no wildcards or loose versioning

• Fully backward compatible:

  • Browsers that do not recognize browser-lib will simply use the standard src or href
  • No runtime errors or behavioral inconsistencies

---

Example Usage

<!-- Load Bootstrap 5.3.2 from browser, fallback to vendor folder -->
<link rel="stylesheet" href="/vendor/bootstrap.css" browser-lib="bootstrap@5.3.2">

<!-- Load Tailwind CSS 3.4.1 if available -->
<link rel="stylesheet" href="/vendor/tailwind.css" browser-lib="tailwind@3.4.1">

<!-- Load jQuery 3.6.0 from built-in bundle -->
<script src="/vendor/jquery.js" browser-lib="jquery@3.6.0"></script>

---

Naming and Specification

This mechanism is referred to as Built-In Web Libraries (BWL).
The proposed HTML attribute is:

browser-lib="library@version"

Supported elements:

• <script>
• <link rel="stylesheet">

---

Conclusion

Built-In Web Libraries (BWL) represent a lightweight, forward-compatible enhancement to the modern web stack. By leveraging the enormous redundancy of frontend libraries across websites, browsers can unlock tremendous performance, reduce global data waste, and enhance user experience, all without breaking existing standards.

We invite the Chromium team and web standards community to consider integrating this proposal for a faster, leaner, and more efficient web.

What solutions exist today?

No response

How would you solve it?

No response

Anything else?

No response

[pmeenan]

For what it's worth, we've been down this path several times before and bundling the libraries with the browser (or even serving from a canonical location and sharing cache) had more issues than it solved. I'm sure there are more, but the primary challenges that I remember are generally of the form of:

• The libraries used by websites are usually bundled/included in with other code and they would have to extract the dependencies.
• There is a HUGE variety in the specific versions of libraries that sites use.
• Bundling versions with the browser tends to make the specific versions shipped with each browser "stickier".
• There's a fairly big adoption problem of getting large parts of the web to make the change.

From the Chrome side of things, we're planning to explore an alternative approach where we ship a compression dictionary that has the most common js/css (maybe HTML?) chunks in it so that the common web libraries would effectively get compressed to zero.

The main benefits that would have are:

• A single version of a given library will likely compress older and newer versions of the same library almost as well since most of the code will be common (so sites continue to use whatever version of the library they'd like).
• It works for bundled versions of the library, compressing the relevant bits out of the bundle automatically.
• It doesn't require changes to the site code itself. It can be applied at the serving/CDN layer automatically.

None of the solutions are going to unlock "tremendous performance" but we're hoping the compression path will solve most of the issues you are describing with the most flexibility.

[TTMTT]

For what it's worth, we've been down this path several times before and bundling the libraries with the browser (or even serving from a canonical location and sharing cache) had more issues than it solved. I'm sure there are more, but the primary challenges that I remember are generally of the form of:

• The libraries used by websites are usually bundled/included in with other code and they would have to extract the dependencies.
• There is a HUGE variety in the specific versions of libraries that sites use.
• Bundling versions with the browser tends to make the specific versions shipped with each browser "stickier".
• There's a fairly big adoption problem of getting large parts of the web to make the change.

From the Chrome side of things, we're planning to explore an alternative approach where we ship a compression dictionary that has the most common js/css (maybe HTML?) chunks in it so that the common web libraries would effectively get compressed to zero.

The main benefits that would have are:

• A single version of a given library will likely compress older and newer versions of the same library almost as well since most of the code will be common (so sites continue to use whatever version of the library they'd like).
• It works for bundled versions of the library, compressing the relevant bits out of the bundle automatically.
• It doesn't require changes to the site code itself. It can be applied at the serving/CDN layer automatically.

None of the solutions are going to unlock "tremendous performance" but we're hoping the compression path will solve most of the issues you are describing with the most flexibility.

Thank you for the thoughtful explanation, and I appreciate the background on previous attempts.

Just to clarify, the BWL (Built-In Web Libraries) proposal is designed to be fully optional, declarative, and entirely developer-controlled. It doesn't aim to replace compression techniques or force any behavior, it simply introduces an opt-in hint for performance-conscious developers who choose to leverage it.

For example:

<script src="https://cdn.example.com/assets/jquery-3.6.0.js" browser-lib="jquery@3.6.0"></script>

This means:

• If the browser has jquery@3.6.0 bundled internally, it uses the built-in version and skips the network fetch.
• If it doesn't, the browser just loads the provided URL as usual.
• If the developer does not want this behavior, they simply don’t use the browser-lib attribute, and nothing changes.

This preserves full backward compatibility, with zero breakage for older browsers.

---

Targeted Use Cases (Not for All Scenarios)

It's also important to clarify that BWL is not meant to cover bundled custom versions of libraries. If a developer combines jQuery with custom code in a build pipeline (e.g., app.bundle.js), they wouldn't use browser-lib, and nothing changes for them.

But for clean, modular loading of common libraries, where versioning is clear and predictable, this hint can:

• Reduce bandwidth and load times
• Save CDN/server costs
• Improve sustainability through reuse

---

Sample Built-In Library List (Example Set)

Browsers could include a curated set of popular versions (under a 30MB cap, for instance), such as:

• jQuery 3.x.x
• Bootstrap 5.x.x (e.g., 5.3.2, 5.2, 5.1.1)
• Tailwind CSS 3.x.x
• FontAwesome 6.x
• Toastr 2.x
• Swiper 11.x
• React 18.x
• Vue 3.x

Again, this isn’t a mandate, just a performance affordance, entirely at the discretion of both browser vendors and developers.

---

In short:

• No guesswork
• No forced behavior
• No breakage
• Just a helpful declarative enhancement for those who want it

I understand the appeal of compression dictionary solutions as well ,and they’re certainly valuable, but I believe BWL could complement such efforts where explicit reuse and library identity are beneficial.

[0f-0b]

Imagine a future where BWL does exist: websites will start putting nonsense values in the src attribute because they know all browsers ship BWL, and browser vendors won't be able to remove or update BWL because it will break these websites. Fast forward 30 years, developers will no longer use BWL because all these libraries will be obsolete, and users will despise BWL because to them these are all just unnecessary bloat.

[TTMTT]

Imagine a future where BWL does exist: websites will start putting nonsense values in the src attribute because they know all browsers ship BWL, and browser vendors won't be able to remove or update BWL because it will break these websites. Fast forward 30 years, developers will no longer use BWL because all these libraries will be obsolete, and users will despise BWL because to them these are all just unnecessary bloat.

By that logic, we’d say "don’t build cars because one day they’ll fly, so a Lamborghini 2025 is pointless."
src is not nonsense, it’s a real fallback. If browser-lib isn’t supported, the browser just loads the URL.
And no, <img src> didn’t become useless when srcset came. Same principle here, let’s stay practical.

And of course, the list of built-in libraries can update with each browser update, keeping old versions for compatibility while adding newer ones, just like browsers already do with other internal features.

[pmeenan]

The problems are around the incentives to use versions that are baked into browsers and what needs to happen for it to be practical (and the constraints that places on sites, frameworks and the browsers).

History

We have looked at this several times over the last few decades of browser performance and the issue isn't the mechanism by which the libraries are referenced, it is a fundamental problem with bundling specific versions of specific libraries and the downstream implications of that.

There's also the thinking that if a feature is useful enough to ship the library with the browser then, maybe, the capabilities that that library offers should really be first-class browser features.

Example

Let's assume for a minute that there are enormous performance benefits to use JQuery from a local browser library...

Currently, the most-performant option for sites to use a framework or library is to include it in with their other common site code, preferably just including the parts they use. This is commonly done with bundlers like webpack but also frequently just with copy/paste.

To get the performance benefit of using the local library, the site needs to move JQuery to be an external reference (and load the whole file). For browsers that bundle the version of JQuery that they use, it gets MUCH faster but for browsers that don't, it gets slower.

The version of JQuery they target will likely be the one with broadest browser support in their target user base, not necessarily the latest or the one that best fits their needs (and there is a LONG tail of browser update adoption).

If there is a security update to JQuery, will sites deploy the update as soon as possible and take a huge performance hit or will they wait until the update has propagated to enough browsers and only then update?

For browsers, how many old versions do they need to ship with the browser? Is it an unbounded size over the years or do they age out anything past N previous versions? Users still have to pay the download and storage price, it has now just moved to the browser update and likely includes a lot of stuff they will never use.

For library maintainers, are they dissuaded from adding features, improving performance or making other frequent changes?

If an alternative to JQuery is created but not included in browsers since there isn't yet broad adoption, it won't get adopted because of the huge performance penalty sites would suffer by using it instead of the common library.

You multiply this out by all of the different libraries you'd want to consider including and it becomes an untenable problem to manage.

Dictionaries

This is where compression dictionaries come in.

We can ship a dictionary that includes a single version of JQuery in the dictionary that will be much more flexible:

• It will "load" the local version of the code no matter how the developer included the original by compressing JQuery out of bundled scripts, inline scripts or stand-alone files (transparently).
• The single version in the dictionary will continue to be effective against newer versions of the library (JQuery 3.7.1 compressed using 3.6.0 as a dictionary is 1/5 the size and that spans 2.5 years of releases).

It doesn't solve the issue of new frameworks being at a disadvantage but it solves all of the other problems we have had with previous attempts which is why it is the path we are experimenting with.

[TTMTT]

@pmeenan I understand your concerns, and I agree these are valid technical points. But I believe this is exactly why BWL (Built-in Web Libraries) is worth re-discussing, not dismissing.

You said that for browsers that don’t include the BWL version (e.g., jQuery 3.6.0), performance would degrade compared to bundling. But that’s exactly the beauty of this approach: it creates natural competition between browsers to improve native support for widely-used libraries.

Let’s imagine a real-world scenario:
I install Firefox, which does not support BWL. I visit GitHub, which uses:

• browser-lib="jquery@3.6.0"
• browser-lib="bootstrap@5.3.2"
• browser-lib="swiper@11.0"

Firefox loads 5MB of assets from CDNs, maybe even more in countries with slow or blocked CDNs. The site loads in 10–15 seconds.
Then I try the same on Chrome, which does support BWL and has those versions built-in. The page loads instantly, under 1 second.

Which browser do you think I’ll stick with?

This same principle drives innovation: once one vendor optimizes a use case, the others follow (just like what i described to user @0f-0b if one car company adds a new feature, the rest must follow, otherwise they lose market share).

Don’t forget that, in the past, java and even SWF wasn’t supported by all browsers. Yet developers didn’t worry that half the users might not be able to open their sites; instead, it was the users who cared and searched for browsers that supported those features or downloaded the compatible plugins themselves.

I know this is an old example, but it illustrates what could happen if a feature like BWL is introduced. We can’t predict the future, and if we try to overthink it, then nothing would ever be built today. After all, no one would produce cars now if we were too focused on how they’ll eventually need to fly.

---

About the security update scenario you mentioned:

"If there is a security update to JQuery, will sites deploy the update as soon as possible and take a huge performance hit or will they wait until the update has propagated to enough browsers and only then update?"

Well, why not?
A developer can just update to src="https://code.jquery.com/jquery-3.7.1.min.js" browser-lib="jquery@3.7.1" in the script tag, and it’ll still load from src for users whose browsers haven’t updated yet. No breakage. No forced downgrade. This isn’t different from how ad blockers update filters, not every site gets blocked instantly until the next ruleset.

---

About browser size concerns:
Most modern browsers already exceed 2GB of disk space with updates and components. Adding 30MB Or even 100MB worth of the most used libraries in compressed form, covering multiple versions (like Bootstrap 5.1.1, 5.2, 5.3.2), won’t be a real problem, especially when it improves page load across millions of websites.

---

About your question about library maintainers being discouraged from making improvements or frequent changes:
Rather than slow them down, BWL simply targets libraries that are already mature, widely adopted, and updated infrequently. Like jQuery, its latest version (3.7.1) was released in 2023, two years ago. So in practice, BWL wouldn’t interfere with rapid iteration, because it doesn't apply to rapidly changing libraries in the first place.

---

Finally, I understand this idea has been discussed before. But I’m not trying to revive a failed idea, I’m trying to reshape it with practical constraints, real-world use cases, and developer control. I also think compression dictionaries are great, and maybe both ideas can co-exist to solve different angles of the same performance problem.