Would a faster laptop fix this?

No. The gap is about two orders of magnitude and a faster CPU is worth a factor of three at the very best. A four-day job becomes a day-and-a-bit job, which is not a different answer.

Would splitting the folder into ten queues fix it?

No, and it is worth being explicit about why: the work is sequential on one thread in every one of those queues, so ten queues of forty files take the same total time as one queue of four hundred, plus ten model loads. Parallelism is the thing that is unavailable here.

So what is the honest advice?

For a folder of twelve-megapixel photographs at 4×, a desktop application with a graphics card behind it. This page says so rather than starting the job. For a folder of small originals, this queue, which is the case it was built for and the case a browser can genuinely finish.

Why four hundred large files will not finish

This is the arithmetic behind the refusal, written out in full, because a limit that is asserted is an excuse and a limit that is calculated is a fact.

One photograph, counted

Take a 4,000 × 3,000 photograph — twelve megapixels, which is what a phone from five years ago produces and what a modern one produces on its default setting.

Step one: the stride

Real-ESRGAN is handed a 128-pixel square at a time, with 8 pixels of context carried on every side so the convolutions near a tile boundary see real neighbouring pixels rather than the edge of a buffer. The part of each tile that is actually kept is therefore 128 − 16 = 112 pixels square. That is the stride.

Step two: the count

Across: ceil(4000 ÷ 112) = 36. Down: ceil(3000 ÷ 112) = 27. Multiply: 972 passes for one photograph.

Step three: the clock

One pass of that network measures 1,200 milliseconds on single-threaded WebAssembly. 972 × 1.2 is 1,166 seconds: nineteen and a half minutes, for one file.

Step four: the folder

Four hundred of them is 466,560 seconds. That is 129 hours 36 minutes — five and a half days of a tab that must stay open, on a laptop that must stay awake, on a battery that will not.

Where the wall actually is

Real-ESRGAN, four hundred files, by source size
Source	Passes a file	Seconds a file	Four hundred files
400 × 400	16	19	2 h 8 min
600 × 600	36	43	4 h 48 min
1,000 × 1,000	81	97	10 h 48 min
2,000 × 1,500	252	302	33 h 36 min
4,000 × 3,000	972	1,166	129 h 36 min

The published envelope draws its Real-ESRGAN line at 600 pixels and fifty files for exactly this reason, and that is already a warned band rather than a comfortable one. Everything below the second row of that table is a job somebody would abandon.

What a graphics card changes

Everything, and it is worth being specific rather than gesturing at it. The passes above are dense convolutions over small tensors, which is the workload a GPU exists for: a mid-range consumer card runs the same network somewhere between fifty and two hundred times faster than one WebAssembly thread, and it does several tiles at once. The five-and-a-half-day job becomes an hour or two.

None of that is available here. WebGPU would close part of the gap, and it is not on this path deliberately: the multi-threaded and GPU backends need cross-origin isolation, which breaks the advertising this network is funded by. So the single-threaded WebAssembly figure is not a pessimistic case, it is the case, and every number this site publishes is that one.

There is no GPU in this path and no second thread, and no setting anywhere on this domain turns either on.
The refusal is set at four hours for a queue and five minutes for a file. Those are policy lines rather than limits of the machine, and they are set so a refused job is obviously refused rather than marginally so.
A refused file is not dropped. It goes through Lanczos3, finishes in well under half a second, and appears in the archive with everything else.

Questions this raises

Would a faster laptop fix this?: No. The gap is about two orders of magnitude and a faster CPU is worth a factor of three at the very best. A four-day job becomes a day-and-a-bit job, which is not a different answer.
Would splitting the folder into ten queues fix it?: No, and it is worth being explicit about why: the work is sequential on one thread in every one of those queues, so ten queues of forty files take the same total time as one queue of four hundred, plus ten model loads. Parallelism is the thing that is unavailable here.
So what is the honest advice?: For a folder of twelve-megapixel photographs at 4×, a desktop application with a graphics card behind it. This page says so rather than starting the job. For a folder of small originals, this queue, which is the case it was built for and the case a browser can genuinely finish.