The Two Things that I did to Optimize Image Delivery<\/h2>\n\n\n\n
Other factors being equal, the two things that matter the most for optimized image delivery are choosing the right format, and the right size.<\/p>\n\n\n\n
Serve the Right Format<\/h3>\n\n\n\n![\"\"](\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/serve-right-format-1024x585.webp\")
<\/figure>\n\n\n\nChoosing the right format is the first step to delivering optimized images. The wrong format can bloat your images, slow down your site, and frustrate users without improving image quality<\/strong>, even if the dimensions are perfect.<\/p>\n\n\n\nHere\u2019s the quick breakdown:<\/p>\n\n\n\n
\n- JPEG<\/strong> \u2013 Great for photos. Small file sizes, decent quality. Doesn\u2019t support transparency.<\/li>\n\n\n\n
- PNG<\/strong> \u2013 Perfect for images that need transparency or sharp edges. Photos and screenshots usually have larger file sizes than JPEGs, but flat vector illustrations with limited colors<\/strong> and no gradients<\/strong> can end up smaller if optimized<\/strong>. If you can use <\/li>\n\n\n\n
- WebP<\/strong> \u2013 The modern all-rounder. Almost always smaller files than JPEG or PNG, supports transparency, and is widely supported.<\/li>\n<\/ol>\n\n\n\n
In practice, WebP is excellent for most use cases<\/strong>. One limitation is that some image editors and software still don\u2019t support it as widely as JPEG or PNG but that’s changing fast.<\/p>\n\n\n\nLet\u2019s take the featured image of this post as an example. The original unoptimized JPEG<\/a> was 263 KB, while an optimized JPEG<\/a> came down to 87 KB with no noticeable loss in quality. The unoptimized PNG<\/a> was 541 KB, and the optimized PNG<\/a> dropped to 111 KB. The WebP version<\/a>? Just 41 KB.<\/p>\n\n\n\nSwitching from the original JPEG to WebP alone saved over 222 KB for a single image. Multiply that by 10 images in a blog post, and you\u2019re looking at roughly 2.2 MB savings<\/strong> just from using the right format.<\/p>\n\n\n\nServe the Right Size<\/h3>\n\n\n\n![\"\"](\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/different-sized-sceneries-1024x585.webp\")
<\/figure>\n\n\n\nServing a 3840px-wide image<\/strong> to a mobile visitor with a 480px-wide screen<\/strong> is a colossal waste of bandwidth. If the height scales proportionally, that\u2019s a 64\u00d7 increase in pixel count<\/strong>, and the file size will be much larger as well.<\/p>\n\n\n\nIdeally, visitors should only load images roughly the size they\u2019ll see. For example, if an image renders at 480px wide, that\u2019s the size you should serve. You don\u2019t need a perfect match. Just strike a balance between the required effort and the optimization benefits.<\/p>\n\n\n\n
On my site, I use up to eight different image sizes, but in some cases<\/strong>, just two sizes are enough<\/strong>. The key is to serve what\u2019s necessary without over-engineering.<\/p>\n\n\n\nYou can easily handle different screen sizes by using the <picture><\/code> tag or the srcset<\/code> attribute on <img><\/code> tags, allowing browsers to pick the most appropriate resolution automatically.<\/p>\n\n\n\nIt\u2019s important to note that even on large screens, smaller images can be more appropriate depending on the layout. For instance, my archive page cards display smaller featured images when the layout shifts to multiple columns with a sidebar on large screens.<\/p>\n\n\n\n
A careful developer keeps this in mind when setting up <picture><\/code> and <img><\/code> tags. Here\u2019s an example from my own site:<\/p>\n\n\n\n<picture>\n\t<source srcset=\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-320x183.webp\" media=\"(max-width: 360px)\">\n\t<source srcset=\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-460x263.webp\" media=\"(max-width: 520px)\">\n\t<source srcset=\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-640x366.webp\" media=\"(max-width: 720px)\">\n\t<source srcset=\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-800x457.webp\" media=\"(max-width: 767px)\">\n\t<source srcset=\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-640x366.webp\" media=\"(max-width: 991px)\">\n\t<img class=\"n-image-responsive n-round-x5\" src=\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-460x263.webp\" alt=\"\">\n<\/picture><\/code><\/pre>\n\n\n\nIn the previous section, I mentioned the full-size WebP image is around 41 KB.<\/p>\n\n\n\n
But on my site, I only need to serve a 460px version on larger screens because of how the theme is designed. That smaller image weighs just 8KB saving about 32KB per image. With 10 posts on an archive page, that\u2019s roughly 320KB saved per page load. On a slow network, that difference can be huge.<\/p>\n\n\n\n
And when a million people visit similar pages, that 320KB saved per page adds up to roughly 300GB of saved bandwidth<\/strong>, translating into substantial cost savings<\/strong>.<\/p>\n\n\n\nFor eCommerce stores, the impact is even greater.<\/strong> Imagine 50+ product images loading as users scroll through a catalog. Every saved kilobyte means faster pages, higher conversions and reduced costs<\/strong>.<\/p>\n\n\n\n\n\nHow Shopify and WordPress Handle Image Optimization<\/h3>\n\n\n\n
Shopify and WordPress both let you serve optimized images, but they approach it differently.<\/p>\n\n\n\n
Shopify<\/strong> does most of the work automatically. Uploaded images are converted to WebP for supported browsers, and multiple sizes are generated in roughly 100px increments. The browser picks the version closest to the visitor\u2019s screen based on the srcset<\/code> value. A developer still needs to pair this with appropriate sizes<\/code> value to get maximum benefit. You can deliver more targeted and optimized images using the picture<\/code> tag but that requires a developer (like me).<\/p>\n\n\n\nWordPress<\/strong>, on the other hand, gives you more control but also more responsibility. By default, it generates a few standard image sizes (thumbnail, medium, large), but to get more precise optimization, you often need plugins like Smush, ShortPixel, or WebP Express. These tools handle format conversion, resizing, and compression, but you have to install and configure them yourself.<\/p>\n\n\n\nIn short: Shopify is automatic and hassle-free<\/strong>, while WordPress is flexible but requires setup<\/strong>. Both can deliver fast images \u2014 it\u2019s just a question of how much manual work you want to do.<\/p>\n\n\n\n
\n\n\n\nI also take optimization a step further by running custom scripts to convert images to WebP, fine-tune compression, and create extra size variants when needed to make sure your site loads fast without sacrificing quality.<\/p>\n<\/div><\/div>\n<\/div><\/div>\n\n\n\n
How Much Difference Can it Make?<\/h2>\n\n\n\n
That depends on how unoptimized your current setup is.<\/p>\n\n\n\n
No Image Optimization at All<\/h3>\n\n\n\n
A typical archive page on my site shows 10 post cards, each with its own featured image. Serving full-size, unoptimized JPEGs adds up to around 2,630 KB<\/strong> of image weight. Properly sized and optimized WebP versions of the same images total just 80 KB<\/strong> which is about 97% less<\/strong> image weight for the page.<\/p>\n\n\n\nSome Optimizations Already in Place<\/h3>\n\n\n\n
If your images are already properly resized, switching to WebP<\/strong> can still cut file sizes by up to 50%<\/strong>.<\/p>\n\n\n\nIf you\u2019re already using WebP<\/strong> but not resizing correctly, the savings depend on how large the downloaded image is compared to its displayed size.<\/p>\n\n\n\nTips to Further Optimize Image Delivery<\/h2>\n\n\n\n
Optimizing size and format gets you most of the way there, but there are a few extra tricks that can squeeze out even more speed. The idea is simple: load what matters first, and delay everything else<\/strong>.<\/p>\n\n\n\nPrioritize Above-the-Fold Images<\/h3>\n\n\n\n
These are the images users see immediately when a page loads. For instance, your hero banners, logos, or key visuals. Because they appear first, the browser should treat them as high priority. Use fetch-priority=\"high\"<\/code> so the browser knows to load them immediately. This ensures your site feels fast right from the start.<\/p>\n\n\n\nLazy Load Other Images<\/h3>\n\n\n\n
Images further down the page, in carousels, or below-the-fold sections don\u2019t need to load immediately. Lazy-load these images using loading=\"lazy\"<\/code>. This cuts initial page weight, reduces bandwidth, and improves perceived speed.<\/p>\n\n\n\nThere are some caveats though. For example, carousels are a bit tricky. If you lazy-load carousel images, they often only start loading when the slide actually comes into view. This can cause a noticeable delay because the image might “pop in” a second after the slide appears.<\/p>\n\n\n\n
Lazy loading takes some effort and expertise to get right. This is where I can help you get maximum performance without impacting user experience<\/strong>.<\/p>\n\n\n\nFinal Thoughts<\/h2>\n\n\n\n
Get size and format right, prioritize above-the-fold images, lazy-load the rest and your site will feel noticeably faster for everyone. You can always hire me if you want to outsource all this to someone competent.<\/p>\n","protected":false},"excerpt":{"rendered":"
Let\u2019s be real. Nothing kills user experience faster than a website that drags its feet. And the biggest culprit? Images. Huge, unoptimized images. We all love big visuals, but your users don\u2019t love waiting for them to load. Why Optimized Images Should be a Priority Images usually make up the bulk of a page\u2019s weight, […]<\/p>\n","protected":false},"author":2,"featured_media":10142,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"class_list":["post-10095","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-case-studies"],"_links":{"self":[{"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/posts\/10095","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/comments?post=10095"}],"version-history":[{"count":28,"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/posts\/10095\/revisions"}],"predecessor-version":[{"id":10162,"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/posts\/10095\/revisions\/10162"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/media\/10142"}],"wp:attachment":[{"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/media?parent=10095"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/categories?post=10095"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/tags?post=10095"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
<\/figure>\n\n\n\nChoosing the right format is the first step to delivering optimized images. The wrong format can bloat your images, slow down your site, and frustrate users without improving image quality<\/strong>, even if the dimensions are perfect.<\/p>\n\n\n\n Here\u2019s the quick breakdown:<\/p>\n\n\n\n In practice, WebP is excellent for most use cases<\/strong>. One limitation is that some image editors and software still don\u2019t support it as widely as JPEG or PNG but that’s changing fast.<\/p>\n\n\n\n Let\u2019s take the featured image of this post as an example. The original unoptimized JPEG<\/a> was 263 KB, while an optimized JPEG<\/a> came down to 87 KB with no noticeable loss in quality. The unoptimized PNG<\/a> was 541 KB, and the optimized PNG<\/a> dropped to 111 KB. The WebP version<\/a>? Just 41 KB.<\/p>\n\n\n\n Switching from the original JPEG to WebP alone saved over 222 KB for a single image. Multiply that by 10 images in a blog post, and you\u2019re looking at roughly 2.2 MB savings<\/strong> just from using the right format.<\/p>\n\n\n\n Serving a 3840px-wide image<\/strong> to a mobile visitor with a 480px-wide screen<\/strong> is a colossal waste of bandwidth. If the height scales proportionally, that\u2019s a 64\u00d7 increase in pixel count<\/strong>, and the file size will be much larger as well.<\/p>\n\n\n\n Ideally, visitors should only load images roughly the size they\u2019ll see. For example, if an image renders at 480px wide, that\u2019s the size you should serve. You don\u2019t need a perfect match. Just strike a balance between the required effort and the optimization benefits.<\/p>\n\n\n\n On my site, I use up to eight different image sizes, but in some cases<\/strong>, just two sizes are enough<\/strong>. The key is to serve what\u2019s necessary without over-engineering.<\/p>\n\n\n\n You can easily handle different screen sizes by using the It\u2019s important to note that even on large screens, smaller images can be more appropriate depending on the layout. For instance, my archive page cards display smaller featured images when the layout shifts to multiple columns with a sidebar on large screens.<\/p>\n\n\n\n A careful developer keeps this in mind when setting up In the previous section, I mentioned the full-size WebP image is around 41 KB.<\/p>\n\n\n\n But on my site, I only need to serve a 460px version on larger screens because of how the theme is designed. That smaller image weighs just 8KB saving about 32KB per image. With 10 posts on an archive page, that\u2019s roughly 320KB saved per page load. On a slow network, that difference can be huge.<\/p>\n\n\n\n And when a million people visit similar pages, that 320KB saved per page adds up to roughly 300GB of saved bandwidth<\/strong>, translating into substantial cost savings<\/strong>.<\/p>\n\n\n\n For eCommerce stores, the impact is even greater.<\/strong> Imagine 50+ product images loading as users scroll through a catalog. Every saved kilobyte means faster pages, higher conversions and reduced costs<\/strong>.<\/p>\n\n\n\n Shopify and WordPress both let you serve optimized images, but they approach it differently.<\/p>\n\n\n\n Shopify<\/strong> does most of the work automatically. Uploaded images are converted to WebP for supported browsers, and multiple sizes are generated in roughly 100px increments. The browser picks the version closest to the visitor\u2019s screen based on the WordPress<\/strong>, on the other hand, gives you more control but also more responsibility. By default, it generates a few standard image sizes (thumbnail, medium, large), but to get more precise optimization, you often need plugins like Smush, ShortPixel, or WebP Express. These tools handle format conversion, resizing, and compression, but you have to install and configure them yourself.<\/p>\n\n\n\n In short: Shopify is automatic and hassle-free<\/strong>, while WordPress is flexible but requires setup<\/strong>. Both can deliver fast images \u2014 it\u2019s just a question of how much manual work you want to do.<\/p>\n\n\n\n I also take optimization a step further by running custom scripts to convert images to WebP, fine-tune compression, and create extra size variants when needed to make sure your site loads fast without sacrificing quality.<\/p>\n<\/div><\/div>\n<\/div><\/div>\n\n\n\n That depends on how unoptimized your current setup is.<\/p>\n\n\n\n A typical archive page on my site shows 10 post cards, each with its own featured image. Serving full-size, unoptimized JPEGs adds up to around 2,630 KB<\/strong> of image weight. Properly sized and optimized WebP versions of the same images total just 80 KB<\/strong> which is about 97% less<\/strong> image weight for the page.<\/p>\n\n\n\n If your images are already properly resized, switching to WebP<\/strong> can still cut file sizes by up to 50%<\/strong>.<\/p>\n\n\n\n If you\u2019re already using WebP<\/strong> but not resizing correctly, the savings depend on how large the downloaded image is compared to its displayed size.<\/p>\n\n\n\n Optimizing size and format gets you most of the way there, but there are a few extra tricks that can squeeze out even more speed. The idea is simple: load what matters first, and delay everything else<\/strong>.<\/p>\n\n\n\n These are the images users see immediately when a page loads. For instance, your hero banners, logos, or key visuals. Because they appear first, the browser should treat them as high priority. Use Images further down the page, in carousels, or below-the-fold sections don\u2019t need to load immediately. Lazy-load these images using There are some caveats though. For example, carousels are a bit tricky. If you lazy-load carousel images, they often only start loading when the slide actually comes into view. This can cause a noticeable delay because the image might “pop in” a second after the slide appears.<\/p>\n\n\n\n Lazy loading takes some effort and expertise to get right. This is where I can help you get maximum performance without impacting user experience<\/strong>.<\/p>\n\n\n\n Get size and format right, prioritize above-the-fold images, lazy-load the rest and your site will feel noticeably faster for everyone. You can always hire me if you want to outsource all this to someone competent.<\/p>\n","protected":false},"excerpt":{"rendered":" Let\u2019s be real. Nothing kills user experience faster than a website that drags its feet. And the biggest culprit? Images. Huge, unoptimized images. We all love big visuals, but your users don\u2019t love waiting for them to load. Why Optimized Images Should be a Priority Images usually make up the bulk of a page\u2019s weight, […]<\/p>\n","protected":false},"author":2,"featured_media":10142,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[23],"tags":[],"class_list":["post-10095","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-case-studies"],"_links":{"self":[{"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/posts\/10095","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/comments?post=10095"}],"version-history":[{"count":28,"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/posts\/10095\/revisions"}],"predecessor-version":[{"id":10162,"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/posts\/10095\/revisions\/10162"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/media\/10142"}],"wp:attachment":[{"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/media?parent=10095"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/categories?post=10095"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hellonitish.com\/blog\/wp-json\/wp\/v2\/tags?post=10095"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
Serve the Right Size<\/h3>\n\n\n\n
![\"\"](\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-webp.webp\")
<\/figure>\n\n\n\n<picture><\/code> tag or the srcset<\/code> attribute on <img><\/code> tags, allowing browsers to pick the most appropriate resolution automatically.<\/p>\n\n\n\n<picture><\/code> and <img><\/code> tags. Here\u2019s an example from my own site:<\/p>\n\n\n\n<picture>\n\t<source srcset=\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-320x183.webp\" media=\"(max-width: 360px)\">\n\t<source srcset=\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-460x263.webp\" media=\"(max-width: 520px)\">\n\t<source srcset=\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-640x366.webp\" media=\"(max-width: 720px)\">\n\t<source srcset=\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-800x457.webp\" media=\"(max-width: 767px)\">\n\t<source srcset=\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-640x366.webp\" media=\"(max-width: 991px)\">\n\t<img class=\"n-image-responsive n-round-x5\" src=\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-460x263.webp\" alt=\"\">\n<\/picture><\/code><\/pre>\n\n\n\nHow Shopify and WordPress Handle Image Optimization<\/h3>\n\n\n\n
srcset<\/code> value. A developer still needs to pair this with appropriate sizes<\/code> value to get maximum benefit. You can deliver more targeted and optimized images using the picture<\/code> tag but that requires a developer (like me).<\/p>\n\n\n\n
\n\n\n\nHow Much Difference Can it Make?<\/h2>\n\n\n\n
No Image Optimization at All<\/h3>\n\n\n\n
Some Optimizations Already in Place<\/h3>\n\n\n\n
Tips to Further Optimize Image Delivery<\/h2>\n\n\n\n
Prioritize Above-the-Fold Images<\/h3>\n\n\n\n
fetch-priority=\"high\"<\/code> so the browser knows to load them immediately. This ensures your site feels fast right from the start.<\/p>\n\n\n\nLazy Load Other Images<\/h3>\n\n\n\n
loading=\"lazy\"<\/code>. This cuts initial page weight, reduces bandwidth, and improves perceived speed.<\/p>\n\n\n\nFinal Thoughts<\/h2>\n\n\n\n
![original unoptimized JPEG<\/a> was 263 KB, while an](\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-original-unoptimized-jpeg.jpg\"){kind=link}
![optimized JPEG<\/a> came down to 87 KB with no noticeable loss in quality. The](\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-optimized-jpeg.jpeg\"){kind=link}
![unoptimized PNG<\/a> was 541 KB, and the](\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-unoptimized-png-1.png\"){kind=link}
![optimized PNG<\/a> dropped to 111 KB.](\"https:\/\/hellonitish.com\/blog\/wp-content\/uploads\/2025\/10\/image-optimization-case-study-optimized-png.png\"){kind=link}