Unfortunately, it looks like the native drawImage method, which I much-praised last time, also acts as a bottleneck to the whole application. I'll surely need to cut the resolution to a fraction of the window size, probably to a fixed one. On the bright side, that's not a big deal, given how young the project is.
Speaking of bright sides, I've finally got to the point where I move the camera instead of the grid. Borrowing some code from my past self sped that up a lot.
Next up: lower resolution; pause/play states.

After careful analysis, I concluded that my old approach to canvas drawing is not outdated at all. Outputting the view to a sub-context first is the way to go. Back in the days, I thought it was a super-duper way of upscaling the game, but it turns out that this cheap trick performs equally well with downscaling matters too. Not only that, but it's also crazy fast to set up and at executing, all thanks to the drawImage method of the CanvasRenderingContext2D, which also accepts an HTMLCanvasElement as the image source.
However, once the sub-canvas gets five times the size of the screen, things start to get laggy. Apparently, 500MB worth of image data is too much for a realtime simulation. I'll someday optimize it.
In the end, I haven't met last time's goal yet, but I'll put it off for today. I guess a good night sleep is more important 😉