This note turns the central question into concrete decisions, checks, boundaries, and ownership.
A target without a budget cannot guide design
‘Fast’ is not a decision. Define measurable targets for representative devices and connections, then assign limits to the resources most likely to threaten them. A practical starting point may include Largest Contentful Paint below 2.5 seconds at the seventy-fifth percentile, Interaction to Next Paint below 200 milliseconds, and Cumulative Layout Shift below 0.1. Translate those outcomes into page-weight, image, font, script, and third-party budgets that designers and developers can inspect before launch.
Identify the likely largest element during direction
On a cinematic homepage, the largest element may be a display heading or CSS composition rather than a photograph. That can be an advantage if fonts are handled carefully. Determine which element is likely to become LCP at desktop and mobile. Avoid hiding it behind client-side rendering or long animation. If a hero image is essential, choose its aspect ratio, responsive crops, dimensions, format, and loading priority during direction. A generic high-resolution upload is not a production image strategy.
Budget fonts as part of the visual identity
Distinctive typography can remain performant when the family, styles, subsets, and loading behaviour are deliberate. Count the files requested on first view. Prefer a small number of weights and avoid loading styles used only below the fold. Subset character ranges only when language requirements are stable. Use suitable fallbacks and font-display behaviour to keep text visible. Measure layout shift caused by metric differences. A variable font can reduce requests but may still contain far more data than the page needs.
Give every script an owner and removal condition
List first-party and third-party scripts with purpose, size, execution cost, data destination, owner, consent category, and removal condition. A tag manager does not eliminate this responsibility; it can obscure it. Load functionality only where it is needed. Defer noncritical work and avoid hydrating static content. Measure long tasks and interaction latency on mid-range mobile hardware. If nobody can explain what a script provides, remove it from the release candidate until its value is demonstrated.
Design images as a pipeline
Specify source quality, crop ownership, generated widths, output formats, compression, focal points, and alt-text responsibility. Use width and height or aspect-ratio to reserve space. Provide responsive candidates so a phone does not download a desktop asset. Lazy-load below-the-fold images, not the primary visual. Treat decorative geometric artwork as CSS or compact SVG when appropriate, but ensure it degrades cleanly. Inspect final output files rather than assuming the content management system produced efficient variants.
Third parties consume privacy and reliability budgets too
Chat, video, maps, scheduling, social embeds, analytics, personalisation, and payment widgets add more than bytes. They introduce DNS connections, main-thread work, cookies, consent complexity, outages, and visual instability. Test a placeholder or user-initiated facade for heavy embeds. Define what happens when the provider is blocked or unavailable. A dependency that fails should not erase core information or prevent navigation. Include third-party behaviour in both the performance budget and the privacy explanation.
Automate enforcement at meaningful checkpoints
Measure the same representative routes in local production builds, staging, and after deployment. Fail or flag builds when bundles, images, fonts, or key metrics exceed agreed thresholds. Synthetic tests provide repeatability; real-user data reveals field conditions. Keep both. Compare against a baseline and annotate intentional changes. A one-time perfect score is less valuable than a process that catches regression when a campaign adds a large image or a vendor changes its script.
Review performance as content changes
The initial build may be lean while ordinary publishing steadily increases weight. Test the longest article, densest listing, most complex form, and common content editor mistakes. Add guidance for image dimensions, video embeds, document downloads, and animated media. Schedule a review after a normal publishing cycle. Performance is sustainable when editors can recognise a risky asset before uploading it and when maintainers know which budget has been exceeded and who can make the trade-off.
Test the budget on the weakest representative route
The homepage may be carefully art-directed while a long article, filtered catalogue, contact form, or third-party embed becomes the slowest common experience. Choose representative routes by resource type and interaction, not importance in the navigation. Include a cold cache, repeat visit, mid-range mobile CPU, constrained network, and a state with validation or expanded content. Record the environment with each result. A budget that passes only on a developer laptop over broadband does not constrain real decisions and should not be used as release evidence.
Reserve space for everything that arrives late
Layout movement can come from consent notices, web fonts, image dimensions, validation messages, embedded tools, and content injected after hydration. Define stable containers or natural document flow for each. Do not pin a fixed height around text that changes by language or zoom. A consent panel should avoid the primary heading and action on first visit. Validation should add messages without pushing the field currently being corrected out of view. Measure layout shift, but also inspect whether movement interrupts reading or causes an accidental activation.
Decide how the page behaves without JavaScript
A static content route should retain its headings, navigation, links, and essential explanation when JavaScript fails. Progressive enhancement may add a mobile menu, local outline, filters, or analytics events, but core content should remain available. Document which controls require script and provide an honest unavailable state where necessary. Test a blocked script and a runtime error. A small bundle is not resilient merely because it is small; failure boundaries and useful HTML determine whether visitors can still complete the central task.
Spend the budget where recognition improves
A performance budget is not a command to remove every distinctive choice. It helps the team compare value. One carefully subset display face, a compact geometric hero, and a small interaction script may create more recognition than a carousel, video background, several generic photos, and a large component runtime. Review each expense against the remembered moment and user task. When a resource exceeds its allowance, first simplify lower-value dependencies rather than flattening the central visual idea. Record the trade-off so later additions do not quietly consume the recovered capacity.
Turn the method into a reviewable record
Apply the ideas in Choose a Performance Budget Before the Hero Image to one real route, decision, or update rather than discussing the entire website in the abstract. Record the current condition, the audience question, available evidence, responsible owner, proposed change, risk, and acceptance check. Attach screenshots or route lists where they clarify the record, but do not substitute visual evidence for an explanation. Ask a reviewer who did not prepare the record to identify the decision and reproduce the check. If they cannot, revise the language or evidence. Keep the record with the project source so a future maintainer can distinguish an intentional rule from an accidental implementation detail. This small discipline reduces repeated debate and makes later corrections safer.
Use a stop condition, not endless refinement
Define what would make the recommendation inappropriate, incomplete, or unsafe. A missing content owner, unverifiable claim, inaccessible interaction, unmapped legacy route, unknown data destination, or absent recovery path may be a reason to pause. Write who can resolve the condition and what evidence allows work to continue. This prevents schedules from converting uncertainty into silent assumptions. It also protects creative work: once the named conditions and acceptance checks pass, the team can stop polishing details that do not improve the audience decision. Review the condition after an ordinary publishing cycle, because real use may reveal a different constraint from the one imagined during design.
The useful standard is a decision somebody else can understand, test, and maintain.
Questions to carry into the project
- Which decision is this work meant to improve?
- What evidence is available now, and who can verify it?
- Which owner can maintain the result after launch?
- What condition should stop, revise, or reverse the release?