On this page
If you are still deciding how to build the site, see how to make a website without coding. If you already have a page and want to finish it, our evening plan for a landing page puts speed in its last hour.
What a speed budget is
A speed budget is a promise to your future self. Web.dev describes a performance budget as a set of limits on metrics that affect site speed, such as page size, load time on mobile networks or the number of requests. It gives everyone who touches the site a shared reference for decisions about design, technology and features.
The idea is simple and often skipped. Without a number, every addition looks harmless: one more image, one more chat widget, one more font. With a number, each addition has to fit or something else has to go. Web.dev lists the options when a budget is exceeded: optimise an existing feature or asset, remove one, or decline to add the new feature.
Two kinds of budget
Web.dev’s article describes three kinds of budget: quantity-based, milestone timings and rule-based scores. Two ideas matter most for a small site.
- Quantity budgets limit what you ship: the weight of images, the number of fonts, the size of scripts, the number of third-party resources. They are easy to communicate and most useful early on. They do not capture the visitor’s experience on their own, because the order in which things load matters.
- Experience budgets limit what the visitor feels: how soon the main content appears, how soon the page responds, and whether the layout jumps. Web.dev’s article calls the milestone timings of this kind user-centric metrics, and Google’s Core Web Vitals are a set of them.
Use both. The quantity budget keeps you honest while you work, and the experience budget tells you whether it worked.
The experience budget: Core Web Vitals thresholds
Google’s Web Vitals guidance names three Core Web Vitals. The table gives the “good” thresholds, each judged at the 75th percentile of page loads, with mobile and desktop assessed separately.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | When the largest image, video or block of text in view finishes appearing | 2.5 s or less | 2.5 to 4.0 s | Over 4.0 s |
| Interaction to Next Paint (INP) | How quickly the page shows a response after a click, tap or key press | 200 ms or less | 200 to 500 ms | Over 500 ms |
| Cumulative Layout Shift (CLS) | How much the layout moves unexpectedly | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
The 75th percentile means three out of four visits should be at least as good as the number. It is a deliberately demanding standard, because it covers slower phones and weaker connections as well as the best ones.
Two details help you read the table. LCP counts the time from the moment the visitor starts to navigate, so a slow first response from the server counts against it, along with redirects. INP is the successor to First Input Delay: instead of the first interaction only, it observes all of them and reports a single value for the visit.
The quantity budget: what to limit
Quantity budgets are the part you control directly. Web.dev gives two examples worth noting. For a product page, a limit of under 170 KB of JavaScript on mobile. For a search page, under 2 MB of images on desktop. Its baseline for critical-path resources is also 170 KB, compressed. Those figures come from an article last updated in 2018 that assumes a modest phone on a slow network, so treat them as examples of the kind of limit, not as rules for your site.
A sensible method for a small site is to measure first. Write down today’s numbers, then set the budget a little below them. A budget you cannot meet on day one is ignored; one a little tighter than today is met, and then tightened again.
Here is a table you can copy and fill in.
| What | What to set | Starting point |
|---|---|---|
| Total image weight per page | A maximum in KB or MB | Under 2 MB, web.dev’s example for a search page on desktop; go lower for a phone-first page |
| Script weight | A maximum in KB | Under 170 KB on mobile, web.dev’s example for a product page |
| Number of web fonts | A maximum count | Two files is a simple limit to start from |
| Third-party embeds | A maximum count | Zero unless the page cannot do its job without it |
| Main content (LCP) | A target time | 2.5 s or less at the 75th percentile |
| Responsiveness (INP) | A target time | 200 ms or less at the 75th percentile |
| Layout movement (CLS) | A target score | 0.1 or less at the 75th percentile |
| Lab score | A minimum | 90 or above, which PageSpeed Insights calls good |
The font and embed rows are our suggestions, not standards. Change them to fit your page.
How to measure with a public tool
PageSpeed Insights is a public tool from Google. You enter the address of a page, and it reports the user experience on mobile and on desktop, with suggestions for improving it. It shows two kinds of data, and the difference matters.
- Field data comes from real visits, drawn from the Chrome User Experience Report for the previous 28 days. It reflects real devices and networks, and it covers a smaller set of metrics: First Contentful Paint, Interaction to Next Paint, Largest Contentful Paint, Cumulative Layout Shift and Time to First Byte.
- Lab data comes from a simulated page load run through Lighthouse. Google’s page says lab data is useful for debugging issues, and that it may miss real-world bottlenecks. Lighthouse reports four categories, Performance, Accessibility, Best Practices and SEO, and rates a score of 90 or above as good, 50 to 89 as needing improvement and below 50 as poor.
A routine that works for small sites:
- Run the page on the mobile report first.
- Note the three Core Web Vitals and the performance score.
- If field data is shown, trust it over the lab score. If it is not shown for your page, use the lab data and test again after each change.
- Change one thing, then measure again, so you know what helped.
- Write the result next to your budget table, with the date.
Do this for the pages that matter most: the home page and the page people arrive on from a link.
What to cut first
Cut by size and by uselessness. These are the usual suspects, with the reason each one matters from Google’s guidance.
- Oversized images. The largest image on a page is often the element LCP measures, so a heavy hero image delays the very thing the metric watches. Images without set dimensions also cause layout shift, because the browser cannot reserve space before they load.
- Third-party embeds. Web.dev lists third-party ads or widgets that resize themselves after loading as a cause of layout shift. Each embed also adds requests you do not control. Keep only the ones the page cannot do without.
- Extra fonts. Web.dev names fonts that render larger or smaller than their fallback as a cause of layout shift. Fewer font files means less to download and less to move.
- Content that appears late. Elements inserted above existing content push everything down. Reserve their space, or place them below what the reader is already looking at.
- Scripts you do not use. INP counts the time from an interaction to the next frame, including the time spent running the code that responds. Less code gives less delay.
Do not start with fine tuning when the page carries a 4 MB photograph. The biggest saving is almost always the biggest file.
Keep the budget alive
Budgets decay. Web.dev says to keep measuring after launch, because budgets need ongoing tracking. For a small site that can be as simple as running the same two pages through the same tool once a month, and whenever you add something.
When the numbers slip, use the three options: optimise what is there, remove something, or decline the new addition. The third is the hardest, and it is the reason to have a budget at all.
For a phone-first route to a finished site, our guide to making a website from your phone is a good next step.