We Measured 16 Fintech Websites: All of Them Ship Too Much JavaScript

Every one of the 16 fintech homepages we measured ships too much JavaScript. The lightest carried 730 KB of script. The heaviest carried 3,245 KB. Most of them still load quickly for real visitors. Where they struggle is the moment after that, when someone taps a button and nothing happens yet.

A month ago we ran the same exercise on 13 digital health websites. That sample was heavy but not slow, and we wrote it up mostly as a warning about trusting lab scores. Fintech gave us a different picture. A more useful one, too.

How we measured

On 29 September we ran 19 fintech homepages through the pipeline behind our audit tool, one run per site, all on the same day. These are companies anyone in the industry would recognise, from the US and Europe: payments, business banking, spend management, consumer banking, brokerage.

We recorded two kinds of numbers and kept them apart.

JavaScript weight comes from a lab load on a simulated mid-range phone. It is a count of bytes. Bytes do not care how the simulated network behaved.

Timing comes from the Chrome UX Report, which is what real Chrome users experienced over the previous 28 days: largest contentful paint (LCP), interaction to next paint (INP), layout shift (CLS) and time to first byte (TTFB). We did not use lab timings to call anything slow. On the health sites the lab got load time and server time backwards, and we are not making that mistake twice.

Three sites did not give us a full report. Plaid and Mollie returned no lab or field data on two attempts each, and Chime did not answer our checks after three tries. That leaves 16.

The weight

Here is what each homepage shipped in JavaScript, lightest first:

• Ramp: 730 KB
• Pleo: 890 KB
• Revolut: 1,193 KB
• Mercury: 1,226 KB
• Airwallex: 1,325 KB
• Monzo: 1,360 KB
• Qonto: 1,492 KB
• Brex: 1,561 KB
• bunq: 1,645 KB
• SumUp: 1,817 KB
• N26: 1,897 KB
• Wise: 1,962 KB
• Stripe: 2,015 KB
• Klarna: 2,061 KB
• GoCardless: 2,562 KB
• Robinhood: 3,245 KB

The middle of the sample sits at about 1.6 MB, and fourteen of the sixteen are over a megabyte. Our health sample had its middle around 800 KB. So a fintech homepage carries roughly twice the script of a health one.

This is not legacy code nobody has touched. At least nine of these sites run on Next.js or React, which means the stacks are current and the bytes are a choice someone can revisit.

Third-party tags are part of it. Klarna's homepage requested 115 external scripts and Stripe's requested 79. Then again, Ramp requested none and N26 just one, and those two sit at opposite ends of the weight list. Tags explain some of the problem. Not all of it.

Load time is mostly fine

Seven of the sixteen have a healthy LCP for real users. Eight sit in Google's "needs improvement" band between 2.5 and 4 seconds. One is poor: Klarna, at 5.2 seconds. Nobody's page takes forever to appear.

If you only looked at this number, you would call fintech web performance decent and move on.

Responsiveness is where it breaks

INP measures how long a page takes to visibly react after someone clicks or taps. Google's bar for good is 200 milliseconds. Twelve of the sixteen miss it for their real users. Wise sits at a full second.

That is the gap between a page that looks ready and a page that is ready. The hero paints, the visitor goes for "Open an account", and the main thread is still busy running the script that came with the page. On a fast laptop you never notice. On an older Android phone it shows up as a tap that does nothing. Then comes the second tap, and sometimes the back button.

Weight is not the whole story, and our own numbers say so. Ramp ships the least JavaScript in the sample and still lands at 0.4 seconds. Robinhood ships the most and keeps its INP close to the line. What weight does is raise the odds. Only two sites pass all three Core Web Vitals, and one of them is Pleo, the second-lightest page we measured. The other is SumUp. Pleo also had the best lab score of the group, 82 out of 100, while thirteen of the sixteen scored under 50.

For a fintech homepage this matters more than for most. The page usually has one job: get someone to start sign-up. That job is an interaction, and INP is the metric that sits closest to it.

Two smaller findings

Layout shift is mostly handled. Twelve of sixteen are healthy; Revolut, N26, GoCardless and bunq move enough while loading to need attention.

Server response is odder. Ten of the sixteen have a field TTFB above Google's 800 millisecond bar. Yet when our server requested the full HTML directly, 12 of the 15 sites we could read answered in under 0.4 seconds. Both can be true. Our request is one fetch from one data center, while field TTFB also counts redirects and the distance to visitors everywhere. When the two numbers disagree this much, check redirects and CDN coverage before anyone rewrites the backend.

What we would fix first

Start with a performance trace of one tap on the main call to action. It usually points at a couple of long tasks, and that is where the INP comes from.

Then push third-party tags past the first input. Analytics that fire half a second later lose nothing.

Hydrate what the visitor can see. A pricing table three screens down does not need to be interactive before the hero button is.

Finally, put a JavaScript budget in CI, so the weight does not creep back one campaign tag at a time.

We did this on our own site first and wrote up what changed. The cause there was the same kind of thing: script above the fold, and hydration running on everything at once.

Limits of this sample

One run per site. Lab JavaScript weight moves a little between runs, so read the list as a ranking rather than numbers to the kilobyte. Revolut's run came back partial, with script weight and field data but no server figures. Field data is Chrome's 28-day window, so it reflects the last month of traffic, not today's deploy. And we only looked at homepages. The logged-in product is a different page with its own problems.

Check your own site

The pipeline we used is public at audit.lomray.com. Paste a URL and the report is ready in about a minute, with script weight and real-user data side by side. It is free and there is no call attached.