Payment Widget Performance on Cashier Pages

Why payment code is different

Hosted payment fields and frames exist for good reasons: they keep card data away from the operator's own servers and let the provider handle security checks. The cost is that the code, its size and its timing belong to the provider. It often loads its own scripts and styles, opens connections to more origins and may resize as it moves between steps such as method choice, card entry and confirmation.

From a performance view, three risks follow: more network work on the cashier page, main-thread work that delays taps (INP) and frames that change height (CLS).

Load it where it is needed

A common pattern is to include the provider's script in a site-wide template "to be ready". That makes every lobby and game page pay for code that only the cashier uses. Load payment code on the cashier route only. If the cashier opens as an overlay in the lobby, load the code when the player taps "Deposit", show a sized skeleton and then insert the frame.

To save connection time, add a preconnect to the provider's origin on the step before the cashier. web.dev advises limiting preconnect to critical origins because "the browser closes any connection that isn't used within 10 seconds".

Reserve the frame's space

web.dev recommends reserving space for embeds and iframes in the initial layout, for example with min-height, and not collapsing it if nothing loads. For a cashier:

• Agree the frame's height for each step with the provider, and size the container to the tallest common step.
• If the provider resizes the frame with messages, apply height changes only in response to the player's own action, so the shift falls within the 500 millisecond input window that CLS excludes.
• Keep error messages and limit notices inside reserved space rather than inserting them above the form.

Keep the page responsive

While the frame starts, the rest of the page should still respond. Avoid heavy work in your own code at the same moment, such as re-rendering the whole account panel. Show the pressed state of "Deposit" in the next frame and load the rest after. See INP for yielding techniques.

Measuring a cashier

Cashier pages sit behind login, so they rarely have URL-level CrUX data, and Google's web-vitals library notes that browser APIs cannot see into iframe content, which can make its numbers differ from Chrome's. In practice:

1. Record lab traces of the full deposit flow on a throttled mobile profile, with a test account.
2. Collect your own field data on the cashier page, including the time from tapping "Deposit" to the frame being ready.
3. Share traces with the provider when their frame dominates the timeline.

Market notes

Deposit limit tools and safer gambling messages are part of the cashier in many regulated markets. Check the current rules for each market you serve. Build those messages into the reserved layout from the first paint instead of inserting them late. They should never be delayed or hidden to improve a metric.

Sources

1. web.dev, Efficiently load third-party JavaScript, last updated August 14, 2019.
2. web.dev, Optimize Cumulative Layout Shift, last updated February 7, 2025.
3. web.dev, Cumulative Layout Shift (CLS), last updated April 12, 2023.
4. web.dev, Browser-level image lazy loading for the web, last updated August 13, 2024.
5. GoogleChrome, web-vitals library, no date shown.