Performance budgets are defined during the technical discovery phase before design begins, establishing strict ceilings for page weight, load timings, and asset counts.
The Technology department calibrates these constraints against your target audience, device profiles, and delivery requirements to ensure consistent site speed.
1. Baseline analysis and scoping
Setting a performance budget begins with establishing realistic technical parameters for the build. Rather than applying generic benchmarks, the Technology department analyses your project specifications alongside your commercial objectives.
For bespoke work, this review occurs within the standard 48-hour quoting window following receipt of a complete brief. For fixed-scope projects, baseline allowances align with the specifications detailed on the packages page.
The Technology department assesses three operational criteria: - Audience context: Typical network conditions (e.g., mobile 4G networks versus fast broadband) and user hardware constraints. - Page architecture: Template complexity, asset density, and the number of dynamic elements required per view. - Core Web Vitals targets: Target ceilings for Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).
2. Allocation of metric thresholds
Once the baseline is verified, we establish quantitative limits categorised across three distinct tiers:
1. Milestone timings: Strict target times for user-centric events, typically specifying an LCP under 2.5 seconds on simulated average mobile hardware. 2. Total asset budgets: Hard limits on transfer size. A standard baseline caps initial page payload at 1.2 MB to 1.5 MB uncompressed, with compressed initial transfer strictly managed under 500 KB. 3. Granular file-type limits: Individual allocations for script execution, styling, and typography. JavaScript payloads are routinely capped at 150 KB to 250 KB compressed, font files to two families subsetted for required glyphs, and structural CSS restricted to under 50 KB.
These metrics are formally documented in your technical specification prior to asset creation.
3. What the client must supply
To ensure budgets accurately reflect your operational reality, you must provide specific telemetry and third-party requirements before the Technology department finalises the metrics:
- Audience demographics: Analytics exports showing device breakdown (desktop versus mobile percentages) and primary geographic locations.
- Third-party scripts: A definitive inventory of marketing tags, tracking pixels, analytics suites, and live chat widgets required at launch. Third-party code is the leading cause of budget failure.
- Critical business assets: Uncompressed master assets, brand typefaces (with appropriate web licensing), and bespoke media requirements that cannot be substituted.
All files and requirements should be submitted directly via the Ask Xylo chat on this portal during our working hours (Monday to Thursday, 09:00–17:00 GMT).
4. Enforcement during production
The Technology department and Creative department work concurrently to prevent performance degradation throughout delivery:
- Design phase: Creative uses the budget to determine asset complexity. If high-resolution video or complex canvas animations are planned, static imagery or typographic weights elsewhere on the template must be reduced.
- Development phase: Automated continuous integration (CI) tests run against every build. If a pull request adds code that pushes the compressed bundle size or simulated load time over the agreed ceiling, the deployment pipeline halts.
5. Budget breaches and trade-offs
When a requested feature or third-party integration threatens to breach the budget, production stops on that component until a resolution is agreed. There are three potential paths:
1. Refactor and optimise: The Technology department re-evaluates asset loading patterns, moving third-party scripts to server-side execution, deferring non-essential assets, or converting media to modern formats such as AVIF and WebP. 2. Asset trade-off: If an external library or custom interaction must remain, an equivalent payload is removed elsewhere—such as eliminating an auxiliary web font or simplifying page layout. 3. Formal budget revision: If business requirements dictate exceeding the original limit, a revised specification must be formally agreed in writing through Operations & Client Services. Note that expanding technical scope midway through development may alter scheduled delivery timelines.
Deposits are non-refundable once your production slot is held. Before work begins, sums not yet earned are refunded pro rata; after work begins, completed work and booked time are charged. Defects are fixed free of charge within the acceptance window. The full terms are on the Refund Policy page of the main site.
6. Implementation checklist
Review this checklist before development begins:
- [ ] Device breakdown and geographic analytics provided.
- [ ] Complete inventory of third-party tags and analytics supplied.
- [ ] Core Web Vitals ceilings (LCP, INP, CLS) approved in specification.
- [ ] Initial bundle and asset transfer caps locked.
- [ ] Font subsets and required weights confirmed.
- [ ] Automated CI performance checks active in repository.