LCP, INP and CLS, measured in the field and fixed at the root
A Lighthouse score on its own is not enough; the user reality sits in field data. We measure LCP, INP and CLS in lab and field conditions, trace each one to its root cause, apply the fix, and then hold the result behind a written performance budget. A catalogue that will not open on a weak mobile network is a lost supplier evaluation.
SCOPE STRIP
When the site slows down, whose job is it?
Core Web Vitals ownership usually splits three ways: the marketing agency reports the metric, the software agency writes the code, the hosting provider keeps the server running. The metric breaks exactly where those three meet, so nobody owns it. We put measurement, root-cause analysis and the fix in one contract, and commit to target values rather than reports.
| Responsibility | Marketing agency | Software agency | Baki Bilisim |
|---|---|---|---|
| Who commits to a mobile LCP target value? | No | No | Yes |
| Who measures the INP cost of each tracking tag that gets added? | Partly | No | Yes |
| Who catches a performance regression after release? | No | Partly | Yes |
This is a responsibility map, not a competitor list. Why delivery and visibility belong in the same contract is set out on why we publish measurements instead of claims.
Why do users say “slow” when the Lighthouse score is high?
Lighthouse is lab data: one device, one fixed network, one load. The Core Web Vitals data Google uses in its ranking systems comes from the field: real Chrome users, measured over a multi-week window and assessed at the 75th percentile of page views. A page that passes in the lab can still fail on a weak mobile network.
What thresholds has Google published?
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP · Largest Contentful Paint | 2.5 s or less | 2.5–4.0 s | over 4.0 s |
| INP · Interaction to Next Paint | 200 ms or less | 200–500 ms | over 500 ms |
| CLS · Cumulative Layout Shift | 0.1 or less | 0.1–0.25 | over 0.25 |
Source: Google web.dev — Core Web Vitals (opens in a new tab) · Accessed: 2026-07-29
What is the measured effect of speed on revenue?
There is no single formula that converts milliseconds into money; sector, funnel and device mix all change the outcome. What exists is the measurement individual companies have published for their own sites. The three findings below are sourced and were produced by their owners, mostly through controlled tests. None of them transfers directly to your pages, which is why we measure yours before promising anything.
Total sales increase Vodafone measured after improving its LCP by 31%. In the same test, visit-to-lead conversion rose 15% and visit-to-cart 11%.
Source: Google web.dev — Vodafone case study (opens in a new tab) · Accessed: 2026-07-29
Revenue per visitor Rakuten 24 measured after a Core Web Vitals optimisation programme. Conversion rate rose 33.13% and average order value 15.20% in the same study.
Source: Google web.dev — Rakuten 24 case study (opens in a new tab) · Accessed: 2026-07-29
Retail conversion effect of a 0.1 second speed improvement on mobile; average order value rose 9.2% in the same analysis. Deloitte ran it across more than 30 million sessions from 37 European and American brands.
Source: Google web.dev — Milliseconds make millions (Deloitte) (opens in a new tab) · Accessed: 2026-07-29
What does this mean for manufacturers and exporters?
A corporate buyer usually builds the supplier shortlist away from an office desk: inside a plant, at a trade fair, on a weak mobile network. If the product catalogue is still blank in the second second, if the technical data sheet will not download, or if a form field gets mis-tapped because a banner shifted under the thumb, the loss happens during evaluation rather than in the rankings. That loss has no line in Search Console; it only shows up as the enquiry that never arrived.
For an international buyer the same fault has a geographic version. Server distance, redirect chains between language versions and region-specific third-party scripts split field data by market, so one global average can look acceptable while the market you are actually selling into sits in the poor band. We read field data per region and per page template for exactly that reason.
Metric definitions, measurement tools and the remediation checklist are set out in the LCP, INP and CLS threshold guide.
What exactly does this service deliver?
Nine items are delivered: a baseline measurement, a separate root-cause analysis for each of the three metrics, a critical request chain map, a font, image and JavaScript loading strategy, a written performance budget, a regression check running in the release pipeline, and a comparative closing measurement. The format and delivery week of each item is written into the contract.
| # | Deliverable | Format | When |
|---|---|---|---|
| 01 | Baseline measurement report (lab and field) | PDF report + raw JSON | Week 1 |
| 02 | LCP root-cause analysis | Prioritised finding list | Week 2 |
| 03 | INP root-cause analysis (long tasks, event handlers) | Breakdown per interaction | Week 2 |
| 04 | CLS source inventory (images, fonts, late-injected content) | Remediation list | Week 2 |
| 05 | Critical request chain map | Diagram + priority order | Week 3 |
| 06 | Font, image and JavaScript loading strategy | Implementation plan + code | Weeks 3–5 |
| 07 | Performance budget definition | Budget file + written thresholds | Week 4 |
| 08 | Release pipeline regression check | Automated check configuration | Weeks 5–6 |
| 09 | Comparative closing measurement and handover document | Before/after report + handover note | Weeks 6–8 |
What sits outside the scope is written down as well: server hardware procurement, performance defects inside third-party software itself, and the removal of scripts your side has not approved. Those are identified and reported, but they are not part of what we commit to.
In what order is the work carried out?
The order starts with measurement, not with a guess. Lab and field data are collected together; each metric is then traced to its root cause, findings are ranked by impact and cost, the performance budget is written, and the fixes are applied. Field verification is not closed before the data window fills. The final stage is regression protection.
-
01
Measurement set-up
Lab measurement (Lighthouse, mobile profile) and field measurement (CrUX plus real user monitoring) are established together. We collect a distribution per page template rather than one headline score: home, category, product, form and search results are measured separately, because they fail for different reasons.
-
02
Root-cause analysis
Each metric is broken down separately: resource discovery time and the critical chain for LCP, long tasks and event handlers for INP, images without size attributes, font swap and late-injected content for CLS. We list causes, not symptoms, and each cause carries an estimated millisecond contribution.
-
03
Prioritisation and performance budget
Findings are ranked by estimated impact and implementation cost. The numeric limits the page may not exceed are then written down: LCP target, first-load JavaScript weight, total page weight, third-party request count. The budget is not a document; it is the acceptance condition for the next stage.
-
04
Applying the fixes
Critical CSS separation, font loading with fallback metrics, image formats and size attributes, JavaScript splitting and deferral, and a third-party script policy are applied. Every change is measured on its own; we do not ship them as one batch, because a batch hides which fix actually worked.
-
05
Field verification
The lab measurement is repeated on release day. Field verification, however, is not closed until the data window has filled: nothing is called fixed before real user measurements accumulate. That waiting period goes into the schedule at the start, so it is never a surprise at the end.
-
06
Regression protection
The performance budget is wired into the release pipeline: a change that exceeds the budget does not ship. Field metrics are monitored periodically and drift is reported. Skip this stage and the scores return to their old level within a few releases; we prevent that with a mechanism, not with goodwill.
These six stages are the performance-specific form of our six-stage working model, contract and exit terms; no separate governance rhythm is introduced.
At which values do we call the work finished?
The engagement closes against six measurable criteria: mobile LCP under 1.8 seconds, INP under 200 milliseconds, CLS under 0.05, mobile Lighthouse Performance 95 or above, first-load JavaScript under 150 KB gzip, and zero third-party requests before consent. The tool and the moment of measurement for each criterion are agreed in advance.
| Criterion | Threshold | Measurement tool | Measured when |
|---|---|---|---|
| LCP (mobile) | < 1.8 s | Lighthouse (lab) + CrUX (field) | Release day + end of field window |
| INP | < 200 ms | Field measurement (CrUX + real user monitoring) | End of field window |
| CLS | < 0.05 | Lighthouse + CrUX | Release day + end of field window |
| Lighthouse Performance (mobile) | ≥ 95 | Lighthouse, mobile emulation profile | Release day |
| First-load JavaScript weight | < 150 KB gzip | Browser network panel + bundle report | Before every release, automated |
| Third-party requests (before consent) | 0 | Browser network panel | Before every release, automated |
We publish our own measurement as well
The site this page belongs to was built to the budget above: there is no image above the fold, so the LCP element is text; two variable fonts are self-hosted; no third-party request is made on first load. The measured values are published with the tool name and the measurement date on this site’s measured scores, as measurements rather than claims. A line that cannot be measured is not published here at all.
In which industries does speed turn directly into lost revenue?
Speed becomes revenue on the pages closest to the buying decision: the product catalogue, the technical document download, the dealer locator, the order and quotation forms. When those pages fail on a weak mobile network in the field, the loss happens inside the funnel rather than in the rankings. Typical failure points in five segments follow.
- 01 Manufacturing and Factories Technical data sheets and product catalogues are usually heavy PDFs and large images; when those pages will not open on a mobile network in the field, the supplier evaluation ends before it starts.
- 02 Retail Chains Campaign banners, chat widgets and tracking tags stack on top of each other and break INP and CLS; a mis-tap caused by a button that shifted under the thumb is an abandonment, not a nuisance.
- 03 Franchise Networks The location finder and the franchise application form usually load alongside a map component; one map script drags down the LCP of hundreds of location pages at the same time.
- 04 Export Industry When the target market sits outside Turkey, server distance and the separate weight of each language version split field data by region; a single average score hides precisely the market that is failing.
- 05 Corporate Holdings When subsidiary sites are run by different agencies the performance standard disappears; without one shared performance budget no comparable measurement can be produced across the group.
Frequently asked questions about Core Web Vitals
Eight questions, answered directly. Where an answer contains a number, its source and access date are inside the answer.
What are Core Web Vitals?
Core Web Vitals are the three field metrics Google defines to measure the user experience of a page: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) and CLS (Cumulative Layout Shift). They measure loading speed, interaction responsiveness and visual stability respectively. The values come from real Chrome users, not from synthetic tests.
What counts as good LCP, INP and CLS?
According to the thresholds Google publishes, the good range is: LCP 2.5 seconds or less, INP 200 milliseconds or less, CLS 0.1 or less. The values are assessed at the 75th percentile of page views, separately for mobile and desktop. Source: Google web.dev, accessed 29 July 2026.
Why do lab and field data give different results?
Lab data is produced synthetically on one device, one fixed network and a single load. Field data carries the device, network, cache and interaction variety of real users and is collected over a window that spans weeks. INP only occurs through real interaction, so it has no exact lab equivalent; the two data types are therefore read together.
How much does speed affect rankings?
Google states that page experience signals are used in its ranking systems, but that a good experience does not promote irrelevant content. In practice speed separates pages of similar relevance; its measurable effect shows up in conversion, bounce rate and session depth. We do not promise rankings, we commit to measurable metric targets.
Can my WordPress site be made fast, or should it be rebuilt?
Most WordPress sites can be brought to threshold without a rewrite: a plugin inventory, the theme’s request chain, and an image and font strategy usually repair LCP and CLS. Two numbers decide the rebuild question after measurement: the volume of third-party JavaScript that cannot be removed, and the length of the critical chain the theme creates.
What is a performance budget?
A performance budget is the set of numeric limits a page may not exceed: for example mobile LCP 1.8 seconds, 150 KB gzip of JavaScript on first load, zero third-party requests before consent. The budget is checked automatically before release and a change that exceeds it does not ship. Optimisation without a budget is reversed within a few releases.
Once the scores improve, do they stay improved?
Not on their own. Performance breaks with a new tag, image, plugin or third-party script. Durability comes from two mechanisms: a performance budget check running in the release pipeline, and periodic monitoring of field data. Without both, scores typically return to their previous level within a few releases.
Do you work with companies outside Turkey?
Yes. Performance work is remote by nature: measurement, root-cause analysis and code changes need repository and analytics access, not a shared office. Reporting, the performance budget and the contract are produced in English. For sites serving buyers abroad we read field data by region, because a single global average hides the market that is actually slow.
Questions about pricing, contract length and international invoicing are answered on the general FAQ page.
See the measured state of your website within five working days.
The audit is free and creates no obligation to work with us. The report itemises findings on AEO answerability, AI crawler access, lab-measured Core Web Vitals, structured data validity and accessibility (automated scan).
We work with corporate-scale, multi-location or multilingual organisations. One-off small jobs fall outside our scope; in that case we point you to smaller studios.