Core Web Vitals Case Study in Pakistan

The Client

A Karachi-based clinic-management SaaS — appointments, patient records, and billing software sold to single-doctor practices and small chains across Pakistan, with roughly 900 paying clinics on tiers from PKR 12,000 to PKR 40,000 a month. The company ran lean: twenty-two people, of whom exactly two touched the marketing site, a React-based build with a blog of 120-plus articles carrying most of its organic visibility.

The go-to-market motion made the marketing site load-bearing in a way that pure e-commerce stores rarely are. There was no self-serve signup and no free tier in the early days of the engagement: every pipeline dollar flowed through a single conversion — the demo request form — after which an inside sales rep took over. The site drew around 52,000 sessions a month, 64% of them mobile, and organic search supplied the majority. Doctors and clinic administrators, the buyer persona, browse on whatever the reception desk and their pocket allow: overwhelmingly mid-range Android handsets on mobile networks, not the laptops a Karachi software team tests on.

That persona reality is what made this a SaaS marketing problem rather than an infrastructure nicety. A clinic owner who waits five seconds for a page to settle is not a delayed demo request; they are a completed bounce, because the waiting happens between patients at a reception counter where five seconds of attention is the entire budget available. Every performance failure on this site was, in commercial terms, a rep’s calendar with holes in it.

The founding team engaged WeProms after a quarter in which demo volume had drifted down while traffic held. They suspected competitors and ranking loss. The first week of field-data review pointed somewhere cheaper to fix: the site had spent that quarter getting materially slower for exactly the devices its buyers used.

The Problem

The performance failures stacked into a single bad experience on a Pakistani Android phone:

• The hero was the problem. A 4.1MB background video autoplayed on the homepage and every feature landing page, making it the largest contentful paint element by definition. On a mid-range device on a throttled network, the page’s main visual commitment took more than four seconds to arrive.
• Images arrived unprepared. CMS uploads shipped as 2–4MB JPEGs at a single width — product screenshots, clinic photos, team headshots — with no responsive sizing, no modern formats, and no dimensions in the markup, so the browser reflowed the layout each time one landed.
• Scripts ran before content. Five font files in two scripts, a chat widget, three analytics tags, a heatmap tool, and an A/B testing script — the last running with zero active experiments — all loaded synchronously in the head, competing with the page’s own content for the connection and the main thread.
• The demo form was the slowest interactive element on the site. A 410KB third-party form embed rendered the one component the entire business depended on, blocking interaction for close to a second on the devices that mattered.
• Pakistan was an afterthought in the architecture. The origin served from a single overseas region with no CDN in front. Time to first byte from Karachi averaged 720ms before a single byte of the page itself began to arrive — a tax every visitor paid on every page.
• Nothing was measured where it counted. The team had a lab score from a dev-machine audit and no field data at all. No one had looked at what real Pakistani users on real devices actually experienced, which is why a site that felt fine in the office could be failing four-fifths of its visitors.

For a SaaS company whose entire pipeline runs through one form on one slow page, this was not a technical hygiene issue. It was a revenue issue wearing an infrastructure costume.

Phase 1 — Field-Data Diagnosis and Baseline (Weeks 1-2)

Phase 1 established the rule that governed the rest of the engagement: field data outranks lab data, and lab data exists to explain field data, not replace it. We pulled CrUX field readings and the Search Console Core Web Vitals report, installed real-user monitoring with the web-vitals library, and ran per-template lab audits to explain what the field numbers reported.

Metric (mobile, p75)	Baseline	Good threshold
LCP	4.3s	≤ 2.5s
INP	340ms	≤ 200ms
CLS	0.21	≤ 0.1
TTFB from Karachi	720ms	—
CWV pass rate	31% of template groups	100%
Bounce rate	53.1%	—
Visitor → demo	2.7%	—

The third-party inventory. We audited every external script by transfer size and main-thread blocking time, and put a disposition against each one. This table became the negotiation agenda for Phase 2:

Third party	Transfer	Main-thread blocking	Disposition
Form embed	410KB	920ms	Replaced with native implementation
Chat widget	310KB	850ms	Reconfigured to load on intent
Three analytics tags	220KB	310ms	Consolidated into one
A/B testing tool	180KB	240ms	Removed — zero active experiments
Heatmap tool	140KB	190ms	Sampled to 10% of sessions

Template-level attribution. Field data was segmented by template group — homepage, ten feature pages, pricing, demo, blog index and posts. The homepage and feature pages failed all three metrics; blog posts failed LCP and CLS but passed INP; the pricing page failed INP alone. Only 31% of template groups passed everything. The fixes, in other words, were not uniform: each template had a named failure and would get a named treatment.

