What are the benefits of warehousing images on the server rather than embedding them into the RapidWeaver project itself?
I can understand how this makes publishing changes simpler but does it confer any perceivable benefit to the website user? Assuming images are optimized before uploading does warehousing affect download speeds to the end user?
My website has lots of photos of kitchens my cabinet shop produces.
The images are sometimes referenced several times.
The same picture could show up as part of a kitchen, a discussion of pots & pans storage or a discussion pros & cons of various options for treating blind corner spaces under countertops.
What is the difference between parking an image in a warehouse and using Issaiah’s SITEIMAGE stack?
Are there any other things to be aware of when utilizing warehoused images?
@cabinetmaker The main advantage of warehouse or using remote links should have little to no effect for the end user. (Perhaps I’m missing something but it seems like this is not a major issue.) Warehoused images, in essence, are like Stacks site images. (May be wrong here but seem to be similar.)
… however the difference to the creator can be vast. For example, RW has a very smart and nifty feature where you can auto-backup your project file. This is a GREAT feature and addition by RealMac. Frankly everyone should take advantage of it. What if your RW project gets corrupted? What if you run into the dreaded need to re-link resources? And on and on. A zipped backup on your server comes in mighty handy in cases like this. But … if your project file is 1 Gb or even 500 Mb then the backup process may take a long time (depending on internet speed). So a person with a big project file may quickly decide this backing up is a luxury rather than an essential feature. If your project file is not “bloated” with storing lots of big resources then this won’t be an issue.
I can think of other benefits also regarding dependability and reliability. But all those reasons benefit the creator/designer.
No and no.
Functionally, it should be none. They will both only download the image once no matter how many times and on different pages the image is used. The web browser should be serving it from it’s cache
Mathew’s advise is solid. I’d only add that in the event you need to do a “republish all files”, it will be much quicker if you use remote (aka warehouse) images. The files are already on the web server and are not transferred via RW during any publishing tasks.
It does take a bit more effort to manage the files yourself, but if you’re working with a lot of image or other large files, it’s worth the additional effort, in my opinion.
In addition to what’s been said above,
If you have a large amount of images warehousing might make it easier for you to manage.
Edit and preview with a large amount of images will be faster if they are not warehoused. Why you might ask, because RapidWeaver will need to load the images from the Internet to edit and preview.
I’ve done some stress testing and found with a large amount of images on a page edit mode can be quite “jurky” and slow even with a gigabit Internet connection. While with the same images stored with the site image stack it was smooth and instant response.
I just enable all free tickets to also have access to @isaiah’s talk at the 2019 WS Summit. It’s a valuable talk that I think everyone should watch. He goes in depth into the pros and cons of how we use images in Stacks. Check it out…
@joeworkman Thanks for being so generous and sharing the Isaiah presentation! For others who watch, he talks specifically about images from about 16 minutes through 42 minutes so it’s a 26 minute discussion on images. It’s definitely “must see” video, especially for anyone who is relatively new to working with images for the web.
However, I want to disagree with @isaiah about one thing in the video. He gives a demo using warehoused images where they are really slow. And they are when reloading the page. But … he is ignoring the first rule of image club:
Always optimize images first.
I realize Isaiah is doing this on purpose. Undoubtedly he has seen folks use full scale images from Unsplash or their own full resolution images put into a folder on a server to warehouse them. But not optimizing your images first is, put discretely, bats**t crazy.
Please oh please use an image editor of some sort and optimize both the dimensions but also quality of those images (e.g. they can often be saved by something like Photoshop at 75% quality and will look great on a web page). There are even inexpensive bulk image resize apps that do a great job (e.g. PhotoBulk for $10).
I’ve discovered the issue of “how to optimize images” is an issue for any website development tool. These kinds of discussions go on a lot with WordPress users as well. Optimizing First should be done no matter whether you warehouse your images or use them within your RW project file.
Thanks guys. This has been really helpful.
I’ve watched Isaiah’s talk a couple of times now and am going back in for another listen.
I usually start to understand this stuff about the third or fourth time I watch it.
Based on this video I think I am going to stick with Isaiah’s Site Images rather than warehousing.
I am a little bit torn about which compression software to use.
I have Photobulk & ImageOptim.
ImageOptim seems to produce slightly smaller file sizes but makes all the changes directly to the image. Photobulk leaves the originals intact and creates a separate folder for the compressed images.
(The file size differences may have something to do with preference settings)
Most optimization (compression) software apps have a setting to determine how much compression to apply. They all use the same process to achieve the smaller file sizes.
It’s a balancing act, the more you compress to reduce file sizes the more quality you lose.
Resizing an image so it’s not any larger than the space you’re allowing it to display on, is lossless. The browser is going to do that anyway.
If you have a 2000px wide image and you only you only have a 500px wide column to display it, the browser will load the full image file but then resize it. In this example if you resized that image to the 500px width, you’ll reduce the size to about an eighth of it’s original size and have zero loss in quality.
Keep in mind that the smaller screen sizes can have the wider width. Remember columns often stack on top of one another on smaller screen widths.
I always suggest you resize first, then compress in two steps. And definitely don’t touch your originals. If the software doesn’t make a copy you should. Designs change and you’ll want to be able to redo the resizing and compression steps if needed.
So if I have a 500px wide column and load a 2000px wide image the browser will throw away 1500px?
Does this loss of 1500 pixels manifest as a lower quality image to the web user’s eye?
Not exactly sure what you mean by “compress in TWO steps”.
Would the first step be the initial resizing when I export the image from Lightroom?
The second step would be when I filter it through something like ImageOptim or PhotoBulk?
If you only have 500px of space the browser will have to “resize” the 2000px image to fit.
Take a large image and open it in preview (built-in Mac app) and you can resize the image there.
What I’m saying is that you can’t fit a 2000px wide image in 500px of space so why send an image 8 times larger in size then space you are allowing it to display within. The browser has no way to “squeeze” these extra pixels into make it a better picture.
I always resize first, the reason is like my example, I can substantially reduce the file size without the quality loss that compression brings. Then I would compress. Since resizing has to happen anyway (if you don’t the browser will) do it first. You might find you can turn down the compression settings and still get the smaller file sizes you need.
Resizing you don’t have a choice, so you might as well do it, the compression step you really need to “eyeball” and make a judgment call on.
What about “retina” images?
Retina display is Apple Speak for double-density displays. These high-density displays crame more pixels in the same amount of space.
When we talk about pixels in web design (CSS pixels) they are referred to as DIPs (Device Independent Pixels). They readjust themselves according to the pixel density of the screen. This applies to every element in CSS not just images.
So if you have an element that has a height of 500px and width of 500px it will use 500px by 500px size in a standard display but would use 1000px by 1000px on a Retina display.
It’s important to keep in mind that a 2x(double-density) image is actually 4 times larger in size (two times the width and two times the height) so they can really impact the load speed of a webpage.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.