Im going to resize all the pics in my store so they are all the same, but what is the ideal size so that when you view the picture on the product page the whole picture shows without getting cut off?
http://www.zippyrooz.com/store/monsters/monsters.php
In case any newbies are wondering I did 800x800 and it all seems to work really nicely now.
there is no perfect size or resolution. the web is designed to be viewed on a wide variety of devices.
800px is about right for an average laptop computer. but some desktops have much larger displays. and some phones have only 360px across.
to make it even harder, iPhones and the latest Apple computers have Retina displays that look best with 2x the width and 2x the height.
responsive images resize to fit the device size and resolution.
if you are using Stacks you an drop a 1600x1600 px image in to your layout. double click to edit and scale it down by 50% to 800x800
Stacks will export the 800x800 image. plus the 1600px image too. and it will write out the crazy CSS and HTML that’s required to make the images resize and swap resolutions and all that good stuff.
Give it a try. It’s pretty neato, although i might be slightly biased since I wrote that bit myself. 
Isaiah
5 Likes
Hi @isaiah,
This is interesting! So does that mean that I can drop a 1600 x 1600 image into the standard image stack, scale it to say 200 x 200 so it displays nicely on a phone screen but still have the 1600 x 1600 display automatically on the iMac screen for example? Which image would then be displayed on an in-between screen size then, will it be the 200 x 200 or the 1600 x 1600 or will it be optimally scaled?
Beem
@beemerang - the behavior is quite complicated. it would be impractical for me to detail every nuance here – i highly recommend some experimentation. however, the answer is… almost… but not quite.
Images scale responsively
So, the first thing I should note is that if you drop any image into Stacks it will scale responsively to whatever container it’s inside of. If that’s the width of your theme, or the width of the device, or the width of the column, etc. It does this with CSS on the web page. This is a very standard approach on today’s web.
Example: If you drop a 1600x1600 image into a Stacks page with a variable width theme – and do nothing else – then the image will fill the width of the theme, up to 1600x1600, no matter the device. So on a 400px width phone, it will show up at 400x400. Note, however, the phone will have ad to download the full 1600x1600px image (which is not always desirable).
Stacks exports an @2x (retina) resolution image WHEN IT CAN
If you drop in an image and do nothing else, Stacks will just export it as is. Stacks will always do as little as it possibly can to images.
But if you do happen to scale an image down by 50% or more, then Stacks will export the scaled image as well as one that is exactly 2x that resolution (a so called @2x image in Apple’s parlance). It will also include the “Source Set” html5 necessary to take advantage of this image on devices that can. Here’s a page that has techy details bout srcset: https://webkit.org/demos/srcset/
Example: If you drop a 1600x1600 image into a Stacks page with a variable width theme – and scale it to 200x200 – then Stacks will export two images: a 200x200 version and a 400x400 version. (note that the 1600x1600 version will NOT be exported).
Responsive display
On the web there are lots of ways to solve this problem, each with its own pros and cons. Some users will have several stacks, each of which displays an image optimized to a specific device type – and then use the responsive display controls in stacks to show/hide the various images on the various platforms. This can work very well – and help you minimize download sizes for specific platforms like phones where image size might be less noticeable and more problematic over a cellular connection.
Animated Gif
GIF images, in order to maintain their optimized color palates, animations, and transparency – are never edited or resized by Stacks – so they can’t participate in this sort of thing (and that’s definitely a feature not a bug).
They will still responsively resize in the browser – but only the original image will very be exported by stacks and that is the only one that will ever be downloaded by the browser.
If you want more control over GIFs then I recommend a purpose designed tool for editing those. There are now a ton of great things for doing this. Google’s recent tool called Motion Stills is my favorite – it converts the “Harry Potter” LivePhotos of the iPhone into gifs and exports them in a variety of formats, including GIF. How cool is that!?
Warehouse images
Many 3rd party stacks have “warehouse image” features. Basically just being able to link directly to an image that’s already hosted somewhere online. Because Stacks has no control over those images, they don’t really apply here. You can still use the responsive display technique with warehoused images, of course.
Caveat emptor
There are lots of exceptions and details. I highly encourage you to experiment to learn how Stacks works in conjunction with your theme and your page and your devices.
Isaiah
2 Likes
Isaiah - that is pretty cool, getting the resize automagically.
Question: Can I do that in a blog page?
it’s tough to answer this question directly. i think the intended info you’re after is a bit different than the literal question you asked.
i believe what you’re asking is:
“Does hiding things on a Stacks page make that page faster?”
The short answer is: sometimes. It depends on what sort of stack you hide.
Images: yes.
Plain text: a bit.
Javascript: not at all.
The longer answer can be broken into the three main time/efficiency areas of a page:
Page load: On most pages, the slowest part is loading the content from your server. Browsers do not render hidden images (unless you force them to with Javascript). So hiding image stacks that aren’t needed for a specific device is a good way to improve page load time significantly. Since images are often responsible a large part of slow pages – this can be a big win.
Page rendering: All of the HTML on your page will need to be rendered. Although invisible content isn’t totally free, it is certainly taster than visible content. This is less of an obvious win than images – but it’s not nothing.
Javascript slowdowns: Some pages are slow because the Javascript takes a lot of time – or because the Javascript is using a lot of memory. Javascript runs no matter what. Hiding will not help here. In fact the Javascript will need to run to determine if content is visible at all.
The things I’ve been talking about a specifically features of Stacks. So they only apply to Stacks pages. Blog pages are a different beast.
Isaiah
See… when you say it like that, it changes the meaning… 
Here’s the thing: just because something “downloads” from the server doesn’t necessarily mean that it slows down the “page load” (significantly). Again, the details here matter quite a bit.
All the images that your page refers to in HTML will, eventually, be requested from the server. However, if the content is hidden, it usually will not delay rendering of the page. So the page is faster – even though the file is downloaded.
Not displaying an image will always be faster than displaying it. But depending on the details of the image, how it is referred to (HTML, CSS, JS, img tag, src-set, … ) and the platform being used… the effects it will have on your page is quite different.
So… how do you know? Test it. In-browser testing of the real content is the only way.
I’ve made an example:
This page shows three images. All visible.
https://dl.dropboxusercontent.com/u/433436/image_load/page/index.html
This page hides two of the images with responsive features of stacks:
https://dl.dropboxusercontent.com/u/433436/image_load/index.html
With Safari Developer mode enabled I open up the inspector, clear and disable all of my caches, and reload both pages.
The page load times on my machine are mostly indistinguishable from one another – but looking at the graphs it’s clear that something quite different is going on in each page. Here’s a screenshot of my timelines. (note the “cached” column as “NO” in all cases – that’s very very important for this test).
One thing to note is that YMMV. Even on the same machine from the same server, with identical images – the load times vary a hair.
But more importantly is to note that in the timeline on the left (the single image) there is a staggering effect. This is because the page starts to render before all of the images are loaded. The invisible images are still loaded from the server – but by the time they finished the page is already visible.
That said, in this particular case, since there are only 3 image – and my Mac Pro has lots of processors, and my network connection has lots of bandwidth, the right-side timeline actually loads all three images concurrently. For this case, it probably turns out that the concurrency is a larger part of the equation than the network fetch. Wow.
So the takeaway here: The devil is in the details.
And some practical advice:
- assume nothing.
- test everything.
- never optimize based on assumptions
- always optimize based on real tests
- verify your optimizations actually improve results
- test on all platforms.
- test over multiple network conditions
1 Like
Hi @isaiah,
thanks a million for providing such a detailed response! I’m going to be studying this information as I’m sure many other Stacks users will be doing.
I appreciate the time you took to explain this.
Cheers,
Beem
1 Like