The spatial view is noticeably slow to render

[colinbdclark]

When switching views in the iOS app, I've noticed that the spatial layout is visibly slower to load than the other pages. This is understandable since there's a decent amount of SVG rendering and spatial audio setup happening, but we should profile the page and see if there are opportunities to speed up the First Contentful Paint (FCP) times.

[Ulexus]

It seems unlikely that the SVG is the problem; it only has a few points and some text renders; for SVG, that is very lightweight, indeed.
I think the more likely culprit is the audio. We use that big and heavy spatial library.
Regardless, you are correct: we should profile it.
As for first-content times, that should be pretty easy. We can set up the basic SVG box empty, populating it as loaded; it would just require reworking how the SpatialRoom JS code works.

[colinbdclark]

I spent just a few minutes profiling the iOS version (on my older iPhone XR dev phone), and it looks we're taking around 580-ish ms to get to the point where our page is visible to the user with the SVG rendered. It looks like about 200 ms of that time is spent running JavaScript prior to rendering the page—mostly spent inside media play methods. As you say, rendering the SVG itself is pretty trivial, we're about 11 ms inside D3 methods during this period.

It feels like we could speed this up (eventually) by drawing the SVG, then enabling the audio—which I think is what you're suggesting?

In the meantime, I think we can live with a bit of lag for now and address once the iOS app is approved and TiMEs is in good shape.

[Ulexus]

Yes, exactly. There is hardly anything to load to render the page. It's 200ms of running the JS, exclusive of downloading it? That sounds crazy; either we have some async thing which is improperly waiting on something or that fancy spatial audio is really that slow (I could see either or both).