Beacon — Load Interactive Content on Demand Without Sacrificing Performance

Modern websites rarely exist without interactive content: maps, videos, embeds from third-party platforms. On almost every project I’ve worked on, at least one of these elements is present, usually more.

The challenge is not whether to use them, but how to use them responsibly.

Every map embed, video player, or external widget usually comes with its own scripts, styles, network requests, and sometimes tracking. All of these are loaded eagerly by default, directly impacting:

• initial page load time
• Core Web Vitals
• perceived performance
• visual clarity of the page

When performance matters (and it always does), the goal is simple: load as little as possible on first paint, and load heavy features only when the user actually wants them.

That is where Beacon comes in.

Play

The Problem: Eager Loading and Visual Noise

External embeds tend to create two kinds of problems:

1. Performance overhead
   Maps, videos, and third-party widgets often load large JavaScript bundles immediately, even if the user never interacts with them. This leads to unnecessary network requests and slower page rendering.
2. Visual clutter
   An embedded map or video often dominates the layout. Sometimes this is desired, but very often, it isn’t. Many pages benefit from a cleaner, calmer layout that invites interaction rather than overwhelming the user.

What we want instead is intentional interaction:

• show a clean, lightweight placeholder
• give the user a clear call to action
• load the heavy content only when requested

Why Gutenberg (and Why Core Blocks)

I strongly prefer building pages using Gutenberg and leaning on what WordPress already provides out of the box. Core blocks are well-tested, accessible, and continuously improved. One block in particular stands out for this use case: Cover.

The Cover block already gives us:

• background images or videos
• overlay content
• text and buttons
• alignment, spacing, and color supports
• responsive behavior

In other words, it already does almost everything we need.

Instead of creating another custom block with custom controls and duplicated logic, I chose a simpler approach.

The Idea: “Beacon” — A Block Variation

Rather than reinventing the wheel, Beacon is implemented as a block variation of the core Cover block.

This approach has a few important advantages:

• no new editor UI to learn
• no duplicated controls
• full compatibility with existing Cover features
• minimal code footprint
• easy future maintenance

The “Beacon” variation does not change how the Cover block works. It simply adds a small layer of behavior when the variation is active.

Conceptually, the Beacon works like this:

• The page loads with a normal Cover block
• The Cover shows an image, text, and a button
• No heavy scripts are loaded initially
• When the user clicks the button, the “Beacon” triggers the dynamic content
• Only then is the interactive content (map, video, iframe, etc.) loaded

The button becomes the signal. The beacon fires only when the user explicitly asks for it.

Minimal PHP, Maximum Effect

One of the core goals of this plugin was to keep the implementation as small and focused as possible.

The variation is registered in PHP and extends the core block without:

• overriding block rendering
• replacing editor components
• adding new inspector panels
• introducing JavaScript-heavy editor logic

This keeps the solution: fast, predictable, and aligned with core WordPress behavior.

\add_filter( 'get_block_type_variations', __NAMESPACE__ . '\\beacon_variation', 10, 2 );

...

// Add a custom variation.
$variations[] = [
	'name'        => 'beacon',
	'title'       => __( 'Beacon', 'beacon' ),
	'description' => __( 'Reduce visual noise and improve page performance with a fast, responsive, and lightweight block for loading interactive content on demand.', 'beacon' ),
	'scope'       => [ 'inserter', 'block', 'transform' ],
	'isDefault'   => false,
	'isActive'    => [ 'variation' ],
	'attributes'  => [
		'variation'     => 'beacon',
		'className'     => 'is-variation-beacon',
		'align'         => 'wide',
		'allowedBlocks' => [ 'core/buttons' ],
	],
	'innerBlocks' => [
		[ 'core/buttons' ],
	],
];

...

The snippet only augments the block when the Beacon variation is used, leaving the standard Cover block completely untouched.

What Beacon Solves

By deferring the loading of interactive content, Beacon achieves two important things:

1. Better performance
   • fewer scripts loaded on initial page load
   • improved Core Web Vitals
   • reduced JavaScript execution time
2. Cleaner user experience
   • less visual noise
   • clearer intent and interaction
   • content loads only when relevant

Instead of forcing heavy embeds on every visitor and every page, Beacon lets users opt in.

A Small Tool With a Focused Purpose

The Beacon plugin is intentionally simple. It doesn’t try to be a page builder or a universal embed system. It does one thing well:

Reduce visual noise and improve page performance by loading interactive content only when the user requests it.

By building on top of existing Gutenberg blocks and core features, it stays lightweight, future-proof, and easy to reason about.

Sometimes, the best optimization is not adding more, but knowing when to load less.

Note: The article featured image was generated using Adobe Firefly AI technology.