A RAXXO tool that felt fast on my desk loaded like a slideshow on a phone in a parking lot with two bars of signal
Every tool now gets a hard performance budget before I call it done, checked on throttled mobile, not my desk
The three numbers I actually enforce: time to first paint, time to interactive, and total page weight
A budget written down beats a feeling, because a feeling is always measured on the best connection in the building
The Parking Lot Test That Changed How I Ship
I tested a new RAXXO tool the way I test everything, on my desk, over fiber, on a monitor bigger than the tool needed. It felt instant. Every click answered before I finished moving the mouse. I was satisfied enough to plan the launch post.
Then I opened the same tool on my phone, standing in a parking lot with two bars of signal, the kind of connection an actual customer is on more often than I like to admit. The page took long enough to load that I checked whether it had frozen. Once it did load, tapping the main action produced nothing for a beat that felt much longer than it measured, because nothing on screen told me it had registered the tap at all. I had shipped something that worked perfectly for exactly one connection speed and one device, mine.
That gap between "fast for me" and "fast for a stranger on mobile data" is an easy one to miss, because the person building a tool is also the person with the best hardware and the best connection testing it. Every measurement I took on my own setup was true and also completely useless as a prediction of what a real visitor would feel. I had been grading speed the same way I once graded accessibility, on a test I was guaranteed to pass myself, because I was the only one taking it.
The fix was not a vague intention to "keep things fast." Good intentions do not survive a deadline. What changed things was writing down actual numbers, checked before a tool ships rather than hoped for after.
The Three Numbers I Actually Check
A performance budget only works if it is specific enough to fail. "Fast" is not a number. So every RAXXO tool now has to clear three concrete thresholds on throttled mobile before I call it shipped, not on my desk, not on WiFi.
Time to first paint is the first number, the point where something meaningful appears on screen instead of a blank page. I aim for under two seconds on a throttled mobile connection. That is not the point where the tool is usable, it is the point where a visitor gets proof the page is actually loading rather than broken, and that proof matters more for whether someone stays than any amount of polish that arrives four seconds later.
Time to interactive is the second number, the point where a tap or click actually does something instead of queuing behind JavaScript that has not finished loading yet. This is the number that caught the parking lot problem. A page can paint fast and still be unresponsive underneath, buttons visible but inert, because the script that wires them up is still downloading. I budget for interactivity under four seconds on the same throttled connection, and I check it by actually tapping the primary action, not by trusting a paint time to imply the page is ready.
Total page weight is the third number, and it is the one that quietly creates the other two problems. A hero image exported at full resolution because it looked sharp on my monitor, a font loaded in four weights when the page uses two, a script pulled in for one small feature and never trimmed down, each one on its own feels harmless. Stacked together across a real page, they are the actual cause of slow paint and slow interactivity. I cap new pages at a fixed weight budget and treat going over it as a build failure, not a note to fix later, because "later" is where unused weight goes to become permanent.
Where the Weight Actually Comes From
Once I started measuring instead of guessing, the sources of bloat were almost always the same handful of things, repeated across different tools.
Images were the biggest offender by far. A product photo exported at the resolution needed for a full-width desktop hero, then reused unscaled on a mobile layout a quarter that size, costs bandwidth for detail nobody on that screen can see. The fix is not a heavier compression setting bolted on at the end, it is exporting the right size for the layout that will actually show it, with a lighter version served to smaller screens instead of the same file scaled down by the browser.
Fonts were the second offender. It is easy to load a full type family, every weight from thin to black, because the design file has all of them available and using what is there feels free. It is not free. Every weight is a separate file the browser has to fetch before text renders in it, and most pages only ever use two or three of those weights in practice. Trimming a font load to the weights a page actually uses is one of the fastest wins available, and it is also one of the easiest to forget, because the cost is invisible until someone measures it.
Third-party scripts were the sneakiest offender, because they arrive attached to something useful, an analytics snippet, an embed, a small widget, and each one seems too small to matter on its own. A page carrying four or five of these scripts, each individually reasonable, adds up to a meaningful chunk of the total weight budget before a single line of the actual tool has loaded. I now audit every third-party script the same way I audit an image, asking whether the thing it provides is worth its specific cost on a throttled connection, not whether it is popular or free to add.
A related trap is loading something before it is needed at all. A script that only matters once someone reaches a checkout step does not need to load on the first screen a visitor sees, and a widget that only serves returning customers does not need to slow down the page for someone arriving for the first time. Deferring a script until the moment it is actually used, instead of loading everything upfront out of convenience, moved more than one tool back under budget without removing a single feature. The feature stayed. Only the moment it started downloading changed.
Building the Budget Into the Check, Not the Wish List
The real failure in my original approach was not the individual mistakes, it was where the check for them lived. A performance review that happens as an afterthought, after the design is locked and the deadline is close, is a review that gets skipped the first time something is running late. I know this because it happened more than once before I changed anything.
So the budget moved into the same shipping check every RAXXO section already goes through, as a required gate rather than a nice-to-have. Before a tool ships, I throttle my own connection deliberately, load the page the way a visitor on mobile data actually would, and check all three numbers against the budget. If a number is over, the tool does not ship that day, the same way it would not ship with a broken checkout button. Slow is a bug. I just used to treat it like a preference.
This changed how I make decisions earlier in the build too, not just at the end. Knowing there is a weight budget waiting at the finish line changes what I reach for while building. I think twice before adding a font weight, a large hero image, or a convenient third-party script, because I know it has to survive a real check later, not just look fine in the moment I add it. The budget is not only a gate, it is a filter that shapes decisions upstream of the check itself, the same way a fixed design system across five RAXXO tools shapes decisions before anyone consciously thinks about consistency.
What surprised me most is how rarely hitting the budget requires a real sacrifice. Almost every fix was invisible to the eye, a smaller image export, a trimmed font load, one fewer script that was not earning its weight. The parts of a page a visitor actually notices, the layout, the copy, the color, none of that had to change to hit the numbers. The fat was almost always somewhere nobody was looking, which is exactly why it had been sitting there unmeasured for as long as it had.
There is one place I do let the budget bend, and I hold that exception on purpose rather than by accident. A tool that genuinely needs a heavier interactive preview, the kind where the whole point is showing motion or a live rendering, gets a wider weight allowance for that one component, clearly scoped to it, while the rest of the page still has to clear the normal numbers. An exception that applies to everything is not a budget, it is a suggestion. An exception that applies to one named, deliberate case is still a budget with a reason attached.
Bottom Line
A tool that feels instant on my desk and loads like a slideshow on a phone in a parking lot is not a fast tool with an edge case. It is a slow tool that happens to have one fast reviewer, me, testing it under conditions no real visitor shares. The gap only closes by measuring the connection a stranger actually has, not the one sitting on my desk.
Three numbers, checked on throttled mobile before a tool ships, closed that gap for good: time to first paint under two seconds, time to interactive under four, and a page weight cap treated as a hard limit rather than a suggestion. None of it required sacrificing how a tool looks or feels. It required admitting that my own setup was never a fair test, and building a check that does not care how good my WiFi is.
Top comments (0)