Facades for Chat Widgets and Maps

Some third-party embeds are heavy for a reason: a live chat widget is a small application with its own framework, websocket connection and styles; an interactive map loads a tiling engine, vector data and fonts. On a static site, where the rest of the page might total 150 KB, one of these can add 400–800 KB and several hundred milliseconds of main-thread work — on every page view, for every reader, although only a few percent of readers ever open the chat or pan the map.

A facade loads the lightweight part that readers see — a chat button, a static map image — and loads the real embed only when a reader shows they want it. This guide builds facades for an Intercom-style chat widget and a Google Map on a static marketing site, warms them up on hover and focus so they feel instant, handles accessibility and consent, and measures the savings. It is part of Third-Party Script Performance on Static Sites, alongside Lazy-Loading YouTube Embeds on Static Sites.

Prerequisites

• An inventory of heavy embeds and how often readers use them (analytics events for opening chat, interacting with the map).
• The vendors' loader snippets and APIs.
• A consent mechanism, if the site needs one for third-party cookies.

What the Embeds Cost

Measured with Lighthouse (mobile, median of five) and the request-blocking method from Measuring Third-Party Cost with Request Blocking:

The chat widget alone accounted for most of the Total Blocking Time on every page, and its loader created a websocket and set cookies on page load.

Facade 1: The Chat Button

The facade is a button styled like the vendor's launcher, rendered in the static HTML with a few lines of CSS. The vendor script loads on first click — or earlier, when the pointer approaches the button or it receives keyboard focus:

<button type="button" class="chat-facade" aria-label="Open chat with support" hidden>
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24" width="24" height="24"><path d="M4 4h16v12H7l-3 3z" fill="currentColor"/></svg>
</button>
<script type="module">
  const btn = document.querySelector('.chat-facade');
  btn.hidden = false;
  let loading;
  const load = () => loading ??= new Promise((resolve) => {
    window.intercomSettings = { app_id: 'abc123', hide_default_launcher: true };
    const s = document.createElement('script');
    s.src = 'https://widget.intercom.io/widget/abc123'; s.async = true; s.onload = resolve;
    document.head.append(s);
  });
  btn.addEventListener('pointerenter', load, { once: true });
  btn.addEventListener('focus', load, { once: true });
  btn.addEventListener('click', async () => {
    btn.setAttribute('aria-busy', 'true');
    await load();
    window.Intercom('show');
    btn.remove();
  });
</script>

The button is hidden until the script runs, so readers without JavaScript do not see a control that does nothing; they get a "Contact support" link in the footer instead. hide_default_launcher stops the vendor from drawing a second button. After loading, the vendor's own launcher replaces the facade for the rest of the session.

On a desktop with hover warm-up, the chat panel opened 180 ms after click on a fast connection — faster than before, because the loader had already finished. On touch devices without hover, the first open took about 900 ms on 4G, shown with a loading state on the button.

Facade 2: The Map

The contact page embedded an interactive Google Map to show the office. The facade is a static map image generated at build time from the Maps Static API, stored in the repository and optimized like any other image, with a link that opens the map in a new tab and a button that loads the interactive map in place:

<figure class="map-facade">
  <img src="/img/map-berlin-800.avif" srcset="/img/map-berlin-400.avif 400w, /img/map-berlin-800.avif 800w, /img/map-berlin-1200.avif 1200w"
       sizes="(min-width: 48em) 40rem, 100vw" width="800" height="450" alt="Map showing our office at Torstraße 49, Berlin, near Rosenthaler Platz" loading="lazy">
  <figcaption>
    <a href="https://maps.google.com/?q=Torstra%C3%9Fe+49+Berlin" rel="noopener">Open in Google Maps</a>
    <button type="button" class="map-load">Show interactive map</button>
  </figcaption>
</figure>

