If you think all the lag is coming from your images or AdSense snippets… I have bad news. Google’s own default Blogger themes inject a pile of layout CSS, external fonts, and widgets you didn’t even enable. I once speed-tested a clean Blogger setup and found 90+ HTTP requests firing before anything I added. Scroll to the footer of most Live on Blogger blogs — half the widgets are untouched, but their scripts still load.
The most egregious one? That stupid LinkWithin-style related posts widget. Turn off gadget visibility in Layout and it’ll still be served if the theme includes it hardcoded. You can usually comment it out in the template editor under <b:if cond=... where it auto-inserts after posts. If you’ve got <b:include data='post' name='postQuickEdit'/> hanging out in every loop iteration, get rid of it unless you actually use Blogger’s post hover-edit buttons.
Oh, and you don’t need <b:skin> generating inline CSS unless you’re designing inside Blogger itself. Inline fonts, in particular, get declared twice if your theme imports Google Fonts AND the gadget area adds it again dynamically. Remove one layer or define your own in the template head.
Image Hosting Outside of Blogger’s Ecosystem
Blogger auto-optimizes images in unpredictable ways. Sometimes it resizes and recompresses images you upload via the post editor… but not in a helpful way. If you host a retina-quality JPEG, it might squash it down to a 1600px WebP that suddenly blurs on scroll — but only when coming from Drive-transferred accounts.
I shifted most static background and logo images to Cloudflare R2 + Email Workers with fixed URL routing — mostly to avoid Blogger’s lazy unpredictability. Bonus: external hosting doesn’t get hit with the data:image/webp;base64 inline injection nonsense Blogger sometimes adds when it reencodes images for AMP themes. That one took me two hours to trace; I just suddenly had 150KB base64 blobs showing up in the HTML inspector randomly after making no theme edits.
What’s Actually in main.js and How to Skip It
This needs more attention because main.js on Blogger themes does a stack of unnecessary things. Form validation (when you don’t have a comment box), lazy-load placeholders that fire too early, and scroll events that break on touch devices. You can’t directly remove main.js without breaking syntax highlighting or nav buttons… unless you inline your own minimalist fork.
I once copied the main.js file from my Blogger blog, reduced it to 15 lines removing debounce and initGadget widgets, and saw page load improve by around half a second. Took some trial-and-error since Blogger sometimes regenerates it on save.
If you’re using themes like Contempo or Soho: you’ll want to kill the dynamicViewsScripts() function directly inside the <script> area of the template. It’s not documented, but removing that hard-references eliminates most of the AJAXy redraw lag.
Fonts in Blogger Are a Disaster. Hardcode Them.
If your page is rendering slow on first load, check Fonts. No, I mean it. Go to Chrome DevTools > Network tab and sort by transfer size. Fonts almost always top the list. Even if you choose a simple body font in Blogger’s editor like Roboto or Lato, Blogger injects not just one but three variants: regular, bold, italic, plus sans fallback logic that re-invokes the CSS when missing.
Override theme font imports manually in <head> to pick a single weight/style combo
Use font-display: swap in your CSS so browser doesn’t wait
Host fonts yourself on GitHub RAW or IPFS if you really care
Avoid ‘header-font’ and ‘body-font’ split gadgets unless necessary—those each trigger additional font loads
Also: Modern Blogger themes include Noto Sans and Droid Serif by default in multiple languages — remove those unless you actively serve a multilingual audience
One eye-opener: removing <link href=...fonts.googleapis.com/css?family=Noto+Serif:&700&subset=latin,greek"> saved 300ms even on my local network.
Removing Jump Break Thumbnail Preloading
The weirdest behavior I ran into: Blogger preloads thumbnail previews for every jump break post within the homepage list, even if the full image is never rendered. Digging through the HTML, Blogger encodes a JSON blob of visible thumbnails server-side — then JS resolves those to force-load imgsrc versions from Blogger CDN, where they still perform dynamic resizing per device.
You can’t disable it via Layout. The fix? Edit the <b:loop values='data:posts' var='post'> block and kill the preview image snippet entirely. This breaks some homepage post listing views, but if you’re only using text excerpts or titles, it avoids spikes in CLS (Cumulative Layout Shift).
I once had CLS go from 0.4 down to 0.03 just from this tweak alone. And that was on mobile view. If your Lighthouse scores are random even with no content changes, this thumbnail system is probably to blame.
AMP Toggle Isn’t a Toggle — It’s a Separate Template System
Blogger has an AMP option that shows up in the Settings panel. Turning it off doesn’t remove AMP rendering. Guess what? A lot of Blogger templates still define an amphtml alternate link in the header, and Googlebot seems to respect it if it was ever on once — meaning your site may be showing busted AMP versions long after you ‘disabled’ them.
This behavior isn’t documented anywhere officially, but you can observe it by visiting ?amp=1 on your Blogger URL after turning AMP off. If you see the site render, it’s still active under the hood. You’ll have to remove any <link rel="amphtml" ...> in the template and pray Google recrawls it properly.
Worst-case scenario: I saw AMP versions rank for my index pages even though I’d switched to custom domains and toggled AMP off. Google Search Console still considered the AMP pages canonical for weeks.
Caching Isn’t Happening Like You Think It Is
If you’re relying on browser caching to speed up repeat loads, Blogger quietly defeats it in several stupid ways:
They inject fragment identifiers (stuff like ?w=640) in image links that force re-request
The template script URLs sometimes include cache-busting hashes even if content doesn’t update
Your favicon? Blogger re-serves it via a dynamic redirect that’s not persistent between sessions
A simple ‘aha’ moment: using Chrome’s devtools audits tab, the site flagging “no caching headers” turned out to be because I accidentally left the contact form widget enabled. That one widget loads from pagead2.googlesyndication.com even if you’re not showing ads at the moment… and it has no cache headers at all.
Custom Domains with HTTPS: Blogger DNS Panel Lies
This one still annoys me. When you connect a custom domain (say via Namecheap or Cloudflare), Blogger claims you’re updated once the DNS matches their A and CNAME values. But there’s a 6-24 hour propagation latency where your custom domain URL redirects but doesn’t serve HTTPS — and you can’t tell from the Blogger UI. It gives a happy green checkmark, but Chrome screams ‘Not Secure’.
During that DNS switchover period, Blogger serves a blank redirect with no cert while gradually provisioning SSL. It starts resolving on www. first, then root, then Mobile. I once sat refreshing my phone hourly for six hours wondering why only desktop Chrome worked. No logs, no error messages, no retry options — just eventual success.
If you’re connecting a new custom domain and care about speed + TLS, monitor it externally with a third-party HTTPS checker (like Uptrends) to verify certs start propagating.
AdSense Code Stability in Blogger Is a Jigsaw Puzzle
Don’t expect stable placement for AdSense. Blogger isn’t consistent about how often it re-wraps your custom HTML blocks on save, so direct code insertion into HTML View can cause encoding issues. I had an adsbygoogle.js block silently disappear because Blogger re-escaped a single ampersand inside a script tag. No error; it just didn’t inject the container at all.
Also: when you place auto ads, Blogger injects ad code after your layout is rendered — meaning above-the-fold scoring can tank if there’s no room left. AdSense will silently remove its own block if there’s less than 320px vertical space left. That’s why sometimes your top ad disappears without warning — the div’s technically there, but AdSense bails at render time.
If you’re placing ads manually, keep at least 400px height on div containers — and avoid float-based wrappers, because the script sometimes skips floated positions as invalid.
