Optimizing file size for Thumbnails & Retina

Classic General
1

I saw something in a recent Joe Workman video that alluded to loading images as a “Retina” version vs a presumably smaller file size. I can’t remember what the smaller file size was called. He did not spend a lot of time discussing the pros & cons of either option. As I recall it had something to do with what type of device the image was going to be displayed on.

I presume that the size of these files is determined prior to bringing them into RapidWeaver.
This sounds like something that would happen in a Lightroom export.

MY QUESTIONS ARE:

What is the optimum size for Thumbnails? Would this be expressed in pixels?

What is the optimum size for a smart phone or tablet?

Is there any difference in resolution if a file optimized for tablet size was displayed on a desktop?

2

That’s right, use what you like to resize the image. The preview that comes with MacOS will work for resizing. It will not, however, optimize(compress) the image for use on the internet. That a number of programs or website that will do this for you. Some free and some paid.

There is no optimum size for any image. The first step should be to determine the space the image will have to display. So it depends on the layout you are using. It also often depends on the screen width it’s being displayed on.

If the image is being displayed in columns then many times the smaller screen sizes will produce a larger image as they will be displayed one up.

So as an example, if you have a page of thumbnails, and each thumbnail can use a maximum of 250px in width, having an image with a larger width than that would be a waste. The first thing a browser going to do is resize the image to fit into the space allowed on the page. If you use a larger image the browser still has to load the full-size image and then resize it to fit.

So here is an example off your test site: https://realdealkitchens.com/

The images you are loading are 1200px wide.

On large screens your layout allows a width of 248px to display each image( 4-up).

2020-01-06_10-30-25

On Medium screen sizes(960px) the layout changes to 3-up but each image can now span a width of 290px.

2020-01-06_10-31-35
2020-01-06_10-31-35792×473 102 KB

On smaller screens (760px) it changes to 2-up and each image is allowed 339px of screen width 339px.

2020-01-06_10-35-07
2020-01-06_10-35-07577×521 80.9 KB

So in this example, an image width greater than about 339px is a waste, there is no room to display any larger image.

So the best practice to prep images for a website

  1. First, determine the largest width that the layout will display that image.
  2. Resize/Crop the image to be not much larger than the area it can display in. This should be done before any other optimation(compression).
  3. Then run the image through one of the many compression processes.
2 Likes
3

If you are working with a lot of images, at different sizes, for whatever reason: then you may want to take a looooong look at this great stack:

@habitualshaker also has set up a free routine that works with the great Retrobatch. I’m sure he’d be willing to share with you if you are interested. Retrobatch you can learn about more here:

It comes in a regular and pro version. The differences explained here:
https://flyingmeat.com/retrobatch/docs-1.0/provsregular/

A wee bit more is included in this discussion:

3 Likes
4

Thanks guys. More to digest.

(I am beginning to think website development is a full time job.)

5

It’s not a full time job, but I do think images is one of those “issues” that people do not fully appreciate. You are kind of caught in the middle as your one site has very very image heavy. Thus in your case it’s awfully important to understand the various nuances of using images.

For instance, just optimizing your images will help a bit but maybe not much if you didn’t start with something at an appropriate size. For example, I took a 6 Mb image and then optimized it. It ended up at about 4 Mb. Is it optimized? Yes. But is it also way to big to use for a website? Yes! Original images might start at 6,000 by 4,000 pixels, or bigger.

So resizing (or in your case probably multiple resizings) are needed before optimizing.

@habitualshaker created a Retrobatch routine I mentioned above. Here’s a screenshot of what it will do: take your original image and create 8 different sizes of it from 2100 pixels to 320 pixels wide! Pretty cool. You probably don’t need 8 sizes, but you can easily tweak so you get 4-5 sizes from the original image. And you can fully process about 500 images all resized in less than 2 minutes.

retrobatch-example
retrobatch-example1218×2050 292 KB

1 Like
6

On the one test page I looked at, it seems that most of the images are starting at 1200 x 960px in size.

It looks as the maximum space they have to display is about 340px wide. You don’t need to worry about height, as you’ll want to keep them proportional to the width.

Just by resizing the images you’ll reduce the weight down to about 1/6th their starting weight. That’s without any compression or quality loss.

Then you add even minimal compression and you can take a multiple megabytes image file down to a slim couple hundred kilobytes.

Now depending on the layout and what stacks you are using it might not make much of a difference on creating different images for different screen sizes. You started this post asking about something @joeworkman said in one of his videos, and asking about optimum image sizes and retina images.

Joe’s new foundation 6 stack, @habitualshaker’s Srcerer stack, along with a few others support doing this. But a lot of the image and gallery stacks don’t support doing this.

7

Thanks Matthew & Doug.

I spent some time at the habitualshaker site and you are indeed right that this will require a deep dive.

Tell me if I have this correct:

  1. Do something first to my images to optimize them
  2. Feed them into Retrobatch to create various sizes of the same image
  3. Use Retrobatch to upload them to a warehouse folder on my website

At this point Srcerer Stack points to the appropriate size image based on whatever size browser the user’s device presents.

Do I have this sequence right?

Are there limitations to what framework this stack will work on?

8

I really think you’d be fine with two versions of your images. The first, which I’ll refer to as thumbnail, would be about 340px. Use these images in any grids or as the thumbnails for any galleries. The second would be the full-size images. These would be used as the large images in the gallery lightbox.

9

Thanks Don, that’s kind of what Doug said.
How big would you recommend for full size images?

