Website Performance BudgetsControl the Cost Before Adding the Script

Google’s current Core Web Vitals guidance focuses on three field metrics: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability.

The current “good” thresholds are LCP at 2.5 seconds or less, INP at 200 milliseconds or less and CLS at 0.1 or less, measured at the 75th percentile of visits. Those targets are explained in the current web.dev Core Web Vitals guidance.

That matters because a lab score is a diagnostic, not the business objective. A page can fluctuate several points between Lighthouse runs while the underlying architecture has not meaningfully changed. Conversely, a page can look acceptable in a fast desktop lab run while real mobile users still experience a slow LCP or delayed interaction.

A useful performance budget therefore starts with experience outcomes, then uses lab tools to locate the work needed to protect them.

The first screen should not pay for every capability the website might eventually need.

For a service website, the critical path usually includes the HTML, the CSS needed to render the first viewport, essential fonts or font fallbacks, the primary navigation and the content that creates the LCP element.

It usually does not need to include:

• a payment SDK before the visitor starts checkout;
• a video player that sits several sections below the fold;
• a calendar library before the visitor opens a booking flow;
• an analytics library that duplicates another analytics library;
• a slider or animation library on pages that do not use it;
• a social embed before the embed is close to the viewport;
• an admin-oriented dependency on public pages.

The principle is not “never use JavaScript.” It is “do not make the first frame fund work that the first frame does not need.”

A common WordPress performance problem is global loading. A plugin registers one stylesheet and one JavaScript file, then enqueues them site-wide because that is simpler than checking where the feature is actually used.

For small files this may be harmless. Across a mature site, the pattern compounds.

A stronger architecture asks where and when the capability is needed:

• Global and critical: navigation or theme behavior needed immediately.
• Page-specific: load only on the page that uses the component.
• Viewport-dependent: load when the component approaches the viewport.
• Interaction-dependent: load only after the visitor opens, selects or starts the feature.
• Consent-dependent: load analytics or marketing tools only when the applicable privacy choice permits it.

This is especially useful for pricing and checkout experiences. The visitor should be able to read the offer and compare options without downloading payment code that is not needed until a transaction is actually initiated.

Third-party tools are useful precisely because they provide functionality the site does not want to build itself. That also means their code, network behavior and future changes are partly outside the site owner’s control.

web.dev recommends treating third-party code as a performance cost: choose the smallest useful option, avoid duplicate vendors, audit redundant scripts and use performance budgets to keep third-party content in check. Its third-party JavaScript performance guidance also highlights chat, analytics, advertising, embeds and experiment tools as common examples.

For GrowthFlint, a practical third-party budget means that a new integration should answer four questions before it becomes permanent:

1. What business or user problem does it solve?
2. Does that value require it on every page?
3. Can it load later without breaking the journey?
4. What changed in page weight, JavaScript execution and Core Web Vitals after adding it?

If the team cannot explain the value, the script should not receive a permanent performance allowance merely because it was easy to install.

A browser can download code that the visitor never uses on that page. That unused code still consumes network transfer and can increase parsing, compilation, memory and main-thread work.

The web.dev unused-code guidance recommends using the Network and Coverage tools to identify JavaScript and CSS that is shipped but not used.

This does not mean every byte reported as unused should be deleted immediately. Shared bundles often contain code needed on other routes, and splitting them too aggressively can create more requests or maintenance complexity.

The useful question is whether a large amount of unused code is being shipped repeatedly to pages that have no reason to receive it. If so, page-level loading, code splitting, conditional enqueueing or architectural simplification may have a better return than another caching toggle.

Using async or defer can stop a script from blocking HTML parsing, but the browser still has to download, parse and execute that code.

That is why a page with many asynchronous tracking or interaction scripts can still become CPU-heavy or network-heavy. Loading a script later can protect the critical path, but it does not remove the total cost.

For non-critical integrations, the stronger progression is often:

1. decide whether the script is needed at all;
2. limit it to the pages where it creates value;
3. defer or lazy-load it when possible;
4. move it behind an interaction when the user does not need it before that point;
5. re-measure after the change.

JavaScript is not the only performance cost. A new banner, web font, image, chat launcher, embedded widget or dynamically inserted notice can shift content after the visitor has started reading or clicking.

CLS exists to measure that visual instability. The current good threshold is 0.1 or less at the 75th percentile, and Google’s CLS optimization guidance highlights unsized images, embeds, dynamic content and web fonts as common causes.

A release budget should therefore include rules such as reserving dimensions for media and embeds, avoiding late insertion above existing content, and testing mobile layouts after interactive components initialize.

Lighthouse is valuable because it can reproduce a controlled test and identify opportunities such as unused JavaScript, render-blocking resources or excessive main-thread work.

Field data answers a different question: what did real visitors experience across their devices, networks and sessions?

A small or new website may not yet have enough Chrome UX Report traffic for page-level field data. In that case the absence of CrUX data is not proof that the site is fast or slow. It simply means lab testing and first-party real-user measurement carry more responsibility until enough public traffic exists.

This is also why a performance team should avoid celebrating a one-off high score. Repeat tests, compare before and after, and keep the architecture understandable enough that future regressions can be traced.

A performance budget is useful because it creates a stopping rule.

Without a release gate, optimization can turn into chasing tiny synthetic-score changes. With a gate, the team knows what must be true before the change is accepted.

A practical service-site gate can include:

• no new blocking third-party script without a documented reason;
• payment or checkout code stays out of the initial path until needed;
• no major unexpected layout shift on mobile;
• key pages remain crawlable and functional with the optimization enabled;
• the primary CTA and forms still work;
• Lighthouse opportunities are reviewed for meaningful regressions;
• field Core Web Vitals are monitored when enough data exists.

The goal is not a website with no JavaScript. The goal is a website where every meaningful dependency has a reason, a loading strategy and a measurable cost.

Caching, compression and CDNs matter, but they cannot fully compensate for an architecture that sends every visitor code for features they have not used.

The durable improvements come from controlling ownership: which plugin or module loads each asset, where it loads, when it executes and what business function justifies it.

That is the standard GrowthFlint applies across WordPress Website Development and Website Maintenance & Performance: protect the critical path first, then add capability without quietly turning every page into a checkout, analytics dashboard and animation engine at the same time.