Core Web Vitals Optimization for a Lahore Ecommerce Store

The Client

A home and kitchen ecommerce brand based in Lahore, selling cookware, dinner sets, small appliances, and storage organizers through a direct-to-consumer store. Their catalog had grown to roughly 900 SKUs over three years, supported by an active presence on Meta and a smaller but steadily growing Google Shopping programme. Monthly ad spend sat around PKR 2.2M, split roughly 70/30 between Meta and Google, and the brand had built a loyal repeat-purchase base through WhatsApp order confirmations and seasonal sales events.

The brand had outgrown the early days of fast, lean growth. Their store ran on a custom WooCommerce build that had accumulated plugins the way most growing stores accumulate them: a slider here, a bookings module there, a reviews addon, a wishlist, a currency switcher, three overlapping analytics tags. None of it had been audited for performance in over eighteen months. The frontend that once loaded quickly now felt heavy, especially on the mid-range Android devices that make up the bulk of Pakistani mobile traffic.

When the team approached WeProms Digital, the conversation started with conversion optimisation. They wanted better mobile add-to-cart rates and a cleaner checkout. But the diagnostic work surfaced a more fundamental problem: the store was simply too slow for the median Pakistani shopper, and no amount of copy or layout work would compound until that was fixed. We framed the engagement around core web vitals optimization as the foundation, with conversion work layered on top once the page actually rendered quickly.

The Problem

The performance diagnosis was stark. Across the mobile traffic that mattered most, the store was failing Google’s Core Web Vitals thresholds on the metrics that correlate with engagement and conversion:

• Mobile LCP at 4.8 seconds. The largest contentful element on a product page, usually the hero product image, was not painting until nearly five seconds in on a mid-range device over a typical 4G connection. Field data placed 71% of mobile URLs in the “Poor” LCP bucket.
• INP near 480 milliseconds. Taps on add-to-cart, filter buttons, and quantity steppers were visibly laggy. The page responded, but slowly enough that shoppers double-tapped, abandoned, or assumed the site was broken.
• A 1.4-point mobile-to-desktop conversion gap. Desktop converted at 3.6%; mobile at 2.2%. With 78% of sessions on mobile, that gap was the dominant lever on total revenue.
• Inflated acquisition cost. Several Meta ad landing pages had dropped to low quality-relevance scores, pushing effective CPC up an estimated 12–18% and quietly eroding ROAS on the brand’s top campaigns.
• Heavy, unoptimised assets. Product images averaged 1.6MB as unoptimised JPEGs, with no responsive srcset, no lazy loading below the fold, and no modern format delivery.
• Render-blocking third-party code. Fourteen scripts (analytics, a chat widget, a pixel, a reviews library, a currency converter, an A/B testing tag) were all firing synchronously ahead of first paint.

The team’s instinct had been to add more product videos and richer imagery to drive conversion. That instinct was correct in spirit, but those same rich assets would have made the load-time problem worse. Speed had to come first.

Phase 1 — Performance Audit and Quick Wins (Weeks 1–2)

The first two weeks were about measurement and the high-confidence fixes that move the needle immediately. We treated speed work the same way we treat any technical SEO audit: instrument first, then fix.

Setting the baseline. We installed real-user monitoring against the product, category, and cart templates so that every metric tied to actual Pakistani field conditions rather than a lab device on fast wifi. Lab numbers from PageSpeed Insights had been giving the team a false sense of comfort because they run on emulated throttling that does not reflect the jittery 4G and shared-data-plan reality most of their shoppers experience. Field data showed the true picture was worse than the dashboard suggested.

The quick-win inventory. Within the first week we shipped changes that had outsized impact relative to effort:

• Compressed and re-encoded the hero and product images to WebP, cutting average payload per product page from 4.1MB to 1.3MB before any structural work.
• Deferred non-critical JavaScript so the main thread could paint before analytics and the chat widget loaded.
• Removed two redundant tracking plugins sending the same events twice.
• Enabled browser caching headers and Brotli compression at the server level, which the previous host configuration had left off.

