Skip to content

Jewellery DTCClient work

The 97 That Was a Lie

A UK jewellery store's PageSpeed score was faked for the benchmark. The honest score was 78; real optimisation reached 92 and LCP fell from 3.4s to 1.2s.

The brief

Context

A UK jewellery DTC brand selling on Shopify. The owner asked for two things: make the store faster, and explain why Meta CPMs looked very high. I worked as the sole contractor: speed, then a tracking-integrity review of what the ad account and the storefront were actually doing.

Sounds familiar?

What the client saw

The situation Jewellery DTC
Tick what applies to you

Tick the lines that describe your case.

Describe my task

The investigation

How I diagnosed it

  1. Decoded the injected script statically, without running its payload. The theme head carried an obfuscated snippet with two eval(atob(...)) blocks. I decoded both blocks and read exactly what they did.

  2. Proved the behaviour at runtime. I loaded the same product page under two device contexts and counted how many scripts each one had deferred.

  3. Took a full theme baseline snapshot before touching anything, then produced a fixed variant and an optimised variant, each with a rollback note.

  4. Ran an A/B/C comparison on one product page in three states: as-was, cloak removed, and honestly optimised.

  5. Reviewed the Meta setup at dataset and event level — integrations present, dedup status, dependency history — and broke the campaign CPMs down from the ad account itself.

Findings

What I found

  1. Finding 01

    The score was manufactured for the benchmark, not for shoppers

    The snippet activated only in a test-robot environment: one block checked for navigator.platform containing x86_64, the other for X11 and GTmetrix. When active, it rewrote dynamically added scripts to a lazyload type and stripped their resource URLs, so the page looked fast to the measuring tool.

    The runtime numbers make it concrete: a real phone deferred 0 scripts and loaded the full, un-optimised page, while the benchmark bot had 75 scripts deferred. Buyers were experiencing roughly a “78-class” page while the dashboards showed a green 97. Once the snippet was removed, the honest score was 78.

  2. Finding 02

    Meta tracking was not broken

    Both datasets carried a Meta pixel and a Conversions API integration; the inspected views showed no active dedup error. The real issue was redundant parallel measurement across two datasets, with dataset totals that spanned several domains. That is a consolidation question, not a rescue — and it needs a domain-level split and event-level dedup confirmation before any cutover.

  3. Finding 03

    The CPM premise did not hold up

    The high US CPMs were concentrated in specific campaigns; no storefront or tracking cause was supported. The exact reason needs campaign-level comparison of audiences, placements, bidding and frequency, which is a media-buying question rather than a measurement one.

Handover

What I fixed

Delivery noteDelivered Jul 2026

  1. Removed the cloaking snippet from the live theme, with the theme baseline and a rollback note saved.
  2. Added an LCP image preload (fetchpriority=high) so the hero renders sooner.
  3. Deferred non-critical apps (a size-chart app and a session-recording script) until interaction or idle, using a gatekeeper that explicitly excluded all tracking and the cart and swatch apps — so the speed gain did not come from delaying measurement or breaking checkout.
  4. Delivered the client report, the master technical report and answers to the client’s eight questions, plus an approval-gated, reversible dataset consolidation plan.
  5. No production tracking change was made. The dataset cutover stayed open on purpose until domain-level attribution and event-level dedup could be confirmed.

Before → after

Results, with dates

Client work Done for real clients. Client details are anonymised.

  • PageSpeed score as seen by the benchmark

    Jul 2026

    97 to 78

    Before
    97 (faked: scripts deferred only for test robots)
    After
    78 (honest baseline once the cloak was removed)

  • PageSpeed score after honest optimisation

    Jul 2026

    78 to 92

    Before
    78
    After
    92

  • LCP (mobile, product page)

    Jul 2026

    3.4 s to 1.2 s

    Before
    3.4 s
    After
    1.2 s

  • Total blocking time (mobile, product page)

    Jul 2026

    200 ms to 50 ms

    Before
    200 ms
    After
    50 ms

  • Scripts deferred: real phone vs benchmark bot

    Jul 2026

    0 deferred on a real phone vs 75 deferred for the bot

The full results table
WhatBeforeAfterDate
PageSpeed score97 (faked)78 honest → 92 optimisedJul 2026
LCP (mobile, product page)3.4 s1.2 sJul 2026
Total blocking time200 ms50 msJul 2026
Scripts deferred0 (real phone)75 (benchmark bot)Jul 2026
Rated 5 out of 5 on Upwork.

He went beyond the agreed work and supported me with additional items to ensure delivery was more outcome oriented rather than just what we had agreed.

Gagan M. Upwork · 2025

Notes on the numbers

Two honest caveats, both from the reports I handed over: the 92 is one lab run on one product page, not a guaranteed site-wide score, and repeated multi-page runs plus cart QA were still outstanding when the speed pass closed.

A note from Daniilbefore you decide

What this means for similar businesses

A green speed score can be manufactured. Some themes and apps defer scripts only for test robots, so the dashboard looks fast while real shoppers load the whole page. The tell is simple: compare what a real device loads with what the score claims, and ask what actually changed for buyers.

A trustworthy speed pass improves LCP and blocking time for every visitor, improves nothing by hiding work from a benchmark, and leaves tracking, cart and checkout untouched. And when CPMs rise, the storefront is one suspect, not the only one — in this case the store was not the cause, and saying so plainly saved the client a rebuild they did not need.

— Daniil

Situations this case answers

All situations
Read another case

From Email to Workshop: Quote Engine, AI Intake and Production Orders

I built quoting, AI-assisted intake and production-order tooling for a made-to-order manufacturer, with human review and explicit limits on what the tests prove.
Daniil Maximkin

Hi, I’m Daniil.

I work with you from defining the problem to implementation and handover. You talk to the person who does the work. I work in English and Russian.

My story My work

Have a similar task?

Describe your task

The first answer is free, within one working day. Or write directly: next@taskfordaniel.com