Core Web Vi­tals Are Rev­enue: What CIOs Ac­tu­al­ly Need to Know About Per­for­mance

Per­for­mance is a line in the P&L, not a line in the load-test re­port. Treat Core Web Vi­tals as a fron­tend de­tail the de­vel­op­ers will some­how sort out, and you give away two things at once: vis­i­bil­i­ty on Google and con­ver­sion in the fun­nel. Both can be put in eu­ros, and that is ex­act­ly why this be­longs at the de­ci­sion-mak­er lev­el rather than buried in a Jira back­log.

The rea­son it mat­ters right now is that the met­rics have moved. Since March 2024 Google no longer mea­sures only how fast a page re­sponds to the first tap, but how re­spon­sive it stays across the en­tire ses­sion. The fron­tend ar­chi­tec­ture has shift­ed in par­al­lel: Serv­er Com­po­nents and in­cre­men­tal ren­der­ing move the load off the brows­er. Any­one mak­ing a plat­form de­ci­sion to­day is also de­cid­ing the per­for­mance ceil­ing the project can ever reach. That ceil­ing is al­most im­pos­si­ble to raise lat­er.

Core Web Vi­tals turn a sub­jec­tive feel­ing, "the page feels slow", into three mea­sur­able num­bers that Google col­lects from real-user data. LCP (Largest Con­tent­ful Paint) mea­sures when the largest vis­i­ble con­tent has loaded; any­thing un­der 2.5 sec­onds is good. INP (In­ter­ac­tion to Next Paint) mea­sures re­sponse la­ten­cy on in­ter­ac­tions across the whole ses­sion; any­thing un­der 200 mil­lisec­onds is good. CLS (Cu­mu­la­tive Lay­out Shift) mea­sures how much the lay­out jumps around; any­thing un­der 0.1 is good. The mea­sure­ment is tak­en at the 75th per­centile and split by mo­bile and desk­top. That split mat­ters, be­cause your desk­top num­bers at the of­fice can pa­per over a poor mo­bile ex­pe­ri­ence.

The point that lands in the board­room: these num­bers cor­re­late with busi­ness met­rics. The study Mil­lisec­onds Make Mil­lions, com­mis­sioned by Google and run by 55 and De­loitte, looked at more than 30 mil­lion ses­sions across 37 brand sites in late 2019. A 0.1-sec­ond im­prove­ment in load time cor­re­lat­ed, in re­tail, with +8.4% con­ver­sion and +9.2% av­er­age or­der val­ue, and in trav­el with +10.1% con­ver­sion. Pin­ter­est re­port­ed +15% signup con­ver­sion and +15% SEO traf­fic af­ter a per­for­mance re­build, which it de­scribed in its own en­gi­neer­ing blog as the team's biggest user-ac­qui­si­tion win that year.

These fig­ures are sol­id enough to jus­ti­fy an in­vest­ment, but they are not laws of na­ture, and I will come back to why. For now the fram­ing is enough: per­for­mance is a lever with mea­sur­able ef­fect on two rev­enue dri­vers, vis­i­bil­i­ty and clos­ing the sale.

If you are still work­ing from the 2023 men­tal mod­el, you are op­ti­mis­ing the wrong met­ric. On 12 March 2024 Google of­fi­cial­ly made INP a Core Web Vi­tal, re­plac­ing FID (First In­put De­lay). The dif­fer­ence is not cos­met­ic. FID mea­sured only the de­lay of the very first in­ter­ac­tion, a for­giv­ing num­ber that was al­most al­ways green. INP mea­sures re­sponse la­ten­cy across all in­ter­ac­tions in a ses­sion and re­ports one of the worst val­ues. That ex­pos­es ex­act­ly the frus­tra­tion users ac­tu­al­ly feel: the tenth click in check­out that hangs, not the first.

For ar­chi­tec­ture de­ci­sions this means JavaScript that blocks the main thread gets more ex­pen­sive. Every heavy client-side com­pu­ta­tion, every over­sized state man­ag­er, every hy­dra­tion of a whole page tree now shows up vis­i­bly in INP. That is why ar­chi­tec­tures send­ing less JavaScript to the brows­er hold a struc­tur­al ad­van­tage. Not be­cause they are mod­ern, but be­cause they put less work on the main thread that de­ter­mines INP.

