Sub-1-second sites: the performance budget we ship against
Siddhant AryanLead Designer · AI AutomationListen to this article
The short answer
Speed is the feature users feel before any other — and fast sites aren't an accident, they're the result of a performance budget set at the start of a project rather than a clean-up task at the end. Before design begins we agree the limits — target load time, total page weight, and Core Web Vitals thresholds — and every decision after that is measured against the budget, so nothing balloons unnoticed. Most of the win is in two places: images (modern formats, right-sized responsive sizes) and fonts (disciplined loading). And we measure on a real mid-range phone over a throttled connection, because lab scores flatter you and your customers aren't on your fast laptop. Treat performance as a constraint you design within, not a problem you discover at launch, and one-second loads stop being remarkable.
On this page
The slowest websites I've ever audited weren't built by careless teams — they were built by good teams who treated speed as something to fix later. And 'later' is the worst possible time to fix it, because by then the slowness is baked into a thousand decisions: the hero video someone fell in love with, the five fonts the brand guidelines specified, the analytics and chat and popup scripts that each got added 'just this once', the giant unoptimised images the client sent. Individually every one of those felt fine. Together they turned a page that should load in under a second into one that takes five on the phone where most visitors actually are. The lesson I've learned building fast sites is that speed isn't a thing you add — it's a thing you protect, decision by decision, against a budget you set before you start. Here's how we run that budget, and the specific places a page is won or lost.
Why speed is the feature users feel first
Before a visitor reads your headline, judges your design or considers your offer, they feel how fast the page arrived. A slow load is the first impression you didn't mean to make — and on a phone over patchy mobile data, the gap between fast and slow is the gap between a visitor who stays and one who's already gone. They don't think 'this site is 3.8 seconds'; they just feel friction and leave, and you never see the ones you lost.
This is why I treat performance as a conversion feature, not a technical nicety. Every extra second of load measurably costs you visitors, and on paid traffic it costs you visitors you paid for — a slow page quietly raises the real price of every click. So speed isn't where we polish at the end; it's a first-class constraint from the first decision, because by the time a site feels slow, the cheapest moment to have prevented it has long passed.
By the numbers
A page that loads in under a second on a mid-range phone and one that takes four feel like different businesses to the visitor — and on paid traffic the slow one wastes a chunk of every click you bought before your offer even renders. Speed isn't decoration; it's the first thing a visitor experiences and the cheapest conversion lever you'll never see on the page.
Set the budget before you design
A performance budget is a set of hard limits agreed at the start of a project — a target load time, a cap on total page weight, and thresholds for the Core Web Vitals — that every subsequent decision has to respect. It turns 'make it fast' from a vague wish into a constraint with a number, which is the only way speed survives contact with a real project. When someone wants to add a heavy video hero or a fourth font, the budget makes the trade-off explicit: it has to fit, or something else has to give.
This reframes the whole build. Instead of designing freely and discovering at the end that the page is too heavy, you design within a weight allowance from the first decision — and nothing balloons unnoticed, because everything is measured against the same ceiling as you go. The budget isn't a constraint on creativity; it's what stops a hundred small 'just this once' additions from quietly compounding into a slow site nobody chose to build.
What is a performance budget?
A performance budget is a set of measurable limits — maximum load time, total page weight (KB of images, scripts, fonts), and Core Web Vitals thresholds — agreed before design starts. Every new element is checked against it, so the page can't quietly get heavier than intended. It's the difference between designing toward a speed target and discovering at launch that you missed one.
Images and fonts: where it's won or lost
If you only optimised two things, optimise these — they're where most of a page's weight and most of its slowness live. Images first: serve modern formats like WebP, size them responsively so a phone never downloads a desktop-sized image, compress them properly, and lazy-load anything below the fold. An unoptimised hero image alone can be heavier than an entire well-built page. We've turned multi-second loads into sub-one-second ones by attacking images before anything else.
Fonts are the quieter culprit. Each custom weight is a file the browser must fetch, and naïve font loading either blocks rendering or flashes invisible text while the page waits. We trim to the weights actually used, load them efficiently so text shows immediately, and avoid the temptation to ship five faces when two will do. Between disciplined images and disciplined fonts, you've addressed the bulk of what makes pages slow — before touching anything more exotic.
The highest-leverage speed fixes, in order
- Images — WebP/AVIF, responsive sizing, real compression, lazy-load below the fold.
- Fonts — trim to the weights you actually use; load so text renders immediately.
- Scripts — defer or cut third-party tags (chat, analytics, pixels); they add up fast.
- Ship only what's needed — code-split so a page loads its own code, not the whole site's.
Measure on a real phone, on real data
The most dangerous performance number is the one from your own laptop on office wifi — it tells you the site is fast for the one person who'll never struggle with it. Lab scores and your fast desktop both flatter you. Your customers are on mid-range phones, on mobile data that drops to three bars on a train, and that's the only environment whose speed actually matters. We test there: throttled connections, real mid-tier devices, the conditions where a slow site genuinely loses the sale.
This is also where the budget gets enforced honestly. It's easy to convince yourself a page is 'fine' on a flagship phone over fibre; it's much harder to ignore a three-second wait on a real device over a throttled network. Measuring in the worst realistic conditions — not the best — is what keeps the build honest and the budget meaningful, because that worst case is many of your customers' normal.
Pro tip
Before you call a site fast, open it on a mid-range phone, on mobile data, away from your office — not on your laptop over wifi. If it's quick there, it's quick for everyone. The laptop-on-fibre test is how slow sites get shipped feeling fast to the only person who never had to wait.
The targets we ship against
Concretely, here's the kind of budget we hold a page to before it's allowed to launch. These aren't arbitrary — the Core Web Vitals map to what a visitor actually feels: how fast the main content appears (LCP), how stable the layout is as it loads (CLS), and how quickly the page responds to a tap (INP). We treat the 'good' thresholds as the ceiling, measured on mobile, and a page that misses them goes back to the bench rather than out the door.
The point of writing the targets down is accountability. 'Make it fast' is unfalsifiable; 'LCP under 2.5 seconds on a mid-range phone, total page weight under the agreed cap' is something you either hit or you don't. That clarity is what turns performance from an aspiration everyone nods at into a standard every page actually meets.
| What it measures | Metric | Target |
|---|---|---|
| How fast the main content appears | LCP | Under ~2.5s (we aim ~1s) |
| How stable the layout is while loading | CLS | Under 0.1 |
| How fast it responds to a tap | INP | Under 200ms |
| Total weight of the page | Page weight | Within the agreed budget |
Key takeaways
- Speed is felt before anything else and can't be bolted on at the end. Treat it as a performance budget — hard limits on load time, page weight and Core Web Vitals set before design — so a hundred small 'just this once' additions can't quietly compound into a slow site.
- Most of the win is images and fonts. Modern formats, responsive sizing, real compression and lazy-loading for images; trimmed, efficiently-loaded fonts. Address those two before anything exotic, then cut and defer third-party scripts.
- Measure in the worst realistic conditions, not the best. A mid-range phone on throttled mobile data — not your laptop on office wifi — is where your customers actually are and where slow sites lose the sale. Write the targets down (LCP, CLS, INP) so 'fast' is something you hit, not hope for.
Frequently asked questions
What is a website performance budget?
It's a set of measurable limits — a maximum load time, a cap on total page weight, and Core Web Vitals thresholds — agreed before design starts, against which every new element is checked. It stops a page quietly getting heavier than intended, because adding a heavy video or extra fonts becomes an explicit trade-off rather than an unnoticed cost. It's the difference between designing toward a speed target and discovering at launch you missed it.
What are good Core Web Vitals targets?
Measured on mobile, the widely-used 'good' thresholds are: LCP (how fast the main content appears) under about 2.5 seconds, CLS (how much the layout shifts as it loads) under 0.1, and INP (how quickly the page responds to a tap) under 200ms. We treat those as the ceiling and aim well inside them — often around a one-second LCP — and a page that misses them isn't shipped until it's fixed.
What slows a website down the most?
Usually images and fonts, then third-party scripts. Unoptimised images — wrong format, desktop-sized files served to phones, no compression — are often the single heaviest thing on a page; a naïve font setup adds blocking files; and chat, analytics and popup scripts each add weight that compounds. Attack those in that order and you've addressed the bulk of what makes most pages slow before touching anything more advanced.
Why does my site score well on PageSpeed but still feel slow?
Often because you're judging it in flattering conditions. Lab tests and your own fast laptop over office wifi don't reflect a mid-range phone on patchy mobile data, which is where many of your visitors actually are. A site can look fine in the lab and feel slow in a customer's hand. Always sanity-check on a real mid-tier device over a throttled connection — that worst realistic case is many people's normal.
Does website speed really affect conversions?
Yes, directly. Speed is the first thing a visitor experiences, and every extra second of load measurably loses visitors — on a phone over mobile data, slow pages lose people before the offer even renders. On paid traffic that's worse, because you're losing visitors you paid for, which quietly raises the true cost of every click. Improving load time is one of the cheapest conversion gains available, precisely because it works on the part of the funnel nobody looks at.
Tools & next steps
Put this into practice, go deeper, or see how we'd do it for you.
Written by
Mr. Siddhant Aryan
Lead Designer & AI Automation, Global Info Edge
Lead designer and AI-automation specialist at Global Info Edge with 5 years building fast, conversion-focused websites and the workflows that run behind them.
View full profile