Self-Exclusion Page Loads in 6s, 37% of Croats Abandon the Form

A self-exclusion form that takes six seconds to load loses roughly 37% of Croatian users before they submit it. That figure comes from a 2024 audit of the four responsible-gambling portals operated or contracted by Croatian-licensed operators, measured on a throttled 4G connection (9 Mbps down, 1.5 Mbps up, 170 ms RTT) across 1,200 sessions split between desktop and mobile. The abandonment is not evenly distributed: it concentrates on mobile, on prepaid SIMs, and on the two portals that load a third-party age-verification script before rendering the form itself.

The six-second threshold is not arbitrary

Croatia's regulated market runs through the Ministry of Finance's Office for Gambling (Uprava za igre na sreću), and the technical requirements for remote gambling operators are set out in the Zakon o igrama na sreću and its accompanying rulebooks. Those rulebooks specify what a self-exclusion mechanism must do — it must be reachable, it must be effective across all brands under the same licence, and it must take effect within a defined window. They do not specify a load-time budget. That gap is where the problem lives.

Six seconds is the point at which the abandonment curve in the audit steepens sharply. Under 2.5 seconds, submission rates sat at 91–94%. Between 2.5 and 4 seconds, they fell to 84%. Between 4 and 6 seconds, 71%. Beyond 6 seconds, 63% — meaning 37% of users who opened the page never completed the form. The same pattern shows up in general e-commerce conversion data, which is why the 6-second line is a useful benchmark rather than a Croatian-specific quirk. What makes it relevant here is that a self-exclusion form is not a checkout. A user who abandons a checkout has lost a purchase. A user who abandons a self-exclusion form has lost a brake.

Why the form is heavier than it needs to be

The audit broke down what each portal loads before the form becomes interactive:

• Portal A (operator-run, desktop-first): 1.8 MB of JavaScript, including a marketing analytics tag and a chat widget that initialises before the form. Median time to interactive: 7.4 s on mobile.
• Portal B (operator-run, mobile-optimised): 640 KB, form renders first. Median TTI: 2.1 s. Abandonment: 6%.
• Portal C (third-party contractor): 2.4 MB, age-verification script blocks render. Median TTI: 9.8 s. Abandonment: 44%.
• Portal D (operator-run, legacy CMS): 1.1 MB, but three sequential redirects before the form loads. Median TTI: 6.2 s. Abandonment: 38%.

The spread between Portal B and Portal C is 7.7 seconds and 38 percentage points of abandonment. That is not a marginal UX difference. It is the difference between a mechanism that mostly works and one that mostly does not.

The mobile problem is a Croatian problem

Croatia's fixed-broadband penetration sits below the EU average, and a meaningful share of online gambling traffic runs over mobile networks — particularly in Dalmatia and the less densely covered interior counties. The audit's throttled profile was not pessimistic; it was roughly the median experience for a user on a prepaid SIM outside Zagreb, Split, Rijeka, and Osijek.

This matters because the abandonment curve is steeper on mobile than desktop at every load-time band:

Time to interactive	Desktop abandonment	Mobile abandonment
< 2.5 s	4%	9%
2.5–4 s	11%	19%
4–6 s	22%	34%
> 6 s	29%	43%

A desktop user who waits seven seconds is annoyed. A mobile user who waits seven seconds has often already switched to another app, and the tab is backgrounded and eventually discarded by the OS. The self-exclusion attempt is silently lost. The user may believe they have excluded themselves when they have not — which is the single most dangerous failure mode in this entire area, because it produces a false sense of protection at exactly the moment the user has acknowledged they need it.

The false-completion problem

In 31 of the 1,200 audited sessions, the user reached a confirmation screen but the submission did not register server-side — typically because a session token expired during the delay or a validation error was returned after the user had already navigated away. These sessions looked successful to the user. They were not. The audit could only detect this because it controlled the test accounts; a real user would have no way of knowing.

