document reasons for increased network load in README

README.md

@@ -15,19 +15,24 @@ following principles will guide its development.
    score keeping tool. Logical expansions, like synching a session between users / devices, will
    not be implemented, because they would be too complicated for the time I intend to spend on
    maintenance.
+
 2. **Simple and stable dependencies:** I have learned in past projects that fast moving
    environments, like many modern JS frameworks, are very tedious to keep up with. Therefore all
    libraries must be stable and consistent. Also, I don't want to spend much time wrangling npm.
    Therefore all dependencies must be vendorable as a couple of files.
+
 3. **Browser based development:** I don't want to spend a lot of time on build tools, transpilers,
    and similar things. All code has to be able to run in the browser in the form it is written. All
    dev tools (like the testing framework) have to be able to run in the browser.
+
 4. **Targetting Baseline:** The limited time for maintenance means I won't be able to do testing
    for all browser/version/os tripples. Instead, I'll target "baseline widely available" and rely
    on it's correctness for portability. I'll also use features that are "baseline newly available",
    but only with feature checking, which I'll only do for them.
+
 5. **Extensive tests:** I don't want to spend a lot of time on bug hunting, therefore everything
    that can be tested automatically should be.
+
 6. **Good documentation:** I'll most certainly forget how some things work at some point. Thus it
    is paramount to keep a good documentation, so I won't have to read through everything again.
 
@@ -38,8 +43,19 @@ have a cost. While I have deemed it to be worthwhile in this case, I consider it
 least document the disadvantages.
 
 1. No access to a lot of JavaScripts modern ecosystem.
+
 2. No access to compile time features such as actual typechecking.
+
 3. More network load that strictly necessary.
+
+   Build tools can provide minification, bundling and tree shaking. All of these are not available
+   to this project, but likely would decrease the total amount of data needed to be transfered.
+   However, likely it wouldn't actually be all that much, because it's a rather small application,
+   and it does its own caching with the service worker.
+
+   Also, most of the icons font could propably be cut away with some build tool. While I could do
+   that manually, it'd be too much hassle if I ever needed an additional icon.
+
 4. Less performance than what would be possible.
 
 ### Violations
@@ -50,10 +66,12 @@ following:
 1. The `jsconfig.json` file is a build tool configuration file. It shouldn't be needed, as the
    project doesn't use any build tools. However, it allows the LSP to be more usefull, thus
    justifying its existence.
+
 2. Nested CSS. It is so much more managable than repeating the same selectors over and over. Keep
    in mind that the principles are to make the maintenence of this side project viable for me in
    the long term. In ~4 months from this writing (2026-03-04) they become baseline widely available
    and I would want to rewrite all the styles then. I deem this to be a worthwhile trade-off.
+
 3. The `:has()` CSS pseudo-class. While it's not as useful, it becomes baseline widely available at
    the same time as nested CSS. Might as well use it then, as a non-supporting browser can't be
    used either way.