A speed test should say whose fix it is

Same numbers, different reading

I think a speed score on its own, with no owner attached, is noise. A store can act on it only once it knows whose fix each issue is.

Why offer a speed test when PageSpeed Insights already exists? Not to get different numbers. The free speed test at Sleeken, the Shopify studio I run inside Saar, runs Google Lighthouse on an emulated mid-range phone over throttled 4G and adds real-user Core Web Vitals, Google's page-experience metrics, from Chrome. It uses the same Lighthouse engine and reads the same Chrome UX Report field data, so the numbers are the same; the difference is interpretation.

The lab score, the one from the emulated phone, moves between runs. Network conditions, server load and how quickly third-party scripts respond all shift it, so treat any single score as the middle of a range. The real-user Core Web Vitals are the stable measure.

Detect first, then talk

Know the stack before giving advice. The test detects the commerce platform, front-end framework, CMS and hosting first, then explains each issue in terms of that stack. The wording changes to match: a WooCommerce store is told about plugins rather than apps, a self-hosted site is told its server response time is a hosting decision rather than the platform's, and a headless front end is not offered advice about themes it does not have.

Then each issue gets an owner. The test says plainly whether the fix belongs to your build, your apps or your platform. That label is there so you can see which problems a rebuild solves and which ones depend on removing or replacing an app.

I sell builds, so I could easily read every slow page as a case for a rebuild. I name the owner not because a rebuild is the wrong answer, but because it is one answer of three, and a store should know which one it faces before anyone quotes for the work, me included.

Keep no IP addresses, cache for an hour

The test calls a Google service with a daily quota on the visitor's behalf, so I count requests to stop that quota being drained. To do that without keeping anyone's IP address, I turn each address into a scrambled one-way code, made with a secret only the server knows, and the privacy policy says so. The code can't be turned back into an address, and it is used for nothing else.

I cache results for an hour per URL and device, so running the same page again straight away returns the same audit rather than a fresh one. That spares a call against the quota, but I value the other effect more: with a lab score that moves between runs, a re-run inside the hour gets the same audit, not a luckier number.

For the visitor, there is no signup and no email, and a run takes about 15 to 40 seconds. What comes back is a performance score, accessibility and SEO scores, the Core Web Vitals and a ranked list of what is costing you the most time.

Claim only what the data can carry

The first step is a written method. Mine is on the benchmark board: Lighthouse 12 on an emulated Moto G Power with a 4G throttle and a cold cache, three runs with the median taken, on the home page and one product page. The plan is one cohort a month, tested on the first Monday and frozen once published, with the stores drawn from organic search in each category rather than picked by me.

The board also says what it is: "Sample data: the stores and scores on this board are illustrative while the first real measurement cohort is prepared. Nothing here describes a real shop yet."

The same rule runs through the speed test. It is free on sleeken.se/tools, and if the fix on your store belongs to your apps or your platform rather than your build, it will say so plainly.