Why the app can feel slow, and how it's addressed

IMS is a build-free web app (a deliberate choice: all code is open and
readable, nothing hidden behind a compiled bundle). Because of this, a
screen loads not one file but dozens of separate ones — and there are a
few typical reasons this can feel slow. Below is what's already been
fixed, and what you can check yourself if it slows down again.

Already fixed in this release

1. 127.0.0.1 instead of localhost. On some Windows machines the
   word localhost first tries to connect over IPv6, gets no response for
   about 2 seconds, and only then tries the regular address — and this
   happens on EVERY new connection, of which a single screen can make
   dozens. We measured this directly (see "How to check" below) — actual
   server work responds in 40-130 milliseconds, while the connection wait
   was eating up to 4 seconds. That's why all our scripts and the browser
   address use http://127.0.0.1:8010, not localhost.

2. Browser cache for UI files. Previously the browser re-downloaded
   every interface file on each visit. Now the server tells the browser
   "this file can be cached", so on a repeat visit anything unchanged is
   read from disk, not over the network.

3. "Busy" cursor while waiting for a server response. Previously,
   clicking a button gave no sign the app was already working — which
   tempted users to click again while it was still processing. Now the
   cursor turns into a "wait" icon for the duration of the request.

4. Don't store the app inside OneDrive/Google Drive/Dropbox. Folders
   that sync in real time noticeably slow down file access — and this app
   has a lot of files. Keep IMSD on a plain local disk.

If it slows down again — how to check what's wrong

The most reliable approach is not to guess but to see where the time is
actually going:

1. Open the app in the browser, press F12 (opens developer tools).
2. Go to the Network tab.
3. Check Preserve log, if available.
4. Repeat the action that feels slow (open a screen, click a button).
5. Right-click the request list → Save all as HAR — this saves a
   .har file.

That file can be handed off for analysis — it shows exactly how much time
went into connecting, how much into the server response, how much into
downloading the file. That's how cause #1 above was found — without such
a file it would have been just a guess.

What we deliberately don't do (and why)

• We don't bundle JS into a single file (so-called "bundling"). This
  would speed up loading, but the code would stop being directly readable
  file-by-file — the whole project is built on the principle "what you
  see is what runs", with no build step. We consider this more important
  than the initial-load speed gain (especially since the browser cache
  already solves this on repeat visits).
• We're not moving to Electron/Tauri (packaging as a separate desktop
  app). This would give speed on par with the old Delphi version (the
  code sits on disk once, only data travels over the network/locally) —
  but that's a separate, larger effort, not a point fix. It's under
  consideration as a possible future direction.
• We don't tune the app for weak/old computers. The browser has to
  parse the interface code on every first visit (afterward it's served
  from cache) — on an old CPU this is noticeably slower, and that's a
  limitation of that specific computer, not of the app's settings.
  Requirements — see RUN_ME.md, "Computer requirements" section. If a
  computer doesn't meet them, the sensible path is to replace the
  computer, not to endlessly optimize the app for old hardware.