Core Web Vitals as a Banking KPI
Setting performance budgets for internet banking
Internet banking performance is usually discussed as a technical concern, measured by the frontend team and reported in milliseconds that mean little to a head of digital channels. Meanwhile, the effects are business effects: loan applications abandoned halfway through a slow form, customers who give up on a payment and call the contact centre instead, and complaints that "the app is slow" that nobody can trace to a cause. Slow pages rarely cause an outage. They quietly reduce conversion and increase support costs, release after release, until someone notices the trend.
Core Web Vitals give banks a way to close that gap. They are a small, standard set of user-centred performance metrics that can be measured for real customers, linked to business outcomes and enforced in the delivery pipeline. This article explains how to turn them into a KPI that product owners and engineers share, how to set performance budgets for internet banking journeys, and how to stop regressions before they reach customers.
The three metrics, in plain words
Core Web Vitals focus on three aspects of how a page feels to the person using it:
Largest Contentful Paint (LCP): how quickly the main content appears. On an account overview, that is usually the balance and the transaction list. Google's threshold for a good experience is 2.5 seconds or less.
Interaction to Next Paint (INP): how quickly the page responds when the customer acts. Tapping "Continue" on a payment form, opening a filter or typing an IBAN. A good INP is 200 milliseconds or less. INP replaced the older First Input Delay metric in March 2024 and is a much stricter measure of responsiveness.
Cumulative Layout Shift (CLS): how stable the page is while it loads. A button that moves just as the customer taps it is irritating on a news site and dangerous on a payment confirmation screen. A good CLS is 0.1 or less.
Each metric is assessed at the 75th percentile of real page loads. In other words, a page passes when at least three out of four customers get a good experience, not just the average customer on a fast office connection.
Why these numbers are business numbers in banking
Internet banking journeys have a property that makes performance especially visible: they are long, multi-step tasks that customers want to finish. A loan application, an account opening or a payment with several fields asks for attention and patience at every step, and each slow step is a point where the customer can give up.
There is published evidence from other industries. Deloitte's "Milliseconds Make Millions" study, run with Google, found that a 0.1-second improvement in mobile site speed was associated with measurable increases in conversion across retail, travel and other sectors. Several companies have published Core Web Vitals case studies showing similar effects. Banking-specific public data is scarce, though, and banks shouldn't rely on retail numbers to make their case.
The stronger argument is the bank's own data. Most internet banking platforms already track journey funnels: applications started and completed, payments initiated and confirmed. Adding performance data to those funnels makes the link measurable:
Completion rate by experience bucket. For a given journey, compare completion rates for sessions where LCP and INP were in the "good" range with sessions where they were "poor". The difference, measured on the bank's own customers, is a far more convincing argument than any external benchmark.
Support contacts after slow sessions. When contact-centre data records the reason for a call or chat, sessions that had poor performance just before a contact can be identified. "I couldn't complete my payment" calls that follow slow sessions are a direct cost.
Device and network segments. Customers on older Android phones or slow mobile networks often have a very different experience from the internal test team. Segmenting the data shows who is being left behind, which also matters for financial inclusion.
Correlation isn't proof of cause. But when the same journeys are improved and completion rates rise in the same segments, the business case builds itself.
Lab data and field data: you need both
Performance can be measured in two ways, and each answers a different question.
Field data comes from real customers using real devices and networks. It is the only true measure of the customer experience, and it is what the KPI should be based on. Public tools such as Google's Chrome UX Report mostly cover publicly accessible pages; the logged-in parts of internet banking, where most journeys happen, need the bank's own real-user monitoring (RUM).
Lab data comes from controlled test runs, for example Lighthouse in a CI pipeline, on a fixed device profile and network. It can't tell you what customers experience, but it is repeatable, which makes it ideal for catching regressions before release.
The practical setup uses lab data as the early warning and field data as the truth. One limitation is worth knowing: INP needs real user interactions, so lab tools can't measure it directly. Total Blocking Time (TBT) is the usual lab stand-in, because heavy JavaScript that blocks the main thread is the most common cause of poor INP.
Collecting field data from real customers
Google's open-source web-vitals library measures the three metrics in the browser using the same definitions as Google's own tools. A minimal integration sends each measurement to the bank's own analytics endpoint:
1 import { onLCP, onINP, onCLS } from 'web-vitals';
2
3 function report(metric) {
4 navigator.sendBeacon('/rum/vitals', JSON.stringify({
5 name: metric.name, // 'LCP' | 'INP' | 'CLS'
6 value: metric.value,
7 rating: metric.rating, // 'good' | 'needs-improvement' | 'poor'
8 journey: currentJourney(), // e.g. 'payment-sepa', 'loan-application'
9 page: routeTemplate(), // '/accounts/:id', never the real account number
10 }));
11 }
12
13 onLCP(report);
14 onINP(report);
15 onCLS(report); Three details matter in a banking context:
Tag every measurement with the journey and step, not just the URL, so that performance can be joined with funnel data.
Never send personal data. Use route templates instead of real paths, and leave out account numbers, names and amounts. Performance monitoring must follow the bank's consent and data-protection policies like any other analytics.
Add custom timings for single-page applications. Core Web Vitals are measured per page load, and in a single-page app, moving between steps of a journey isn't a new page load. For key steps, such as "payment form ready" or "offer displayed", add custom timings with the browser's Performance API (performance.mark and performance.measure) and report them alongside the standard metrics.
Setting budgets per journey
A performance budget is a limit the team agrees not to exceed. In banking, budgets work best when they are set per journey rather than per site, because the journeys matter differently. A slow statement archive is an annoyance; a slow payment confirmation is a lost payment.
We set three kinds of budget for each critical journey:
Experience budgets, based on Core Web Vitals at the 75th percentile of field data. For example: LCP of 2.5 seconds or less on the account overview, INP of 200 milliseconds or less on every step of the payment flow, and CLS of 0.1 or less on all confirmation screens.
Lab budgets, used in CI, with the same thresholds where they can be measured, and TBT as the stand-in for INP.
Resource budgets, which limit the causes rather than the symptoms: the size of JavaScript loaded for each journey, the number and weight of third-party scripts, and image weight on content-heavy pages.
Resource budgets are where most banking regressions are caught early. Analytics tags, chat widgets, consent managers, device-fingerprinting scripts for fraud prevention and A/B testing tools are each added for good reasons, often by different teams. Together, they can easily cost more than the bank's own application code. A resource budget turns "can we add one more script?" into a visible trade-off, with an owner, instead of a gradual drift.
Budgets should start from today's measured baseline, not from an ideal number. A journey with a poor LCP today gets a budget that prevents it from getting worse, plus a target and a date for improvement. Tightening budgets in steps is more sustainable than setting thresholds that fail every build on day one.
Enforcing budgets in CI
Budgets only work if a regression is noticed before release, by the team that caused it. We enforce them at three points in the pipeline.
1. At build time: bundle size
Most modern build tools can fail a build when a bundle exceeds a size limit. Angular, for example, has budgets built into its build configuration, and similar checks exist for other frameworks and bundlers. This is the fastest and cheapest check, and it runs on every commit.
2. Before merge: lab tests on key journeys
Lighthouse CI runs Lighthouse against a set of URLs in a test environment and compares the results with assertions. For internet banking, the URLs must include logged-in pages, so the test setup signs in with a test customer first, using a scripted login. The assertions express the lab budgets:
1 {
2 "ci": {
3 "collect": {
4 "url": [
5 "https://test.bank.example/accounts",
6 "https://test.bank.example/payments/new",
7 "https://test.bank.example/loans/apply"
8 ],
9 "numberOfRuns": 3
10 },
11 "assert": {
12 "assertions": {
13 "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
14 "cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
15 "total-blocking-time": ["error", { "maxNumericValue": 200 }],
16 "resource-summary:script:size": ["error", { "maxNumericValue": 400000 }],
17 "resource-summary:third-party:count": ["warn", { "maxNumericValue": 8 }]
18 }
19 }
20 }
21 } Running each URL several times and using the median reduces noise. Lab results vary with the test machine's load, so thresholds in CI should leave a small margin rather than fail on the first millisecond over the limit.
3. After release: field alerts
The real budget is the field budget. RUM data is aggregated per journey and compared with the 75th-percentile thresholds daily. When a journey moves from good to needs-improvement, the owning team gets an alert with the release that most likely caused it. Releasing gradually, to a share of customers first, makes this comparison much clearer.
Making it a shared KPI
A performance budget only becomes a business tool when product owners and engineers own it together. The practices that make that work:
One dashboard per journey, showing Core Web Vitals at the 75th percentile alongside the funnel metrics for that journey: starts, completions and support contacts. Product owners see performance next to the numbers they already care about.
Budgets in the definition of done. A feature that pushes a critical journey over its budget isn't finished, in the same way a feature with failing tests isn't.
A clear exception process. Sometimes a business need justifies a temporary budget overrun, such as a regulatory requirement that adds a heavy script. The exception is agreed by the journey owner, recorded with an end date, and paired with a plan to recover the budget.
Third-party scripts with owners. Every external script has a named business owner, a documented purpose and a performance cost. Reviewing that list each quarter usually finds scripts nobody uses any more.
A monthly review, in which product and engineering look at trends together and decide where to invest. Improving a journey from "poor" to "good" is a feature, and it should be planned and celebrated like one.
Where to start
For a bank that doesn't yet treat performance as a KPI, a realistic first quarter looks like this:
Add real-user monitoring with journey tags to the three most important journeys, for example login and account overview, a payment and one application flow.
Measure a baseline for four to six weeks, and join it with the funnel data for those journeys.
Set budgets from the baseline, and add bundle-size checks and Lighthouse CI for those journeys.
Fix the biggest gap first, which in internet banking is often third-party scripts or a large initial JavaScript bundle, and measure the effect on completion rates.
That first measured improvement, expressed in completed applications or avoided calls rather than milliseconds, is usually what turns performance from an engineering topic into a business KPI.
Closing thought
Customers don't measure internet banking in milliseconds. They notice whether the balance appears straight away, whether the payment form responds when they tap, and whether the confirm button stays where they expect it. Core Web Vitals turn those experiences into numbers a bank can track, link to completed journeys and protect in every release. With budgets set per journey, enforced in CI and reviewed by product and engineering together, frontend performance becomes something the business manages, not something it discovers in a complaint report.
