Web design, CMS and development, since 2014VR Games
Guides

Lazy Load YouTube & Map Embeds to Keep Your Site Speed

Just one YouTube embed can add 18 requests and 1.8 megabytes to your page load. Lazy loading techniques can bring this down to 2 requests and 2 kilobytes, by deferring the video until close to playback. Using clickable thumbnails as placeholders further saves weight, and keeps performance measures like core web vitals. Let's deal with a website that slows after adding a YouTube or map embed.

When “Just One Embed” Breaks Your Page Speed

YouTube and map embeds are a common performance bottleneck. One practical test shows that loading a YouTube video iframe on page load produces 18 network requests and maxes out page weight at 1.8 megabytes. In contrast, lazy loading that same embed lets the initial load hit the page with only 2 requests and 2 kilobytes–a more than 700 times reduction.

[A recent Chrome study confirmed these concerns. The research found that lazy loading offscreen iframes for data-saver users reduced median data usage by 2-3%, and stepped up first contentful paint by 1-2% -- improving first input delay by 2% at the 95th percentile.]

Since 2021, all modern browsers support native lazy loading for iframes. Just adding loading="lazy" to the <iframe> element will defer the iframe’s loading until it comes near the viewport. This gives an immediate boost to largest contentful paint time, as well as interaction to next paint, provided you have reserved layout space for where the video or map will appear.

However, iframes are heavy. Chrome’s study found that native iframe lazy loading brings only modest performance gains: 2-3% median data savings, a 1-2% step-up in first contentful paint at the median, and a 2% improvement in first input delay—the time from user action to painting—at the 95th percentiles of distribution, only.

In fact, native lazy loading doesn’t even cut the load; its main impact is deferring the cost of load until the iframe is close to the viewport. Once the video or map is about to display, all the scripts, connection setups, and main-thread activities it kick-starts will still take place. And if the heavy third-party iframe is in a high-traffic area like above the fold, players like YouTube will benefit not at all from loading="lazy".

Native Lazy-Loading: What loading="lazy" Actually Buys You

In 2021, Chrome established iframe lazy loading for data saver users. Adding the loading="lazy" attribute to the <iframe> element will delay loading an embedded YouTube video or map until the iframe comes near the user's viewport. This simple, one-line fix substantially reduces the initial network request count and the first contentful paint time, as well as Core Web Vitals interaction to next paint time. But only for embeds below or far from the fold.

Chrome’s research indicates that deferring offscreen YouTube embeds like this brings a 2-3% improvement in median data usage, a 1-2% boost in first contentful paint, as well as a 2% improvement in first input delay.

Wide reserved space for where the iframe will later appear is a crucial part of this benefit. A Fudge.ai guide notes that a facade on a YouTube video or Vimeo clip—that is, an embedded thumbnail image and play button that only attaches the iframe when clicked—de-executes all the iframe's network requests, avoiding the 200 kilobyte or more in weight often added by the iframe and its scripts. But you have to match up the placeholder's width and height to the iframe, to reserve this space and prevent it causing layout shifts—or CLS.

And finally, if positioning the heavy iframe above the fold on your page, it won't see any benefit at all from loading="lazy". Remember, Core Web Vitals is all about the critical rendering path, and loading="lazy" doesn't do anything for iframes in the initial rendering. An above-the-fold player will still see all its scripts and resources loaded on page launch, without any performance benefit from native lazy loading.

Facade Patterns: Thumbnails First, Players on Demand

A facade is a way of showing an embedded video or map only on user action. In effect, the template displays a playback thumbnail. When users click to play the video or access the map, the facade pattern replaces the image with the actual iframe. This approach saves on load—both in bytes as well as delay—and waiting time. Load time is the time before any part of the page appears, while time to interact is the time before users feel in control and start interacting with the page.

SSW confirms that lazy loading is the simplest implementation, but that facades are the best for performance. Fudge.ai reported that facade patterns saved upwards of 200 kilobytes in script weight over native lazy loading, while a Block81 case study reported that users on mobile saw a 39% improvement in performance when videos were shown as images until playback was started.

Thumbnails with click handlers are used in implementations. Stack Exchange recommends replacing iframes with images and binding an onClick handler to the thumbnail, injecting the embed only on user click. Intersection observers are also used: rounding down when an iframe is about to become visible in the viewport.

If you use the facade pattern, suggest using "privacy-enhanced" player URLs, like YouTube’s no-cookie domain. Privacy modes disable some tracking and communications set up by the iframe, but their specific impact on performance has not been established. Only privacy is known for sure for "privacy-enhanced" modes, not performance.

Case Studies and Framework Patterns (Vue, Shopify, WordPress)

vue-lazytube is a Vue.js package that lazy loads YouTube embeds, avoiding up to 1.1 megabytes per video in initial loading weights by blocking the load of YouTube player scripts until needed.

Fudge.ai’s Shopify-focused guide recommends the facade pattern, stating that "scripts only load on user intent."

WPSpeedFix's WordPress guidance mentions that loading="lazy" can be combined with srcdoc to show only thumbnails initially.

Core Web Vitals, Privacy Modes, and What Performance Can’t Fix

The eye-popping numbers establish the importance of these patterns. A single above-the-fold YouTube embed can balloon your network request count by tens and your page weight by megabytes, reinforcing the need for tactics like native iframe lazy loading and facade patterns.

Note that this performance impact is compounded and sustained even when natively using loading="lazy". The load-work is deferred, but not avoided. If your video or map is in a high-traffic space, all the network requests, main-thread interleaving, and load that were delayed will be executed around when that iframe becomes visible on the user's screen.

Natively, iframe lazy loading doesn't buy you much from Core Web Vitals, because it relies on loading="lazy". As a result, that iframe's performance load happens right when it renders, even if you defer it. But if you are intent on defending users' privacy, using privacy-enhanced URL parameters for YouTube embeds may be implemented. As for permissions,.

OpenReplay highlighted that deferring doesn't solve all the iframe problems. If you want significant performance improvement from your embeds, stash their resources and load the iframe on user intent. Replace the iframe with an image thumbnail, then load the video or map only when the user clicks the thumbnail. This is the facade pattern.

This simple change–replacing the iframe with an image until clicked–cut 39% off mobile page load times. With native iframe lazy loading, massive page loads from heavy embeds can still trip up your site. A better approach is to reserve the iframe’s width and height and save its loading for user interaction.[]