Phase 1 closed with the baseline frozen in a shared dashboard, per-template, so that week-over-week claims would answer to a fixed starting point.

Phase 2 — Asset, Script, and Infrastructure Rebuild (Weeks 3-5)

Phase 2 was the structural rebuild — the work that changes what the browser downloads, which is the only work that moves field data at scale. It followed the site speed and Core Web Vitals optimization sequence we run for Pakistani marketing sites.

The hero, demoted. The 4.1MB autoplaying video became a 220KB optimized poster image that paints instantly, with the video behind a click-to-play control. Nothing about the design language changed; the change was that the page’s largest element now weighed two hundred kilobytes instead of four thousand. Lab LCP on the homepage fell below 1.5s the day this shipped.

An image pipeline, not a cleanup. CMS images moved through AVIF and WebP variants with responsive srcsets, width and height baked into the markup, and blur-up placeholders. Upload constraints capped future images at sane dimensions, so the fix survived the next content hire — a deliberate concern, since the blog was the site’s organic engine.

Fonts on a diet. Five weights across Latin and Urdu script subsets became two weights with a minimal Urdu subset loaded only on the pages that render Urdu, preloaded and swapped rather than blocked. Text stopped waiting on fonts to appear at all.

Scripts renegotiated, not just deferred. The dispositions from Phase 1 executed: the form embed replaced with a native HTML form posting to the same endpoint with async validation — the demo form’s interaction cost effectively vanished; the chat widget reconfigured to load on first scroll or intent, with chat-initiated demos holding steady at around 34 a month, confirming deferral cost nothing; the unused A/B tool deleted; analytics consolidated; the heatmap sampled.

Edge delivery for Pakistani traffic. Static assets and HTML moved behind a CDN with points of presence serving Pakistan, with long-lived caching for immutable assets and stale-while-revalidate for HTML. Time to first byte from Karachi fell from 720ms to roughly 180ms — a before-and-after every visitor’s phone felt on every navigation.

Layout stability at the component level. The testimonial slider that loaded late and shoved content downward got reserved space; embeds got aspect-ratio boxes; images got dimensions. CLS is unglamorous arithmetic — reserve the space, and the shift cannot happen.

Phase 3 — Interaction Tuning and Budget Enforcement (Weeks 4-8)

With payloads fixed, Phase 3 attacked what remained: how the page behaved under fingers.

INP work. Long main-thread tasks on the pricing page were split; a JavaScript animation library behind the plan-toggle interaction was replaced with CSS transitions; input handlers were rewritten to yield rather than compute synchronously. The form’s own validation moved off the critical path so that a tap on a field responded in the same frame it was received. Interaction to Next Paint fell from 340ms to the 150s as the blocking work underneath it disappeared — and notably, none of it required heroics, because by Phase 3 the main thread was no longer crowded: subtraction in Phase 2 had done most of the work before tuning began.

Prefetch where intent shows. The demo route now prefetched on hover and on viewport intersection from the pricing and feature pages, so the click that matters most in the funnel landed on a page that was already arriving. This is a deliberately cheap trick that pays outsized dividends on high-latency last-mile networks: the round-trip the buyer would have paid for after the click is spent before it, during the seconds they spend reading the pricing table with their thumb already hovering over the CTA.

Budgets with teeth. The change most responsible for the results lasting: per-template performance budgets wired into the deploy pipeline, with the build failing on regression beyond tolerance. LCP, total transfer weight, and third-party script count each carry a ceiling per template. Marketing could still ship anything — within a budget the site’s economics had already paid for.

RUM as the referee. Real-user monitoring stayed live, reporting p75 vitals by template and device class, with alerting on sustained regression. The dashboard that closed Phase 1 became the permanent instrument panel; the office wifi lost its vote permanently.

Guardrail	Budget set at
Homepage lab LCP	≤ 2.0s
Total transfer, feature pages	≤ 1.2MB
Third-party scripts, any page	≤ 4, ≤ 350KB combined
CLS, any template	≤ 0.05
CI behaviour	Build fails on breach

Phase 4 — Monitor, Verify, and Compound (Weeks 8-12)

Field data moves on its own calendar. CrUX and Search Console aggregate over rolling 28-day windows, so Phase 4 was largely the discipline of waiting correctly: watching matured windows rather than reacting to daily noise, and reading the funnel alongside them.

The pass-rate climb. Template groups crossed over as their 28-day windows filled with post-fix sessions: 31% at baseline, 68% by week six, 100% by week eleven. The homepage and feature pages — the templates carrying the demo conversion path — were among the first to clear, which is why the behavioral metrics moved before the pass rate finished.