Clicking the button replaces the image with the embed iframe at the same aspect ratio, so nothing shifts. Most readers only needed the address and a link to their own maps app, which the facade provides with one tap; 89% of views of the contact page never loaded the interactive map. Generating the static image at build time, rather than hotlinking the Static API, keeps the page free of third-party requests and lets the image pipeline serve AVIF at the right sizes.

Accessibility and Consent

Facades must be real controls. The chat facade is a <button> with an accessible name that says what it does, not "chat bubble icon"; aria-busy communicates loading; focus moves into the vendor panel after it opens, and the vendor's close button returns focus to the page. The map's alt text describes the location, which is the information the map conveys.

For consent, the facade is the natural place to ask. The site's consent banner covers analytics; for the map, the interactive button's first click shows a short inline notice ("Loading Google Maps sends data to Google") with confirm and cancel, and remembers the choice. No Google request happens before that. The chat vendor is covered by the site's privacy notice and loads only on explicit interaction, which the legal review accepted without a separate prompt.

Other Candidates for Facades

The same pattern applies to most embeds that are visible on load but used by a minority: social media post embeds (render the post text and author as static HTML at build time, load the vendor script on click), code playgrounds (show the code with a "Run" button that loads the sandbox), booking and calendar widgets (a styled "Pick a time" button), comment systems (a "Show 14 comments" button that loads the thread), and audio players from hosting platforms (a play button and duration from build-time metadata). Each one follows the same steps: measure how many readers actually use it, render a static stand-in that carries the useful information, load the real embed on explicit intent, and warm up on hover or focus where a delay would be noticeable. On this site, the comments embed on blog posts was the next facade after chat and maps; 6% of readers opened comments, and the blog template lost another 140 KB of JavaScript.

Measured Impact

Two weeks of field data and Lighthouse lab runs, before and after:

Chat usage did not fall — it rose slightly, possibly because pages became responsive sooner. The support team had worried that a facade would reduce conversations; the data settled the question.

Pitfalls & Rollback

• A facade that looks clickable before it works. Hide it until its script runs, and provide a no-JavaScript alternative.
• Double launchers. Tell the vendor not to render its own button until the facade hands over.
• Hotlinking static map images. That is still a third-party request; generate the image at build time.
• Missing required attribution. Keep the vendor's logo or notice where terms require it.
• Rollback: the facade is one component per embed; restoring the vendor snippet in the layout brings back eager loading.

Conclusion

Heavy third-party widgets used by a small share of readers should not load for everyone. Facades — a styled button for chat, a static image for maps — keep the page light and load the real embed on interaction, warmed up on hover and focus. On this site they removed over 300 KB of JavaScript from every page, halved INP and took the contact page's LCP from 3.1 s to 1.9 s, without reducing chat usage.

FAQ

What is a facade?

A lightweight static stand-in for a heavy third-party embed, such as an image of a map or a styled chat button, that looks like the real thing and loads the actual embed only when the reader interacts with it or clearly signals intent, such as hovering or focusing the element.

Does a facade hurt the experience for readers who use the widget?

Slightly, the first time: the real widget takes a moment to load after the click. Warming up on hover or focus, and showing a loading state, keeps that delay short. For the majority of readers who never use the widget, the page is much faster.

Are facades allowed by the vendors' terms?

Usually yes, as long as you do not misrepresent the vendor or bypass required notices. Map providers often offer a static image API meant for exactly this. Check the terms for attribution requirements and keep required logos and notices on the facade.

Do facades help with privacy and consent?

Yes. Because the vendor's script does not load until interaction, no third-party requests or cookies occur for readers who never use the widget, which simplifies consent requirements. The facade can also show a consent notice before loading.

Related

• Parent: Third-Party Script Performance on Static Sites — managing vendor scripts.
• Lazy-Loading YouTube Embeds on Static Sites — the video version.
• Measuring Third-Party Cost with Request Blocking — quantifying what facades save.
• Fixing CLS from Late-Loading Embeds — keeping the swap stable.
• Fixing CLS from Cookie Banners — consent UI without shifts.