How the dollar amount is calculated
Every figure Vyle Guard shows you is an estimate, and you deserve to see how it was built. This page is the whole formula — every constant, where it comes from, and what the number deliberately doesn't claim. Nothing here is proprietary. Check it.
The one-line version
We take how far your store sits below Google's “good” speed score, treat that gap as a slice of lost conversions, and multiply it against your own monthly revenue.
The visitors and the order value are yours, and they come after the measurement. Your speed scores and the list of app scripts running on your storefront are read from the URL alone — nothing to fill in. You add those two numbers afterwards, and all they do is turn that reading into money. The conversion rate is the one figure we still supply, and it's in the table below.
Every constant, and why it's that value
| Input | Value | Where it comes from |
|---|---|---|
| Mobile speed score | 0–100 | Measured live by Google PageSpeed Insights. The only input that's actually about your store. |
| “Good” threshold | 85 | Lighthouse's own boundary for a green score. Hit it and your leak reads exactly $0. |
| Recoverable ceiling | 22% | A conservative cap on the share of conversion that speed alone can win back. It scales down with your gap — it is never applied in full. |
| Monthly visitors | Yours | Typed in by you after the check, and optional — we never read it from your store, and we don't touch your analytics. Leave it out and the figure is quoted as a rate instead (see § A4). |
| Average order value | Yours | Also yours, also typed in afterwards. Neither number is needed to measure your store; both go straight into the formula above, unadjusted. |
| Baseline conversion | 2% | The conventional ecommerce average. Deliberately not flattering. |
Only one line in that table is still an assumption: the 2% baseline conversion. Everything else is either measured by Google or supplied by you, and the two you supply are printed back under the figure so you can check we used them.
Worked example — a store scoring 40
Say the merchant entered 20,000 monthly visitors and a $45 average order value. Those two figures are the example's, not ours — swap in your own and every step below runs the same way.
- Find the gap(85 − 40) ÷ 100 = 0.45The store is 45% of the scale below “good”.
- Apply the ceiling0.45 × 0.22 = 9.9%The share of revenue we estimate speed is costing.
- Set the baseline20,000 × 0.02 × $45 = $18,000Monthly revenue from the merchant's own two numbers.
- Multiply$18,000 × 9.9% = $1,782The monthly leak we'd print in the readout.
What the number can and can't be
The formula is bounded on both ends, on purpose. Score 85 or better and the figure is zero — we will not invent a leak for a fast store. At the other extreme, a score of 0, it tops out at 18.7% of your monthly revenue and can never exceed it, because the ceiling caps it. The table below is in dollars at the example baseline of $18,000/mo; the percentages hold whatever your numbers are.
| Speed score | Gap below 85 | Share of your revenue | Leak on the example |
|---|---|---|---|
| 90 | 0% | 0% | $0/mo |
| 75 | 10% | 2.2% | $396/mo |
| 60 | 25% | 5.5% | $990/mo |
| 40 | 45% | 9.9% | $1,782/mo |
| 25 | 60% | 13.2% | $2,376/mo |
| 10 | 75% | 16.5% | $2,970/mo |
One more rule, for the same reason. The formula multiplies by your traffic, so a store doing 300 sessions a month lands a hair above $0 — arithmetically correct and useless to read. Below 1,000 monthly visitors we stop printing a monthly amount and run the same formula against 1,000 visitors instead, labelled for what it is: a rate, per 1,000 visitors. Leaving the visitors field blank gets you the same rate.
Nothing is inflated to make that number look bigger — the only thing that changes is the visitor count going in, and the label says which one we used. A monthly dollar figure built on 300 sessions is noise; the rate is what the leak costs you as traffic arrives.
How the per-culprit costs are split
Google hands back a list of specific opportunities — render-blocking scripts, oversized images, unused CSS — each with the milliseconds it costs you. We split the leak across them in proportion to those milliseconds.
One honest wrinkle: Google returns up to six opportunities and the readout lists the top four. The denominator is still all six — so the four costs you see add up to less than the headline figure, never more. We'd rather under-attribute than pad the list.
There is a second, cruder split behind one line in the report. When you tick an app as one you no longer use, we put a rough cost on it like this:
Read that as an order of magnitude and nothing more. Only the script-shaped opportunities feed it — an oversized hero image is your theme's doing, not an app's — and the result is split evenly, because Google's data tells us what your scripts cost in total, never what any single one of them costs. An even split is the one division that doesn't pretend to know more than that.
What this figure is not
- It is not a measurement of your revenue. We never see your sales, sessions or analytics — only your public page speed and the two numbers you typed in yourself. Estimate those high and the leak reads high; that's arithmetic, not insight.
- It is not a promise. Fixing every culprit will not automatically deposit this amount in your bank.
- It is not a lead-gen scare number. The constants are conservative, disclosed, and capped at 18.7% of the revenue your own numbers imply — we don't pad what you give us on the way in, and we don't print “$40,000 lost!”
- It is an order-of-magnitude estimate of what slow load is plausibly costing a store like yours — arithmetic you can redo on paper in a minute.