Performance with many portals

[wonderwhy-er]

One issues I encountered before with iframes for which good workaround does not exist is when same embed SPA is embedded with slightly different params. Example would be something like multiple charts in iframes. They use same resources, yet especially on first visit they end up loading multiple times in parallel. It is even worse for JavaScript which is not only downloaded multiple times but is evaluated multiple times.

Partially this can be mitigated with some 'hacks' of ServiceWorker that claims clients on first visit and starts to at least share network request between iframes for same resources.
But each iframe gonna do their own js evaluation which can take hundreds of milliseconds for complex SPA, and then for 10 iframes it is 1s of javascript evaluation.

Could it be possible to show same page(truly same) with different offsets in multiple portals for such a case? Aka multiple portals to different parts of the one instance of the page?

[matthewp]

I would expect similar performance to having many iframes. I don't think it should be a goal of portals to solve this problem. You can likely solve this yourself by using IntersectionObserver to lazily load the portals.

[jeremyroman]

Could it be possible to show same page(truly same) with different offsets in multiple portals for such a case? Aka multiple portals to different parts of the one instance of the page?

That's an interesting suggestion. It'd have significant implications, though. For instance, how should IntersectionObserver report this? Once input is supported, how should that work? Can focus work reasonably in such a case? There are possible resolutions (e.g. allowing a document to create other frames/documents that are same-origin to and scriptable by it, and allowing it to spawn off auxiliary portals in a similar way to auxiliary windows), but they seem far from simple.

Because of this complexity (and, as you point out, this is possible today albeit at a resource cost), I think it's unlikely to be part of an initial version of portals.

[wonderwhy-er]

Could it be possible to show same page(truly same) with different offsets in multiple portals for such a case? Aka multiple portals to different parts of the one instance of the page?

That's an interesting suggestion. It'd have significant implications, though. For instance, how should IntersectionObserver report this? Once input is supported, how should that work? Can focus work reasonably in such a case? There are possible resolutions (e.g. allowing a document to create other frames/documents that are same-origin to and scriptable by it, and allowing it to spawn off auxiliary portals in a similar way to auxiliary windows), but they seem far from simple.

Because of this complexity (and, as you point out, this is possible today albeit at a resource cost), I think it's unlikely to be part of an initial version of portals.

Thank you jeremyroman. Issues you mention with this indeed sound too complex.
Thinking about them I actually may be though of a solution with iframes that could work. You could create a transparent whole page iframe for embed page, create divs in places of multiple iframes with correct sizes and then render content meant for those iframes in that big background iframe at correct offsets.
Probably will not work in many situations due to z-index overlap types of problems but would be close.

[jeremyroman]

That issue, and the natural desire to want to apply additional style (e.g. transforms) to particular pieces of it is another potential issue. In any case, something to think about when/if the less ambitious stuff succeeds.

[Malvoz]

#125 (comment)

I would expect similar performance to having many iframes. I don't think it should be a goal of portals to solve this problem. You can likely solve this yourself by using IntersectionObserver to lazily load the portals.

Iframes have the loading attribute to enable lazy-loading, it seems sensible for the <portal> spec to add it as well IMO. Has this been discussed?

[domenic]

I'll close this for now, since it seems pretty speculative and there are probably simpler ways of achieving the desired behavior. At the same time I'll open a new issue to track adding the loading="" attribute.