I often visit https://yjs.dev looking for a link to this discourse page; however, I notice that at least on Firefox, the page loads visually but it takes 2-3 seconds before I can click on the “Discuss” link. I assume this is because Yjs and its accompanying libraries (prosemirror, etc.) are doing a lot of background work.
My first question is, am I seeing a delay in Yjs startup time itself? (I don’t think this is the case, but I know earlier on, there was such an issue).
And second, if not, is there a best practice around “backgrounding” load times like this? Perhaps a worker thread? (I’m not very familiar with what this can do, but seems to help in similar situations).
I’m not seeing that long stall but looking at Chrome “Performance” profile shows that during the loading the page method called “t” is called in https://discuss.yjs.dev/assets/ember_jquery-06c652c311e41b5c974c6ba126148aab973123d5e0bc526f5065b740f3f8439f.js by some timer that causes javascript engine to run for 909 ms on my machine in the event handler. This machine has low latency Linux kernel and all CPU cores forced to 3.6 GHz all the time to reduce latency so lesser systems may see longer latency. During this 909 ms Chrome will no update the page so it probably is the cause for the stall you’re seeing. I have no idea what this method is supposed to do because at least Chrome is unable to unwrap that method from the minimized source.
I expect that the page loads slowly because some users pasted a lot of content into the website. ProseMirror and Yjs need to load this content into memory. The page can be easily slowed down by pasting a lot of content.
Now I don experience this problem because I haven’t loaded the large document from other peers. You could try deleting your document content. If the document state with the huge amount of content is versioned (you clicked the version button) then you need to clear the indexeddb storage (Open Development tools ⇒ Application ⇒ Tab Application ⇒ Clear Storage ⇒ Clear site data)
Does the site load fast when you close all browsers a browser instance in incognito mode (make sure that all other browsers visiting yjs.dev are closed)?
@mtrantalainen I think you are talking about a different problem on discuss.yjs.dev. The function you mentioned renders the dynamic DOM (content from the database, list of threads, depending …) and it really might take some time. On my computer it takes about 350ms (on rather low-spec computer).
I checked in a Firefox private mode browser and it took the same amount of time (about 5 seconds to load the UI, and about 3 seconds before responsive UI).
However, next, I went to record it, but the site loaded nearly instantaneously! It looks like the server history may have been cleared in between?
Okay, that’s good. Seems like somebody deleted the content that took up the space. Maybe it even was a huge image embedded into the prosemirror / quill editor.
When the content is deleted, the Yjs optimizations will reduce the size of the document. It will only preserve history of content that is relevant for version snapshots.
Maybe a client with a huge document history joined the editing session and now that client always syncs its huge document to all peers when they ask for content. Since yjs.dev is a peer-to-peer application using webrtc and there are literally no restrictions on who can join the network, it is to be expected that the site will sometimes blow up. There will naturally be some people who want to test how much content Yjs can handle. That’s fine, I use this website for performance testing as well. The document content has beet online for almost a year now and it is still running rather smoothly as long as somebody deletes the created content at some point.