This is the one I keep having to relearn. I’ll be rushing a post, drop in a 3MB PNG from a client’s logo pack, and suddenly, the mobile version of the blog is crawling like it’s 2010 on a $4 prepaid plan. Blogger will technically let you upload massive images. That doesn’t mean it should.
The trick isn’t just resizing before upload. Blogger compresses them, yes — but not well. That stuff still ends up in the page’s source DOM, bloating everything unnecessarily. Swap to WebP before uploading. I use a janky local script on my Mac:
for f in *.png; do
cwebp "$f" -q 80 -o "${f%.png}.webp"
done
I also figured out Blogger randomly serves different image resolutions depending on where you upload from — if it’s uploaded through the Blogger image widget, you get one URL structure; if it’s inserted via Google Photos integration, it’s another. That randomness makes cache control a losing game unless you’re watching the source like a hawk.
Avoid uploading directly from mobile. I tried it once at a Starbucks and ended up with an 8MB moon photo somehow injected into my mobile homepage carousel. Took ages to find where it was hiding because Blogger obfuscates image URLs if they’re uploaded through mobile—not reflected in post source.
Split Static Assets Into a Separate Drive Folder
I stopped attaching media directly into Blogger posts years ago. Instead, I store everything in a dedicated Google Drive folder shared publicly, and embed using <img src=""> with generated public links. It’s not elegant, but it’s faster than trying to reverse-engineer Blogger’s internal media library structure.
This completely neuters Blogger’s image compression (which is usually a plus), and gives you actual control over image sizes, cache headers (if routed smartly), and folder organization — Drive folders let you vaguely simulate a content management system when Blogger won’t. Just don’t count on Drive thumbnails staying active forever — Google quietly throttles public Drive image links if they get too many hits per hour. No official threshold, of course, just silent image 403s for a bit.
If you’re even semi-serious, route Drive image links through a free Cloudflare Worker so you can cache them. I’ve got one that just:
with a cache rule slapped on. Not beautiful, but it shaves a ton of load time if your readers are mostly mobile or international.
Don’t Rely on Blogger’s Mobile View Compression
I learned the hard way that Blogger’s built-in “mobile version” doesn’t do any real image optimization. It reflows the layout, sure, but your media still loads in its original resolution unless you’ve explicitly resized in a container or post editor. So your cute 200px blog header is actually loading as a full-width 1920×1080 image on every mobile view. I found that with Chrome DevTools while debugging load times — image request size was 1.8MB, despite it being displayed at like 300px wide.
There’s no toggle for this. You have to use inline style="max-width:100%; height:auto" or resize images manually before upload. Yes, even in 2024. The compression Blogger applies is more like a handshake agreement — sometimes it kicks in, sometimes it doesn’t. Cached hard. Real annoying when testing.
Here’s a weird one: if you embed an image, then add a caption via Blogger’s caption UI, the image loads from a different endpoint than without a caption. That version? Less compressed, and doesn’t seem to play nice with lazy loading. No documentation on that, naturally.
Avoid The Blogger Media Library Trap
It took me years to learn this structure isn’t maintainable: if you upload images through Blogger itself, the URLs are tied to Picasa web albums (yes, still, under the hood) or Google Photos backend. And they’re not even <emdirectory-consistent. You’ll see references like:
If the encoding logic ever changes — and once every couple years, it does — old embedded media can first slow way down, then just break entirely. Happened to me in 2022 when around forty thumbnails just stopped loading randomly across ten posts. They were all tied to an older Blogger-Picasa bridge logic that quietly deprecated.
There’s no reliable downloader or bulk archiver for media inside Blogger. Once it’s uploaded and embedded, it’s cloaked. My ugly workaround was loading all post HTML exports into a parser, regexing out the image URLs, and attempting to scrape a copy before Google killed the CDN-path. Do yourself a favor and start storing externally — even a free Imgur album gives you saner permanence.
The One Greasemonkey Script That Fixed Inline Preview Bugs
Here’s a weird behavioral bug that only happens when you’re previewing a post with images sourced from Google Drive in an incognito tab. The inline preview strips domain tokens and redirects some images through an internal proxy (labeled gvt1), which then fails on first load. On repeat views? It works fine. No mention of this anywhere in Google documentation.
I slapped together a Greasemonkey script years ago — still use it — that checks if the image is from Drive, and if so, re-injects the public preview token after the page loads. No magic or optimization, just a hack because Google’s proxy sometimes eats its own routing.
That saved me from mis-diagnosing my post renders dozens of times thinking load times were my fault when it was just Blogger eating cookies again during preview mode.
Bulk Media Renaming Saves Searchability
I know, nobody wants to think about this when they’re posting three times a week, but seven months from now, when you’re trying to find that illustrated cat GIF from the coffee review post in June, you’re screwed if every file is named IMG_2023-06-25_22-51-19.png.
What I do now — yes, after years of doing it the wrong way — is name every asset with a triple-token pattern before uploading:
That way, when I’m spelunking through the folder at 2AM trying to find the post banner from that failed mobile template experiment, I have at least a prayer. Especially helpful if you’re versioning local images and later syncing to Drive or S3.
Notably, Drive search (and even Blogger’s own internal search) doesn’t index image content or tag structure — it’s pure filename. So unless your older self left breadcrumbs, you’re toast.
Embedding from Third-Parties Still Beats Blogger’s Tooling
Look, I tried to stick to the built-in image/video tools for six months. They break. Randomly. A YouTube embed loads fine in preview. A day later, it vanishes on mobile but works on desktop. Images stall during lazy load but only on Firefox. Blogger support? Radio silence. There’s no roadmap anymore.
I started shifting embeds to basic iframe wrappers where I control the source. Worked better with audio especially—Blogger’s integration with Google Drive + audio is entirely broken post-2022. You’ll get a play button that does nothing unless the visitor already has that file cached into their Google profile somehow.
It’s annoying, yeah. But if you slap a <video> wrapper using a public Cloudflare R2 file or something similar, it just plays. Fast. Reproducible. Doesn’t eat up Editor RAM or fail silently when tokens expire.
If you’re not feeling that level of jankiness, even hosting stuff on PastePixel or Dropbox and hotlinking works more reliably than trusting the Blogger post UI.
