Save for Web~
The purpose of this page is to share tests using Photoshop’s Export>Save for Web image optimization feature. These tests were to explore the optimum size for photographs on a full width website using a shared hosting service. What is the compromise, what image size will still show good detail yet load quickly.
I set this up for my own reference but decided to share the page in case the results benefit someone else.
To cut to the chase, the type of server you are using determines how large your images should be. In a screenshot I share down below, the recommendation for Shared Hosting states images should be no wider than 1400 px on the longest end. However, this doesn’t work for me as I like viewing some pages full screen in my browser and 1400 cuts off. Also, the new retina screens are more demanding for pixel width so all that has to be considered.
Bottom Line~
• Recognize the type of web hosting you have and the image size recommendations.
• Determine the container width(s) of whatever website Theme you are using.
• Experiment with Save for Web to find the quality/page load compromise.
• Use some kind of Image Compression plugin or engine if possible.
• Post it somewhere private or public where you can view the results.
• Check your cPanel for more insight if you are comfortable with that.
What works for me~
• The total file size should be somewhere in the 300-350 KB range if possible for most images.
• I use the Quality percentage tab to get the file the right size.
• I like 1800 pixel wide on full width, 1080 px for blog size images.
There are lots of different opinions out there. You have to find out what works for you.
If you are on a phone or tablet, and that is all you use, none of this will probably make any sense because all the images below will look the same. Although “think mobile” is the mantra for website design, and I enjoy my phone and tablet especially for podcasts and such, I still like a desktop with a nice monitor for photography and editing.
In Save for Web, the pixel width and Quality Tab determines the size of your file. The Quality Tab defaults are: Low=10%, Medium=30%, High=60%, Very High=80%, and Maximum=100%. I ignore the presets and go right for the percentage.
I read that 75% is good even though it is not a default, so I included some of those just to view the results. The size of the file is in the captions. By the end of this experiment, I found 75% usually makes a file too large and could not notice an any increase in quality over 60%, even viewing full screen.
For years I used a 2000 px width with a Save for Web>High 60% setting and had the WordPress Imagely Theme set to Full Width with an overall container width of 1800 px. I also set the Imagely Gallery to resize images @ 1800 px, so I figured making the images a little larger and sizing down was good for display. Although 2000 px wide looks awesome viewing full screen, had to rethink all that when problems developed with the data load on the server.
This is all with using WebP compression in conjunction with W3 Total Cache which was great when it worked, but that’s another story.
Web Hosting Requirements~
Above~ Screenshot of image size recommendations from Imagely regarding how web hosting may affect the image sizes you should be using. I wish I had seen this before, because to me this determines everything. We are on shared hosting and have had problems bumping up against data limits. So I decided to pursue this further with Yellow Pencil.
Inspecting Elements with Yellow Pencil~
Above is a screenshot of the Yellow Pencil plugin interface. Here a container has been selected and top right you see the inspecting elements drop down tabs. Measures is 7th down. Most people use Inspect Elements on Chrome or Develop on Safari, but I find this plugin sometimes more user friendly.
Above~ Here we can see that the container width for a large image on this website is 1333 so 1400 px would be fine. However, it came up short when I went full screen on my browser and needs 1800 for the full effect. The Slideshow containers are also the same, 1333 px.
Below we can see the container width of blog images is currently at 1035 px so 1080 px would be fine for images intended for a page with a sidebar. Using the same tool revealed the sidebar is currently set at 246 px wide, which is sometimes useful to know. However, when going full screen Yellow Pencil revealed blog images are 1410 px wide.
So what does all this mean? Well, it means that if I want to view things full screen I would need 1800 px, not 1400, but somehow try to keep the file between 300 KB and 500 KB, which is where Save for Web comes in.
Save for Web Interface~
The links at the bottom of the page provide some good guidelines about Save for Web. I’ll just mention a couple features here:
2up Comparison~
A useful tool is the 2-Up (or 4-Up) feature available at the top as shown above. Here we can see some of what will happen when a 300 resolution tif image is converted to 72 resolution jpeg @ High 60%, and this is without reducing the width yet.
If you want to see actual changes in resolution try zeroing in on a feature, going to 300% and use the Low to Max setting at the top. You will also notice the file size change.
Preview~
Another feature that you may find useful is Preview where we can see what an image will look like on your computer’s default browser .
PNG Images~
Since screenshot files can be quite large, I’ve found Save for Web seems to works pretty well on a PNG file that needs to be reduced. Under the file type tab select PNG-8, and you control the size of the file by adjusting the width. The 2-Up feature is useful for seeing the file size difference.
Pixel Width Experiment~
2000 px width~
1400 px width~
1280 px width~
1st Impresions~
If viewed in full screen on a good desktop monitor I could notice a slight improvement in quality between a 2000 px Very High (80%) vs High (60%) default, and the difference was more noticeable between Very High vs Medium. I could see what buddy was talking about with the 75% thing. 2000 px looks beautiful full screen, but how many people are browsing that way?
I noticed 1400 px at High (60%) is 525 KB which is just over the 500 KB max recommendation I read somewhere. 1280 px at High is 445 KB.
Using WebP~
WebP is a compression engine used for compressing images that are uploaded. It is great when it works. We’ve also used Smush, etc. However, when we began using W3 Total Cache it worked at first, then didn’t, I keep getting messages about Cron on my Site Health module, etc. etc. The whole thing with W3TC and WP Optimize and the maintenance nightmare that WordPress has become is a story for another day. Right now, WebP is working and is fine for uploading images to the Media File, but WebP has nothing to do with uploading images into Galleries on the Imagely Theme, which is a great theme engine. So I ran an experiment.
Experiment with Gallery Image Sizing~
• Redoing Gallery Image Sizes~
In WordPress, by going to NextGen Gallery>Manage Galleries and selecting the one you want, you can then resize all images. In the screenshot shown below, you would click the ID to select all, select Resize Images from the dropdown menu, click Apply, then change the image width to whatever you want and click OK.
Because Imagely is flexible and allows a lot of latitude, I went through each Gallery I had and resized them all from the 1800 px preset to 1400. I did one Gallery first as an experiment, didn’t notice any loss in quality, so did them all. Using the cPanel info cPanel>Tools>General Information>Disc Usage as a guide, when I was done I had reduced 1.5 GB off the Server load.
• Redoing Gallery Image Sizes using Save for Web~
I became curious about the size of the images themselves on the Server–what would happen if I also reduced the image sizes before they are uploaded to a gallery. Since I was working on a page at the time and the images were still in my Documents Folder, I created a “phoney” gallery, and dragged the Save for Web 2000 px images into Photoshop (which loaded instantly), resized them to 1400 px, and uploaded them into the new gallery, and checked them out.
Before converting all of them, I took one original Tiff image, did a Save for Web at 1400, and compared it to the one already converted at 2000 and then converted again to 1400 px to see if there was any loss in quality. No difference at all. This was good news, since the ones already converted are so much faster to work with.
Above is a screenshot of the file sizes of one of my galleries in the cPanel. This was before any reduction and are images uploaded after using Save for Web @ 2000 px wide Quality>High>60%. Notice two are above 1 MB. In the phoney gallery I created with 1400 px wide Quality>High>60% the file size was only reduced about 18% and there were still images above 500 KB,
Conclusions~
I got the cart before the horse: I should have been operating within my hosting requirements first, and then gone after appearance considering size and quality after.
Overall, the percentage window on the Save for Web interface is your friend. It can help you reduce the size of the file.
Also, I wish I had caught the NextGEN image size note about the all the image heights needing to be the same in a gallery or else it will make the image smaller to fit. For example if Save for Web is set to 1400 x 934 as standard, but an image has been cropped, set the height on a cropped image to 934 and let the width float.
I finally settled on 1800 px wide and kept Quality at 30% to keep the files under 500 KB. Blog images would be 1400 KB.
I noticed when I redid a header image at 2000 px wide @ 60% it was 428 KB.
Links~
Best Image Size for Websites in 2025~ from tiny-img.
Photoshop Save for Web~ Good info from Cotinga.
Ultimate Guide to Website Images~ from CRO:NYX
Image Size Guidelines~ from the WP Imagely Theme.
Yellow Pencil Visual Style Editor~ Wordpress CSS style editor plugin.