ShopYourWay: a 90-second mobile teardown

SummaryThe headline read

Server response is quick (time to first byte around a quarter-second), but that is where the good news ends. The largest element paints at a median of ~2.5s across our eight loads, which sits right on Google's "good versus needs-improvement" line, and that is in a lab on a clean, unthrottled connection. On a real phone over cellular, a meaningful share of visits will cross into "poor".

The bigger story is not raw speed. It is touch ergonomics, layout stability, and a measurement gap that repeated on every single load. None of these show up in a page-views dashboard, and all of them cost taps and trust on a phone.

Below: exactly what we measured, with the spread across loads, why each one matters on mobile, and a short prioritized list. We separate the findings that were identical on all eight loads from the ones that swung. Where we are reasoning rather than measuring, we say so.

01How this was measured

This is deliberately humble. Eight automated visits, from a headless Safari profile spoofing an iPhone 14 viewport (390px wide, 3x density), to https://www.shopyourway.com/ on May 22, 2026. On each load we recorded navigation timing, every network response, the rendered DOM, and the geometry of every interactive element, the same surface our pixel reads on a real visit. Eight loads instead of one so we can tell a stable defect from a noisy single reading, and report the spread rather than a single lucky number.

Two methodology notes that matter. First, the homepage rotates its promo content: DOM node counts and image counts shifted slightly load to load, which is itself a reason a one-shot audit of this site is unreliable. Second, these are lab numbers on a fast, unthrottled connection. Real phones on real cellular will be slower, so treat every timing here as a floor, not a typical experience.

What this is not: it is not field data from your real shoppers, it is not a multi-page crawl, and it is not an A/B test. Synthetic loads cannot see rage taps, dead clicks, scroll drop-off, or how the checkout behaves under load. That gap is the whole point of the last section.

02Speed: quick to byte, slow to paint

The server is fast. The render is not, and it is inconsistent. Here is the spread across all eight loads, not a single cherry-picked number:

The headline correction: LCP sits at a median of ~2.5s, exactly on Google's good/needs-improvement boundary, and it swung as high as 3.0s. That is in a lab, on an unthrottled connection, with no competing tabs. Field conditions only move it one direction. The fast quarter-second byte is being squandered somewhere between the server responding and the page actually painting.

Weight is a big part of why. Of the ~2.8 MB pulled in, about 1.9 MB is images and 0.9 MB is JavaScript, across roughly 60 requests. The fix is cheap and well understood: serve responsive image sizes and modern formats, and defer or trim the JavaScript so paint is not waiting on it.

03The mobile finding: taps are too small

This is the standout. Of 46 interactive elements we could measure on the mobile homepage, 36 were smaller than the 44 by 44px target that Apple and Google both recommend for touch. That is 78 percent.

Concrete examples from the scan:

• The menu toggle (the hamburger) measured 32 by 32px. It is the first thing a mobile shopper reaches for, and it is well under target.
• A row of FAQ and support accordions measured 358 by 41px. Wide enough, but 41px tall sits just below the 44px floor, so the top and bottom few pixels are easy to miss.

The fix is pure CSS: bump the tappable area (padding, not just the icon) to at least 44 by 44px. No redesign, no new assets.

04Layout stability: a built-in risk

Every one of the 10 images on the page loaded without a width or height attribute, and only one was lazy-loaded. Missing dimensions are the classic cause of layout shift: the browser does not reserve space, so when an image arrives it shoves the content below it down. On a phone, that is the moment a shopper goes to tap a link and the page jumps, so they hit the wrong thing.

We did not get a clean layout-shift score from a single headless load, so we are not quoting a CLS number. But the cause is unambiguous and worth pre-empting: set explicit width and height (or a CSS aspect-ratio) on every image. It is one of the highest-leverage, lowest-effort fixes on the page.

05SEO and analytics: two quiet gaps

The homepage has no meta description

The <meta name="description"> on the homepage was empty, and the title tag was just "Shop Your Way". For a brand this size, that leaves Google to invent the search-result snippet from whatever text it finds, which is a missed chance to control the first impression on a brand-name search. There is one well-formed FAQ schema block on the page, which is a good sign, so the foundation for rich results is already there.

The analytics beacon aborted on every single load

This is the one we want to flag hardest. The Google Analytics 4 collection request (google-analytics.com/g/collect) aborted before completing on all eight loads, 8 of 8. This is not a fluke we saw once; it reproduced every time. If the same thing happens for a comparable share of real sessions, the GA4 numbers in the reporting dashboard are quietly undercounting traffic and conversions, and nothing raises an alarm. We cannot, from the outside, prove the exact real-world drop rate, but a beacon that fails 8 for 8 in clean lab conditions is a strong signal that something in the tag setup or consent/loading order is killing the hit. This alone is worth a developer's afternoon.

06What a single scan cannot see

Everything above came from eight external loads. The expensive questions still need real visitors. With the Harvv pixel installed (a 16 KB script, zero personal data, no engineering project), within about 72 hours you would be able to answer:

• Are those 32px and 41px targets actually causing mis-taps? Rage taps and repeated taps on the same element would prove it, by element, on real thumbs.
• What is the real GA4 drop rate? We measured it aborting 8 of 8 in the lab. On live traffic we would report the exact share of sessions where the beacon never lands, so you know how much of your reporting is fiction.
• Where do mobile shoppers stall and leave? Dead clicks, hover-then-abandon, and scroll drop-off show the exact spot, not just the bounce rate.
• Does the layout shift hurt real taps? We would catch the click that landed a beat after the page jumped.

The teardown tells you where to look. The pixel tells you how often it actually happens, and to whom.

07The short list, in priority order

08Limitations, stated plainly

• Eight loads, one page. Eight synthetic mobile loads of the homepage. Enough to separate stable defects from noise, but still not a crawl of the full site, not your real traffic, and not multiple device classes.
• Synthetic, not field. A headless browser on a clean, unthrottled network. Real phones on real connections will see worse timings, so the ~2.5s median LCP is a floor, not a typical experience.
• The analytics drop is reproducible, but its real-world rate is unknown. It aborted 8 of 8 in our loads. We cannot measure the true share of real sessions affected from the outside. That is precisely what the pixel would quantify.
• Friction is inferred, not measured. We can prove the targets are small (36 of 46, identical on every load). We cannot, from synthetic loads, prove how often that causes a mis-tap. That requires live behavioral data.

Prepared by Harvv as an external courtesy scan. Measured May 22, 2026 from a mobile Safari profile. For questions or to run the live version, get in touch.