This shift is also a warn­ing to any­one who signed off on their per­for­mance num­bers be­fore March 2024. A page that was green un­der FID can be red un­der INP. If you have not re-mea­sured since then, you do not know your ac­tu­al po­si­tion. Google mea­sures con­tin­u­ous­ly from the Chrome User Ex­pe­ri­ence Re­port, so the re­gres­sion reach­es your rank­ing be­fore it reach­es your dash­board.

Here the plat­form de­ci­sion gets con­crete. Most per­for­mance prob­lems arise be­cause too much JavaScript reach­es the brows­er, where it has to be parsed, ex­e­cut­ed and hy­drat­ed. That is ex­act­ly where Re­act Serv­er Com­po­nents in Next.js in­ter­vene. Com­po­nents ren­der on the serv­er by de­fault; only what is ex­plic­it­ly marked with 'use clien­t' ends up in the client bun­dle, to­geth­er with its im­port graph. The Next.js doc­u­men­ta­tion di­rect­ly at­trib­ut­es an im­prove­ment in First Con­tent­ful Paint to ship­ping less JavaScript. Less client JavaScript is the most di­rect lever­age on INP an ar­chi­tec­ture can of­fer.

On top of that comes ISR (In­cre­men­tal Sta­t­ic Re­gen­er­a­tion). In­stead of ren­der­ing every re­quest live, Next.js serves pre-ren­dered sta­t­ic pages for most re­quests and re­gen­er­ates them in the back­ground us­ing the stale-while-reval­i­date pat­tern: the user gets the fin­ished page im­me­di­ate­ly, the re­fresh hap­pens asyn­chro­nous­ly. That cuts serv­er load and sta­bilis­es LCP, be­cause the ex­pen­sive ren­der work sits out­side the user's crit­i­cal path. Cache-Con­trol head­ers are set au­to­mat­i­cal­ly, and the caching be­hav­iour is ob­serv­able via the x-nex­tjs-cache head­er.

How far this scales be­comes clear in the high-traf­fic case. For sites with au­di­ences in the mil­lions, this com­bi­na­tion of pre-ren­der­ing and a lean client bun­dle is pre­cise­ly why a stack of San­i­ty and Next.js can serve mil­lions of vis­i­tors with­out a per­for­mance col­lapse. And be­cause Google mea­sures at the mo­bile per­centile, every one of these op­ti­mi­sa­tions feeds di­rect­ly into the num­bers that rank, an ar­gu­ment tied tight­ly to dis­ci­plined mo­bile-first de­sign. The next/im­age op­ti­mi­sa­tion runs self-host­ed too, zero-con­fig via next start, ship­ping mod­ern for­mats and the right im­age sizes by de­fault and so ad­dress­ing the sin­gle most com­mon LCP killer out of the box.

Now the part a ven­dor sell­ing you Next.js would rather skip. The frame­work is a pre­con­di­tion, not a guar­an­tee. Used wrong, a Next.js page is as slow as any oth­er, some­times slow­er, be­cause the frame­work weight is added on top.

The typ­i­cal mis­takes are well known and sur­face in every au­dit. A team marks too much with 'use clien­t' and push­es half the page tree into the client bun­dle, and the Serv­er Com­po­nent ad­van­tage evap­o­rates. It builds ren­der wa­ter­falls, where one data query waits on the next in­stead of load­ing in par­al­lel, and LCP climbs. It drops in unchecked im­ages in­stead of us­ing the im­age op­ti­mi­sa­tion. It reach­es for a heavy client-side state li­brary where serv­er state would have done, block­ing the main thread, with di­rect dam­age to INP. Next.js pre­vents none of these mis­takes. It only makes them eas­i­er to avoid when the team knows what it is do­ing.

Then there are the stud­ies them­selves. The fa­mous rule of thumb, "Ama­zon: 100 ms of de­lay costs 1% of rev­enue", has no of­fi­cial Ama­zon source. It traces back to a 2006 Stan­ford pre­sen­ta­tion by a for­mer en­gi­neer, rough­ly twen­ty years old and con­text-de­pen­dent. The of­ten-cit­ed Wal­mart num­bers come from a 2012 Ve­loc­i­ty talk, doc­u­ment­ed only through sec­ondary sources. Even the De­loitte/Google up­lifts from late 2019 are sec­tor-spe­cif­ic cor­re­la­tions, not a uni­ver­sal law of "0.1 sec­ond = +X% every­where". Present these num­bers as a fixed causal rule in front of the board and the first sharp CFO will take you apart. Cite them as or­ders of mag­ni­tude, with the date and the ver­ti­cal at­tached. That is more hon­est, and it sur­vives the chal­lenge.