I am guessing that Thumbnail & Full Size would show up as two separate assets if they were stored in a Site Image?

10

Doug @teefers always has good advice!

I’m sure you’re tired of reading this, but it depends. What size you make the full-size depends on your site design and the image detail. A lot of times you have to try a few sizes and compression quality settings to get a good balance between file size and image quality. Some times a larger image with more compression is better than a smaller image with less compression. Some of my full-size images are 900px wide and some are 1600px. From what I’ve seen, your 1200px looks pretty good.

How many images you have on a page also influences the size I use. The more images on a page, the more I concern myself with the file size of each image. Generally I try to stay under 200kb for full images.

1 Like
11

I would switch the order. I always resize first. The reason is that resizing is a lossless size-reduction. File compression is a balancing act. The smaller the file size lower the quality. Almost all image compression products allow you to tweak the level of compression.

I find that by resizing the image first, you can get significate file size reductions without losing any quality of the image. Then you can “turn down” the compression a bit and get very nice file sizes.

There’s also another product(PhotBulk) I’ve used for years that allows you to Resize, Optimize, and more in bulk. It’s non-destructive, and you can do it all at once or resize in one batch and then optimize in another.

12

Thanks for the tip about resizing first. I remember reading one time about lossless compression.
So I start with the size I want then run it through compression filter. I should then probably test drive the same image at various levels of compression quality.

I think after I get all this figured out I can create pre-set exports from lightroom that reflect all these tweaks.

Am I correct in thinking that the full size file has to do with how many wide the column is that holds the container that holds the Site Image?

If this is the case, how would I go about correlating column widths to pixels?

13

I think there are a lot of ways to compute the max-width an image will take.

If your using foundry than the first step is knowing the breakpoints for when the columns change from Mobile to Tablet to Desktop. If I got it right Mobile is ≤767px Desktop is ≥ 992px, and tablets are between.

So if you want a “rough” size if you know you are 2-up on mobile then simply take the 767 and divide it by two and you get about 383px. Now I said roughly because there’s padding, margins, and gutter(space between columns to account for. We also need to think about the maximum width for the desktop size. If you have the columns in a container set to a fixed width or fluid width.

Now you can also take a more precise approach and use the developer tools with the simulator, preview or browsers. Then you would set up the column layout you want with simple placeholder images and the number of columns for each breakpoint and look at the images on different size windows.

The latter approach is what I use, the developer tools might seem a little tough at first but they are really quite easy to use.

14

I’ll add some info about Srcerer here. Whether you need this level of control over the images on your site is up to you. The approach that Srcerer uses is great for sites where images are front and centre and (largely) the focus of visitors to your site. In these cases you really want to be displaying the best possible image at all times. Where images are just decorative then there is definitely less value.

Srcerer (Sizes) stack allows you to add up to 8 different width versions of the same image. The browser then displays the most appropriate image for whatever device width it is being viewed upon - it takes into account the width of the device and whether it is a retina screen. (e.g. a 600px wide ‘space’ on a 2x retina device would need a 1200px image to display perfectly.)

Additionally, in Srcerer you can specify ‘image conditions’. With these you can state how much of the screen the image takes up at different breakpoints. For example, you could say that it is full width on devices up to 768px and then 50% of available width on devices up to 1200px (e.g. if it is in a column). If the image is in a max-width container then you can also specify this. All of this ensures that it is always just the smallest possible image from the available options that is selected by the browser.

Outside of Srcerer you need to generate your images in however many different widths you wish (up to 8). As @Mathew mentioned I have a Retrobatch workflow for this (you can read more about that process and download the workflow here). You do not need Retrobatch but it is a really great tool for this kind of thing (and way more).

Once you have your images then there are 3 options in Srcerer stack to link to them. The first 2 warehouse options require you to upload the images to a folder on your server. The 3rd option allows you to just drag and drop them into image wells in the stack.

Any questions just ask.

1 Like
15

Thanks Stuart.

Are there any performance issues (download speed) associated with the different methods of linking to the images?

Would images that are linked from a server folder load faster than images that were linked via drag & drop?

16

Even if you add your images via drag and drop (or via RW resources etc) they will end up in a folder on your server and be accessed the same way as via warehousing (i.e. via a url). So no speed differences in that respect. The main benefits of warehousing come when you are using multiple instances of that same image as the this approach will reference the same image file (as opposed to different versions of the same image). Warehousing also allows you to retain your own image names.

I personally feel that everybody should take ownership of their images and manage them themselves. i.e. add your optimised images to an organised images folder on your server and link to them from there. Warehousing has many additional benefits that have been discussed on this forum in many posts.

Hope that helps?

17

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.

1 Like
18

I know. I was answering a question in relation to this:

19

Don,

You said: “Generally I try to stay under 200kb for full images.”

Is there an optimum overall kb size you strive for with respect to the entire webpage?
I am not talking about weight for each individual image but rather combined weight for ALL images.

20

I’ve never really looked closely at the total page size. I try to keep single images as small as necessary and sized for how they’ll be displayed. I let my desired layout and content determine how many images end up on a page.

On sites where people are very interested in your content, they’ll tolerate a bit longer page load times. Keep the main landing pages pretty lean and when you get deeper into content where you know people are already interested in seeing your content, you can have more page weight. In your case, the kitchens’ overview page is one that I’d keep fairly light. Once they click to an individual kitchen (or a gallery on an individual kitchen) they’ll tolerate more wait.