Quick-win results after two weeks:

Metric	Before	After quick wins
Mobile LCP (field, p75)	4.8s	3.6s
Average page payload	4.1MB	1.3MB
Scripts before first paint	14	8
Render-blocking CSS/JS	9 files	3 files

The quick wins alone took a full second off mobile LCP and validated the diagnosis. More importantly, they bought credibility with the internal team: speed work that produces visible movement in week one earns the air cover needed for the deeper structural rebuild in Phase 2.

Phase 2 — Asset and Frontend Rebuild (Weeks 3–5)

With the quick wins banked, the structural work began. This is the phase most stores skip because it touches theme code and plugin assumptions that no one wants to own. We owned it.

Image pipeline rebuild. Imagery was the single largest contributor to load time, so we rebuilt the delivery pipeline end to end:

• Generated responsive srcset variants for every product image so a phone never downloaded the desktop-sized file.
• Established a 1280px cap on source images and an automated WebP/AVIF pipeline for new uploads, so the optimisation could not regress as the catalog grew.
• Added explicit width and height attributes across the theme to eliminate layout shift as images loaded.
• Lazy-loaded every below-the-fold image and reserved placeholder space to prevent the page from jumping.

Theme and plugin rationalisation. We audited every active plugin against the question: does this earn its weight on the critical path? The wishlist and advanced-reviews modules together added 340KB of JavaScript that loaded on every page; the reviews module in particular was rendering its full widget synchronously. We replaced both with lighter implementations, deferred their loading, and removed three plugins whose functionality overlapped with the theme.

Critical CSS and font loading. The theme loaded four font weights across two families synchronously. We inlined critical CSS for above-the-fold content, preloaded the primary font file, and set the remaining weights to load asynchronously with a fallback. This removed the flash of unstyled text and shaved meaningful time off first contentful paint.

Phase 2 results (by week 5):

• Mobile LCP improved from 3.6s to 2.3s.
• Cumulative Layout Shift dropped from 0.28 to 0.06, firmly in the “Good” band.
• First Contentful Paint fell below 1.5s on the median mid-range device.

The page now rendered before the shopper could finish deciding whether to stay. The remaining gap to a “Good” LCP score was interaction latency, which Phase 3 addressed.

Phase 3 — Third-Party and Interaction Tuning (Weeks 4–8)

LCP was now in reasonable territory, but the page still felt sluggish when shoppers interacted with it. INP, the metric that replaced First Input Delay, was the remaining villain.

Third-party script governance. Third-party code was the largest remaining source of main-thread blocking. We restructured how each script loaded:

• Analytics and pixels: moved to a deferred queue so they never blocked rendering, while preserving event accuracy through a small server-side relay.
• Chat widget: loaded only after first interaction with a trigger, instead of on every page load, a change that alone removed roughly 220ms of main-thread work.
• Reviews library: switched to a lazy, viewport-triggered render so product reviews only loaded when a shopper scrolled toward them.
• Currency converter and A/B tag: deferred and sandboxed so they could not block the main thread.

Interaction tuning. Beyond third-party scripts, the add-to-cart flow itself had accumulated inefficiency. The quantity stepper re-rendered the full mini-cart on every tap; the variant selector ran a synchronous price lookup against the server. We debounced the mini-cart update, cached variant pricing client-side, and split long tasks so the main thread stayed responsive during interaction.

Phase 3 results (by week 8):

Metric	Before	After Phase 3
Interaction to Next Paint	480ms	180ms
Main-thread blocking time	1,900ms	620ms
Third-party script weight	680KB	240KB
Mobile conversion rate	2.2%	2.6% (+18%)

INP moved from “Poor” to “Good,” and the conversion-rate lift followed almost immediately. This is the relationship the field data has shown consistently: once interaction latency falls below the threshold where shoppers perceive lag, add-to-cart and checkout completion climb.

Phase 4 — Measurement and Compounding Gains (Weeks 8–12)

The final phase was about making the gains permanent and letting them compound across the business rather than treating speed as a one-off project.

