`share` attribute on <link> and <script> tags

HTML
1

What if browsers shared resources across same origin tabs using a share attribute on <link> and <script> tags which will take a regex pattern so that if other tabs with the same origin and paths’s match the regex pattern of the share attribute they don’t have to request that resource again.

It’ll work like the following:

<link rel="stylesheet" src="https://example.com/style.css" share="/*">

Now when I open another tab with the same origin let’s say the link being: https://example.com/it/could/be/whatever, mind you I already have https://example.com open

and that tab is requesting that same css file above the browser has already loaded it, and therefore doesn’t have to request it again.

the share pattern allows https://example.com/it/could/be/whatever to use that css file because it’s /* allowing any path that needs to request it, but this only works for same origin tabs.

Also the new fetch api could allow:

fetch('style.css', {share: true});

Isn’t that what caching is for??

No the share attribute is only storing it in the browser until each tab of that origin is closed and then it’s gone.

The easiest use would be, sites that stay the same could easily add the share attribute, and not have to setup a cache or use ServiceWorkers.

Therefore I could easily just add a share="/*" to my links and scripts.

This will allow me to open multiple tabs of the same origin and have them load much quicker.

Now if I were to update my resource, the new one would load when the first tab with that origin opens again.

I feel like I repeated myself a couple times. So I’ll stop here, what do you guys think??

But one more thing, it could just be a Boolean now whenever the browser request that same file it just uses it. But the regex path would prevent some paths from accessing it, not sure if that’s necessary?? but that was my initial thought.

2

This functionality already exists: just use appropriate caching headers on the resource. Then it doesn’t even have to be same-origin - anything can request that file and get the cached response instead of making a new request.

3

Sorry I replied by email, and didn’t show up here. So here’s what I said:

No because when all tabs from that origin are closed, and that origin is opened again a new request is made meaning they were gone when all tabs were closed. Why would we want that, because its super simple to use without any JS and using a simple HTML attribute. It could also keep the resource when connection is offline and then when one new tab from that origin is opened use it, and when back online automatically request a new one, all with an HTML attribute. Now that part would be like caching.

Point is sharing across tabs because with caching and service workers is having to run that service worker logic for each tab when it could run less with just an HTML attribute. Again many already made sites could easily add this to their files without needing to think about the logic of when to request a new one or so what.

4

No, appropriate caching headers on the resource will keep it alive in the cache for as long as you want (or until it’s evicted, which can happen at any time).

This has nothing to do with Service Workers. Caching headers have been around forever and require no extra code to use. It’s typically just a line in your server config to add caching headers to all resources of a given type.

5

HTML Imports also have deduping abilities which are apparently different from regular caching, if that’s what you’re after

6

I was discussing this with a friend already, and came to this conclusion:

My thought was to have this share in memory, because compare to caching it’ll write it to the drive, then when I open another tab it’ll read from disk first and then use it. This would read from memory and not store at all. But that’s pointless because the amount of time it’ll do that is kind of immeasurable how much it’ll improve the speed. Now I agree browsers should probably already do that if there not, read from memory of resources loaded in other tabs first, but perhaps they already are. And not having it store was for update reasons but that’s dumb as well because you could just have it store for an hour. So yea now the only thing we thought of was a cache=false so that you could force the browser not to automatically cache that, but the browser should decide that not the dev. So yea this is pretty useless now that I think about.

Only thing I can say is again, if browsers aren’t already doing that, they should share resources from other tabs so it doesn’t have to read from cache but just having to check the shared resources is not even worth the time it will save, because it’ll most likely just take longer having to check, then reading from cache.

7

So I should probably open this up, in another discussion if this is a good idea, but before I do that, I’d like some interesting quick feedback first:

What if browsers didn’t have to reparse every element in the html received by the server. What if they already have some prehtml parsed.

So if I have the following:

<nav share>
  <ul share>
    <li share>Nav 1</li>
    <li share>Nav 2</li>
  </ul>
</nav>

When a new tab of the same origin is made the markup above is used, and when the html parser sees the same markup of the new fetched html, it’ll simply skip over it and use the same elements.