A the­sis is only worth some­thing if it knows its own lim­it. Here is the lim­it: Core Web Vi­tals are one rank­ing fac­tor among many, and they do not map one to one onto rev­enue. Google it­self states in its search doc­u­men­ta­tion that there is no stand­alone boost sig­nal and that rel­e­vance and con­tent qual­i­ty stay pri­ma­ry. A per­fect LCP res­cues no weak of­fer, no con­fus­ing fun­nel, no page that sells the wrong thing.

That does not rel­a­tivise the in­vest­ment, it sharp­ens it. Per­for­mance is hy­giene, not a growth lever in a vac­u­um. Be­tween two pages of equal sub­stance, the page-ex­pe­ri­ence sig­nal tips the bal­ance; on a bad page, the fastest load time changes noth­ing. So the hon­est fram­ing is: get the of­fer right first, then the fun­nel, then per­for­mance feeds into both. In that or­der.

In­vert it, pol­ish­ing the last 100 mil­lisec­onds while check­out still has three re­dun­dant re­quired fields, and you are mi­cro-op­ti­mis­ing at the wrong end. The right ques­tion in the steer­ing com­mit­tee is not "how fast are we" but "where in the fun­nel is slow­ness cost­ing us con­ver­sions". That ques­tion leads to pri­ori­tised, de­fen­si­ble in­vest­ments rather than a green Light­house score as an end in it­self. There are also cas­es where Next.js is the wrong choice: a pure con­tent site with no in­ter­ac­tiv­i­ty car­ries frame­work weight a lighter set­up would shed.

The TCO per­spec­tive is miss­ing from most per­for­mance dis­cus­sions, and it be­longs there. Per­for­mance is not a one-off project but an op­er­at­ing state that has to be main­tained. Every new fea­ture, every track­ing script from mar­ket­ing, every em­bed­ded third-par­ty com­po­nent can de­grade the num­bers. With­out con­tin­u­ous mon­i­tor­ing from real-user data, you no­tice the re­gres­sion only when the rank­ing gives way, and re­cov­ery is ex­pen­sive by then.

On the ar­chi­tec­ture side there is a pat­tern we see con­sis­tent­ly in our own projects: a clean first im­ple­men­ta­tion is an in­vest­ment that pays back over the life­time, be­cause the per­for­mance ceil­ing sits high and op­ti­mi­sa­tions stay cheap. A slop­py im­ple­men­ta­tion de­fers the cost, where it ac­crues as tech­ni­cal debt with in­ter­est. If you want the dif­fer­ence in num­bers, the same log­ic is worked through in our break­down of what a self-host­ed stack re­al­ly costs over time.

The op­er­at­ing ef­fort for a well-built self-host­ed set­up runs, in our ex­pe­ri­ence, to a few hours a month for up­dates, mon­i­tor­ing and back­ups. That is mod­est against what poor per­for­mance costs on the rev­enue side, if the or­ders of mag­ni­tude in the stud­ies ap­ply to your busi­ness even ap­prox­i­mate­ly. The maths rarely comes out close.

Treat per­for­mance as a busi­ness met­ric with its own re­port­ing, not a fron­tend by-prod­uct. Have the Core Web Vi­tals of your most im­por­tant fun­nel pages shown to you from real-user data, split by mo­bile and desk­top, at the 75th per­centile, not the flat­ter­ing Light­house score from a de­vel­op­er lap­top. If the mo­bile num­bers are red, you have a quan­tifi­able rev­enue prob­lem, not a tech­ni­cal de­tail.

When you choose the plat­form, choose an ar­chi­tec­ture that sends lit­tle JavaScript to the brows­er and can pre-ren­der. Next.js with Serv­er Com­po­nents and ISR is one of the strongest avail­able start­ing con­di­tions for that, but in­sist that the team knows where 'use clien­t' be­longs and where it does not. The full ar­chi­tec­tur­al case for why this stack works as a per­for­mance foun­da­tion is on our Next.js pil­lar page. The plat­form alone buys you noth­ing. The skill of the team us­ing it de­cides whether the ceil­ing is reached.

And keep the or­der in mind: of­fer, fun­nel, then per­for­mance. In­vert it and you op­ti­mise mil­lisec­onds on a page that fails to sell for oth­er rea­sons. Keep it and per­for­mance be­comes ex­act­ly what it should be, a mea­sur­able con­tri­bu­tion to rev­enue you can de­fend in front of any CFO.