This is the argument for treating load time as a compliance issue rather than a design preference. A self-exclusion mechanism that fails silently is worse than one that fails loudly, because the user's next action — depositing — proceeds on a false premise.

What the regulator requires, and what it does not

Under the current framework, a Croatian-licensed operator must offer self-exclusion, must honour it across all its own brands, and must not send marketing to excluded users. The Office for Gambling has the power to revoke a licence for non-compliance, and it has used that power — most notably in the periodic purges of unlicensed offshore operators targeting Croatian players, though those actions are about licensing status rather than self-exclusion UX.

What the framework does not do is set a performance floor. There is no requirement that the self-exclusion form load within X seconds, no requirement that it render before marketing scripts, and no requirement that a failed submission be surfaced to the user. In practice this means an operator can be fully compliant on paper while running a form that 44% of mobile users never complete.

The cross-operator gap

Croatia does not operate a single national self-exclusion register of the kind that exists in some EU jurisdictions. Self-exclusion is operator-level. A user who excludes themselves from Operator A can, the same evening, open an account with Operator B and deposit without any check. This is not a Croatian anomaly — several EU states have the same structure — but it compounds the load-time problem. If the form is hard to complete and the exclusion only binds one operator, the user's fallback is trivially available and requires no effort at all.

A national register has been discussed in policy circles for years. The practical obstacle is not technical; it is that a register requires operators to expose a real-time check API, and the smaller licensed operators have historically run infrastructure that would struggle to meet a latency budget. That is the same infrastructure problem showing up in the form itself.

What operators actually control

Load time is not a law of nature. The audit's Portal B demonstrates that a self-exclusion form can render in 2.1 seconds on a throttled mobile connection with 6% abandonment. The changes that produce that result are unglamorous:

1. Render the form before anything else. No marketing tags, no chat widget, no cookie-consent modal blocking the form. Consent can be collected after submission.
2. Drop the third-party age-verification script from the critical path. Age verification can run server-side after the form is submitted, or asynchronously. It does not need to block render.
3. Remove redirects. Portal D's three redirects added 3.4 seconds on their own. A self-exclusion form should live at a stable URL that resolves in one hop.
4. Cache aggressively. The form's static assets change rarely. A 24-hour edge cache costs nothing and removes a round trip.
5. Handle failure visibly. If submission fails, the user must see it, with a retry that preserves their input. Silent failure is the worst outcome.

None of these require new infrastructure. They require prioritising the self-exclusion form above the marketing stack, which is a decision that costs an operator measurable conversion on the acquisition side and returns nothing on the revenue side. That is precisely why it does not happen by default.

The incentive problem

An operator's commercial interest is in a fast, frictionless deposit flow and a self-exclusion flow that is compliant but not optimised. The two are not symmetrical. Every second shaved off the deposit page is revenue; every second shaved off the self-exclusion page is, in the short term, cost. The audit's Portal C — the third-party contractor — is the clearest case: the operator had outsourced the function and had no visibility into its performance until the audit surfaced it.

This is where the regulator's leverage sits. A performance floor — say, time-to-interactive under 3 seconds on a defined mobile profile, with failed submissions logged and reportable — would convert a commercial afterthought into a compliance metric. The technology to measure it already exists; the audit methodology described here is reproducible with open-source tooling.

The number that should worry the industry

37% abandonment is the headline, but the more uncomfortable figure is the 31 silent failures out of 1,200 sessions — 2.6%. Extrapolate that across the Croatian licensed market's active self-exclusion attempts, and you get a small but non-trivial number of users each year who believe they are excluded and are not. At that point the question stops being about page speed and becomes about what a self-exclusion mechanism is actually for. If it exists to satisfy a rulebook, 6 seconds is fine. If it exists to stop someone from depositing at 2 a.m. on a bad night, 6 seconds is a design failure with a person on the other end of it.

The open question is whether the Office for Gambling will treat load time as part of the compliance surface, or continue to treat it as an implementation detail. The data suggests the two are the same thing.