When trying to speed up a slow website, most creators jump straight to image compression plugins or format conversion. Those tools help, but they miss the most critical step: resizing images before uploading them. Uploading a 4000-pixel-wide photo and letting HTML or CSS shrink it on the page wastes server bandwidth and slows down mobile visitors, even after you've compressed the file.
Hey, Welcome back to BytebaseX. I'm Suptojit Modak, and in this post of Image Optimization series, I'll explain how to properly resize images before uploading them to your website. We'll look at display dimensions versus file size, recommended pixel dimensions for web assets, and why resizing before upload directly improves your Largest Contentful Paint (LCP) score. If you missed the previous post on Lossless vs Lossy compression, you can read it here.
Dimensions vs File Size: Understanding the Difference
Image dimensions mean the physical width and height of an image, measured in pixels (for example, 1920 × 1080 px). File size means the storage space the image takes up on a drive or server, measured in kilobytes (KB) or megabytes (MB). These two are related, but they're not the same thing, and mixing them up is why a lot of "compressed" images still load slow.
When you scale down the pixel dimensions of an image, you cut the raw data it contains by a lot, before you even touch compression. Shrinking an image from 4000 px wide to 1200 px wide often reduces the raw payload by 70% to 80% on its own.
Standard Image Dimensions for Websites in 2026
To keep page layouts fast and responsive, match your uploaded image dimensions closely to the maximum container width of your site layout. Serving images larger than their display container forces the visitor's browser to download extra data and downscale the file on the fly, which wastes bandwidth for no visual benefit. Use this table as a starting point.
| Image Placement | Recommended Dimensions | Target File Size |
|---|---|---|
| Blog Featured / Hero Images | 1200 × 630 px | Under 100 KB |
| In-Article Screenshots / Diagrams | 800 px (max width) | Under 70 KB |
| Sidebar / Grid Thumbnails | 300 × 300 px (or 400 × 250 px) | Under 30 KB |
| Site Logos & Favicons | 512 × 512 px (favicon) / 250 px width (logo) | Under 20 KB |
CSS Resizing vs Actual Pre-Upload Resizing
A common mistake is using inline attributes like width="800" or a max-width rule in your stylesheet to shrink a huge file visually. This keeps the page looking fine on desktop or mobile, but it doesn't reduce what actually travels over the network.
The browser still downloads the full, oversized file before applying any CSS rule to render it smaller. So a 4000 px image displayed at 800 px through CSS still costs your visitor the same download time as the full 4000 px file. Resizing the actual source file before upload is what changes that, since the network then only transfers what is visually necessary.
How to Resize an Image Before Uploading
You don't need design software for this. A few simple tools cover almost every case:
- Squoosh: lets you resize and compress in the same step, with a live before-and-after preview so you can check the result before downloading.
- Preview (Mac) or Paint (Windows): built into your OS, good enough for a quick one-off resize when you don't want to open another tool.
- ShortPixel or Image Resizer plugins: useful if your CMS lets you set a maximum upload width, so every image gets resized automatically the moment you upload it.
For Blogger, there's no automatic resize step on upload, so you need to resize the file on your device first, then run it through compression, before uploading it to a post.
How to Fix the "Properly Size Images" Warning in PageSpeed Insights
When you run a speed test on Google PageSpeed Insights, one of the most common warnings under performance is "Properly size images." This warning shows up when the size an image is actually displayed at on screen is much smaller than the pixel dimensions of the source file you uploaded. As a general rule, serving an image at roughly 2x its rendered display size is enough to look sharp on most phone and laptop screens; anything beyond that just adds file weight without a visible difference.
Fixing this warning brings a few direct benefits:
- Lower LCP (Largest Contentful Paint): smaller file payloads let hero images above the fold render faster.
- Reduced memory usage: mobile devices need less RAM and CPU power to decode smaller image dimensions.
- Saved bandwidth: less data used for visitors browsing on mobile data instead of Wi-Fi.
A Simple Pre-Upload Workflow
Once you have the right dimensions and the right tools, the order you do things in matters too. Follow this workflow every time you prepare an image for a post:
- Crop unnecessary areas: remove extra background or empty canvas space from the image first.
- Resize pixel dimensions: scale the width down to match your site layout, for example 1200 px for featured images, 800 px for inline body images.
- Compress and convert: apply lossy compression and convert the output to WebP.
- Upload and add alt text: upload the final, lightweight file to your site editor.
Doing this in order matters. If you compress a 4000 px image first and resize it after, you've already spent the bandwidth savings on a file size that gets thrown away anyway.
Conclusion
Resizing images before uploading, to their actual target display dimensions, is the most effective way to stop wasting payload on your site. Compression and format conversion work best when they start from a correctly sized file, not a massive high-resolution original that gets shrunk after the fact.
This post is part of the ongoing Image Optimization series on BytebaseX. In the next guide, I'll cover how to fix the "Serve Images in Next-Gen Formats" warning in PageSpeed Insights.
