Mantys Core
On a fast office connection, the Axeptio banner shows up almost at once. On a phone in the street, visitors read, scroll and tap before it appears, sometimes long after the page itself. Meanwhile your tags wait for a consent that has not been asked yet, and the banner lands on top of a page the visitor is already using.
Axeptio is rarely the culprit on its own. What delays it is where it sits in the queue. This guide shows what the banner needs before it can appear, what a real page does to that chain, and the levers that bring it forward without touching what consent requires.
What Axeptio loads before the banner appears
The banner is the last step of a short chain, and each step waits for the previous one:
- The settings: a small inline script that declares
window.axeptioSettings(your project id and cookies version) and injects the SDK. - The SDK, a script served from
static.axept.io. - The project configuration: texts, vendors and design, fetched by the SDK once it runs.
- The styles and the font of the widget, including a web font stylesheet from
fonts.axept.io. - The banner, rendered once all of the above is there.
None of these files is heavy. The problem is that on a busy page they are requested while dozens of other files are already downloading, and on a slow mobile connection every request in the queue costs a round trip.
A case study: 16 seconds on Slow 4G
We measured a real WordPress landing page built with a page builder, about 150 requests, with Axeptio installed. Protocol: phone emulation at 390 × 844 pixels, browser cache disabled, no consent cookie, no interaction, five runs per network, medians kept.
- Unthrottled: first paint at 0.57 s, banner in place at 1.42 s.
- Fast 4G: first paint at 1.32 s, banner in place at 3.12 s.
- Slow 4G: first paint at 5.72 s, banner in place at 15.98 s.
On the slow profile, the visitor has had ten seconds of page before being asked anything. Every tag waiting for consent waited with them.
A stripped-down version of the same page, with about 80 requests instead of 150, had its banner in place at 5.8 s on Slow 4G. That version also changed how the banner was presented, so the comparison gives an order of magnitude rather than an exact gain. The order of magnitude is the point: halving the competition cut the wait by roughly two thirds.
Lever 1: lighten what competes with the banner
This is the biggest lever, and it has nothing to do with Axeptio settings. Look at the Network panel on a throttled mobile profile and list what loads before the banner: page builder stylesheets used on other templates, a slider script for a slider below the fold, a chat widget, several marketing pixels, full-size images far down the page.
- Delay the scripts that are not needed at load (chat, pop-ups, sliders below the fold), keeping the consent tool out of the delay (lever 2).
- Stop loading assets on templates that do not use them.
- Lazy load the images below the fold, never the main image at the top.
- Trim the CSS to what the page uses, so fewer and smaller stylesheets sit in the queue.
Every request you remove from the start of the load is a slot the Axeptio chain gets sooner.
Lever 2: never delay the consent tool
Performance tools that postpone JavaScript until the first interaction are a common reason for a banner that only appears after a scroll or a tap. If the inline settings or the SDK are delayed, the banner waits for the visitor to move, and consent is asked after the fact.
Add both to the exceptions of your delay tool: the inline script, which you can match on axeptioSettings, and the SDK, which you can match on axept.io. Then check the result: reload in a private window, touch nothing, and the banner must appear on its own. The general method to find what a delay broke is in our JavaScript delay guide.
Lever 3: start the chain early
Place the Axeptio snippet high in the <head>, not in the footer and not behind another script that itself waits. Then warm up the connection to the SDK host, so the first request does not pay for DNS and TLS on top of its place in the queue:
<link rel="preconnect" href="https://static.axept.io">Keep the hints to the hosts you actually see in the Network panel for Axeptio, and to one or two in total: every preconnect opens a connection that competes too.
Lever 4: the font nobody sees
The widget injects a stylesheet for its own web font. If your banner is styled with your site’s font, that request is pure waste: one more file in the queue, and any script that waits for document.fonts.ready waits for it as well. On the page we measured, a banner reveal that waited for fonts lost 600 ms on Slow 4G to a font that was never displayed.
If, and only if, your banner does not use that font, you can remove the stylesheet as soon as it is inserted:
// Removes the widget's web font stylesheet as soon as it is added.
// Only if the banner is styled with your own font.
(function () {
function drop(node) {
if (node.nodeType !== 1) return;
if (node.tagName === 'LINK' && /fonts\.axept\.io/.test(node.getAttribute('href') || '')) { node.remove(); return; }
if (node.querySelectorAll) node.querySelectorAll('link[href*="fonts.axept.io"]').forEach(function (l) { l.remove(); });
}
new MutationObserver(function (mutations) {
mutations.forEach(function (m) { m.addedNodes.forEach(drop); });
}).observe(document.documentElement, { childList: true, subtree: true });
})();Check in the Network panel that no request to fonts.axept.io remains, and that the banner text renders in your font. If your delay tool rewrites inline scripts, exclude this one too.
If you customize the banner
Many sites restyle the banner to match their brand. Three rules keep that customization from costing you later:
- Target stable hooks. The widget’s class names are generated and change between versions. Target ids such as
#axeptio_btn_acceptAll, or a container by its content (for examplediv:has(> #axeptio_btn_acceptAll)), never a generated class. - Keep the wording in the Axeptio back office. What is displayed must be what Axeptio records as shown to the visitor. Rewriting the texts in JavaScript makes the screen and the consent proof diverge.
- React to the choice through the SDK, not the markup. The banner’s elements can stay in the page after the visitor has answered, so waiting for them to disappear can wait forever. Listen to the SDK instead:
// Runs once the visitor has made a choice.
window._axcb = window._axcb || [];
window._axcb.push(function (sdk) {
sdk.on('cookies:complete', function (choices) {
// choices holds the vendors the visitor accepted.
});
});And if you hide the floating cookie button, give visitors another way back to their choices, shown only when the SDK exposes it:
<a href="#" id="manage-cookies" hidden>Manage cookies</a>
<script>
window._axcb = window._axcb || [];
window._axcb.push(function () {
var link = document.getElementById('manage-cookies');
if (typeof window.openAxeptioCookies !== 'function' || !link) return;
link.hidden = false;
link.addEventListener('click', function (e) { e.preventDefault(); window.openAxeptioCookies(); });
});
</script>Measure it the way a new visitor lives it
- A private window, so no consent cookie is set; with a cookie, the banner never shows and you measure nothing.
- DevTools with the cache disabled and a throttled mobile profile, Slow 4G included.
- Touch nothing, and note when the banner is on screen, for example with the screenshots of the Performance panel.
- Five runs per profile and the median, as explained in our guide on lab and field data.
- Also test with a content blocker: if Axeptio is blocked, the page must stay usable and never wait for a banner that will not come.
With Mantys Core
Mantys Core can run your whole performance layer, cache included, or sit next to the setup you already have. For a consent banner, its job is to clear the road:
It delays the scripts that are not needed at load, and you add
axeptioSettingsandaxept.ioto its delay exceptions so the consent tool starts at once.It trims the CSS page by page and can stop assets from loading on templates that do not use them, so fewer requests compete with the banner.
It keeps images below the fold lazy loaded and the main image eager.
The loading moment of your analytics tags can be set per tag, so they do not crowd the start of the load.
The consent logic stays Axeptio’s. The platform makes sure it is not stuck in the queue.
In summary
- The Axeptio banner is the end of a chain of small requests, and on a busy page that chain waits its turn.
- On the page we measured, the banner took 16 s on Slow 4G; with half the requests, under 6 s.
- Lighten what competes, never delay the consent tool, load it high in the head, and drop the font you do not display.
- Customize through stable ids and the back office, and react to the choice through the SDK.
- Measure as a new visitor: private window, cache off, throttled mobile, no interaction, several runs.
Comments
Stuck on a similar problem? Describe your setup and what you see. We read every comment and answer.
No comments yet. Be the first to share your case.