Code blocks load slower than the rest of the page

The SVG code blocks we use for section transitions are slow to load. This leaves visible white gaps in the lesson and causes the page to jump as the blocks appear, making the learner experience feel broken and unpolished.

We use code blocks to create SVG section transitions in Rise. These are full-width, solid-colour shapes, sometimes with waves or cut-outs etc, that visually separate one part of a lesson from the next.

SVG is ideal for these transitions because it:

• keeps curves, waves, and cut-outs sharp at any screen size
• scales to the full width without cropping or leaving white slivers at the edges
• uses our exact brand hex colours, without compression affecting them
• is significantly smaller than an equivalent PNG

The issue is not the SVG itself. From the browser inspect I can see that each code block is loaded inside a sandboxed iframe from sandbox.articulateusercontent.com, with loading="lazy" enabled. 

Lazy loading makes sense for larger or more complex embeds, but it creates a noticeable delay for small decorative blocks placed throughout a lesson.

Even though each SVG is only a few hundred bytes and has no external assets, the browser still needs to connect to Articulate’s sandbox domain before the content can render. The initial connection can involve steps such as a DNS lookup and TLS negotiation, so the delay is caused by retrieving the iframe rather than by the size or complexity of the SVG.

When a learner scrolls at a normal pace, two things can happen:

1. The learner reaches the block before it has loaded.
   The lazy-loading buffer does not provide enough time if the learner is scrolling quickly. Instead of seeing the full-width, solid-colour transition shape, they see a white gap.
2. The page shifts when the block appears.
   The block’s height is calculated after it renders and is then passed back through --block-html-height. This causes the content below it to move once the transition shape loads.

A delayed text or video block is relatively easy to overlook. A delayed transition shape looks like a hole in the page, so it reads as broken rather than slow. The issue is more noticeable on patchy or variable Wi-Fi, which is common across many of our sites.

The irony is that the SVG is much lighter than the image format we are avoiding. The delay comes from loading the iframe from Articulate’s servers, not from the size or complexity of our code.

__________________________________________________________________________________

Anyway what we’d like to see instead:

Preconnect to the sandbox domain

Adding the following to the published page’s <head> would establish the connection when the page first loads:

<link rel="preconnect" href="https://sandbox.articulateusercontent.com">

This would allow subsequent code blocks to skip most of the connection setup. It is a small change that would benefit any customer using code blocks, particularly in modules containing several of them.

Reserve the block height before it renders

The block height is already measured after loading and applied through the --block-html-height CSS variable.

If that height is available at publish time, applying it before the block loads would reserve the required space and prevent the page from shifting, even when the iframe is slow to render.

Also worth considering:

Give lazy loading more runway

The current buffer starts the fetch when the block is close to the viewport. Increasing that distance would give small blocks enough time to load before the learner reaches them, without loading everything at once. Even a modest increase would cover most normal scrolling speeds.

Eager-load the first code block on a page

A code block at the top of a page has no runway at all — it is already in the viewport when the page loads, so the fetch only begins after the main layout has settled.

We have worked around this by never placing a code block first on a page, and that is a fair enough trade-off for us. But it is a workaround rather than a fix, and it limits how we can structure a lesson.

Eager-loading only the first code block would be a targeted change with no cost to modules containing many blocks.

We are not asking for lazy loading to be removed. We understand why it is useful, particularly in lessons containing multiple media-heavy embeds. We are asking whether its visible effects can be reduced for small, lightweight code blocks.

Impact

We are building a Rise template that will be used across our organisation, so these solid-colour transition shapes will appear in every module our team produces.

The loading gap undermines an otherwise polished learner experience, and it is not something we can resolve through design or by optimising the SVG further.

Preconnecting to the sandbox domain and reserving the block height would address both the delayed rendering and the layout shift without removing the benefits of lazy loading.