A slow store does not lose visitors. It loses orders.

What it cost

~2s TTFB

about 70% of the LCP failure · ads traffic worldwide

A high-traffic store selling worldwide through Meta and Google ads, where every landing URL carries campaign params and a geolocation currency switcher busted the page cache per currency. TTFB sat around 2 seconds, roughly 70% of the LCP failure. On ads traffic, cache experiments gone wrong showed up same-day as conversion crashes: one Spanish-campaign crash took the conversion rate to near zero for a day. Checkout 504 storms added their own lost orders during campaigns.

The fix

• Per-currency page-cache architecture, so the currency switcher stops busting the cache
• Cache-control conflicts resolved between CDN and store
• FunnelKit checkout stabilized; 504 storms during campaigns ended
• Migration to Cloudflare and Hetzner

What came back

sub-1s TTFB

cache safe to test · conversion crashes gone from the log

TTFB came down from ~2s to sub-1s, and the cache became safe to test on live ads traffic. That was the client's framing of the whole job: live testing on this traffic means burning money, so even a 1% conversion improvement covers the server budget.

Full ads-side receipt on the Ads & Conversion page →

Read the full case study →

What it cost

a month of ad spend, zero orders

the owner's report, Google Ads and social

Ad clicks landed on a store that took too long to open, and the owner's report after a month of spend was zero orders. A 2026 re-audit measured 4 MB mobile payloads and 2.5 to 3s uncached TTFB. The budget did not fail. The store it pointed at did.

The fix

• Full-store speed on the Elementor build: nginx fixes, LiteSpeed crawler throttled under load
• Cron cache warming, so the cache is hot before the ads land
• REST API kept fast: the store feeds a mobile app through the Woo API
• Elementor Pro template features that forced full page reloads on product filtering reworked instead of a rebuild

What came back

~100ms cached TTFB

from 2.5s · phase-2 retainer active since 2026 · public feedback 5.0

From 2.5s TTFB to ~100ms cached. When the client's senior developer recommended dropping Elementor outright, the honest answer was that a rebuild costs weeks while optimization gets Elementor green, so the template-level cause was reworked instead. The relationship continued into a phase-2 infrastructure retainer.

Full ads-side receipt on the Ads & Conversion page →

What it cost

5s TTFB

clinic and store on one slow origin

The clinic site carries a store, and the whole origin was slow: 5s TTFB, with GTranslate language pages among the worst offenders. The first rescue took 18 months of caching and server work. Then the 2026 Colibri-to-Elementor rebuild quietly reintroduced frontend pain: a 5.4 MB PNG hero sat as a CSS background inside the Elementor page stylesheet, discoverable only after 51 render-blocking stylesheets, about 1.2s of discovery delay, while Lighthouse still looked fine and CrUX showed the damage.

The fix

• The rescue: page-caching rework, Redis object caching, PHP-FPM tuning
• GTranslate pages fixed; later, /es/ pages cached through Cloudflare
• The rebuild repair: hero re-served as optimized WebP with fetchpriority=high
• A second page went 3.6 MB to 83 KB; stylesheet chain trimmed, leftover block plugins removed

What came back

1.19s TTFB

from 5s · the rebuild trap, closed

TTFB settled at 1.19s. The rebuild is the cautionary half of the story: a site that had already been rescued once lost the work silently, because the lab test never scrolled and the field data did. Store owners rebuilding a theme should re-run the speed work the week the rebuild ships, not the quarter after.

The builder anatomy on the Elementor page →

What it cost

0.45 CLS

flagged in Search Console

A CLS program opened by Search Console's own report: 0.45 CLS on an Elementor + WooCommerce build, with the shifts coming from popups and late-loading assets on a store selling to two countries. On a webshop, layout shift is not cosmetic: the buttons it moves are Add to cart and checkout.

The fix

• Elementor font subsetting saved roughly 500 KB
• New dedicated server for the store
• Prebuilt static HTML delivery for 99% of visitors
• Popup-caused layout shifts stabilized

What came back

~0 CLS

from 0.45 · visitors on static HTML, editor untouched

CLS settled near zero. The builder stayed as slow as ever in the editor, and that was fine: the editor path is not the visitor path. 99% of visitors now get prebuilt static HTML, and the team keeps the workflow they know.

The builder anatomy on the Elementor page →

What it cost

984 URLs failing

mobile CrUX, product URLs across the store family

984 product URLs failing mobile Core Web Vitals in CrUX across a family of four stores, with checkout failing in a way scores did not show: a WAF was blocking the checkout AJAX calls, so carts died mid-funnel on a medical store where the order matters most.

The fix

• WAF-blocked checkout AJAX unblocked
• Dynamic caching restored for cart and checkout
• EWWW and PHP 8 plugin conflicts resolved

What came back

CWV green

held across a three-year ongoing relationship

The failing URLs recovered to Core Web Vitals green. The ongoing relationship is the point of this arc: three years of holding vitals green across four stores while catalogs, plugins, and PHP versions kept changing underneath.