Many queued files can make Zeronet stop responding?

### Step 1: Please describe your environment

* ZeroNet version: 4176
* Operating system: W10
* Web browser: FF
* Special configuration: Multiuser

### Step 2: Describe the problem:
"I made the mistake of trying to seed all small and big files on a board that apparently is mostly 0 peers. I've been stuck "updating 14000 files" for a week now and it's very unresponsive. How do I cancel trying to sync all those files?" source: [millchan](http://127.0.0.1:43110/1ADQAHsqsie5PBeQhQgjcKmUu3qdPFg6aA/?:users/12NPW6WLFBLVivNGqijcfktARobftfLFAN:dev:b79fce8b-df0d-4ab4-a89e-4c37585aa6d1#post-7f55628f-57e2-48e1-8c33-ce02eed14878)

And some time ago, i have had similar feeling, that too many (1000+) files queued and being actively downloaded (or at least attempted), maybe simultaneously on multiple zites, maybe makes zeronet do not respond other request (to load a webpage). Can this be true? If so, can you improve this so it does not influence site loading and its operations?

PS: maybe the cause of the lag/unresponding is not queued files, but the way images are loaded on the site i linked above. Because zeronet stop loading sites and when i browse opened tabs, i sometimes see that on above linked web zite is the page where many images did not loaded (instead of a image thumbnail, there is a wheel indicating image loading) and when i close that tab, zeronet start responding... i always had impression it has to do with some zite function that is made wrongly to hang. Or the function should have some timeout or something.

If the problem is the browser limit, i have following in the Firefox "about:config" page:
network.http.max-persistent-connections-per-proxy - 32
network.http.max-persistent-connections-per-server - 6
network.http.max-urgent-start-excessive-connections-per-host - 3
so i have added 0 at the end of each value in hope to remove this lag
dom.workers.maxPerDomain - 512

No source files or tests are named. Start by reproducing the slowdown with roughly 14,000 queued files and the image-heavy zite described, then compare responsiveness while the queue and image requests are active. Done means establishing whether queued downloads, image loading, or browser connection limits cause the blocking behavior and documenting a concrete cancellation, timeout, or scheduling requirement.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.