Set a Performance Budget for Your Personal Site
Use limits for fonts, scripts, images, and interaction metrics to keep each new feature honest.
Personal sites rarely become slow in one dramatic change. They slow down through a sequence of “small” additions: a font family, analytics, two unoptimized covers, advertising, and comments. Each looks harmless alone; together they can make the first screen take seconds on a mobile network.
A performance budget gives growth a boundary before a feature reaches production. It is not a demand for a perfect synthetic score. It translates perceived speed into constraints a team—even a team of one—can enforce.
Define an experience target
Core Web Vitals offer three useful views. LCP asks when the main content becomes visible, INP observes interaction response, and CLS measures unexpected movement. They do not describe the entire experience, but they stop us from looking only at server response time.
A modest starting budget might look like this:
| Measure | Mobile target |
|---|---|
| Initial transfer | Under 500 KB |
| Critical CSS | Under 30 KB |
| Initial JavaScript | Under 100 KB |
| LCP | 75% of visits below 2.5 s |
| CLS | Below 0.1 |
These are not universal laws. A photography portfolio and a text journal need different numbers. The value is having a line that must be discussed before it moves.
Fonts are easy to underestimate
Complete CJK font files contain thousands of glyphs and can weigh several megabytes. Requiring every visitor to download one for visual consistency is often a poor trade.
System fonts are a reliable body-text choice. If the identity genuinely needs a web font, restrict it to a smaller character set or display use and configure font-display: swap. Be selective with preload: an eagerly loaded font competes with CSS and the lead image.
Pay for JavaScript only where interaction needs it
A static article should not download an application framework merely to show navigation. Render what HTML and CSS can express during the build. Load scripts only for components that own real state.
When evaluating a dependency, ask whether it enters every route, whether it can be delayed until interaction, whether a native browser API already covers the need, and whether its maintenance profile matches the expected life of the site. Removing 30 KB is often more effective than minifying it with greater sophistication.
Reserve space for media and ads
Images need explicit width and height so the browser can establish their aspect ratio before the bytes arrive. The lead image should not be lazy loaded; below-the-fold media generally should. Responsive variants should reflect actual display sizes rather than sending a 2400-pixel image to a 360-pixel screen.
Advertising also needs a spatial budget. A zero-height container that expands after load produces visible layout shift. Reserve a sensible minimum height and keep ads away from download and action controls.
Enforce the budget in the release path
A budget that lives only in documentation will be forgotten. Have the build report asset sizes, and run Lighthouse or an equivalent check in continuous integration. Real-user data then reveals devices and networks the lab did not model.
Not every small fluctuation must block a release, but a material regression should be visible. A monthly trend is more useful than an occasional screenshot of a perfect score.
Performance is an ongoing product decision. With a budget in place, “should we add this?” becomes a better question: is the value to the reader worth the loading and interaction cost?