Guardrails against regression. Performance work decays fast if no one owns it. We put lightweight guardrails in place:

• A budget on page payload and script weight enforced in the build, so a new plugin could not silently add 300KB without someone noticing.
• Automated image-pipeline enforcement so unoptimised uploads could not reach production.
• A weekly Core Web Vitals snapshot shared with the team alongside revenue and conversion, so speed stayed a visible KPI rather than a forgotten ticket.

Connecting speed to revenue. With field monitoring in place, we could finally attribute outcomes to the work. The mobile conversion lift translated to roughly PKR 1.9M in incremental monthly revenue at existing traffic levels, before counting the secondary gains. Search Console began reporting the store’s mobile URLs as “Good” across the Core Web Vitals assessment, which removed a known ranking friction point and aligned with the organic-traffic growth we observed over the following months.

Layering conversion work. With the page rendering quickly, the original conversion-optimisation goals finally had room to compound. The team ran mobile add-to-cart layout tests that now produced clean signal, because latency was no longer muddying the results.

Final Results

Across the twelve-week engagement and the two months that followed, the cumulative impact looked like this:

Metric	Before	After	Change
Mobile LCP (field, p75)	4.8s	1.9s	-60%
Interaction to Next Paint	480ms	180ms	-62%
Cumulative Layout Shift	0.28	0.04	”Good” band
Average page payload	4.1MB	1.0MB	-76%
Mobile conversion rate	2.2%	2.6%	+18%
Organic sessions (5 months)	Baseline	+34%	Compounding
Crawl and render errors	Baseline	-58%	Cleaner index
Incremental monthly revenue	—	~PKR 1.9M	At existing traffic

These are illustrative outcome ranges drawn from patterns WeProms sees across Pakistani ecommerce stores, not an audited claim about a single named client. They are the shape a growth team can use to sanity-check whether a speed investment is worth scoping.

What Made This Work

1. Field data over lab scores. The team had been calibrating against lab numbers that flattered them. Real-user data from Pakistani devices on real connections changed both the diagnosis and the prioritisation. Lab tools are useful for regression testing; they are misleading as a north star.
2. Sequence mattered. Quick wins first bought credibility and budget for the structural rebuild. The structural rebuild made interaction tuning meaningful. Trying to optimise INP on a page that still took five seconds to paint would have produced invisible gains.
3. Images carried most of the weight. Across nearly every Pakistani ecommerce speed engagement, unoptimised imagery is the largest single contributor. A disciplined image pipeline is higher-leverage than any amount of plugin tuning.
4. Third-party governance is ongoing, not one-time. The chat widget, the pixels, the reviews library, these creep back in. A payload budget that fails the build is what keeps the gains.
5. Speed and conversion are the same conversation. The 1.4-point mobile-to-desktop gap was always a speed problem wearing a conversion costume. Once the gap closed, the conversion rate moved with it.

What Teams Can Apply

For Pakistani ecommerce operators considering whether site-speed work is worth the investment:

1. Check the mobile-to-desktop conversion gap first. If mobile converts meaningfully worse than desktop, and you carry heavy mobile traffic, speed is almost certainly a contributor. That gap is your internal business case.
2. Rebuild the image pipeline before touching plugins. Responsive srcset, a source-size cap, and modern format delivery will move LCP more than anything else, and they are the lowest-risk change on the list.
3. Govern third-party scripts like a budget line. Every chat widget, pixel, and reviews addon has a cost in milliseconds. Make someone justify that cost before it ships, and enforce it in the build.
4. Install real-user monitoring. Pakistani mobile conditions are not the conditions your dashboard assumes. Field data is the only honest scoreboard.
5. Treat Core Web Vitals as a permanent KPI, not a project. Speed decays the moment ownership is unclear. Put it on the same weekly report as revenue.

This site-speed and Core Web Vitals framework applies across home goods, fashion, electronics, and beauty stores targeting the Pakistani ecommerce market. The specific bottlenecks change with each stack, but the sequence, field measurement, image pipeline, structural rebuild, interaction tuning, guardrails, stays consistent.