Behavior followed speed. Bounce fell from 53.1% to 43.0% over the window — a 19% relative drop, concentrated exactly where the diagnosis predicted it would be: mobile sessions on feature pages that had previously failed LCP. Pages per session rose from 2.1 to 2.5. Visitor-to-demo conversion rose from 2.7% to 3.4%, worth roughly 364 additional demo requests a month on identical traffic. Chat-initiated demos held steady, confirming that script deferral traded nothing away.

The compounding base. With the technical layer stable, the natural next workstream for this company is the one speed work quietly enables — SEO for SaaS companies built on a site that no longer taxes every crawl and every visitor. Organic sessions trended up modestly in the weeks after the fixes, consistent with recoveries where the ranking effect trails the user-experience effect; we deliberately made no headline claim from it, because the field-data and conversion movements were the honest, attributable results.

Handoff. The engagement closed with a runbook: the budget table, the script inventory with dispositions, the RUM dashboard, and a quarterly review cadence. The two-person marketing team can ship within budget without asking permission, and the pipeline fails loudly when something threatens the numbers that now fund it. One ritual from the engagement survived as a habit worth copying: the monthly review opens with the RUM p75 readings before anyone is allowed to discuss traffic or rankings — the site’s actual condition on Pakistani devices sets the context for every growth conversation that follows.

Final Results at 90 Days

Metric (mobile, p75)	Before	After	Change
LCP	4.3s	1.8s	−58%
Interaction to Next Paint	340ms	150ms	−56%
Cumulative Layout Shift	0.21	0.04	−81%
CWV pass rate	31%	100%	+69 points
TTFB from Karachi	720ms	180ms	−75%
Bounce rate	53.1%	43.0%	−19% relative
Visitor → demo request	2.7%	3.4%	+26%
Pages per session	2.1	2.5	+19%

Every row traces to a phase: LCP and TTFB to the asset and CDN rebuild, INP to script renegotiation and interaction tuning, CLS to component-level reserved space, and the behavioral rows to the composite of all of it landing on the devices the buyer actually holds. These are illustrative outcome ranges built from the patterns WeProms sees across Pakistani marketing-site performance engagements — not audited third-party figures. They exist so a growth team can sanity-check what a vitals recovery should plausibly return for a site of this shape in this market.

What Made This Work

1. Field data set the priorities. The office connection had been assuring the team the site was fine for a year. CrUX, Search Console, and real-user monitoring on actual Pakistani devices replaced that assurance with measurements — and the measurements named the hero video, the form embed, and the uncached overseas origin as the three items worth fixing first.

2. Scripts were renegotiated, not decorated. Deferring a heavy widget hides its cost below the fold; replacing the form embed and deleting the unused A/B tool removed the cost entirely. The INP halving came from subtraction, which is also why it survived.

3. The gains were made structural. Budgets in CI, upload constraints in the CMS, and RUM alerting meant the recovery did not depend on anyone remembering it. Speed work that lives only in a Slack thread decays within a quarter; speed work that lives in the pipeline compounds.

4. Templates were treated individually. The pricing page’s INP failure and the homepage’s LCP failure had different causes and different fixes. A single sitewide pass would have over-fixed some templates and under-fixed the one carrying the demo form.

5. The business metric stayed in the room. Demo conversion sat beside LCP in every weekly read, which kept the work honest in both directions: no vitals target was pursued at the expense of the funnel, and no funnel claim was made that the vitals data could not support.

What Teams Can Apply

For Pakistani SaaS and marketing-site teams whose mobile experience quietly lags their office connection:

1. Read field data before anything else. CrUX and the Search Console Core Web Vitals report cost nothing and reflect the devices your buyers hold. If your only performance evidence is a lab run on fast hardware, you do not yet know your site’s speed.
2. Put your largest element on a diet first. LCP is decided by one element. An autoplaying hero video or an unoptimized hero image is the most common four-second sentence a Pakistani marketing site serves its visitors — and the cheapest to commute.
3. Inventory third-party scripts by blocking time, not just bytes. A 410KB form embed blocking 920ms of main thread is worth more removed than a megabyte of images optimized. Delete the tools you no longer use; you are paying for them in every session.
4. Serve Pakistan from near Pakistan. A CDN with in-country or adjacent points of presence cuts 400–500ms of TTFB before any code changes. It is the single infrastructure change every visitor benefits from on every page.
5. Give your budgets enforcement. A performance budget that lives in a document is a suggestion; one that fails the build is a system. Wire it into CI with per-template ceilings, and monitor real users afterward so the office connection never gets the deciding vote again.

WeProms Digital has run this framework across SaaS, ecommerce, and publishing sites in Karachi, Lahore, and Islamabad. The stacks differ; the sequence — field-data diagnosis, payload rebuild, script subtraction, edge delivery, budgeted CI — stays the same.