The Site Image Stack does this as well. It also allows you to control the image names in resources.
An image no matter how you put it on a page becomes a separate file stored on a server. If you drag an image directly to a stacks page it manages and creates a separate file for you. It creates the URL link to load the image on the page.
If you do what’s referred to as ”warehouse” images, you create the images and manage them on the server outside of RapidWeaver. You then place a stack that supports remote URLs (aka warehousing) on the page and fill in the URL to the image you’re managing.
Prior to Stacks 4 and RW8, if you drag an image onto the page it used the older Image Stack. That created a separate copy of the image for every instance you dragged on to the page.
Stacks 4 along with RW 8 introduced the Site Image Stack. It stores a single copy of the image and stores it in the RW resources folder. That single image is managed by RapidWeaver, every time you drag the same image onto any page, the same URL is used to serve the image.
Modern browsers are pretty smart about not having to go back to the server to retrieve files that they’ve recently read. This is called caching. If the browsers still have a file (URL) in its cache it uses that file rather than reload it from the server.
Now to make things even more confusing, Stacks that you drag the image into the side well (inspector area on the right) not directly onto the page, are treated like the older Stacks Image Stack and each time you drag the image to the page a separate copy is used.
From an end-user perspective, the performance of serving a single image would be the same no matter how you put that image onto the page. If the same image (URL) is used on a second spot like a separate page then if you use a version that is cacheable, subsequent uses of the same URL would be much faster.
From the management of the images side of things, if you have a lot of images and various versions like thumbnails, small, medium, and large, retina, etc. Than managing them outside of RapidWeaver is probably the best approach.