Typing/pinwheel lag, narrowed down to possible website running in background/cache?

There are a lot of typing lag complaints on here, but this one doesn’t respond to the usual recommended fixes.

My project consists of less than 6,000 words currently, and the scenes tend to run 1,000 words or less. I noticed the lagging behavior in a scene of around 1200 words. The project file is rather large because I’ve imported a lot of images and web pages into the research folder, but I do not have any of that content in the active editor while I’m getting the lag.

Noticed no problems for quite a while in this project, typing was smooth and responsive, no lag. Today it started lagging after every couple words, occasionally getting a momentary pinwheel (macOS catalina). Changing the autosave settings did nothing, and as I said, the actual scene I’m working with (no split screen or anything) was text-only.

After some expirementing, I found the culprit. I had referenced one of the imported web pages in my research folder. Once accessing this web page, then switching back to typing in the scene (again, not having the web page on my screen anmore, no split editor involved), thus started the lag. So somehow the imported web page is responsible, and is affecting the editor even when it’s not being accessed.

I am unfamiliar with what scrivener does in the background and how it handles imported web pages, and whether or not it refreshes them or runs scripts etc. I’m guessing this web page is loaded into some sort of cache or something, and continues to take up system resources even when it’s not being called upon in the editor. Perhaps it’s even running some sort of code, or periodically refreshing. I’m not sure why this would be designed that way, but it’s my best guess. Does anyone else have any more informed guesses about what’s going on here, and if there’s anything I can do to fix it, aside from abstaining to use the web pages i’ve loaded into the research section? (It might be a problem with one particular web page, too—I’ve used others in this project and haven’t noticed this lag until today). Something as simple as clearing some sort of cache? Is this something the programmers can address in future releases?

1 Like

I have an alternative approach you might wish to consider.
You could setup topical pages in Research with links to webpages and then drag the topical pages to Document Bookmarks, where an item on the page would typically relate to the subject at hand in a particular scene or scenes.
For example, I have a topic called Health and Medical, with links to a number of webpage articles. One of those articles would have something to do with what’s happening in my scene, like say: Pre-Hospital Care in Burn Injury, since one of my characters is caught in an explosion.
I then click on the link in the Documents Bookmark preview pane and the webpage opens. The link’s effect on my Scrivener project is 1 kilobyte or something similarly ridiculously small.
The setup looks something like this (the brown text is links):

1 Like

You might try loading the web page into a browser and seeing how it behaves there. Probably the underlying cause is a script on this particular page that is being overly aggressive about trying to contact the originating server.

Scrivener is best seen as a “web viewer,” rather than a full-featured browser, and as such it doesn’t have the full complement of pop-up blockers and such that a browser would. To deal with a “rogue” page like this, the best options are (a) use a link as @Kevitec57 suggested, and open the page in a browser or (b) capture just the visible contents of the page as a PDF or RTF file.


It’s still a bug. Viewing it in a web browser instead or having a list of links are workarounds but that doesn’t change the fact that a webpage opened previously shouldn’t be running scripts in the background and affecting my active editor

If you have a bit of Scrivener that wants to hog resources (the web page doing what the web page developer intended) in what Scrivener admits is not a real/fully-functional web browser, why would that be a “bug” by Scrivener? Just disconnect that web page from its server or remove any of the HTML in that web page you hold that causes it to hog the system.

I am pretty certain that Scrivener’s mini-web browser cannot do everything. It needs help from humans.


I’m not asking it to do more. I’m in fact asking it to do less. Specifically, to STOP working when I don’t have it active. It shouldn’t be active when it’s not even visible. I don’t see why that’s such a controversial opinion. It’s not on my screen, it shouldn’t be running. That is the expected behavior, and it’s not behaving as expected, which means it’s a bug

Bug or not, the two suggestions I offered are available now and do not require changes to Scrivener’s code.

The specific bug, if you want to call it that, is that Scrivener is failing to kill a process created by the web page when the page is pushed into the background. But it’s still the web page hogging your system resources.

1 Like

Yes. This is the bug I found and wish to report. The workarounds already suggested I knew how to do. I was merely interested in reporting a bug for the improvement of scrivener releases. Sorry that I wasn’t more clear on my purposes here.