Website · THE NO-PANIC PLAN
Set a website performance budget and check Core Web Vitals
A performance budget turns speed goals into decisions the team can review before new code or assets ship. This workflow sets separate limits for important page templates, combines resource-size budgets with user-centered metrics, runs repeatable lab checks, and then compares them with field data. Current Core Web Vitals use LCP, INP, and CLS; Google's recommended good thresholds are evaluated at the 75th percentile and segmented by mobile and desktop. Lighthouse lab runs can identify regressions before launch but cannot measure real-user INP. Nirmion's Performance Budget Builder creates a reviewable budget document, and its Image Compressor locally compresses still images; neither measures the site or installs changes.
MISSION Set per-template performance limits, test representative pages in the lab, optimize oversized still images where appropriate, and compare results with real-user Core Web Vitals after launch.
Build a performance budget and test a representative pageTHE REAL-WORLD BIT
What happens outside this browser tab?
Choose representative page templates and user journeys; collect a baseline and audience conditions; define independent resource and Core Web Vitals targets; generate and review a budget; measure in repeatable lab tests; compress suitable still images and preserve visual quality; add regression checks to the build; then monitor real-user field metrics after release and revise limits from evidence.
YOUR CHECKLIST, WITH FEWER DRAMATIC SIGHES
One step at a time.
Follow the order below. If a step names a Nirmion tool, its link is right there with it.
- 01
Choose page templates and performance priorities
List the page types that matter most to users, such as home, search, product, article, and checkout, and choose representative URLs or fixtures for each. Record the important action and largest visible content on each template so teams do not optimize a page-weight number while harming the task. Note the supported mobile and desktop devices, network conditions, locales, logged-in state, and third-party dependencies. Performance budgets should be specific to the content and user experience of each page type, not copied unchanged across the whole site. (Sources 1, 2)
Evidence:web.dev: Performance Budgets 101 - 02
Measure a baseline in field and lab data
Before setting limits, collect current evidence for each template. Use available real-user monitoring, Chrome UX Report/PageSpeed Insights, or Search Console to understand field performance by device; separately run repeatable Lighthouse or DevTools tests in a documented environment for pre-release diagnosis. Record tool version, browser, device emulation, network settings, cache state, URL, and date. Field and lab values answer different questions: lab tests are controlled and useful for catching regressions, while field data reflects actual devices, networks, and interactions. A new site with no field data should label estimates as provisional and review them after real usage begins. (Sources 1, 3, 4)
- 03
Set separate limits for user experience and page resources
Agree on measurable targets with product, design, and engineering owners. For current Core Web Vitals, Google's recommended good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1 for the 75th percentile of page loads, segmented by mobile and desktop. Pair those field goals with resource budgets such as JavaScript bytes, image bytes, font count, or third-party requests on critical templates. Treat quantity budgets as leading constraints, not proof of a fast experience. Select stricter or different internal limits from your audience, baseline, and business requirements; avoid presenting one generic target as a guarantee. (Sources 1, 2)
- 04
Create and review a versioned performance budget
Use Nirmion's Performance Budget Builder to create a bounded, reviewable budget with the template, metrics, units, thresholds, environment assumptions, owner, and review date. Have the team check that every limit is measurable and that the budget still permits required content, accessibility, security, and product behavior. The tool produces a document; it does not run Lighthouse, inspect bundle output, monitor users, or enforce thresholds in CI. Store the approved budget next to the site configuration and specify who can approve exceptions when a new feature exceeds a limit. (Sources 2, 3)
- 05
Run repeatable lab checks and investigate regressions
Run the same lab procedure on each representative template before and after a change. Use Lighthouse or DevTools to inspect loading, layout shifts, and resource costs; compare the report with the matching page budget and investigate large regressions before release. Lighthouse does not simulate user input for field INP; its Total Blocking Time can help diagnose responsiveness but is not the same metric. Use a controlled test setup and enough repeated runs to understand variability instead of treating a single score as a stable fact. Keep report artifacts and tie each regression to a change owner. (Sources 1, 3, 4)
- 06
Reduce suitable image bytes without damaging the asset
Inspect large still-image resources and confirm whether each is necessary, correctly sized for its display, and served in a suitable format. For a JPEG, PNG, or WebP still image where lossy compression is acceptable, use Nirmion's Image Compressor on a non-sensitive authorized copy, compare output size, and visually review detail, text, transparency, and color before replacing the source. Keep originals and test responsive variants where the page needs different sizes. Compression changes the image file; it does not resize page layout, generate srcset markup, optimize SVG or animation, update your CDN, or guarantee an LCP improvement. (Sources 5, 6)
- 07
Enforce budgets in delivery and monitor real users
Add automated checks for measurable resource limits and lab regressions to the build or release pipeline, with a documented exception path. After launch, collect real-user LCP, INP, and CLS across the devices and pages that matter; review the 75th percentile and investigate template-level outliers. Compare field trends with lab reports and avoid treating Lighthouse as a substitute for field monitoring. Revisit limits when page features, traffic, or user devices change, and keep decision history so the budget remains a useful product constraint rather than a stale score target. (Sources 1, 2, 3, 4)
THE HELPER CREW
Tools for the fiddly bits.
These are the currently published Nirmion tools matched to this guide. Open a tool page for its accepted inputs and limits.
RECEIPTS, PLEASE
Sources & review notes
Each source is linked to the steps it supports. Open it to check its scope and current guidance.
Source checked 2026-10-10