Website Size Question

I have some basic questions about the relationship between size of website and user experience.

The website I have in mind probably has between 200-300 pages of content. The pages will, for the most part, be very image intensive. (I am still working out the methodology for presenting the images.)

Does the size of the overall website actually matter or is the real driver for download speed how cogent the information is? I know a little bit about user experience in databases. In that paradigm it’s all about packets of information that have go up to the server and come back again and get redrawn on the user’s screen. Speed in that world is affected by how you sequentially phrase your queries.

Is it the same for websites? If I can keep the amount of information that must be down-loaded on any given page to the bare minimum could I theoretically have the site itself contain any number of pages?

I want to add to this.

Assuming that I hold the number of images per page to a reasonable size and each image is reasonable in pixel dimension, what is the most efficient way (relative to download speed) to display these images?

Is there any inherent advantage to displaying images in a slideshow vs just a static image on a web page or a lightbox? Is the real driver for speed just file size or does the delivery mechanism have any influence?

A subset to this question has to do with how the images are stored on the server. As I understand it Site Images are stored just once. In Stacks 3 each instance of an image on your website also represented a separate instance on the server.

But what does that matter to the website user?
Don’t they just see the image that is germane to the page they are seeing on their device? Does the fact that there are redundant images on the server have any impact on user experience?

I’d say, for the user, it all comes down to page loading speed - if you have a lot of images that aren’t sized or optimized properly then it might be a chore for the page to load, particularly when internet connection is sub-optimal. This is potentially a significiant impact to a user/customer.

There’s also an issue of using the right amount of images. Just because you have them doesn’t need they should be on the site, but I don’t know your application.

There’s something to this as well. I can’t speak with a ton of authority but I know there are some stacks (Gallery stacks, in particular) that will load small thumbnail versions first and won’t load the larger images until it needs to (i.e. when someone clicks on a gallery). In that case, you’re likely buying yourself a lot of page loading time by letting the page get started and dealing with the bigger images only when needed.

If you have a unique image, how it is stored doesn’t matter. However, if you had an image that repeats across multiple pages (a logo, for example, or a common header/background image) then the image gets downloaded once on the first page visit, but every other time it is needed, it serves up a cached/already-downloaded version so the user gets it instantly and it improves page speed. So, in stacks 3, that repeating image gets re-downloaded multiple times. With warehousing (or Site Images in Stacks 4) it only gets downloaded once.

Jason,

You are right about “just because you can doesn’t mean you should”.
The comic Craig Ferguson put it well:

“Does this need to be said?”
“Does this need to be said by me?”
“Does this need by me, now?”

I hadn’t thought about the impact of loading thumbnails first then big images only when asked for.
That’s useful insight.

Is this what is meant by “Lazy Loading”?

There’s definitely others on here that can talk about more intelligently than me but, yeah, that’s the concept behind lazy loading.