• Focus on simplifying and removing code, at the cost of not handling edge cases.
• We didn't use any external libraries other than gl-matrix. We were able to make size optimizations everywhere throughout our codebase.
  • Rather than npm install gl-matrix, we copied parts of it to our repository and rewrote to TypeScript. This allowed us to make small adjustments which benefited the final code size.

$ make
Compiling project... Done
Bundling files into one... Done
Running replacements... Done
Stripping newlines... Done
Minifying...
- parse: 0.105s
- rename: 0.000s
- compress: 1.058s
- scope: 0.026s
- mangle: 0.071s
- properties: 0.082s
- output: 0.035s
- total: 1.378s
Size gzipped (including HTML): 13881 bytes

• The differences between compression formats and methods can be significant.
• A few bytes saved with gzip might have a completely different effect on the final release build compressed with 7z.
• For future reference, here's the CLI command calling 7z to create a best-quality Zip archive using the DEFLATE compression method:

  7z a opt.zip -mx=9 -mfb=256 -mpass=15 \
      public/opt/index.html \
      public/opt/game.terser.js \
      public/opt/models.tfu

• On Ubuntu, install 7z with apt install p7zip-full.

• We forgot to remove a similar GL_LINK_STATUS. It would have saved us 52 bytes!

• drawArrays(gl.POINTS, ..)
• drawElements(gl.TRIANGLES, ..)

for (let name in this.GL) {
    // @ts-ignore
    if (typeof this.GL[name] == "function") {
        // @ts-ignore
        this.GL[name.match(/^..|[A-Z]|([1-9].*)/g).join("")] = this.GL[name];
    } 
}

Then, we use sed to rename these methods accordingly at the callsites. Here's an excerpt from the list of replacements that we run:

s/createVertexArray/crVA/g
s/bindVertexArray/biVA/g
s/createBuffer()/crB()/
s/bindBuffer/biB/g
s/bufferData/buD/g
s/enableVertexAttribArray/enVAA/g
s/vertexAttribPointer/veAP/g
s/vertexAttribDivisor/veAD/

let vertex = `#version 300 es\n
    // Matrices: PV, world, self
    uniform mat4 p,q,r;
    // ...
`;

passes=3
ecma=9
booleans_as_integers
drop_console
pure_getters
toplevel
unsafe
unsafe_math
hoist_funs

• It makes Terser minify property names, like Game.ViewportWidth, consistently across the entire codebase.
• When using it, you have to be careful to not minify too much. For instance, you don't want to minify window.innerWidth or document.querySelector.
• There are a number of ways to only minify some property names.
  • You can pass a list of reserved names to Terser, e.g. ["innerWidth", "querySelector", ..], but that's hard to maintain and wouldn't scale well in Backcountry.
  • Or you can decide to keep quoted names: window["innerWidth"], but that's a bit tedious and more typing.
  • Or you can only mangle property names matching a regex.
• We chose the regex approach: --mangle-props regex=/^[A-Z]/, which is why you'll see a lot of UpperCamelCase names (aka PascalCase) in our code. It's not a common practice to write JavaScript this way, but it turned out to be a really effective way of differentiating between our custom properties and properties defined by various web APIs.
  • We could have used a prefix or a postfix, e.g. _ or $, but we thought it would add visual clutter to the code. It would need to be used for all fields of all interfaces in all components.
• In our codebase, --mangle-props saves around 700 bytes!

• There's a cost for each individual file added to the Zip archive, so it's best to keep everything in a single file.
• That said, we left models.tfu as a separate file because our testing revealed that it was the optimal choice. We tried base64-encoding it and inlining into HTML, but the end result was a bigger Zip archive.

• In TypeScript, we typed the arrays holding component data like so:

  class Game implements ComponentData {
      public World: Array<number>;
      public [Get.Transform]: Array<Transform> = [];
      public [Get.Render]: Array<Render> = [];
      // ...
  }

• Thanks to this approach, every time we access component data through game[Get.Transform][entity], the retrieved element is properly typed.
• The JavaScript produced by the compiler, however, is rather verbose:

  var _a, _b, // 21 more declarations
  class Game {
      constructor() {
          this.World = [];
          this[_a] = [];
          this[_b] = [];
          // 21 more arrays initialized, one for each component storing data.
      }
  }
  
  _a = 1 /* Transform */, _b = 2 /* Render */, // 21 more assignments

• Before minification happens, we hand-edit the compiled JavaScript and replace the code above with the following, which saves us 44 bytes.

  class Game {
      constructor() {
          // ...
          for (let i = 0; i < 23; i++) {
              this[i] = [];
          }
      }
  }

(…) zipping algorithms are not interested in the input size. They care about input entropy.

— Mateusz Tomczyk

• The first function is bright, but every other occurrence throughout the codebase is practically free. The same is true for the return keyword.

• Here's what the original code looks like, using sys_transform as an example. Because we use this pattern consistently across all systems, it compresses very well.

  export function sys_transform(game: Game, delta: number) {
      for (let i = 0; i < game.World.length; i++) {
          if ((game.World[i] & QUERY) == QUERY) {
              update(game, i);
          }
      }
  }

• We use DEFLATE rather than gzip in the final build, so the actual compression details are different. The heatmap still gives a good idea of what goes into the archive.
• We used the web-based version available at https://github.com/simonw/gzthermal-web.
  • gzthermal.now.sh appears to be permanently down, but it's fairly easy to set up the server locally with Docker.
• A full heatmap of a pre-release version of Backcountry is available at heatmap.png (1.87 MB).

• If you continue working on the game and add some other code later on, there's a chance that early size optimizations actually hurt the final build size. Measuring the impact of an early change on the final size may be an impossible task.
• It's crucial to only start heavy optimizations when the game is complete.

• It takes ca. 4:30 minutes on an 8th-gen i7.

• Mission accomplished :)

• Brotli is well-supported by browsers and servers, and is MIT-licensed, which makes it a good successor both for the web traffic and the competition.
• Similar to gzip, Brotli can only compress individual files. For the purpose of the experiment we tar-ed our two files into a single archive.

• One old benchmark shows that JS can be orders of magnitude faster than the native DOMMatrix. Tested on an i7-8750H 2.20 GHz:
  • In Chrome, multiplySelf is 700x faster in JavaScript than when using the native DOMMatrix method!
  • In Firefox, multiplySelf is 250x faster in JavaScript than when using the native DOMMatrix method.
  • Other DOMMatrix methods perform better, with the JavaScript counterparts being "only" 5-10x faster.
• However, a comment in blink-dev argued that the benchmark was not realistic because it only transformed matrices without ever using them.
• Another benchmark was proposed in which DOMMatrix performs better than JS.
  • Looking at its code today, the DOMMatrix test case does less then the JS equivalents. When the test is modified to account for this, DOMMatrix performs 18x slower than the Float32Array snippet.
  • The JS test cases could benefit from some optimization to avoid unnecessary allocation of interim arrays.

• This seems to be the reason why both the now-deprecated WebVR API and the current WebXR specification use Float32Arrays to represent matrices.
• In Backcountry, we experimented with caching Float32Arrays produced by toFloat32Array(). It improved the situation a little bit but it still wasn’t enough.

• For instance, to invert the World transformation matrix and store the result in the Self matrix, you call invert(transform.Self, transform.World).