Outlook blocks images by policy—header preloads bypass it
The office is quiet at 6:14 a.m., coffee still too hot to drink, inbox count climbing faster than you’d like. Half your readers open email in Outlook, where images stay hidden until someone clicks “Download pictures”. Your header logo loads anyway. Here’s why.
Outlook blocks external images by default—but preloaded headers slip through
Image-blocking settings don’t treat every image equally—some load before the user decides.
Outlook’s default security posture blocks external images to prevent tracking pixels and malicious content. That policy applies to hero images, inline photos, and most visual assets you embed in a newsletter. But header logos and certain above-the-fold images often load immediately, even when the recipient hasn’t clicked “Download pictures”. The difference comes down to preloading logic—browsers and email clients fetch small, critical assets early to improve perceived performance, and Outlook’s blocking rules don’t always catch them.
Preloading works when images are referenced in specific HTML attributes (like src on an <img> tag positioned at the top of the document structure) and fall below a certain file-size threshold. Outlook’s block applies after the preload request has already fired. That means your 8 KB header logo might render instantly, while your 120 KB hero image stays hidden behind a placeholder. The behaviour isn’t consistent across Outlook versions—desktop, web, and mobile clients handle preload differently—and it changes when recipients adjust security settings or use cached sessions. If you’re designing transactional emails or time-sensitive alerts, understanding which images preload and which don’t determines whether your branding appears or your message lands in a visual void.
The practical takeaway: test your templates in Outlook with images blocked, measure which assets actually render, and optimise file size and placement for the elements that matter most. If your header branding depends on an image that won’t preload, consider text-based fallbacks or inline SVG. If your call-to-action lives inside a blocked hero, move it into HTML text with a styled button.
TACTIC
Page caching breaks the parts of your site that change per visitor
Caching plugins speed up WordPress by serving static HTML to every visitor—but that means personalised greetings, logged-in user menus, and dynamic email opt-in forms all break unless you exclude them. Most operators discover the problem only after a subscriber complains they’re still seeing a default navigation bar despite being logged in, or when A/B test variants stop rotating. The fix requires cache exclusion rules for specific page elements, and every plugin handles the syntax differently. WP Rocket, W3 Total Cache, and LiteSpeed Cache each use separate methods to carve out dynamic content, and misconfiguring one can tank your page-load speed or silently serve stale data.
WORTH READING
Social scheduling tools hit rate limits per account, not per app
When your Buffer or Hootsuite workflow stops posting to Instagram, the error message blames “rate limits”—but the cap isn’t on the scheduling app, it’s on your Instagram account. Platforms like Twitter, LinkedIn, and Facebook enforce per-user thresholds that apply to all apps you’ve authorised, so connecting three different scheduling tools won’t triple your posting capacity. The limit resets on different schedules depending on the platform, and exceeding it can trigger temporary bans or force you into a 24-hour cooldown. If you’re running client accounts through a single scheduling dashboard, each client’s limit is separate—but if you’re cross-posting your own content through multiple tools, you’re burning through one shared bucket.
FROM THE ARCHIVE
Google rewrites most meta descriptions—here’s when to bother writing them
You spend fifteen minutes crafting the perfect meta description for your latest post, then watch Google replace it with a sentence pulled from paragraph three. Research shows Google rewrites roughly 63 per cent of custom meta descriptions, especially when the query doesn’t match your chosen snippet or when your description is too long, too short, or stuffed with keywords. The rewrite isn’t random—Google prioritises text that directly answers the searcher’s intent, so pages targeting transactional queries (buy, download, sign up) see higher rewrite rates than informational ones. The practical advice: write meta descriptions for high-value landing pages and transactional posts, skip them for blog archives and category pages, and always include the target keyword early in the body text where Google’s algorithm can find it.
Know someone who would like this? Forward today’s email — every operator we reach is one closer to running an online business with a little less friction.