Now the problem with this is, there may be pages of the same origin which don’t need that same markup, so we could have a <meta> tag that defines the path, to which to share the same html.

We can access this via API as well Element#share is a boolean

8

Leaving aside questions of realms and implementations and so on for a moment…

Parsing elements isn’t really that expensive and it’s a one-shot deal, once it’s done, it’s done. Storing a few copies of elements in memory on those rare occasions where you have N pages that would share open also isn’t likely to have noticeable impacts. Regardless though, it seems to me that in your proposal, the work implications actually go up because you open so many new questions - the DOM (and scripts in general re: your OP) have state and scope. In your proposed model, actions in one tab would affect other tabs as well? So now I click something in one document and it has to recalculate not just in its own tab, but in others? You’d not be able to predict the initial state either. Or, depending on how you were imagining this - maybe browsers would have to save the equivalent of a template which it would clone instead - or you’d have to invent immutable DOM. I honestly can’t imagine any of these happening though as they’d be pretty complicated, introduce potentially complex new problems and there are already many many ways to share all but the instance itself.

Interesting though. Have you looked at all at SRI? I think you might be interested in that, especially post v1 discussions.

1 Like
9

actions in one tab would affect other tabs as well

No

So now I click something in one document and it has to recalculate not just in its own tab, but in others

No

You’d not be able to predict the initial state either

What do you mean?

Or, depending on how you were imagining this - maybe browsers would have to save the equivalent of a template which it would clone instead

Sort of

or you’d have to invent immutable DOM

No

When duplicated to a different tab it’ll just use the last state, it won’t affect other tabs, therefore if I have a <nav> already implemented with event listeners etc, that will be duplicated into the new tab, but if I were to remove it from one tab it won’t remove it from others. (This saves adding complex event listeners over and over)

Point is I can see sites that are really slow that have enormous amount of nodes in their sites, reuse elements, now the big part would be if we could somehow let the server know what markup we already have, but I think that would have to do with a server configuration so I’m assuming NO

Also like when I first mentioned, if used on <link rel="stylesheet"> and <script> tags, they won’t have to be reparsed and executed, when getting the resources from the network or the cache (which involves reading from harddrive) which can be slow on old devices. Not sure if you read about the performance of JavaScript on Android

10

I researched this topic, because it definitely sounds like a good idea. Browsers thought so too, and largely already implemented this, or are planning to.

  • The HTTP cache is first stored in RAM, so shared resources don’t even get read from disk.

  • JavaScript engines cache their compiled results, even across domains and URLs.

  • Similarly, CSS is decoded once for a given URL, and only discarded when system resources are better served elsewhere.

  • HTML chunks don’t have an easy solution like you propose (outside of like, <iframe>s, but those have baggage), but between <template> and the upcoming HTML Imports, any truly expensive DOM-parsing can be done once and then never again if you need the boost.

As for sharing HTML across tabs, that would decrease performance—modern browsers run tabs in different processes (even Firefox in a few versions), and cross-process communication to share parsed HTML would have more overhead than any gains.

11

I’m still not entirely clear on what you are suggesting, but @Tigt is also pointing you down the same path I was trying to arrive at - browsers are already working on sharing cache/parse opportunities where possible - but there are things that make that the right level to handle it - things like SRI can help them do that better (potentially). You are talking about things at a higher level and all of my questions were geared toward trying to figure out precisely how that would work.

If, as it seems in your example, you’re talking about sharing about sharing the actual parsed script with state and all - that would, as @Tigt explained be probably slower and possibly a security issue too (you can host JS anywhere) because it would involve shared state. Imagine I have page x.html and it loads some script and it has handles to the window and a bunch of dom instances and so on - now I open another page that includes that script, it might not even be the same page - or even if it is, the pointers would now somehow have to be multi-pointed, scopes in closure would… I’m not really sure and that’s what I was trying to get more information on. I think honestly its very very likely moot, but I’m still curious to hear what you’re thinking even if you want to send more details privately.

12

@Tigt thanks, that’s awesome, and @briankardell, thanks for the feedback, feel free to close this discussion, I’m not sure if I’m able to, I believe you were the one who closed one of my others ones, so I believe you have the power to?

13