Ah yes, I forgot to mention this in the export-time optimisations tutorial, but it's not usually a significant saving. At export time, C2 counts the colors to determine if images will fit in to PNG-8 - but it also checks if the color values can be losslessly converted to a lower bit-depth texture in memory. We generally say all images are decompressed to 32-bit ARGB in memory, and this is indeed generally true. However if an image has a fully opaque alpha channel, it marks it as 24-bit RGB instead of 32-bit ARGB. This potentially allows the driver to save 25% of the memory by skipping the alpha. However I think most memory-constrained devices only support 16 or 32-bit textures, so in practice this will still turn in to a 32-bit texture in memory, and the driver will add an opaque alpha channel anyway.
It's also possible C2 will notice the image fits in to a 16-bit format, like 1-5-5-5 ARGB, or 5-6-5 RGB. This reduces the memory usage by half, and can actually render faster too (since less data is involved). However it's usually pretty rare for images to be able to be marked as a 16-bit format, since C2 only does so when it's truly lossless. A single pixel that can't be losslessly represented by, say, 5-bit values instead of 8-bit values, means the image must be encoded back to 32-bit ARGB - and this happens at the level of an entire spritesheet.
It's also possible to use compressed texture formats. These are like simple forms of JPEG with light compression ratios that are handled natively by the GPU, so the texture can actually be stored and directly rendered from a compressed format in memory. This can save loads of memory, but has several problems: there is still not one compressed texture format that all GPUs support; some formats are patented and we would not be able to ship encoders with Construct 2 games; most of them are lossy, so will slightly tarnish artwork (like low quality JPEG settings); some of them don't support alpha; and so on. It's possible one day these problems will be solved, and we'll add compressed texture support to exported projects, but again this will probably only happen to images in the project and not images loaded from a URL (since C2 can pre-process them).
A much more important saving is memory use: a 130x130 image loaded from a URL is not spritesheeted, so is probably placed on a power-of-two surface in memory at 256x256, using about 4x as much memory as necessary. If the image was in the project, it'd probably be spritesheeted in a way that wasted much less memory.
Construct 2 works really hard to both compress images to be as small as possible, and save as much memory as possible, using all sorts of tricks. Every time you load an image from a URL, you are missing all of those optimisations. If you make heavy use of loading images from URLs, you can end up with a significantly less efficient game than if you had everything imported to the project as object images.