Cloudinary q_auto and f_webp are supposed to shrink your images. You move your Blogger hero image to Cloudinary specifically to fix a slow LCP, and add these parameters to the URL exactly the way every optimization guide tells you to. Then you check the actual file size, and it's the same number it was before: 175 KB, for an image that displays at 600×400 pixels on the page. q_auto and f_webp are doing exactly what they're supposed to do. Your image is still too big anyway.
Here's the parameter nobody mentions, and why it's easy to miss specifically on Blogger.
Before you start: this assumes you've already uploaded an image to Cloudinary and you're pasting the resulting URL straight into Blogger's HTML editor, rather than using a plugin or SDK. If that's your setup, the transformation segment — the part between /upload/ and the filename, where q_auto and f_webp already live — is exactly where the fix below goes.
Why q_auto and f_webp don't shrink the file the way you'd expect
q_auto controls compression quality. f_webp (or f_auto) controls the file format. Neither one touches the pixel dimensions of the file Cloudinary actually sends to the browser. Without an explicit width instruction, Cloudinary delivers the image at whatever resolution it was uploaded at, quality-optimized and in a modern format, but still full-size — the same slow-LCP problem covered in Why Your Blogger Blog Isn't Showing on Google.
Cloudinary's own resizing documentation is direct about this: relying on the browser to shrink a full-size image down using CSS or HTML width and height attributes forces users to download a file that's larger than what they'll ever see, and images should be delivered from the server already at their final size. Their image optimization docs make the same point from the other direction: serving a properly resized image, separate from whatever quality and format savings q_auto/f_auto add on top, is itself one of the biggest wins available.
Most Cloudinary tutorials skip this because they assume you're using one of Cloudinary's SDKs, or a plugin, that automatically builds responsive srcset markup and picks the right width for each device. On Blogger, there's no plugin doing that for you. You're typing the transformation string directly into the HTML editor, one static URL, and nothing adds the missing width unless you do it yourself.
The fix: add an explicit width to the transformation
- Find the actual display size of the image in your theme, from the CSS or the width/height attributes on the
<img>tag itself. - Add
w_followed by that number into the transformation segment of the URL, alongside your existingq_autoandf_webp(orf_auto) parameters. - If you're also using a
<link rel="preload">tag for this image, update it to the exact same URL as the<img src>. A browser only uses a preload when its URL matches the resource the page actually requests, so the two have to be identical, width parameter included. - Confirm the result in Chrome DevTools, Network tab, with caching disabled. Don't judge this by eye. Look at the actual transferred size of the request.
%20(1).webp "Cloudinary image reduced to 87KB after adding w_600 parameter")
On this blog, the hero image went from a flat 175.3 KB (q_auto,f_webp, no width) down in two steps once the width parameter was added:
| Version | File weight |
|---|---|
Original (q_auto,f_webp, no width) | 175.3 KB |
w_750 | 132 KB |
w_600 (matches actual display width) | 87 KB |
Same quality setting, same format, same image. The only thing that changed between the first row and the last is one width parameter, and the file dropped by half.
The short version:
q_autoandf_auto/f_webpoptimize quality and format, not dimensions. If you're hand-writing a Cloudinary URL into Blogger's HTML editor, you have to add the width yourself, or you're serving the full-size original no matter how many optimization flags you stack on top of it.
One thing to watch while you're testing it
Once you've made this change, don't judge whether it worked from a single PageSpeed Insights score. Google's own Lighthouse variability documentation confirms that lab-based performance scores can shift noticeably between two runs of the exact same deployed code, purely from network and lab conditions. Trust the DevTools file size you measured directly. If you want a second confirmation, run the page through PageSpeed a few times and look at whether the trend moves in the right direction, rather than treating any single run as final.
Does q_auto reduce file size at all on its own?
Yes, but only through compression and format selection, at whatever dimensions the image already has. It won't shrink a 1200×800 upload down to the 600×400 the page actually displays.
What width value should I use?
Match it to the largest size the image is actually displayed at in your theme, usually the desktop width from your CSS or the <img> tag's width attribute. Going smaller than that will make the image look soft on larger screens.
Do I need to update the preload tag too, or just the img tag?
Both, and they need to match exactly. A preload pointing at a different URL than the actual <img src> just adds a second download instead of speeding up the real one.
Will this affect my Cloudinary bandwidth or transformation limits?
It should reduce bandwidth usage, not increase it. You're now delivering a smaller file per request instead of the full-size original, and Cloudinary caches each transformed version after the first request.
That's the whole fix — one width parameter, no plugin, no rebuild. If your Blogger images are still sluggish after this, the bottleneck is probably somewhere else: a missing loading="lazy" on offscreen images, or a preload tag pointing at the wrong file. Worth checking those next.
More Blogger technical diagnostics on this blog: Why Your Blogger Blog Isn't Showing on Google, and I Lost 20 Indexed Pages on Blogger. Here's Why.
.webp)
.png)
0 Comments