Maps, Chat and Embeds: Load Them Only When Wanted

A map on the contact page, a chat bubble in the corner, a booking widget, an Instagram feed in the footer. Each is genuinely useful to some visitors. But on many sites they load in full for every visitor, the moment the page opens, whether or not anyone looks at the map or starts a chat. This article explains how to keep these tools while loading them only for the people who want them.

What an embed brings with it

An embed is a window onto another company's service, usually an <iframe> or a script. It brings its own code, styles, images and fonts. Google's guide to third-party embeds says “many popular embeds include over 100 KB of JavaScript, sometimes even going up to 2 MB”, and that lazy loading a YouTube embed can save about 500 KB on the initial page load.

A carbon test counts these files like any others. GreenTracer measures one initial, uncached load of the page with Google PageSpeed Insights, without scrolling or clicking. So an embed that loads straight away is counted, and one that waits for a scroll or a click is not. Under the Sustainable Web Design Model v4, every 500 kB removed from that first load lowers the estimate by about 0.074 g CO₂e per page view (about 0.061 g on a host listed as green).

Waiting for a click is not a trick to flatter the test. Visitors who open the map or the chat still download it. Everyone else, often most visitors, no longer does. If an embed is held back by your cookie banner rather than by a click, our article on cookie banners, tags and your carbon test covers that separately.

Lazy iframes: wait until they are near

The simplest change is one attribute. Adding loading="lazy" to an iframe tells the browser to wait. MDN describes it as deferring the iframe “until it reaches a calculated distance from the visual viewport”, and web.dev reports support across the major browsers (Chrome 77, Edge 79, Firefox 121, Safari 16.4).

<iframe src="https://…" title="Map of our shop"
  width="600" height="400" loading="lazy"></iframe>

• Use it for embeds further down the page. A map in the footer or a video halfway down is a good fit. An embed at the very top will be near the viewport straight away, so it gains little.
• It still loads for anyone who scrolls past. Lazy loading saves data for visitors who never reach the embed, not for those who do.
• It needs JavaScript. MDN notes that loading is only deferred when scripting is enabled, as an anti-tracking measure.

Facades: a preview until someone clicks

A facade goes further. Google's Lighthouse guidance, “Lazy load third-party resources with facades”, describes it as a static element that looks like the embed but isn't functional. The real embed loads only when the visitor interacts with it. The guidance names video players, social buttons and chat widgets as candidates, and lists ready-made options such as lite-youtube-embed for YouTube and react-live-chat-loader for chat.

One update worth knowing: Lighthouse 13 removed the automated facades audit. The release notes say it covered a limited set of facades and that Google would prefer third parties to improve their own embeds. So a recent PageSpeed Insights report may not flag facade opportunities, but the pattern itself is unchanged.

The guidance is also honest about trade-offs. A facade doesn't have every feature of the real embed: a chat preview may not show a new-message badge, and video autoplay may not work reliably. Visitors need one extra click, and there can be a short wait while the real tool loads.

Maps, chat, booking and social posts

• Maps. web.dev suggests that a static image can replace a map embed where the map doesn't need to be interactive. Show an image of the map with your address and a “Open in Google Maps” link or a “Show interactive map” button.
• Chat widgets. A look-alike button in the corner can load the real widget when someone hovers over or clicks it, the approach web.dev describes for react-live-chat-loader. Ask your chat provider whether they offer a delayed or click-to-load option before building your own.
• Booking tools. If the full calendar sits on every page, consider a clear “Book now” button that opens the booking tool, or keep the embed only on a dedicated booking page. People who want to book are one click away, and everyone else skips the download.
• Social posts and feeds. web.dev notes that an Instagram embed can be over 100 KB gzipped and that Facebook's plugins have a data-lazy setting. A feed of several posts multiplies that. A simple “Follow us” link, or a few of your own optimised images linking to the account, often does the same job.
• Video. A poster image with a play button is the classic facade. The Lighthouse guidance lists several ready-made components for YouTube and Vimeo.

Check what changed

1. Before changing anything, open the page in a private window with Chrome DevTools' Network panel open, tick “Disable cache” and reload. Note the transferred total at the bottom.
2. Make one change at a time, for example the map, and reload to see how much the total falls.
3. Click the facade to check the real embed still loads and works, on a phone as well as a desktop.
4. Check the page again and compare the bytes measured in the new report with the old one. The report keeps earlier checks as history.

If your mobile and desktop results differ a lot after the change, images are the usual reason; see why desktop and mobile results differ.

Sources

• web.dev: best practices for using third-party embeds
• web.dev: it's time to lazy-load offscreen iframes
• MDN: the iframe element (loading attribute)
• Lighthouse: lazy load third-party resources with facades
• Chrome for Developers: what's new in Lighthouse 13
• Sustainable Web Design: estimating digital emissions (SWDM v4)