A quick overview of the WebGL renderer is this: (maybe this deserves a separate blog post)
1. As far as memory usage goes, the layout-by-layout loading means that on start of layout all textures that are used by the layout are loaded (and any others released). All frames of all animations of any objects initially placed on the layout are loaded. This means for the purposes of rendering a layout, loading/unloading textures can be ignored.
2. The WebGL renderer is a batched back-to-front renderer. This means it draws the bottom thing on the bottom layer and then moves to the front, drawing things over what's already been rendered.
3. The "batch primitives" include things like "set texture" and "draw N quads". C2 batches draw calls to eliminate redundant work. For example if the engine tries to set the same texture 3 times in a row, it only adds one "set texture" batch job.
4. If there are 10 of the same sprite showing the same texture, and they are all drawn in a row (so they must be consecutive in Z order), the batch can be just two items: "set texture" then "draw 10 quads".
5. If there are 10 of alternating sprite types with different textures, they cannot be batched with a single "draw 10 quads" call, because that can only use the same texture for all of them. So the batch ends up with "set texture A", "draw 1 quad", "set texture B", "draw 1 quad", "set texture A", "draw 1 quad"...
This is not as bad as it sounds. These are very quick calls and are still much faster than the equivalent canvas2d rendering commands.
6. After export there are lots of optimisations run like image deduplication and spritesheeting. This makes it more likely that objects share the same texture, so in some cases after exporting the batch can look like step 4 where it would have looked like step 5 in preview, which improves performance slightly.
So overall you can optimise your game by doing things like making sure objects with the same images appear consecutive in Z order. But this can be difficult, and is probably a "micro-optimisation" - there are likely to be much more important things to worry about for performance.
It's possible to make giant spritesheets that have all the game's images on it, but it doesn't totally eliminate texture switching if you have lots of images and exceed the maximum texture size with one spritesheet. Also putting all images in one image can make the loading bar useless in web games, and actually can significantly increase the download size (particularly problematic where stores have a file size limit, like Google Play). More info in this in the blog post Under the hood: spritesheets in Construct 2.